From isis-wg-admin@spider.juniper.net Wed Dec 13 16:01: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 QAA21451 for ; Wed, 13 Dec 2000 16:01:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA75710; Wed, 13 Dec 2000 13:23:04 -0800 (PST) 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 NAA75698 for ; Wed, 13 Dec 2000 13:22:03 -0800 (PST) From: bneal@broadwing.com X-JNPR-Received-From: outside Received: from metconnect.ixc-comm.com (mx1.broadwinginc.com [38.244.111.5]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id MAA42085 for ; Wed, 13 Dec 2000 12:56:47 -0800 (PST) (envelope-from bneal@broadwing.com) Received: by metconnect.ixc-comm.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 14:56:46 -0600 Message-ID: <8E9322ACF085D311918E00805FE6CEE702E7B1F7@metexch3.ixc-comm.com> To: isis-wg@juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C06547.33D00C90" Subject: [Isis-wg] Draft Submission Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Dec 2000 14:56:45 -0600 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_000_01C06547.33D00C90 Content-Type: text/plain; charset="iso-8859-1" Members and Chairpersons of the IS-IS for IP Internets Working Group, My name is Brad Neal, and I would like to submit this draft to the list for review. Please take a moment to examine it, and reply with you thoughts. Best regards, Brad Neal Broadwing Communications Abstract: This draft describes an extension to Integrated IS-IS, which can be used to pass additional information among routers within an IS-IS domain that can aid in policy administration. This extension is roughly similar in function to the BGP communities attribute; in that it provides a mechanism to associate a routed prefix with some administrative group, such that an administrator may define a routing policy for that group. ~~~~~~~~~~~~~~~~~ <> ------_=_NextPart_000_01C06547.33D00C90 Content-Type: text/plain; name="draft-neal-isis-policy-ext-00.txt" Content-Disposition: attachment; filename="draft-neal-isis-policy-ext-00.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force Brad Neal Internet Draft (Broadwing Communications) Expiration Date: June 2001 November 2000 A Policy-Group Sub-TLV for IS-IS Extended IP Reachability=20 Information draft-neal-isis-policy-ext-00.txt 1. Status of this Document 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 obsolete 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. 2. Abstract This draft describes an extension to Integrated IS-IS, which can be "draft-neal-isis-policy-ext-00.txt" 176 lines, 7340 characters written [bneal@kenny bneal]$ cat draft-neal-isis-policy-ext-00.txt Internet Engineering Task Force Brad Neal Internet Draft (Broadwing Communications) Expiration Date: June 2001 November 2000 An Policy-Group Sub-TLV for IS-IS Extended IP Reachability=20 Information draft-neal-isis-policy-ext-00.txt 1. Status of this Document This document is an Internet-Draft and is in full conformance with all=20 provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task=20 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=20 and may be updated, replaced, or obsolete by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at=20 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. 2. Abstract This draft describes an extension to Integrated IS-IS, which can be=20 used to pass additional information among routers within an IS-IS=20 domain that can aid in policy administration. This extension is=20 roughly similar in function to the BGP communities attribute; in that=20 it provides a mechanism to associate a routed prefix with some=20 administrative group, such that an administrator may define a routing=20 policy for that group. 3. Introduction It is sometimes necessary for a network administrator to control the=20 distribution of reachability information in a routing domain according=20 to some policy. In particular, an administrator may wish control which = active=20 routes are advertised to various neighbors, or which active routes are=20 redistributed into other protocols. There are several syntaxes for=20 routing-policy specification among vendors, but most consist of an=20 ordered list of 'match' conditions and 'set' actions that is applied to = a routing process. Most implementations allow a match condition to be a = simple list of statically defined prefixes, or some attribute=20 associated with a prefix in the context of the protocol through which=20 it was learned (e.g., "match all area A routes, and redistribute=20 into..."). In general, it is more preferable to match some transitive=20 attribute of a prefix, rather than define a static list as a match=20 condition. This is due to the administrative complexity of maintaining = said list at every node that must apply that policy. Sometimes an=20 administrator may wish to match a group of routes with some common=20 logical property. For interdomain routing with BGP, [COMM] defines a=20 protocol extension that is helpful in this regard; and has, in=20 practical implementation, come to be of significant utility. 4. Policy-Group Sub-TLV There does not currently exist a mechanism in the IS-IS protocol=20 specification [ISIS-IP], or in the proposed standard [ISIS-TE] that=20 allows an us to arbitrarily identify an IP prefix as a member of an=20 administratively defined group. In most current implementations; if an=20 administrator wishes to match routes with some common property, that=20 administrator must define a static list of routed prefixes as a match=20 condition. We suggest the definition of an "Policy-Group" extension to=20 the IS-IS Extended IP Reachability Information" TLV which will address=20 this. =20 An administrator may define an interesting property and associate it=20 with a policy-group. A policy-group identifier is, in turn, associated=20 with an IP prefix with that property and 'sticks' to the IP=20 reachability information for that prefix as it is flooded throughout=20 the routing domain.=20 A complient ISIS implementation... - MUST be able to assign a policy group to any IP prefix,=20 for which it generates an extended IP reachability information TLV, - MUST be able to assign more than one tag to a particular prefix, = and.. - SHOULD be able to rewrite or remove the policy-group of a=20 received prefix according to its own policy. =20 The policy-tag(s) is/are a sub-TLV carried within the Extended IP=20 reachability=20 TLV, whose TLV type is 135[ISIS-TE]. A tag is represented as a 16-bit=20 value, so the length portion of the sub-TLV will be 16 times the number = of tags asscociated with the ip prefix. 5. Operation Consider the network in figure 1. We wish to "leak" L1 prefixes [LEAK]=20 with some property, A, from L2 to the L1 router R1. Without=20 policy-groups, there is no way for R2 to know property A prefixes from=20 property B prefixes.=20 R2--------R3--------R4 =20 L2 / \ =20 - - - /- - - - - - - - - - - \- - -=20 L1 / \ =20 R1 R5----1.1.1.0/24 (A) | =20 | =20 1.1.2.0/24 (B) Figure 1 We associate policy-group 100 with property A, and have R5 attach that=20 value, in a sub-TLV, to the IP extended reachability information TLV=20 for prefix 1.1.1.0/24. R2 has a policy in place to "match prefixes with = policy-group 100, and leak to L1." The previous example is rather simplistic, and it seems that it would=20 be=20 just as easy for R2 simply to match the prefix 1.1.1.0/24. However if=20 there are a large number of routers that need to apply some policy=20 according to property A and large number of "A" prefixes, this=20 mechanism can be quite helpful. It is appropriate 6. Security Considerations This documents raises no new security issues for IS-IS. 7. References [COMM] R. Chandra, P Traina, "BGP Communities Attribute", RFC 1997,=20 August 1996 [ISIS-IP] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual=20 Environments" RFC 1195, December 1990 [ISIS-TE] Tony Li, Henk Smit, "IS-IS extensions for Traffic=20 Engineering", work in progress [LEAK] T. Li, T Przygienda, H. Smit, "Domain-wide Prefix Distribution=20 with Two-Level IS-IS", RFC 2966, October 2000 8. Author's Address Postal: Brad Neal Broadwing Communications 1835 Kramer Lane - Suite 100 Austin, Texas 78758 USA Email: bneal@broadwing.com Full Copyright Statement "Copyright (C) The Internet Society (March 2000). All Rights Reserved.=20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it or = assist in its implementation may be prepared, copied, published and=20 distributed, in whole or in part, without restriction of any kind,=20 provided that the above copyright notice and this paragraph are=20 included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing the = copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of developing=20 Internet standards in which case the procedures for copyrights defined=20 in the Internet Standards process must be followed, or as required to=20 translate it into languages other than English. The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns. ------_=_NextPart_000_01C06547.33D00C90-- _______________________________________________ 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 Dec 14 15: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 PAA12606 for ; Thu, 14 Dec 2000 15:49:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA81344; Thu, 14 Dec 2000 13:11:03 -0800 (PST) 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 NAA81332 for ; Thu, 14 Dec 2000 13:10:40 -0800 (PST) X-JNPR-Received-From: outside Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id MAA73832 for ; Thu, 14 Dec 2000 12:45:16 -0800 (PST) (envelope-from prz@net4u.net4u.ch) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id VAA24542; Thu, 14 Dec 2000 21:40:13 +0100 From: Tony Przygienda Message-Id: <200012142040.VAA24542@net4u.net4u.ch> Subject: Re: [Isis-wg] Draft Submission In-Reply-To: <8E9322ACF085D311918E00805FE6CEE702E7B1F7@metexch3.ixc-comm.com> from "bneal@broadwing.com" at "Dec 13, 2000 2:56:45 pm" To: bneal@broadwing.com Cc: isis-wg@juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Dec 2000 21:40:13 +0100 (MET) Content-Transfer-Encoding: 7bit Brad, looks to me like the OSPF tag pretty much. OSPF tag was generally accepted as good idea in its time. In practical deployment it turned out to not have been really used for anything. That's just my experience, others may disagree here. For your specific problem, I fail somehow to see what significant difference it makes to write policies to tag the prefixes from writing the policies to filter prefixes unless you change IP addresses in your IGP cloud often which is unlikely in IP backbones in my experience. This is _very_ different from the way communities in BGP are often used, e.g. a certain peer is putting communities on all prefixes it learns. Those prefixes are not known a-priori. Given that applying policies per neighbor in IGP is a really bad idea IMHO, the problems solved are very different and I'm not convinced the problem you mention is very relevant in ISIS. -- 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 Dec 15 21:56: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 VAA04224 for ; Fri, 15 Dec 2000 21:56:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA88440; Fri, 15 Dec 2000 19:18:07 -0800 (PST) Received: from www-004.pocketmail.com ([206.79.76.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA43400 for ; Fri, 8 Dec 2000 02:20:17 -0800 (PST) Received: (from nobody@localhost) by www-004.pocketmail.com (8.9.3/8.9.3) id RAA40923; Thu, 21 Sep 2000 17:17:35 -0700 (PDT) (envelope-from nobody) Message-Id: <200009220017.RAA40923@www-004.pocketmail.com> To: isis-wg@spider.juniper.net From: Edward Chang CC: mpls@uu.net X-Mailer: PHP4.0RC1 Subject: [Isis-wg] Question on DCC Architecture Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Sep 2000 17:17:35 -0700 (PDT) Hi, I am a developer of DCC for an NE. I have few questions regarding DCC architecture. In the system that I am developing, the network between GNE and EMS/OS is IP, it is naturally for me to consider TCP/IP on the top of DCC. This architecture makes the DCN including DCC consistent, and makes the DCC implementation easy. However, when I read the SIF document SIF-018-1998 and TELCO document GR-253-CORE, I found that the OSI on DCC is a standard and TCP/IP on DCC is not. Here comes my question: Is there any standard about TCP/IP on DCC that I don't know? If there is no such standard, is any one or company implementing such architecture of DCC? If there is no such standard, is any one or company writing such standard? I appreciate if you could give me some related information. Thank you in advance. Edward _______________________________________________ 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 Dec 16 00:54: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 AAA12924 for ; Sat, 16 Dec 2000 00:54:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA89179; Fri, 15 Dec 2000 22:17:04 -0800 (PST) Received: from alpha-tony.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA89167 for ; Fri, 15 Dec 2000 22:16:49 -0800 (PST) Received: (from tli@localhost) by alpha-tony.procket.com (8.9.3/8.9.3) id VAA03358; Fri, 15 Dec 2000 21:50:45 -0800 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tony.procket.com: tli set sender to tli@alpha-tony.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14907.693.141245.416611@alpha-tony.procket.com> To: Edward Chang Cc: isis-wg@spider.juniper.net Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <200009220017.RAA40923@www-004.pocketmail.com> References: <200009220017.RAA40923@www-004.pocketmail.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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Dec 2000 21:50:45 -0800 (PST) Content-Transfer-Encoding: 7bit Ed, Welcome to the wonderful world of SONET. | I am a developer of DCC for an NE. I have few questions regarding DCC | architecture. | | In the system that I am developing, the network between GNE and EMS/OS | is IP, it is naturally for me to consider TCP/IP on the top of DCC. This | architecture makes the DCN including DCC consistent, and makes the DCC | implementation easy. However, when I read the SIF document SIF-018-1998 | and TELCO document GR-253-CORE, I found that the OSI on DCC is a | standard and TCP/IP on DCC is not. Here comes my question: | | Is there any standard about TCP/IP on DCC that I don't know? Nope. It would make sense, wouldn't it? | If there is no such standard, is any one or company implementing such | architecture of DCC? If there is no such standard, is any one or | company writing such standard? I'm unaware of anyone writing such a document nor is it particularly clear as to where this type of feature should be standardized. It would make some sense to do this in the IETF, but it's certainly not the only possible place. I do know that many folks have discussed doing this. Tony p.s. I've excluded MPLS, as I don't see the relevance... _______________________________________________ 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 Dec 16 15:40: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 PAA16193 for ; Sat, 16 Dec 2000 15:40:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA94639; Sat, 16 Dec 2000 13:02:04 -0800 (PST) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA94627 for ; Sat, 16 Dec 2000 13:01:10 -0800 (PST) Received: from vjorge-dsl1.cisco.com (vjorge-dsl1.cisco.com [10.21.134.162]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA03860; Sat, 16 Dec 2000 12:34:32 -0800 (PST) From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <2518.001216@cisco.com> To: Tony Li CC: Edward Chang , isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture In-reply-To: <14907.693.141245.416611@alpha-tony.procket.com> References: <14907.693.141245.416611@alpha-tony.procket.com> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 16 Dec 2000 12:26:23 -0800 Content-Transfer-Encoding: 7bit Tony, Ed A number of companies working in the SONET area already use or are planning to use DCC for IP control plane [I put MPLS list back ;), since this question is related to GMPLS and OTN-related work]. There are two types of IP encapsulation on DCC that I know of: LAP-D and PPP/HDLC. We use the second one in our SONET products. I think writing up an IETF document describing this would make sense. -- Alex Zinin Friday, December 15, 2000, 9:50 PM, Tony Li wrote: > Ed, > Welcome to the wonderful world of SONET. > | I am a developer of DCC for an NE. I have few questions regarding DCC > | architecture. > | > | In the system that I am developing, the network between GNE and EMS/OS > | is IP, it is naturally for me to consider TCP/IP on the top of DCC. This > | architecture makes the DCN including DCC consistent, and makes the DCC > | implementation easy. However, when I read the SIF document SIF-018-1998 > | and TELCO document GR-253-CORE, I found that the OSI on DCC is a > | standard and TCP/IP on DCC is not. Here comes my question: > | > | Is there any standard about TCP/IP on DCC that I don't know? > Nope. It would make sense, wouldn't it? > | If there is no such standard, is any one or company implementing such > | architecture of DCC? If there is no such standard, is any one or > | company writing such standard? > I'm unaware of anyone writing such a document nor is it particularly clear > as to where this type of feature should be standardized. It would make > some sense to do this in the IETF, but it's certainly not the only possible > place. > I do know that many folks have discussed doing this. > Tony > p.s. I've excluded MPLS, as I don't see the relevance... > _______________________________________________ > 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 Sat Dec 16 17:23:59 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 RAA01370 for ; Sat, 16 Dec 2000 17:23:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA95114; Sat, 16 Dec 2000 14:46:03 -0800 (PST) Received: from interceptor.mahinetworks.com (216-174-224-194.atgi.net [216.174.224.194]) by external.juniper.net (8.9.3/8.9.3) with SMTP id OAA95102 for ; Sat, 16 Dec 2000 14:45:54 -0800 (PST) Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Sat, 16 Dec 2000 14:22:11 -0800 (Pacific Standard Time) Received: by main.mahinetworks.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Dec 2000 14:19:10 -0800 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C90FD5D3@main.mahinetworks.com> From: Yuchen Zhou To: "'Tony Li'" , Edward Chang Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on DCC Architecture 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 16 Dec 2000 14:19:02 -0800 On a related thread to Ed's question ... You can use mediation devices to network EMS/OS with GNE/NE (which run OSI over DCC) over DCN. On the other hand, there are also some proposals to tunnel IP through OSI networks. Regards. Yuchen -----Original Message----- From: Tony Li [mailto:tli@procket.com] Sent: Friday, December 15, 2000 9:51 PM To: Edward Chang Cc: isis-wg@spider.juniper.net Subject: [Isis-wg] Question on DCC Architecture Ed, Welcome to the wonderful world of SONET. | I am a developer of DCC for an NE. I have few questions regarding DCC | architecture. | | In the system that I am developing, the network between GNE and EMS/OS | is IP, it is naturally for me to consider TCP/IP on the top of DCC. This | architecture makes the DCN including DCC consistent, and makes the DCC | implementation easy. However, when I read the SIF document SIF-018-1998 | and TELCO document GR-253-CORE, I found that the OSI on DCC is a | standard and TCP/IP on DCC is not. Here comes my question: | | Is there any standard about TCP/IP on DCC that I don't know? Nope. It would make sense, wouldn't it? | If there is no such standard, is any one or company implementing such | architecture of DCC? If there is no such standard, is any one or | company writing such standard? I'm unaware of anyone writing such a document nor is it particularly clear as to where this type of feature should be standardized. It would make some sense to do this in the IETF, but it's certainly not the only possible place. I do know that many folks have discussed doing this. Tony p.s. I've excluded MPLS, as I don't see the relevance... _______________________________________________ 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 Sun Dec 17 02:54: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 CAA23980 for ; Sun, 17 Dec 2000 02:54:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA97320; Sun, 17 Dec 2000 00:16:04 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA97308 for ; Sun, 17 Dec 2000 00:15:44 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id IAA02178; Sun, 17 Dec 2000 08:44:34 +0100 From: Tony Przygienda Message-Id: <200012170744.IAA02178@net4u.net4u.ch> Subject: Re: [Isis-wg] Question on DCC Architecture In-Reply-To: <2518.001216@cisco.com> from Alex Zinin at "Dec 16, 2000 12:26:23 pm" To: azinin@cisco.com Cc: tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 17 Dec 2000 08:44:34 +0100 (MET) Content-Transfer-Encoding: 7bit > > Tony, Ed > > A number of companies working in the SONET area already use or are > planning to use DCC for IP control plane [I put MPLS list back ;), > since this question is related to GMPLS and OTN-related work]. > > There are two types of IP encapsulation on DCC that I know of: > LAP-D and PPP/HDLC. We use the second one in our SONET products. > > I think writing up an IETF document describing this would make sense. First, this smells much like ISO thing to do so we'd need an agreement/liason first from their side. That is obviously only worth pursuiting if we have authors commiting to provide the cycles first. Second, which workgroup ? One of the MPLS offsprings such as GSMP ;-) ? What about a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't be surprised if the joke find takers ;-) ? thanks -- 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 Sun Dec 17 10:52: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 KAA22095 for ; Sun, 17 Dec 2000 10:52:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA99338; Sun, 17 Dec 2000 08:15:04 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA99323 for ; Sun, 17 Dec 2000 08:14:45 -0800 (PST) Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA08674; Sun, 17 Dec 2000 10:48:59 -0500 (EST) Received: from jlearman-nt (jlearman-dsl4.cisco.com [10.83.2.141]) by dingdong.cisco.com (Mirapoint) with SMTP id ACX03663; Sun, 17 Dec 2000 10:48:59 -0500 (EST) Message-Id: <4.1.20001217101926.00a47100@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Edward Chang , isis-wg@spider.juniper.net From: Jeff Learman Subject: Re: [Isis-wg] Question on DCC Architecture Cc: alanr@cisco.com In-Reply-To: <200009220017.RAA40923@www-004.pocketmail.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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 17 Dec 2000 10:48:52 -0500 Edward, This issue has been discussed at NSIF (Network and Services Integration Forum, "http://www.atis.org/atis/sif/sifhom.htm") and at T1M1 (see www.t1.org) meetings, under the discussion concerning an IP profile for TMN, which does not currently exist other than for RFC-1006). T1M1 is normally for technology-independent aspects of telecom management; the more limited subject of IP for SONET DCC would normally be handled by T1X1, which handles technology-dependent aspects. If you are marketing your equipment for an IP infrastructure, IP/PPP/HDLC is the best solution, in my opionion. If you are marketing your equipment in circuit-switched world and you need interoperability with existing Telcordia- and TMN-compliant SONET NEs in the same ring, then you will need to support OSI, at least at the network layer and below. For IP/PPP/HDLC, be sure to implement the draft RFC, Three-Way Handshake for IS-IS Point-to-Point Adjacencies, "http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-03.txt". In the latter case (interoperability required), it is still possible for your NE to be IP-managed, using IP/CLNP encapsulation, but note that there are nontrivial routing issues. Best Regards, Jeff Note: Opinions expressed are my own and do not necessarily represent the opinions of my empoyer. At 05:17 PM 09/21/2000 -0700, Edward Chang wrote: >Hi, > >I am a developer of DCC for an NE. I have few questions regarding DCC >architecture. > >In the system that I am developing, the network between GNE and EMS/OS is IP, >it is naturally for me to consider TCP/IP on the top of DCC. This architecture >makes the DCN including DCC consistent, and makes the DCC implementation easy. >However, when I read the SIF document SIF-018-1998 and TELCO document >GR-253-CORE, I found that the OSI on DCC is a standard and TCP/IP on DCC is >not. Here comes my question: > >Is there any standard about TCP/IP on DCC that I don't know? >If there is no such standard, is any one or company implementing such >architecture of DCC? >If there is no such standard, is any one or company writing such standard? > >I appreciate if you could give me some related information. > >Thank you in advance. > >Edward > >_______________________________________________ >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 Sun Dec 17 12:59:14 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 MAA12877 for ; Sun, 17 Dec 2000 12:59:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA99879; Sun, 17 Dec 2000 10:22:04 -0800 (PST) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA99867 for ; Sun, 17 Dec 2000 10:21:10 -0800 (PST) Received: from vjorge-dsl1.cisco.com (vjorge-dsl1.cisco.com [10.21.134.162]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA13001; Sun, 17 Dec 2000 09:53:54 -0800 (PST) From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <0406.001217@cisco.com> To: Tony Przygienda CC: tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture In-reply-To: <200012170744.IAA02178@net4u.net4u.ch> References: <200012170744.IAA02178@net4u.net4u.ch> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 17 Dec 2000 09:45:45 -0800 Content-Transfer-Encoding: 7bit Tony, >> A number of companies working in the SONET area already use or are >> planning to use DCC for IP control plane [I put MPLS list back ;), >> since this question is related to GMPLS and OTN-related work]. >> >> There are two types of IP encapsulation on DCC that I know of: >> LAP-D and PPP/HDLC. We use the second one in our SONET products. >> >> I think writing up an IETF document describing this would make sense. > First, this smells much like ISO thing to do so we'd need an agreement/liason > first from their side. That is obviously only worth pursuiting if we have > authors commiting to provide the cycles first. Hmmm... why do you think specification of *IP* encapsulation over SONET DCC using "PPP over HDLC-like framing" is something ISO should do? > Second, which workgroup ? One of the MPLS offsprings such as GSMP ;-) ? What about > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't be surprised > if the joke find takers ;-) ? Definitely not me ;) I think some kind of individual submission should be ok. I guess the Internet Area is the one that logically hosts it. Thanks, Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Dec 17 21:28:15 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 VAA18859 for ; Sun, 17 Dec 2000 21:28:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA02045; Sun, 17 Dec 2000 18:51:04 -0800 (PST) Received: from mail.packetcom.com (sjca.packetcom.com [63.108.173.130]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA02033 for ; Sun, 17 Dec 2000 18:50:55 -0800 (PST) Received: by mail.packetcom.com with Internet Mail Service (5.5.2650.21) id ; Sun, 17 Dec 2000 18:22:52 -0800 Message-ID: From: Riad Hartani To: "'Alex Zinin'" , Tony Przygienda Cc: tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: RE: [Isis-wg] Question on DCC Architecture 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 17 Dec 2000 18:22:51 -0800 On this subject, the OIF UNI 1.0 specification (submitted for last call) describes, among other things, how to use SONET Line and/or Section DCC overhead bytes to transport various IP control plane messages (called IP Control Channel -IPCC-). For discovery of information required by the IP control plane, both DCC or J0 bytes may be used in the actual proposal. For the IP control plane, the proposal requires IP packets to be encapsulated in PPP over HDLC-like framing with bit stuffing format. The spec also describes various aspects related to the selection and maintenance of IPCC parameters, as well as other ways of carrying IP control information in Sonet/WDM environments. Hope this helps, Riad > -----Original Message----- > From: Alex Zinin [mailto:azinin@cisco.com] > Sent: Sunday, December 17, 2000 9:46 AM > To: Tony Przygienda > Cc: tli@procket.com; echang@pocketmail.com; > isis-wg@spider.juniper.net; > skatukam@cisco.com; mpls@UU.NET > Subject: Re: [Isis-wg] Question on DCC Architecture > > > > Tony, > > >> A number of companies working in the SONET area already use or are > >> planning to use DCC for IP control plane [I put MPLS list back ;), > >> since this question is related to GMPLS and OTN-related work]. > >> > >> There are two types of IP encapsulation on DCC that I know of: > >> LAP-D and PPP/HDLC. We use the second one in our SONET products. > >> > >> I think writing up an IETF document describing this would > make sense. > > > First, this smells much like ISO thing to do so we'd need > an agreement/liason > > first from their side. That is obviously only worth > pursuiting if we have > > authors commiting to provide the cycles first. > > Hmmm... why do you think specification of *IP* encapsulation > over SONET DCC > using "PPP over HDLC-like framing" is something ISO should do? > > > Second, which workgroup ? One of the MPLS offsprings such > as GSMP ;-) ? What about > > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't > be surprised > > if the joke find takers ;-) ? > > Definitely not me ;) > > I think some kind of individual submission should be ok. I guess > the Internet Area is the one that logically hosts it. > > Thanks, > > Alex. > > > _______________________________________________ > 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 Sun Dec 17 22:08: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 WAA20054 for ; Sun, 17 Dec 2000 22:08:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA02271; Sun, 17 Dec 2000 19:31:04 -0800 (PST) Received: from femail7.sdc1.sfba.home.com (femail7.sdc1.sfba.home.com [24.0.95.87]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA02228 for ; Sun, 17 Dec 2000 19:26:23 -0800 (PST) Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail7.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001218030037.QTZA16755.femail7.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Sun, 17 Dec 2000 19:00:37 -0800 Message-ID: <035001c06903$6c6bdb00$1cd01318@frmt1.sfba.home.com> Reply-To: "Manohar Ellanti" From: "Manohar Ellanti" To: "Riad Hartani" , "'Alex Zinin'" , "Tony Przygienda" Cc: , , , , References: Subject: Re: [Isis-wg] Question on DCC Architecture Organization: @home 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 07:01:37 -0800 Content-Transfer-Encoding: 7bit I think there are two aspects to the IP over SONET DCC. One is UNI Signaling for the purpose of CPE-ONE Signaling and possibly NNI Signaling and the other is DCN (at least that is the term we used and I believe is borrowed from work done in Sonet Interoperability Forum) for EMS/NMS. The latter is something that is discussed quite a bit in SIF and may be in ANSI T1X1 as well. Incase it might help here are some references. 1. Brown, Mike, SIF-AR-9804-055, "Survey of Requirements for IP on the non-DCC DCN," April 15, 1998. 2. Hunt, Christopher J., SIF-AR-9804-058, "TCP/IP DCN Alternatives," April 14, 1998. 3. Jamal, Rashid, SIF-AR-9803-054, "IP On DCN - Sprint's Response," April 14, 1998. 4. Reference architecture proposed at May IP DCN conference call. I think, SIF primarily focused on use of DCC bytes (called as embedded operations channel) for SONET network management plane and not for control plane. IP over PPP over HDLC over DCC bytes as pure network transport mechanism need not be linked with control plane or management plane. I think UNI 1.0 does leave scope for UNI signaling messages to be transported using 1. DCC bytes 2. SPE 3. alternate transport such as UNI over internet reaching the ONE. 4. Ethernet if CPE is co-located with ONE such as in a POP A general informational document drawing inputs from SIF, UNI 1.0 and from other useful dicussions elsewhere might be helpful for IETF community while avoiding re-inventing some of the issues and operational problems expressed already and draws from good inputs in the past of lot of people. Manohar N Ellanti ----- Original Message ----- From: "Riad Hartani" To: "'Alex Zinin'" ; "Tony Przygienda" Cc: ; ; ; ; Sent: Sunday, December 17, 2000 6:22 PM Subject: RE: [Isis-wg] Question on DCC Architecture > On this subject, the OIF UNI 1.0 specification (submitted for last call) > describes, among other things, how to use SONET Line and/or Section DCC > overhead bytes to transport various IP control plane messages (called IP > Control Channel -IPCC-). For discovery of information required by the IP > control plane, both DCC or J0 bytes may be used in the actual proposal. > > For the IP control plane, the proposal requires IP packets to be > encapsulated in PPP over HDLC-like framing with bit stuffing format. The > spec also describes various aspects related to the selection and maintenance > of IPCC parameters, as well as other ways of carrying IP control information > in Sonet/WDM environments. > > Hope this helps, > > Riad > > > -----Original Message----- > > From: Alex Zinin [mailto:azinin@cisco.com] > > Sent: Sunday, December 17, 2000 9:46 AM > > To: Tony Przygienda > > Cc: tli@procket.com; echang@pocketmail.com; > > isis-wg@spider.juniper.net; > > skatukam@cisco.com; mpls@UU.NET > > Subject: Re: [Isis-wg] Question on DCC Architecture > > > > > > > > Tony, > > > > >> A number of companies working in the SONET area already use or are > > >> planning to use DCC for IP control plane [I put MPLS list back ;), > > >> since this question is related to GMPLS and OTN-related work]. > > >> > > >> There are two types of IP encapsulation on DCC that I know of: > > >> LAP-D and PPP/HDLC. We use the second one in our SONET products. > > >> > > >> I think writing up an IETF document describing this would > > make sense. > > > > > First, this smells much like ISO thing to do so we'd need > > an agreement/liason > > > first from their side. That is obviously only worth > > pursuiting if we have > > > authors commiting to provide the cycles first. > > > > Hmmm... why do you think specification of *IP* encapsulation > > over SONET DCC > > using "PPP over HDLC-like framing" is something ISO should do? > > > > > Second, which workgroup ? One of the MPLS offsprings such > > as GSMP ;-) ? What about > > > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't > > be surprised > > > if the joke find takers ;-) ? > > > > Definitely not me ;) > > > > I think some kind of individual submission should be ok. I guess > > the Internet Area is the one that logically hosts it. > > > > Thanks, > > > > Alex. > > > > > > _______________________________________________ > > 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 Sun Dec 17 22:15:59 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 WAA20132 for ; Sun, 17 Dec 2000 22:15:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA02361; Sun, 17 Dec 2000 19:39:05 -0800 (PST) Received: from boyle.eng.level3.com (rdu162-225-174.nc.rr.com [24.162.225.174]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA02349 for ; Sun, 17 Dec 2000 19:38:23 -0800 (PST) Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id UAA01102; Sun, 17 Dec 2000 20:17:52 -0700 X-Authentication-Warning: boyle.eng.level3.com: jboyle owned process doing -bs From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: Tony Przygienda cc: azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net, ip-optical@lists.bell-labs.com Subject: Re: [Isis-wg] Question on DCC Architecture In-Reply-To: <200012170744.IAA02178@net4u.net4u.ch> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 17 Dec 2000 20:17:52 -0700 (MST) Tony, since you threw the bait in the water... Apologies to the ISIS wg, as this clearly isn't their issue. I think this is an important issue, if interoperability between the transmission equipment utilizing the wonderful IP control plane are to actually interoperate (which is a novel concept in some circles). There is a relevant submission in the NSIF (NSIF-0009-038) which says "use PPP" and then hits on some of the TLI/TMN issues. I'd suggest directing any further discussion of this topic to IPO as it is within the current version of their charter. They might be just as happy making sure that the right progress is being made somewhere, in this case, NSIF. Jim (at least I help cut the line :) On Sun, 17 Dec 2000, Tony Przygienda wrote: > > > > Tony, Ed > > > > A number of companies working in the SONET area already use or are > > planning to use DCC for IP control plane [I put MPLS list back ;), > > since this question is related to GMPLS and OTN-related work]. > > > > There are two types of IP encapsulation on DCC that I know of: > > LAP-D and PPP/HDLC. We use the second one in our SONET products. > > > > I think writing up an IETF document describing this would make sense. > > First, this smells much like ISO thing to do so we'd need an agreement/liason > first from their side. That is obviously only worth pursuiting if we have > authors commiting to provide the cycles first. > > Second, which workgroup ? One of the MPLS offsprings such as GSMP ;-) ? What about > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't be surprised > if the joke find takers ;-) ? > > thanks > > -- 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 Sun Dec 17 22:40:59 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 WAA21292 for ; Sun, 17 Dec 2000 22:40:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA02529; Sun, 17 Dec 2000 20:04:04 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA02517 for ; Sun, 17 Dec 2000 20:03:56 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id EAA14186; Mon, 18 Dec 2000 04:32:29 +0100 From: Tony Przygienda Message-Id: <200012180332.EAA14186@net4u.net4u.ch> Subject: Re: [Isis-wg] Question on DCC Architecture In-Reply-To: from Jim Boyle at "Dec 17, 2000 8:17:52 pm" To: jboyle@level3.net (Jim Boyle) Cc: prz@net4u.ch, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net, ip-optical@lists.bell-labs.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 04:32:28 +0100 (MET) Content-Transfer-Encoding: 7bit > > Tony, since you threw the bait in the water... > > Apologies to the ISIS wg, as this clearly isn't their issue. I think > this is an important issue, if interoperability between the > transmission equipment utilizing the wonderful IP control plane are to > actually interoperate (which is a novel concept in some circles). > > There is a relevant submission in the NSIF (NSIF-0009-038) which says > "use PPP" and then hits on some of the TLI/TMN issues. > > I'd suggest directing any further discussion of this topic to IPO > as it is within the current version of their charter. They might be just > as happy making sure that the right progress is being made somewhere, in > this case, NSIF. yepp, I think that was the intention of my e-mail. At least one reader got the meaning between the lines. We have charters to follow here ;-) On the other hand, ISIS-wg has not been unheard of taking outrageous issues that had to be either done very quickly, didn't fit into any other corner of the world or were in the danger of inertia induced death in other, slow moving forums ;-) This one seems to me not being either (maybe yet ;-) thanks -- 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 Mon Dec 18 10:44: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 KAA09840 for ; Mon, 18 Dec 2000 10:44:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05520; Mon, 18 Dec 2000 08:07:03 -0800 (PST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05508 for ; Mon, 18 Dec 2000 08:06:29 -0800 (PST) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id HAA17062; Mon, 18 Dec 2000 07:40:37 -0800 (PST) From: Mike Truskowski Message-Id: <200012181540.HAA17062@diablo.cisco.com> Subject: Re: [Isis-wg] Question on DCC Architecture To: ellanti@home.com ("Manohar Ellanti") Cc: riad@caspiannetworks.com, azinin@cisco.com, prz@net4u.ch, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net In-Reply-To: <035001c06903$6c6bdb00$1cd01318@frmt1.sfba.home.com>; from "Manohar Ellanti" at Dec 18, 100 7:01 am X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 7:40:37 PST For what it is worth, there are NO formal agreements in the NSIF for IP on the DCC and to my knowledge no work in the ITU dealing with the DCC. Mike > > I think there are two aspects to the IP over SONET DCC. One is UNI > Signaling for the purpose of CPE-ONE Signaling and possibly NNI Signaling > and the other is DCN (at least that is the term we used and I believe is > borrowed from work done in Sonet Interoperability Forum) for EMS/NMS. The > latter is something that is discussed quite a bit in SIF and may be in ANSI > T1X1 as well. > > Incase it might help here are some references. > > 1. Brown, Mike, SIF-AR-9804-055, "Survey of Requirements for IP on the > non-DCC DCN," April 15, 1998. > 2. Hunt, Christopher J., SIF-AR-9804-058, "TCP/IP DCN Alternatives," April > 14, 1998. > 3. Jamal, Rashid, SIF-AR-9803-054, "IP On DCN - Sprint's Response," April > 14, 1998. > 4. Reference architecture proposed at May IP DCN conference call. > > I think, SIF primarily focused on use of DCC bytes (called as embedded > operations channel) for SONET network management plane and not for control > plane. IP over PPP over HDLC over DCC bytes as pure network transport > mechanism need not be linked with control plane or management plane. I think > UNI 1.0 does leave scope for UNI signaling messages to be transported using > 1. DCC bytes > 2. SPE > 3. alternate transport such as UNI over internet reaching the ONE. > 4. Ethernet if CPE is co-located with ONE such as in a POP > > A general informational document drawing inputs from SIF, UNI 1.0 and from > other useful dicussions elsewhere might be helpful for IETF community while > avoiding re-inventing some of the issues and operational problems expressed > already and draws from good inputs in the past of lot of people. > > Manohar N Ellanti > > > > ----- Original Message ----- > From: "Riad Hartani" > To: "'Alex Zinin'" ; "Tony Przygienda" > Cc: ; ; > ; ; > Sent: Sunday, December 17, 2000 6:22 PM > Subject: RE: [Isis-wg] Question on DCC Architecture > > > > On this subject, the OIF UNI 1.0 specification (submitted for last call) > > describes, among other things, how to use SONET Line and/or Section DCC > > overhead bytes to transport various IP control plane messages (called IP > > Control Channel -IPCC-). For discovery of information required by the IP > > control plane, both DCC or J0 bytes may be used in the actual proposal. > > > > For the IP control plane, the proposal requires IP packets to be > > encapsulated in PPP over HDLC-like framing with bit stuffing format. The > > spec also describes various aspects related to the selection and > maintenance > > of IPCC parameters, as well as other ways of carrying IP control > information > > in Sonet/WDM environments. > > > > Hope this helps, > > > > Riad > > > > > -----Original Message----- > > > From: Alex Zinin [mailto:azinin@cisco.com] > > > Sent: Sunday, December 17, 2000 9:46 AM > > > To: Tony Przygienda > > > Cc: tli@procket.com; echang@pocketmail.com; > > > isis-wg@spider.juniper.net; > > > skatukam@cisco.com; mpls@UU.NET > > > Subject: Re: [Isis-wg] Question on DCC Architecture > > > > > > > > > > > > Tony, > > > > > > >> A number of companies working in the SONET area already use or are > > > >> planning to use DCC for IP control plane [I put MPLS list back ;), > > > >> since this question is related to GMPLS and OTN-related work]. > > > >> > > > >> There are two types of IP encapsulation on DCC that I know of: > > > >> LAP-D and PPP/HDLC. We use the second one in our SONET products. > > > >> > > > >> I think writing up an IETF document describing this would > > > make sense. > > > > > > > First, this smells much like ISO thing to do so we'd need > > > an agreement/liason > > > > first from their side. That is obviously only worth > > > pursuiting if we have > > > > authors commiting to provide the cycles first. > > > > > > Hmmm... why do you think specification of *IP* encapsulation > > > over SONET DCC > > > using "PPP over HDLC-like framing" is something ISO should do? > > > > > > > Second, which workgroup ? One of the MPLS offsprings such > > > as GSMP ;-) ? What about > > > > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't > > > be surprised > > > > if the joke find takers ;-) ? > > > > > > Definitely not me ;) > > > > > > I think some kind of individual submission should be ok. I guess > > > the Internet Area is the one that logically hosts it. > > > > > > Thanks, > > > > > > Alex. > > > > > > > > > _______________________________________________ > > > 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 Mon Dec 18 10:51: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 KAA09960 for ; Mon, 18 Dec 2000 10:51:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05588; Mon, 18 Dec 2000 08:14:04 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05576 for ; Mon, 18 Dec 2000 08:13:46 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10352; Mon, 18 Dec 2000 07:47:53 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA05553; Mon, 18 Dec 2000 10:47:52 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.11.1+Sun/8.11.1) id eBIF2xV101738; Mon, 18 Dec 2000 10:02:59 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14910.9794.654736.588261@gargle.gargle.HOWL> From: James Carlson To: Alex Zinin Cc: Tony Li , Edward Chang , isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture In-Reply-To: Alex Zinin's message of 16 December 2000 12:26:23 References: <14907.693.141245.416611@alpha-tony.procket.com> <2518.001216@cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 09:59:14 -0500 (EST) Content-Transfer-Encoding: 7bit Alex Zinin writes: > A number of companies working in the SONET area already use or are > planning to use DCC for IP control plane [I put MPLS list back ;), > since this question is related to GMPLS and OTN-related work]. > > There are two types of IP encapsulation on DCC that I know of: > LAP-D and PPP/HDLC. We use the second one in our SONET products. > > I think writing up an IETF document describing this would make sense. Describing which part? I think there are at least three separate issues here. One is the control plane issue (specifying the use of IP over DCC for carrying control messages), another is the encapsulation (for which RFCs 1332, 1661, and 1662 should do fine), and a third is having ITU-T specify that PPP is a "legal" option for DCC. For the first two issues, I think those are already handled. It's just that third one that might be an issue for some users, and I don't think that can be done within an IETF working group. If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good thing, I suppose that's possible, but I don't see what it accomplishes. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp _______________________________________________ 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 Dec 18 13:06: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 NAA12162 for ; Mon, 18 Dec 2000 13:06:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA06330; Mon, 18 Dec 2000 10:29:04 -0800 (PST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA05205 for ; Mon, 18 Dec 2000 06:55:03 -0800 (PST) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA22205 for ; Mon, 18 Dec 2000 09:29:12 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA22172; Mon, 18 Dec 2000 09:29:12 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA28669; Mon, 18 Dec 2000 09:29:11 -0500 (EST) Message-ID: <3A3E1F37.72C9E56A@lucent.com> From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@spider.juniper.net CC: mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture References: 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 09:29:11 -0500 Content-Transfer-Encoding: 7bit Hello All, Traditionally, SONET/SDH run OSI stack over DCC, that's where the LAPD/DCC came from. For IP traffic, PPP/HDLC/DCC is commonly used. Below is the introduction of DCC from "ietf-koay-mpls-and-optical-00.txt". Details can be found at any ANSI, Bellcore, ITU ... SONET/SDH document. "3.1 Line DCC-MS Line DCC or Multiplex-section DCC are the D4-D12 bytes in the overhead of a SONET or SDH frame respectively. Being in the line or multiplex-section overhead, they are passed thru repeaters in the span. Hence, DCC-MS should be used for neighbor discovery when the link connection contains section terminating regenerators. SDH customers should already be familiar with enabling multiplex-section DCC for management traffic (ITU-T G.784 10/98). In this standard, Line DCC-MS is recommended for routing management traffic and for communication between two SONET/SDH line/MS terminating nodes when regenerators are in the span. 3.2 Section DCC-RS Section DCC or regenerator-section DCC are the D1-D3 bytes in the overhead of a SONET or SDH frame respectively. The section overhead bytes are terminated by regenerators. Since regenerators are not Network Control nodes, Section DCC-RS can be used only if there are no regenerators in the span." However, using in-band control channel always has bandwidth limitation. Remember, DCC are fixed bytes and is not only used by control traffic. The "control plane" (not the data plane) "network" (not only links) should start from understanding its network level requirements (performance, security, reliability and etc.) Which physical medium and its "default" layer 2 protocol should meet the network level requirement and come naturally and conveniently. Yangguang Riad Hartani wrote: > > On this subject, the OIF UNI 1.0 specification (submitted for last call) > describes, among other things, how to use SONET Line and/or Section DCC > overhead bytes to transport various IP control plane messages (called IP > Control Channel -IPCC-). For discovery of information required by the IP > control plane, both DCC or J0 bytes may be used in the actual proposal. > > For the IP control plane, the proposal requires IP packets to be > encapsulated in PPP over HDLC-like framing with bit stuffing format. The > spec also describes various aspects related to the selection and maintenance > of IPCC parameters, as well as other ways of carrying IP control information > in Sonet/WDM environments. > > Hope this helps, > > Riad > > > -----Original Message----- > > From: Alex Zinin [mailto:azinin@cisco.com] > > Sent: Sunday, December 17, 2000 9:46 AM > > To: Tony Przygienda > > Cc: tli@procket.com; echang@pocketmail.com; > > isis-wg@spider.juniper.net; > > skatukam@cisco.com; mpls@UU.NET > > Subject: Re: [Isis-wg] Question on DCC Architecture > > > > > > > > Tony, > > > > >> A number of companies working in the SONET area already use or are > > >> planning to use DCC for IP control plane [I put MPLS list back ;), > > >> since this question is related to GMPLS and OTN-related work]. > > >> > > >> There are two types of IP encapsulation on DCC that I know of: > > >> LAP-D and PPP/HDLC. We use the second one in our SONET products. > > >> > > >> I think writing up an IETF document describing this would > > make sense. > > > > > First, this smells much like ISO thing to do so we'd need > > an agreement/liason > > > first from their side. That is obviously only worth > > pursuiting if we have > > > authors commiting to provide the cycles first. > > > > Hmmm... why do you think specification of *IP* encapsulation > > over SONET DCC > > using "PPP over HDLC-like framing" is something ISO should do? > > > > > Second, which workgroup ? One of the MPLS offsprings such > > as GSMP ;-) ? What about > > > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't > > be surprised > > > if the joke find takers ;-) ? > > > > Definitely not me ;) > > > > I think some kind of individual submission should be ok. I guess > > the Internet Area is the one that logically hosts it. > > > > Thanks, > > > > Alex. > > > > > > _______________________________________________ > > 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 Dec 18 13:06: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 NAA12172 for ; Mon, 18 Dec 2000 13:06:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA06346; Mon, 18 Dec 2000 10:29:50 -0800 (PST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05651 for ; Mon, 18 Dec 2000 08:22:26 -0800 (PST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA09259 for ; Mon, 18 Dec 2000 10:56:35 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id KAA09231; Mon, 18 Dec 2000 10:56:34 -0500 (EST) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA24773; Mon, 18 Dec 2000 10:56:34 -0500 Message-ID: <3A3E41C3.98EA0CBE@hotair.hobl.lucent.com> From: "S.Sankaranarayanan" Reply-To: ssnarayanan@lucent.com Organization: JJ0C21010 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Truskowski CC: Manohar Ellanti , riad@caspiannetworks.com, azinin@cisco.com, prz@net4u.ch, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture References: <200012181540.HAA17062@diablo.cisco.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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 11:56:35 -0500 Content-Transfer-Encoding: 7bit Just to clarify a point... The ITU-T SG15 Q14 has recently started work on a generic DCN architecture and there was agreement in the last experts meeting in Dec, 2000 that this DCN would be IP based and would address the issue of interworking between an OSI based DCN and IP based DCN. Regards, Shiva _______________________________________________ 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 Dec 18 13:06:53 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 NAA12182 for ; Mon, 18 Dec 2000 13:06:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA06362; Mon, 18 Dec 2000 10:29:56 -0800 (PST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05762 for ; Mon, 18 Dec 2000 08:34:06 -0800 (PST) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id IAA09491; Mon, 18 Dec 2000 08:08:14 -0800 (PST) From: Mike Truskowski Message-Id: <200012181608.IAA09491@diablo.cisco.com> Subject: Re: [Isis-wg] Question on DCC Architecture To: ssnarayanan@lucent.com Cc: truskows@cisco.com, ellanti@home.com, riad@caspiannetworks.com, azinin@cisco.com, prz@net4u.ch, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net In-Reply-To: <3A3E41C3.98EA0CBE@hotair.hobl.lucent.com>; from "S.Sankaranarayanan" at Dec 18, 100 11:56 am X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 8:08:14 PST OK, but the DCN is not the DCC. The NSIF, formerly the SIF, worked on the mediation issues dealing with OSI and TCP/IP. The work was incomplete since it dealt with datagrams and not software download. Are you saying that the SG15 is working on mediation in the DCN to include software download? Mike > > Just to clarify a point... > > The ITU-T SG15 Q14 has recently started work on a generic DCN > architecture and there was agreement in the last experts meeting in Dec, > 2000 that this DCN would be IP based and would address the issue of > interworking between an OSI based DCN and IP based DCN. > > Regards, > Shiva > _______________________________________________ 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 Dec 18 15:57: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 PAA15338 for ; Mon, 18 Dec 2000 15:57:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA07175; Mon, 18 Dec 2000 13:20:04 -0800 (PST) Received: from zrtps06s.us.nortel.com (h50s48a140n47.user.nortelnetworks.com [47.140.48.50]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA07160 for ; Mon, 18 Dec 2000 13:19:24 -0800 (PST) Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Mon, 18 Dec 2000 15:27:02 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 18 Dec 2000 15:26:51 -0500 Message-ID: From: "Cypryan Klish" To: "'Mike Truskowski'" Cc: isis-wg@spider.juniper.net, mpls@uu.net Subject: RE: [Isis-wg] Question on DCC Architecture MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06930.D9287D70" X-Orig: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 15:26:48 -0500 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_01C06930.D9287D70 Content-Type: text/plain; charset="iso-8859-1" > OK, but the DCN is not the DCC. Wrong. This is a very common misunderstanding, however, the definitive ITU-T recommendation states otherwise. Specifically, ITU-T M.3010 (02/00) 11.2 states: "The DCN may consist of a number of individual subnetworks of different types, interconnected together. The DCN may be a local path, or a wide area connection among distributed functional blocks. The DCN is technology independent and may employ any single or combination of transmission technologies." Previous editions of M.3010 such as (05/96) contained a similar definition. In fact, section 4.1.4. of M.3010 (05/96) stated: "...The various types of subnetworks may include technology specific subnetwork(s) such as the SDH DCC." In other words the DCC is part of the DCN; the two are not separate. SIF's Architecture Work Group found a need to clarify this further by adapting the terms "access DCN" and "embedded DCN" per the proposal contained in SIF-AR-9808-120; this became common usage in the final year of that work group's activity (1999). As to the scope of the SIF work, it addressed only an IP-based "Access DCN" - the part of the DCN between an OSS and a GNE; see the approved document SIF-033-1999 "Requirements for the TCP/IP Protocol Suite on the SONET Access DCN." This approved document does contain requirements (sections 7.5) for FTP-based file transfers and for a FTP/FTAM translation device, so an infrastructure for software download was put in place, so I don't know what would be considered incomplete about software download support. In fact, Annex C of SIF-033-1999 contains SIF's addional TL1 messages specific to file transfer. However, I don't know if anyone ever implemented these. The SIF IP on the DCC activity was never completed, although some of the contributions identified earlier in this thread are informative as to the issues and discussions. However, note they are just contributions and not approved solutions. Kip Klish -----Original Message----- From: Mike Truskowski [mailto:truskows@cisco.com] Sent: Monday, December 18, 2000 11:08 AM To: ssnarayanan@lucent.com Cc: truskows@cisco.com; ellanti@home.com; riad@caspiannetworks.com; azinin@cisco.com; prz@net4u.ch; tli@procket.com; echang@pocketmail.com; isis-wg@spider.juniper.net; skatukam@cisco.com; mpls@UU.NET Subject: Re: [Isis-wg] Question on DCC Architecture OK, but the DCN is not the DCC. The NSIF, formerly the SIF, worked on the mediation issues dealing with OSI and TCP/IP. The work was incomplete since it dealt with datagrams and not software download. Are you saying that the SG15 is working on mediation in the DCN to include software download? Mike > > Just to clarify a point... > > The ITU-T SG15 Q14 has recently started work on a generic DCN > architecture and there was agreement in the last experts meeting in Dec, > 2000 that this DCN would be IP based and would address the issue of > interworking between an OSI based DCN and IP based DCN. > > Regards, > Shiva > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C06930.D9287D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Question on DCC Architecture

> OK, but the DCN is not the DCC.

Wrong.  This is a very common misunderstanding, = however, the definitive ITU-T recommendation states otherwise.

Specifically, ITU-T M.3010 (02/00) 11.2 = states:

"The DCN may consist of a number of individual = subnetworks of different types, interconnected together.  The DCN = may be a local path, or a wide area connection among distributed = functional blocks.  The DCN is technology independent and may = employ any single or combination of transmission = technologies."

Previous editions of M.3010 such as (05/96) contained = a similar definition.  In fact, section 4.1.4. of M.3010 (05/96) = stated:

"...The various types of subnetworks may include = technology specific subnetwork(s) such as the SDH DCC."

In other words the DCC is part of the DCN; the two = are not separate.

SIF's Architecture Work Group found a need to clarify = this further by adapting the terms "access DCN" and = "embedded DCN" per the proposal contained in SIF-AR-9808-120; = this became common usage in the final year of that work group's = activity (1999).

As to the scope of the SIF work, it addressed only an = IP-based "Access DCN" - the part of the DCN between an OSS = and a GNE; see the approved document SIF-033-1999 "Requirements = for the TCP/IP Protocol Suite on the SONET Access DCN."  This = approved document does contain requirements (sections 7.5) for = FTP-based file transfers and for a FTP/FTAM translation device, so an = infrastructure for software download was put in place, so I don't know = what would be considered incomplete about software download support. In = fact, Annex C of SIF-033-1999 contains SIF's addional TL1 messages = specific to file transfer.  However, I don't know if anyone ever = implemented these.

The SIF IP on the DCC activity was never completed, = although some of the contributions identified earlier in this thread = are informative as to the issues and discussions. However, note they = are just contributions and not approved solutions.

Kip Klish


-----Original Message-----
From: Mike Truskowski [mailto:truskows@cisco.com]=
Sent: Monday, December 18, 2000 11:08 AM
To: ssnarayanan@lucent.com
Cc: truskows@cisco.com; ellanti@home.com; = riad@caspiannetworks.com;
azinin@cisco.com; prz@net4u.ch; tli@procket.com; = echang@pocketmail.com;
isis-wg@spider.juniper.net; skatukam@cisco.com; = mpls@UU.NET
Subject: Re: [Isis-wg] Question on DCC = Architecture


OK, but the DCN is not the DCC.

The NSIF, formerly the SIF, worked on the = mediation
issues dealing with OSI and TCP/IP.  The work = was
incomplete since it dealt with datagrams and = not
software download.  

Are you saying that the SG15 is working on = mediation
in the DCN to include software download?  =

Mike

>
> Just to clarify a point...
>
> The ITU-T SG15 Q14 has recently started work on = a generic DCN
> architecture and there was agreement in the = last experts meeting in Dec,
> 2000 that this DCN would be IP based and would = address the issue of
> interworking between an OSI based DCN and IP = based DCN.
>
> Regards,
> Shiva
>

_______________________________________________
Isis-wg mailing list  -  = Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg

------_=_NextPart_001_01C06930.D9287D70-- _______________________________________________ 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 Dec 18 17:05: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 RAA16317 for ; Mon, 18 Dec 2000 17:05:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA07496; Mon, 18 Dec 2000 14:28:03 -0800 (PST) Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA07484 for ; Mon, 18 Dec 2000 14:27:15 -0800 (PST) Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAL06673; Mon, 18 Dec 2000 16:01:18 -0600 (CST) Received: from tellabs.com (bbpchr53.bb.tellabs.com [138.111.163.53]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA29329; Mon, 18 Dec 2000 16:01:18 -0600 (CST) Message-ID: <3A3E892A.BEB26662@tellabs.com> From: Jonathan Sadler Reply-To: Jonathan.Sadler@tellabs.com Organization: Tellabs ONG SE Platform X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: james.d.carlson@east.sun.com CC: azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture References: 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 16:01:14 -0600 Content-Transfer-Encoding: 7bit However, use of PPP on the Section DCC may cause an interoperability issue if you have a regenerator in line, and it only supports CLNP/LAPD. For that reason, GRE encapsulation (ala the Cisco 15303), or IP over LAPD (ala RFC 1663?) may be a better approach, until a standards body puts a stake in the sand. Another issue not covered is the operational use of IS-IS on this channel. As IS-IS is used by SONET terminal/regenerator gear, what is going to happen to all the CPU and memory constrained ADMs out there when they start receiving the LSPs with all of the TE and GMPLS TLVs? Many are limited to less than 50 nodes and less than 100 links in an Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS TLVs. Jonathan Sadler james.d.carlson@east.sun.com wrote: > > Alex Zinin writes: > > A number of companies working in the SONET area already use or are > > planning to use DCC for IP control plane [I put MPLS list back ;), > > since this question is related to GMPLS and OTN-related work]. > > > > There are two types of IP encapsulation on DCC that I know of: > > LAP-D and PPP/HDLC. We use the second one in our SONET products. > > > > I think writing up an IETF document describing this would make sense. > > Describing which part? I think there are at least three separate > issues here. One is the control plane issue (specifying the use of IP > over DCC for carrying control messages), another is the encapsulation > (for which RFCs 1332, 1661, and 1662 should do fine), and a third is > having ITU-T specify that PPP is a "legal" option for DCC. > > For the first two issues, I think those are already handled. It's > just that third one that might be an issue for some users, and I don't > think that can be done within an IETF working group. > > If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good > thing, I suppose that's possible, but I don't see what it > accomplishes. > > -- > James Carlson, Internet Engineering > SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > Second Edition now available - http://people.ne.mediaone.net/carlson/ppp _______________________________________________ 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 Dec 18 18:25: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 SAA17770 for ; Mon, 18 Dec 2000 18:25:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA07848; Mon, 18 Dec 2000 15:45:04 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA07833 for ; Mon, 18 Dec 2000 15:44:42 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id AAA06690; Tue, 19 Dec 2000 00:13:03 +0100 From: Tony Przygienda Message-Id: <200012182313.AAA06690@net4u.net4u.ch> Subject: Re: [Isis-wg] Question on DCC Architecture In-Reply-To: <3A3E892A.BEB26662@tellabs.com> from Jonathan Sadler at "Dec 18, 2000 4: 1:14 pm" To: Jonathan.Sadler@tellabs.com Cc: james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 00:13:03 +0100 (MET) Content-Transfer-Encoding: 7bit > Another issue not covered is the operational use of IS-IS on this > channel. As IS-IS is used by SONET terminal/regenerator gear, what is > going to happen to all the CPU and memory constrained ADMs out there > when they start receiving the LSPs with all of the TE and GMPLS TLVs? > Many are limited to less than 50 nodes and less than 100 links in an > Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS > TLVs. This is something that a body equivalent to Nanog in SONET world should probably be concerned with. ISIS working group has as primary topic the standardization of bits on the wires between boxes to make sure that different vendors interoperate. Although things like application guidelines and protocol analysis is common, it would be vain trying to publish RFCs with implementation guidelines since technology is still galloping forward @ a speed that makes such publications often obsolete within months. As to deployment issues with older gear that you outline, IETF has been pretty much shaped by the Darvinian ISP approach "get them to upgrade your software, get them to upgrade your hardware, if they can't, throw the gear away and pick up a better vendor". As an alternate solution, you may just choose not to deploy all that optional new stuff .. --- 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 Mon Dec 18 19:33:52 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 TAA18941 for ; Mon, 18 Dec 2000 19:33:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA08175; Mon, 18 Dec 2000 16:54:04 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA08163 for ; Mon, 18 Dec 2000 16:53:25 -0800 (PST) Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA10185; Mon, 18 Dec 2000 19:27:29 -0500 (EST) Received: from jlearman-nt (dhcp-64-102-83-127.cisco.com [64.102.83.127]) by dingdong.cisco.com (Mirapoint) with SMTP id ADA07833; Mon, 18 Dec 2000 19:27:31 -0500 (EST) Message-Id: <4.1.20001218191638.00a648f0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Jonathan.Sadler@tellabs.com From: Jeff Learman Subject: Re: [Isis-wg] Question on DCC Architecture Cc: isis-wg@spider.juniper.net In-Reply-To: <3A3E892A.BEB26662@tellabs.com> References: 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 19:25:25 -0500 At 04:01 PM 12/18/2000 -0600, you wrote: >However, use of PPP on the Section DCC may cause an interoperability >issue if you have a regenerator in line, and it only supports >CLNP/LAPD. For that reason, GRE encapsulation (ala the Cisco 15303), or >IP over LAPD (ala RFC 1663?) may be a better approach, until a standards >body puts a stake in the sand. How would any of these solve this problem? If the regenerator can't handle IP frames, it will drop them regardless of the encapsulation. And this is not just a problem for regenerators, it's an interop problem for any multi-vendor ring. >Another issue not covered is the operational use of IS-IS on this >channel. As IS-IS is used by SONET terminal/regenerator gear, what is >going to happen to all the CPU and memory constrained ADMs out there >when they start receiving the LSPs with all of the TE and GMPLS TLVs? >Many are limited to less than 50 nodes and less than 100 links in an >Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS >TLVs. That's only the tip of the iceberg on this issue. According to RFC 1195 (Integrated IS-IS), you can't have any OSI-only routers in a dual-protocol area. If you do, you won't get any error messages -- you'll just get black holes. >Jonathan Sadler > >james.d.carlson@east.sun.com wrote: >> >> Alex Zinin writes: >> > A number of companies working in the SONET area already use or are >> > planning to use DCC for IP control plane [I put MPLS list back ;), >> > since this question is related to GMPLS and OTN-related work]. >> > >> > There are two types of IP encapsulation on DCC that I know of: >> > LAP-D and PPP/HDLC. We use the second one in our SONET products. >> > >> > I think writing up an IETF document describing this would make sense. >> >> Describing which part? I think there are at least three separate >> issues here. One is the control plane issue (specifying the use of IP >> over DCC for carrying control messages), another is the encapsulation >> (for which RFCs 1332, 1661, and 1662 should do fine), and a third is >> having ITU-T specify that PPP is a "legal" option for DCC. >> >> For the first two issues, I think those are already handled. It's >> just that third one that might be an issue for some users, and I don't >> think that can be done within an IETF working group. >> >> If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good >> thing, I suppose that's possible, but I don't see what it >> accomplishes. >> >> -- >> James Carlson, Internet Engineering >> SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 >> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 >> Second Edition now available - http://people.ne.mediaone.net/carlson/ppp >_______________________________________________ >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 Dec 18 20:42:52 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 UAA19645 for ; Mon, 18 Dec 2000 20:42:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA08507; Mon, 18 Dec 2000 18:05:04 -0800 (PST) Received: from bridge.axiowave.com ([209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA08492 for ; Mon, 18 Dec 2000 18:04:12 -0800 (PST) Message-ID: From: Jeff Parker To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] [IS-IS WG] Subsecond Timers Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Dec 2000 20:38:17 -0500 The "Sub Second convergence" draft draft-alaettinoglu-ISIS-convergence-00.ps has a number of useful suggestions about implementation. While most of these ideas can be implemented today, the one change that would be needed to include all recommendations would be a new way to encode the hold timer in hello messages. Do the authors plan to put that forward in a later version of the document? - jeff parker _______________________________________________ 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 Dec 19 11:03:25 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 LAA16896 for ; Tue, 19 Dec 2000 11:03:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA11951; Tue, 19 Dec 2000 08:26:04 -0800 (PST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA11939 for ; Tue, 19 Dec 2000 08:25:16 -0800 (PST) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id HAA01127; Tue, 19 Dec 2000 07:59:16 -0800 (PST) From: Mike Truskowski Message-Id: <200012191559.HAA01127@diablo.cisco.com> Subject: Re: [Isis-wg] Question on DCC Architecture To: prz@net4u.ch (Tony Przygienda) Cc: Jonathan.Sadler@tellabs.com, james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net In-Reply-To: <200012182313.AAA06690@net4u.net4u.ch>; from "Tony Przygienda" at Dec 19, 100 12:13 (midnight) X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 7:59:16 PST The issue is simply stated... while you look at ISIS to enhance it for "IP". Don't break it for "CLNS" because there are 10's of thousands of sonet/sdh NE's relying on ISIS today. Certainly, we in the NSIF can move forward creating an IP stack... but the rings which are already using clns on the DCC will be there for awhile longer. I would prefer running a native protocol end2end while others would rather see clns on the dcc and ip2clns mediation on the DCN. There are no simple answers here. Mike > > > Another issue not covered is the operational use of IS-IS on this > > channel. As IS-IS is used by SONET terminal/regenerator gear, what is > > going to happen to all the CPU and memory constrained ADMs out there > > when they start receiving the LSPs with all of the TE and GMPLS TLVs? > > Many are limited to less than 50 nodes and less than 100 links in an > > Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS > > TLVs. > > This is something that a body equivalent to Nanog in SONET world should > probably be concerned with. ISIS working group has as primary topic the > standardization of bits on the wires between boxes to make sure that > different vendors interoperate. Although things like application > guidelines and protocol analysis is common, it would be vain trying to > publish RFCs with implementation guidelines since technology is still > galloping forward @ a speed that makes such publications often obsolete > within months. As to deployment issues with older gear that you outline, > IETF has been pretty much shaped by the Darvinian ISP approach "get them to > upgrade your software, get them to upgrade your hardware, if they can't, > throw the gear away and pick up a better vendor". As an alternate solution, > you may just choose not to deploy all that optional new stuff .. > > --- 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 Tue Dec 19 11:33:27 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 LAA17642 for ; Tue, 19 Dec 2000 11:33:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA12112; Tue, 19 Dec 2000 08:56:03 -0800 (PST) Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA12100 for ; Tue, 19 Dec 2000 08:55:45 -0800 (PST) Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAL13802; Tue, 19 Dec 2000 10:14:13 -0600 (CST) Received: from tellabs.com (bb73338l.bb.tellabs.com [138.111.163.78]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA05872; Tue, 19 Dec 2000 10:14:13 -0600 (CST) Message-ID: <3A3F8954.5B177B07@tellabs.com> From: Jonathan Sadler Reply-To: Jonathan.Sadler@tellabs.com Organization: Tellabs ONG SE Platform X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: jlearman@cisco.com CC: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Question on DCC Architecture References: 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 10:14:12 -0600 Content-Transfer-Encoding: 7bit At 19:25:25 12/18/2000 -0500, jlearman@cisco.com wrote: > > At 04:01 PM 12/18/2000 -0600, you wrote: > >However, use of PPP on the Section DCC may cause an interoperability > >issue if you have a regenerator in line, and it only supports > >CLNP/LAPD. For that reason, GRE encapsulation (ala the Cisco 15303), or > >IP over LAPD (ala RFC 1663?) may be a better approach, until a standards > >body puts a stake in the sand. > > How would any of these solve this problem? If the regenerator can't > handle IP frames, it will drop them regardless of the encapsulation. > And this is not just a problem for regenerators, it's an interop > problem for any multi-vendor ring. Agreed. However, autoconfiguration of a link becomes harder if the link layer protocol is not consistant for Dual and OSI-only interfaces. Of course use of GRE is the band-aid of last resort to connect IP islands. > >Another issue not covered is the operational use of IS-IS on this > >channel. As IS-IS is used by SONET terminal/regenerator gear, what is > >going to happen to all the CPU and memory constrained ADMs out there > >when they start receiving the LSPs with all of the TE and GMPLS TLVs? > >Many are limited to less than 50 nodes and less than 100 links in an > >Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS > >TLVs. > > That's only the tip of the iceberg on this issue. According to > RFC 1195 (Integrated IS-IS), you can't have any OSI-only routers in > a dual-protocol area. Again agreed. However, it is possible to have OSI only links on a dual router. Some vendors are utilizing this capability to add Integrated IS-IS support to their nodes in anticipation of IP over DCC being standardized. > If you do, you won't get any error messages -- > you'll just get black holes. Actually, 1195 does require generation of ICMP host unreachable and CLNP destination unreachable messages when a dual router identifies that the next hop is, respectively, IP or OSI incapable. > >Jonathan Sadler > > > >james.d.carlson@east.sun.com wrote: > >> > >> Alex Zinin writes: > >> > A number of companies working in the SONET area already use or are > >> > planning to use DCC for IP control plane [I put MPLS list back ;), > >> > since this question is related to GMPLS and OTN-related work]. > >> > > >> > There are two types of IP encapsulation on DCC that I know of: > >> > LAP-D and PPP/HDLC. We use the second one in our SONET products. > >> > > >> > I think writing up an IETF document describing this would make sense. > >> > >> Describing which part? I think there are at least three separate > >> issues here. One is the control plane issue (specifying the use of IP > >> over DCC for carrying control messages), another is the encapsulation > >> (for which RFCs 1332, 1661, and 1662 should do fine), and a third is > >> having ITU-T specify that PPP is a "legal" option for DCC. > >> > >> For the first two issues, I think those are already handled. It's > >> just that third one that might be an issue for some users, and I don't > >> think that can be done within an IETF working group. > >> > >> If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good > >> thing, I suppose that's possible, but I don't see what it > >> accomplishes. > >> > >> -- > >> James Carlson, Internet Engineering > >> SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > >> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > >> Second Edition now available - http://people.ne.mediaone.net/carlson/ppp > >_______________________________________________ > >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 Dec 19 12:25: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 MAA18873 for ; Tue, 19 Dec 2000 12:25:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA12396; Tue, 19 Dec 2000 09:48:04 -0800 (PST) Received: from interceptor.mahinetworks.com (216-174-224-194.atgi.net [216.174.224.194]) by external.juniper.net (8.9.3/8.9.3) with SMTP id JAA12383 for ; Tue, 19 Dec 2000 09:47:36 -0800 (PST) Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Tue, 19 Dec 2000 09:24:45 -0800 (Pacific Standard Time) Received: by main.mahinetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 09:21:44 -0800 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C90FD5D9@main.mahinetworks.com> From: Yuchen Zhou To: isis-wg@spider.juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] ISIS compliance test Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 09:21:38 -0800 Hi, Does anyone know of any ISIS compliance /interoperability test suites / tools? UNH InterOp lab does not seem to have such a suite, while QA Robot does. Yuchen _______________________________________________ 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 Dec 19 13:47: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 NAA21223 for ; Tue, 19 Dec 2000 13:47:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA12764; Tue, 19 Dec 2000 11:10:04 -0800 (PST) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA12749 for ; Tue, 19 Dec 2000 11:09:53 -0800 (PST) Received: from dhcp-171-69-103-120.cisco.com (dhcp-171-69-103-120.cisco.com [171.69.103.120]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA10992; Tue, 19 Dec 2000 10:42:48 -0800 (PST) From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <16440.001219@cisco.com> To: James Carlson CC: Tony Li , Edward Chang , isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture In-reply-To: <14910.9794.654736.588261@gargle.gargle.HOWL> References: <14910.9794.654736.588261@gargle.gargle.HOWL> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 10:34:35 -0800 Content-Transfer-Encoding: 7bit James, I'm talking mostly about the second part. The question such a document (BCP or whatever status) could address is "how does one send IP over a SONET DCC channel?". The answer could be as simple as "by using RFC1662 encapsulation and treating D{1-3}/D{4-12} OH bytes as a synchronous stream of octets", i.e., not by using LAP-D, or LAP-B, or SLIP, and not trying to align HDLC frames within the sequence of SONET frames. -- Alex Zinin Monday, December 18, 2000, 6:59 AM, James Carlson wrote: > Alex Zinin writes: >> A number of companies working in the SONET area already use or are >> planning to use DCC for IP control plane [I put MPLS list back ;), >> since this question is related to GMPLS and OTN-related work]. >> >> There are two types of IP encapsulation on DCC that I know of: >> LAP-D and PPP/HDLC. We use the second one in our SONET products. >> >> I think writing up an IETF document describing this would make sense. > Describing which part? I think there are at least three separate > issues here. One is the control plane issue (specifying the use of IP > over DCC for carrying control messages), another is the encapsulation > (for which RFCs 1332, 1661, and 1662 should do fine), and a third is > having ITU-T specify that PPP is a "legal" option for DCC. > For the first two issues, I think those are already handled. It's > just that third one that might be an issue for some users, and I don't > think that can be done within an IETF working group. > If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good > thing, I suppose that's possible, but I don't see what it > accomplishes. _______________________________________________ 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 Dec 19 14:06: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 OAA21783 for ; Tue, 19 Dec 2000 14:06:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA12874; Tue, 19 Dec 2000 11:29:04 -0800 (PST) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA12857 for ; Tue, 19 Dec 2000 11:28:12 -0800 (PST) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id eBJJ2CF01049; Tue, 19 Dec 2000 14:02:13 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; TUE, 19 Dec 2000 13:50:55 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 13:50:55 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E563A8135@newman.tenornet.com> From: "Shah, Himanshu" To: "'Jeff Parker'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] [IS-IS WG] Subsecond Timers 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 13:50:50 -0500 OSPF restart (which I guess can be extended for ISIS) and fast convergence seems to have conflicting goal (by way of affecting routerDeadInterval, one desiring longer other desiring shorter), don't you think? This needs to be tackled in one or the other RFC too. -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Monday, December 18, 2000 8:38 PM To: isis-wg@spider.juniper.net Subject: [Isis-wg] [IS-IS WG] Subsecond Timers The "Sub Second convergence" draft draft-alaettinoglu-ISIS-convergence-00.ps has a number of useful suggestions about implementation. While most of these ideas can be implemented today, the one change that would be needed to include all recommendations would be a new way to encode the hold timer in hello messages. Do the authors plan to put that forward in a later version of the document? - jeff parker _______________________________________________ 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 Dec 19 14:06: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 OAA21812 for ; Tue, 19 Dec 2000 14:06:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA12890; Tue, 19 Dec 2000 11:29:13 -0800 (PST) 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 LAA12862 for ; Tue, 19 Dec 2000 11:28:26 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03070; Tue, 19 Dec 2000 11:02:21 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA03579; Tue, 19 Dec 2000 14:02:19 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id eBJJ2XH108374; Tue, 19 Dec 2000 14:02:33 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14911.45256.826676.896877@gargle.gargle.HOWL> From: James Carlson To: Alex Zinin Cc: Tony Li , Edward Chang , isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture In-Reply-To: Alex Zinin's message of 19 December 2000 10:34:35 References: <14910.9794.654736.588261@gargle.gargle.HOWL> <16440.001219@cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 14:02:32 -0500 (EST) Content-Transfer-Encoding: 7bit Alex Zinin writes: > I'm talking mostly about the second part. > > The question such a document (BCP or whatever status) could > address is "how does one send IP over a SONET DCC channel?". > The answer could be as simple as "by using RFC1662 encapsulation > and treating D{1-3}/D{4-12} OH bytes as a synchronous stream > of octets", i.e., not by using LAP-D, or LAP-B, or SLIP, and > not trying to align HDLC frames within the sequence of SONET > frames. Note that there are no IETF documents covering, for instance, how to carry PPP over T1 lines. I don't consider that to be a gap that necessarily needs to be filled. Similarly, I think the treatment of D1-D3 as one bit-oriented synchronous data stream (Section DCC) and D4-D12 as another (Line DCC) is a rather obvious usage of those SONET features that doesn't need a separate draft for interoperable use. I don't think SLIP is a serious suggestion (is it?), since it has no error control or protection against address misconfiguration. LAP-D/B/F variants are possible, but similarly somewhat outside the control of the IETF. That's why I suggested a BCP instead. I don't see it as a standards issue but rather a usage issue. (If some implementations concatenate D1-D12 together, then I suppose that could be a problem, and would need standards language, but, again, probably not from the IETF.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp _______________________________________________ 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 Dec 19 14:19: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 OAA22140 for ; Tue, 19 Dec 2000 14:18:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA12983; Tue, 19 Dec 2000 11:42:03 -0800 (PST) Received: from bridge.axiowave.com ([209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA12971 for ; Tue, 19 Dec 2000 11:41:45 -0800 (PST) Message-ID: From: Jeff Parker To: "'Shah, Himanshu'" , Jeff Parker , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] [IS-IS WG] Subsecond Timers MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 14:15:42 -0500 My understanding of the two proposals has them in strict opposition: the convergence draft tries to minimize the impact of a crash by reducing the time needed to route around any problem, and the Restart proposal tries to work fast enough to avoid getting caught. Of course there are other uses for this functionality, but if you know you want to bring one side down for an upgrade, you can simply configure the box to start sending hellos with a longer Holding Timer. In IS-IS each side gets to dictate their own criteria. I think that if you try this with OSPF, the other side will break the association. My point on the converge draft was simply this: there is only one aspect of the draft that describes on-the-wire behavior, and that would have to do with the meaning of the Holding Time. One side could send "1" if we trusted both sides to be able to respond to hellos in a timely fashion, but we cannot go below that with today's draft. If the authors think 1 second is fast enough, we could simply change the granularity of the resend in the MIB, and keep the protocol behavior unchanged. - jeff parker > OSPF restart (which I guess can be extended for ISIS) and > fast convergence seems to have conflicting goal (by way of > affecting routerDeadInterval, one desiring longer other > desiring shorter), don't you think? > > This needs to be tackled in one or the other RFC too. > > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Monday, December 18, 2000 8:38 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] [IS-IS WG] Subsecond Timers > > > The "Sub Second convergence" draft > > draft-alaettinoglu-ISIS-convergence-00.ps > > has a number of useful suggestions about > implementation. While most of these ideas > can be implemented today, the one change that > would be needed to include all recommendations > would be a new way to encode the hold timer in > hello messages. Do the authors plan to put that > forward in a later version of the document? > > - jeff parker > _______________________________________________ > 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 Dec 19 15:06: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 PAA23403 for ; Tue, 19 Dec 2000 15:06:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA13319; Tue, 19 Dec 2000 12:29:04 -0800 (PST) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA13307 for ; Tue, 19 Dec 2000 12:28:40 -0800 (PST) Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id eBJK2eF12677; Tue, 19 Dec 2000 15:02:40 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; TUE, 19 Dec 2000 14:51:16 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 14:51:16 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E563A8138@newman.tenornet.com> From: "Shah, Himanshu" To: "'Jeff Parker'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] [IS-IS WG] Subsecond Timers 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 14:51:08 -0500 I understand your point and am not contradicting that point. My point is that, If I understand correctly, router restart's proposed goal is to restart before neighbor declares him dead and proceed to clean up. If routerDeadInterval is in sub-seconds, restart may not complete. If this is a point to worry about then it should be addressed or mentioned. If not, no sweat.. If ISIS allows changing hold times on per packet basis then your described method would work for managed restarts for ISIS. However, if that hello packet got lost after changed configuration in congestion (which can happen in busy network :-) then you may have to hope for the best... -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Tuesday, December 19, 2000 2:16 PM To: 'Shah, Himanshu'; Jeff Parker; isis-wg@spider.juniper.net Subject: RE: [Isis-wg] [IS-IS WG] Subsecond Timers My understanding of the two proposals has them in strict opposition: the convergence draft tries to minimize the impact of a crash by reducing the time needed to route around any problem, and the Restart proposal tries to work fast enough to avoid getting caught. Of course there are other uses for this functionality, but if you know you want to bring one side down for an upgrade, you can simply configure the box to start sending hellos with a longer Holding Timer. In IS-IS each side gets to dictate their own criteria. I think that if you try this with OSPF, the other side will break the association. My point on the converge draft was simply this: there is only one aspect of the draft that describes on-the-wire behavior, and that would have to do with the meaning of the Holding Time. One side could send "1" if we trusted both sides to be able to respond to hellos in a timely fashion, but we cannot go below that with today's draft. If the authors think 1 second is fast enough, we could simply change the granularity of the resend in the MIB, and keep the protocol behavior unchanged. - jeff parker > OSPF restart (which I guess can be extended for ISIS) and > fast convergence seems to have conflicting goal (by way of > affecting routerDeadInterval, one desiring longer other > desiring shorter), don't you think? > > This needs to be tackled in one or the other RFC too. > > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Monday, December 18, 2000 8:38 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] [IS-IS WG] Subsecond Timers > > > The "Sub Second convergence" draft > > draft-alaettinoglu-ISIS-convergence-00.ps > > has a number of useful suggestions about > implementation. While most of these ideas > can be implemented today, the one change that > would be needed to include all recommendations > would be a new way to encode the hold timer in > hello messages. Do the authors plan to put that > forward in a later version of the document? > > - jeff parker > _______________________________________________ > 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 Dec 19 15:06:44 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 PAA23415 for ; Tue, 19 Dec 2000 15:06:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA13346; Tue, 19 Dec 2000 12:30:04 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA13325 for ; Tue, 19 Dec 2000 12:29:34 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id UAA30001; Tue, 19 Dec 2000 20:57:47 +0100 From: Tony Przygienda Message-Id: <200012191957.UAA30001@net4u.net4u.ch> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: from Jeff Parker at "Dec 19, 2000 2:15:42 pm" To: jparker@axiowave.com (Jeff Parker) Cc: hshah@tenornetworks.com, jparker@axiowave.com, isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 20:57:46 +0100 (MET) Content-Transfer-Encoding: 7bit > My understanding of the two proposals has them > in strict opposition: the convergence draft > tries to minimize the impact of a crash by > reducing the time needed to route around any > problem, and the Restart proposal tries to > work fast enough to avoid getting caught. > > Of course there are other uses for this > functionality, but if you know you want to > bring one side down for an upgrade, you can > simply configure the box to start sending > hellos with a longer Holding Timer. > In IS-IS each side gets to dictate their own > criteria. I think that if you try this with > OSPF, the other side will break the association. > > My point on the converge draft was simply this: > there is only one aspect of the draft that > describes on-the-wire behavior, and that would > have to do with the meaning of the Holding Time. > One side could send "1" if we trusted both sides to > be able to respond to hellos in a timely fashion, > but we cannot go below that with today's draft. > If the authors think 1 second is fast enough, we > could simply change the granularity of the resend > in the MIB, and keep the protocol behavior unchanged. > > - jeff parker ISIS restart draft doesn't even exist yet and the fast convergence draft is _not_ a workgroup item and had generated some contingency in terms of viability, therefore I would prefer not to see work going on based on extrapolation of things to come but rather have the group focused working on items within our scope. That does not mean thta I discourage the discussions happening, but I'd prefer not to see changes creeping into existing drafts before the facts. -- 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 Dec 19 15:46:14 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 PAA24333 for ; Tue, 19 Dec 2000 15:46:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA13593; Tue, 19 Dec 2000 13:09:03 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA11991 for ; Tue, 19 Dec 2000 08:32:41 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 148PHY-000JNU-00; Tue, 19 Dec 2000 08:06:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Mike Truskowski Cc: prz@net4u.ch (Tony Przygienda), Jonathan.Sadler@tellabs.com, james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture References: <200012182313.AAA06690@net4u.net4u.ch> <200012191559.HAA01127@diablo.cisco.com> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 08:06:28 -0800 Content-Transfer-Encoding: 7bit there are small security advantages to NOT having is-is over ip randy _______________________________________________ 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 Dec 19 16:38: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 QAA25597 for ; Tue, 19 Dec 2000 16:38:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA13887; Tue, 19 Dec 2000 14:01:04 -0800 (PST) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA13752 for ; Tue, 19 Dec 2000 13:37:16 -0800 (PST) Received: from JHARPER-7020CT.cisco.com ([10.49.188.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA00445; Tue, 19 Dec 2000 21:08:57 GMT Message-Id: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Randy Bush From: John Harper Subject: Re: [Isis-wg] Question on DCC Architecture Cc: Mike Truskowski , prz@net4u.ch (Tony Przygienda), Jonathan.Sadler@tellabs.com, james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net In-Reply-To: References: <200012182313.AAA06690@net4u.net4u.ch> <200012191559.HAA01127@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 21:09:39 +0000 Not true - there are BIG security advantages to not having is-is over ip. It rules out a huge class of spoofing attacks to which OSPF is vulnerable. Further, there are no evident advantages to having is-is over ip, at least not that I have ever heard of. John At 08:06 19/12/2000 -0800, Randy Bush wrote: >there are small security advantages to NOT having is-is over ip > >randy >_______________________________________________ >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 Dec 19 16:38: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 QAA25607 for ; Tue, 19 Dec 2000 16:38:24 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA13903; Tue, 19 Dec 2000 14:01:40 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA13827 for ; Tue, 19 Dec 2000 13:52:17 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id WAA31189; Tue, 19 Dec 2000 22:20:22 +0100 From: Tony Przygienda Message-Id: <200012192120.WAA31189@net4u.net4u.ch> Subject: Re: [Isis-wg] Question on DCC Architecture In-Reply-To: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> from John Harper at "Dec 19, 2000 9: 9:39 pm" To: jharper@cisco.com (John Harper) Cc: rbush@bainbridge.verio.net, truskows@cisco.com, prz@net4u.ch, Jonathan.Sadler@tellabs.com, james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 22:20:22 +0100 (MET) Content-Transfer-Encoding: 7bit > Not true - there are BIG security advantages to not having is-is over ip. > It rules > out a huge class of spoofing attacks to which OSPF is vulnerable. last I checked nobody saw them so the whole thing is more a mental construct than reality. And even if, running proper security in your routing protocol is a pretty good answer to that ... > Further, > there are no evident advantages to having is-is over ip, at least not that I > have ever heard of. there are some, they are just not that important at the moment and that's why the work is dormant. One day we may run out of patience defining IS-IS encaps for every new link-layer technology that comes our way or really want to solve the MTU problem or maybe simply run out of smallest MTU times 255 LSPs bytes space in the protocol and then it may become a very handy tool thanks -- 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 Dec 19 16:52: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 QAA25852 for ; Tue, 19 Dec 2000 16:52:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA14050; Tue, 19 Dec 2000 14:16:05 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA14038 for ; Tue, 19 Dec 2000 14:15:27 -0800 (PST) Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA08656; Tue, 19 Dec 2000 16:49:24 -0500 (EST) Received: from jlearman-nt (dhcp-64-102-83-127.cisco.com [64.102.83.127]) by dingdong.cisco.com (Mirapoint) with SMTP id ADD06103; Tue, 19 Dec 2000 16:49:25 -0500 (EST) Message-Id: <4.1.20001219163611.00a558d0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: James Carlson , Alex Zinin From: Jeff Learman Subject: Re: [Isis-wg] Question on DCC Architecture Cc: Tony Li , Edward Chang , isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net In-Reply-To: <14911.45256.826676.896877@gargle.gargle.HOWL> References: <14910.9794.654736.588261@gargle.gargle.HOWL> <16440.001219@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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 16:41:12 -0500 >That's why I suggested a BCP instead. I don't see it as a standards >issue but rather a usage issue. This is not an IETF standards issue, it's a SONET NE standards issue. Vendors need to know what to implement to ensure the widest interoperability. This is not the forum to discuss them, although it was a reasonable one to ask the question in order to get the appropriate redirects (which were provided by several responses). Regards, Jeff _______________________________________________ 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 Dec 19 17:26:21 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 RAA26356 for ; Tue, 19 Dec 2000 17:26:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA14353; Tue, 19 Dec 2000 14:49:04 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA14341 for ; Tue, 19 Dec 2000 14:48:32 -0800 (PST) Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA09813 for ; Tue, 19 Dec 2000 17:22:30 -0500 (EST) Received: from jlearman-nt (dhcp-64-102-83-127.cisco.com [64.102.83.127]) by dingdong.cisco.com (Mirapoint) with SMTP id ADD06695; Tue, 19 Dec 2000 17:22:30 -0500 (EST) Message-Id: <4.1.20001219172222.00a7e6f0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: isis-wg@spider.juniper.net From: Jeff Learman Subject: Re: [Isis-wg] Question on DCC Architecture 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 17:22:26 -0500 Folks, I don't think this thread (IP on SONET DCC) has anything to do with IS-IS over IP. Please pick a new topic if you have something to say about that. Thanks, Jeff >there are small security advantages to NOT having is-is over ip > >randy >_______________________________________________ >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 Dec 19 17:50: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 RAA26774 for ; Tue, 19 Dec 2000 17:50:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA14499; Tue, 19 Dec 2000 15:13:04 -0800 (PST) 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 OAA14096 for ; Tue, 19 Dec 2000 14:22:58 -0800 (PST) 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 NAA12632; Tue, 19 Dec 2000 13:54:45 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id NAA29817; Tue, 19 Dec 2000 13:54:44 -0800 (PST) Message-Id: <200012192154.NAA29817@cirrus.juniper.net> From: Dave Katz To: jharper@cisco.com CC: rbush@bainbridge.verio.net, truskows@cisco.com, prz@net4u.ch, Jonathan.Sadler@tellabs.com, james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net In-reply-to: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> (message from John Harper on Tue, 19 Dec 2000 21:09:39 +0000) Subject: Re: [Isis-wg] Question on DCC Architecture Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 13:54:44 -0800 (PST) There was the ATM-VCMUX-encaps-to-avoid-two-cell-TCP-ACKs argument, but Henk's NLPID scheme (a truly wonderful reverse-ISO hack) is a hell of a lot simpler. Not true - there are BIG security advantages to not having is-is over ip. It rules out a huge class of spoofing attacks to which OSPF is vulnerable. Further, there are no evident advantages to having is-is over ip, at least not that I have ever heard of. _______________________________________________ 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 Dec 19 17:51:05 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 RAA26797 for ; Tue, 19 Dec 2000 17:51:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA14531; Tue, 19 Dec 2000 15:13:53 -0800 (PST) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA14282 for ; Tue, 19 Dec 2000 14:39:39 -0800 (PST) Received: from mosquito.inet.org ([24.168.212.166]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 19 Dec 2000 17:13:38 -0500 Message-Id: <5.0.0.25.2.20001219170332.00a0e1b0@gnat.inet.org> X-Sender: rja@gnat.inet.org X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: John Harper From: RJ Atkinson Subject: Re: [Isis-wg] Question on DCC Architecture Cc: isis-wg@spider.juniper.net, mpls@uu.net In-Reply-To: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> References: <200012182313.AAA06690@net4u.net4u.ch> <200012191559.HAA01127@diablo.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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 17:05:12 -0500 At 16:09 19/12/00, John Harper wrote: >Not true - there are BIG security advantages >to not having is-is over ip. Randy was right, IMHO, the advantages are modest. >It rules out a huge class of spoofing attacks to which OSPF >is vulnerable. OSPF is not vulnerable at all to spoofing attacks if configured properly (e.g. MD5 enabled, reasonable keys chosen). >Further, >there are no evident advantages to having is-is over ip, Agree. 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 Tue Dec 19 17:51:08 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 RAA26807 for ; Tue, 19 Dec 2000 17:51:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA14515; Tue, 19 Dec 2000 15:13:43 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA14206 for ; Tue, 19 Dec 2000 14:30:48 -0800 (PST) Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA09250; Tue, 19 Dec 2000 17:04:44 -0500 (EST) Received: from jlearman-nt (dhcp-64-102-83-127.cisco.com [64.102.83.127]) by dingdong.cisco.com (Mirapoint) with SMTP id ADD06384; Tue, 19 Dec 2000 17:04:45 -0500 (EST) Message-Id: <4.1.20001219170224.00a75460@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Tony Przygienda , jharper@cisco.com (John Harper) From: Jeff Learman Subject: Re: [Isis-wg] Question on DCC Architecture Cc: rbush@bainbridge.verio.net, truskows@cisco.com, prz@net4u.ch, Jonathan.Sadler@tellabs.com, james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net In-Reply-To: <200012192120.WAA31189@net4u.net4u.ch> References: <4.3.2.7.2.20001219210836.02a17038@jaws.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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 17:04:42 -0500 I don't think this thread (IP on SONET DCC) has anything to do with IS-IS over IP. Please pick a new topic if you have something to say about that. Thanks, Jeff At 10:20 PM 12/19/2000 +0100, Tony Przygienda wrote: >> Not true - there are BIG security advantages to not having is-is over ip. >> It rules >> out a huge class of spoofing attacks to which OSPF is vulnerable. > >last I checked nobody saw them so the whole thing is more a mental >construct than reality. And even if, running proper security in your >routing protocol is a pretty good answer to that ... > >> Further, >> there are no evident advantages to having is-is over ip, at least not that I >> have ever heard of. > >there are some, they are just not that important at the moment and that's >why the work is dormant. One day we may run out of patience defining IS-IS >encaps for every new link-layer technology that comes our way or really >want to solve the MTU problem or maybe simply run out of smallest MTU times >255 LSPs bytes space in the protocol and then it may become a very handy tool > > thanks > > -- 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 Tue Dec 19 20:44: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 UAA29577 for ; Tue, 19 Dec 2000 20:44:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA15378; Tue, 19 Dec 2000 18:08:04 -0800 (PST) Received: from roam.psg.com (adsl-63-206-97-82.dsl.snfc21.pacbell.net [63.206.97.82]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA15300 for ; Tue, 19 Dec 2000 17:54:40 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 148Y37-0008Ty-00; Tue, 19 Dec 2000 17:28:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: John Harper Cc: Mike Truskowski , prz@net4u.ch (Tony Przygienda), Jonathan.Sadler@tellabs.com, james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture References: <200012182313.AAA06690@net4u.net4u.ch> <200012191559.HAA01127@diablo.cisco.com> <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 17:28:09 -0800 Content-Transfer-Encoding: 7bit >> there are small security advantages to NOT having is-is over ip > Not true - there are BIG security advantages to not having is-is over ip. not being in sales or at a vendor, i am used to making more moderate claims :-) _______________________________________________ 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 Dec 19 21:44: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 VAA01391 for ; Tue, 19 Dec 2000 21:44:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA15684; Tue, 19 Dec 2000 19:07:04 -0800 (PST) Received: from roam.psg.com (adsl-63-206-97-82.dsl.snfc21.pacbell.net [63.206.97.82]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA15509 for ; Tue, 19 Dec 2000 18:28:34 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 148YaI-0008VB-00; Tue, 19 Dec 2000 18:02:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Tony Przygienda Cc: jharper@cisco.com (John Harper), truskows@cisco.com, Jonathan.Sadler@tellabs.com, james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net Subject: Re: [Isis-wg] Question on DCC Architecture References: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> <200012192120.WAA31189@net4u.net4u.ch> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Dec 2000 18:02:26 -0800 Content-Transfer-Encoding: 7bit >> Not true - there are BIG security advantages to not having is-is over ip. >> It rules out a huge class of spoofing attacks to which OSPF is >> vulnerable. > last I checked nobody saw them i assure you that the ops community, at least the wiser part of it, sees them. > And even if, running proper security in your routing protocol is a pretty > good answer to that ... except the beast does not exist. md5 sigs are not considered strong. randy _______________________________________________ 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 Dec 19 21:59:14 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 VAA01579 for ; Tue, 19 Dec 2000 21:59:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA15801; Tue, 19 Dec 2000 19:22:04 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA15762 for ; Tue, 19 Dec 2000 19:18:40 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id DAA02309; Wed, 20 Dec 2000 03:46:31 +0100 From: Tony Przygienda Message-Id: <200012200246.DAA02309@net4u.net4u.ch> Subject: Re: [Isis-wg] Question on DCC Architecture In-Reply-To: from Randy Bush at "Dec 19, 2000 6: 2:26 pm" To: rbush@bainbridge.verio.net (Randy Bush) Cc: prz@net4u.ch, jharper@cisco.com, truskows@cisco.com, Jonathan.Sadler@tellabs.com, james.d.carlson@east.sun.com, azinin@cisco.com, tli@procket.com, echang@pocketmail.com, isis-wg@spider.juniper.net, skatukam@cisco.com, mpls@uu.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 20 Dec 2000 03:46:31 +0100 (MET) Content-Transfer-Encoding: 7bit > >> Not true - there are BIG security advantages to not having is-is over ip. > >> It rules out a huge class of spoofing attacks to which OSPF is > >> vulnerable. > > last I checked nobody saw them > > i assure you that the ops community, at least the wiser part of it, sees > them. I didn't argue that they don't _exist_, I argued that I didn't hear of many incidents where ISP OSPF backbones were target of such attacks (contrary to some fancy BGP TCP attacks ;-) And if such attacks are being performed and I'm unaware of those, doing things like dropping OSPF packets with TTL>1 (with necessary exceptions) is a fairly trivial fix on the fast-path for many vendors. > > And even if, running proper security in your routing protocol is a pretty > > good answer to that ... > > except the beast does not exist. md5 sigs are not considered strong. about 1 1/2 years ago there was some wind that some guy came close to crack MD5 with serious computing power but didn't happen as far I heard. I get the impression that we're arguing here for the sake of the argument now and not the technical content anymore, so that's my last e-mail on this thread. BTW, Randy and others, pls subscribe to isis-wg list if you keep posting to it, otherwise it's quite a pain to let e-mails of non-subscribers in since we're running it moderated (which is a very good solution, thanks to Juniper hosting it ;-) -- 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 Dec 22 13:16:38 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 NAA09557 for ; Fri, 22 Dec 2000 13:16:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA30864; Fri, 22 Dec 2000 10:39:04 -0800 (PST) Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA30852 for ; Fri, 22 Dec 2000 10:38:52 -0800 (PST) Received: from localhost.localdomain.packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.11.0/8.11.0) with SMTP id eBMICTQ67143; Fri, 22 Dec 2000 10:12:29 -0800 (PST) (envelope-from cengiz@packetdesign.com) From: Cengiz Alaettinoglu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14915.39280.503477.749864@localhost.localdomain> To: Tony Przygienda Cc: jparker@axiowave.com (Jeff Parker), hshah@tenornetworks.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <200012191957.UAA30001@net4u.net4u.ch> References: <200012191957.UAA30001@net4u.net4u.ch> X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-to: cengiz@packetdesign.com X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 448 8219 X-Fax: +1 (310) 823 6714 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 22 Dec 2000 10:12:00 -0800 (PST) Content-Transfer-Encoding: 7bit Tony Przygienda (prz@net4u.ch) on December 19: > ISIS restart draft doesn't even exist yet and the > fast convergence draft is _not_ a workgroup item > and had generated some contingency in terms of > viability, > therefore I would prefer not to see work going on based on > extrapolation of things to come but rather have the > group focused working on items within our scope. > That does not mean thta I discourage the discussions > happening, but I'd prefer not to see changes > creeping into existing drafts before the facts. Tony, A large group of people who spoke at the microphone expressed the need/interest for this. The topic is of increasing interest. It's difficult to get credible experience with the real effects of using sub-second timers if they can't be specified. It is all right for some vendors not to be able to implement this today because they lack the horsepower (which becomes more and more available everyday). But, some vendors who want to differentiate their products will want to implement this sooner. And everyone will get there eventually. It is better to have a standard way of specifying this. (We are not suggesting everyone to switch using subsecond timers immediately nor instead of a level-2 notification scheme. But the WG should not stop people from being able to do so). The subsecond convergence is covered by the WG charter. Hence, this work can be a WG item if the chairs/WG agree. I dont mind doing the work with other volunteers to write what needs to be added to the wire protocol into a short draft. Happy holidays, Cengiz -- Cengiz Alaettinoglu Packet Design Inc. _______________________________________________ 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 Dec 22 16:33: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 QAA14918 for ; Fri, 22 Dec 2000 16:33:39 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA31667; Fri, 22 Dec 2000 13:57:04 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA31655 for ; Fri, 22 Dec 2000 13:56:48 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id WAA05244; Fri, 22 Dec 2000 22:23:56 +0100 From: Tony Przygienda Message-Id: <200012222123.WAA05244@net4u.net4u.ch> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <14915.39280.503477.749864@localhost.localdomain> from Cengiz Alaettinoglu at "Dec 22, 2000 10:12: 0 am" To: cengiz@packetdesign.com Cc: prz@net4u.ch, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 22 Dec 2000 22:23:56 +0100 (MET) Content-Transfer-Encoding: 7bit > > Tony Przygienda (prz@net4u.ch) on December 19: > > ISIS restart draft doesn't even exist yet and the > > fast convergence draft is _not_ a workgroup item > > and had generated some contingency in terms of > > viability, > > therefore I would prefer not to see work going on based on > > extrapolation of things to come but rather have the > > group focused working on items within our scope. > > That does not mean thta I discourage the discussions > > happening, but I'd prefer not to see changes > > creeping into existing drafts before the facts. > > Tony, > > A large group of people who spoke at the microphone expressed the > need/interest for this. The topic is of increasing interest. whether the discussion on the mike expressed need/interest or only mild interest/irritation (Vijay) is bound to interpretation by parties tinted by the agenda they pursuit so I don't buy this argument. There was no motion made and consensus built and implying any such thing on the list here should be done only carefully. > It's difficult to get credible experience with the real effects of > using sub-second timers if they can't be specified. It is all right > for some vendors not to be able to implement this today because they > lack the horsepower (which becomes more and more available > everyday). Lack of horsepower is not the problem with sub-second hellos in terms of _real_ implementation of such protocols, this is just something you extrapolated from your black-box observatioons. There were people (including me) doing that sub-second stuff on different IGPs in proprietary fashion around for quite a long time and the effects were to put it mildly "surprising". Otherwise, believe me, it would have been widely deployed already. > But, some vendors who want to differentiate their products > will want to implement this sooner. And everyone will get there > eventually. It is better to have a standard way of specifying > this. (We are not suggesting everyone to switch using subsecond timers > immediately nor instead of a level-2 notification scheme. But the WG > should not stop people from being able to do so). > The subsecond convergence is covered by the WG charter. There is a lot of things that can be interpreted as "being in the charter" but won't make sense. Are you making a formal motion here to make the "subsecond-timers" being a workgroup item ? And if so, it would help your cause immensly to have a couple of ISPs deploying the protocol today on a large scale saying "yes, go for it" on this list and moreover, clearly stating what is the problem this sub-second hellos they hope will solve for them ? And then, of course workgroup items need a draft so we know what we talk about in terms of bits & bytes first. > Hence, this > work can be a WG item if the chairs/WG agree. I dont mind doing the > work with other volunteers to write what needs to be added to the wire > protocol into a short draft. IMHO, that only makes sense if you remain completely backwards-compatible with the existing implementations. If you intend to change the hello interval fields or their semantics in the existing hello-packets than I would say, you rather sit on the sidelines until a new version of IS-IS happens that will not be compatible with the deployed one or convince some preople to do it under the wraps as proprietary thing or move the work into IRTF since I would be most reluctant to open the "new ISIS-version" can of worms right now. thta's all modulo other Tony's opinion of course since I didn't have any chance to syn up with him on that topic yet ... -- 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 Dec 22 17:49: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 RAA15832 for ; Fri, 22 Dec 2000 17:49:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA32018; Fri, 22 Dec 2000 15:13:04 -0800 (PST) Received: from mx2out.umbc.edu (mx2out.umbc.edu [130.85.253.52]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA32006 for ; Fri, 22 Dec 2000 15:12:33 -0800 (PST) Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id RAA07861; Fri, 22 Dec 2000 17:46:11 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id RAA318303; Fri, 22 Dec 2000 17:46:10 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs From: Vijay Gill X-Sender: vijay@irix2.gl.umbc.edu To: Cengiz Alaettinoglu cc: Tony Przygienda , Jeff Parker , hshah@tenornetworks.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <14915.39280.503477.749864@localhost.localdomain> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 22 Dec 2000 17:46:10 -0500 On Fri, 22 Dec 2000, Cengiz Alaettinoglu wrote: > A large group of people who spoke at the microphone expressed the > need/interest for this. The topic is of increasing interest. Having worked with very large scale networks, the trendline based on emprical experience, network meltdowns, and implementation failures has always been to turn up the timers such as hellos and the hello-mults. Emperical observations from working on ISP type networks indicate that setting the isis hello-multiplier to 12 or thereabouts seem to result in more stable networks. > It's difficult to get credible experience with the real effects of > using sub-second timers if they can't be specified. It is all right But first, instead of setting the multipliers and timers to milliseconds, getting the large isps to set them to 3 down from 12 might be a good interim step. Large networks prefer stability before speed of convergence in general, and a reduction in a factor of 4 should give us good feedback. > for some vendors not to be able to implement this today because they > lack the horsepower (which becomes more and more available everyday). > But, some vendors who want to differentiate their products will want > to implement this sooner. And everyone will get there eventually. It Considering that vendors can barely implement the spec as it stands. The number of people I'd trust to implement isis, (outside of Dr. Li, John Moy, Dr. Przygienda, henk, dkatz and bcole) I can count on one hand), I'll not be holding my breath anytime soon that these vendors will actually see use in operational networks of any size. /vijay _______________________________________________ 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 Dec 22 19:29:25 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 TAA16530 for ; Fri, 22 Dec 2000 19:29:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA32446; Fri, 22 Dec 2000 16:53:04 -0800 (PST) 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 QAA32434 for ; Fri, 22 Dec 2000 16:52:12 -0800 (PST) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.8.7) with ESMTP id QAA30860; Fri, 22 Dec 2000 16:25:47 -0800 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 BAA01424; Sat, 23 Dec 2000 01:35:02 +0100 Message-Id: <200012230035.BAA01424@kraak.procket.com> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers To: vijay@umbc.edu (Vijay Gill) Cc: cengiz@packetdesign.com (Cengiz Alaettinoglu), prz@net4u.ch (Tony Przygienda), jparker@axiowave.com (Jeff Parker), hshah@tenornetworks.com, isis-wg@spider.juniper.net In-Reply-To: from "Vijay Gill" at Dec 22, 2000 05:46:10 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 23 Dec 2000 01:35:02 +0100 (MET) Content-Transfer-Encoding: 7bit Vijay wrote: > Having worked with very large scale networks, the trendline based on > emprical experience, network meltdowns, and implementation failures has > always been to turn up the timers such as hellos and the hello-mults. > > Emperical observations from working on ISP type networks indicate that > setting the isis hello-multiplier to 12 or thereabouts seem to result in > more stable networks. Most of this "empirical experience" is based on very old networks built out of routers with 20 MHz processors (cisco 7000s come to mind). And in those days the queuing strategies on linecards, and between linecards and control planes was all less elaborate. FYI, when I worked at cisco, I have worked with customers that used holdtimes of only several seconds, but those were not ISPs. > But first, instead of setting the multipliers and timers to milliseconds, > getting the large isps to set them to 3 down from 12 might be a good > interim step. Large networks prefer stability before speed of convergence > in general, and a reduction in a factor of 4 should give us good feedback. Note that the lowest possible value of the ISIS holdtimer is 1 second. With the current protocol one could let a router send, say, 5 hellos in 1 second. That would be a considerable improvement over today's networks. (For those that are interested, over a year ago I implemented a feature in cisco IOS that would allow you to configure a holdtime of just one second. This feature is available in 12.1 for sure. Ask you cisco support about the details. Maybe Stefano has ported it to 12.0S). I agree it would be very interesting if some networks (ISPs or other networks) would get more familiar with holdtimes of 1 second before we define a new TLV. On the other hand, issuing an experimental TLV would not hurt much. > Considering that vendors can barely implement the spec as it stands. The > number of people I'd trust to implement isis, (outside of Dr. Li, John > Moy, Dr. Przygienda, henk, dkatz and bcole) I can count on one hand), I'll > not be holding my breath anytime soon that these vendors will actually see > use in operational networks of any size. Thank you very much. But you are exaggerating. I don't think low holdtimers are the tricky thing to implement fast convergence. The tricky part is to react quickly to events in your network, without ever risking a meltdown. There is more to it than just faster hellos. Tony Prz wrote: > IMHO, that only makes sense if you remain completely > backwards-compatible with the existing implementations. If you intend > to change the hello interval fields or their semantics in the existing > hello-packets than I would say, you rather sit on the sidelines until > a new version of IS-IS happens that will not be compatible with the > deployed one or convince some preople to do it under the wraps as > proprietary thing or move the work into IRTF since I would be most > reluctant to open the "new ISIS-version" can of worms right now. Tony, maybe you should do a little technical thinking before we start the politics. ;-) Doing sub-second holdtimers in a backward compatible manner is *very* simple. All we need is a new TLV to be included in the IIHs. Don't forget this is not OSPF. You configure the holdtimer on the router that is sending the IIHs. Suppose you configure your router to send an IIH every 20 ms, and you want the holdtime to be 100 ms. So what your router must do is: 1) send hello every 20 ms 2) set the old-fashioned advertised holdtimer to 1 second 3) set the advertised holdtimer in the new TLV to 100 milliseconds. If the neighbor supports the new TLV, it will see both the 1 second old-fashioned holdtimer and the new-fashioned 100 millisecond holdtimer. Of course it will prefer the new holdtimer. So after the neighbor missed 5 hellos from your router, it will declare the adjacency down. Exactly what your wanted. If the neighbor does not support the new TLV, it will use a holdtime of 1 second. So only after it missed 50 hellos it will declare the adjecency down. Not very quick, but still it would detect the down event. And the simplicity is that there is no negotiation involved at all. You include the TLV or you don't. You understand it when you receive it, or you don't. The protocol does not break. Hope this helps, 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 Fri Dec 22 19:38: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 TAA16606 for ; Fri, 22 Dec 2000 19:38:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA32553; Fri, 22 Dec 2000 17:02:04 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA32541 for ; Fri, 22 Dec 2000 17:01:23 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id BAA07021; Sat, 23 Dec 2000 01:28:34 +0100 From: Tony Przygienda Message-Id: <200012230028.BAA07021@net4u.net4u.ch> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <200012230035.BAA01424@kraak.procket.com> from Henk Smit at "Dec 23, 2000 1:35: 2 am" To: henk@procket.com (Henk Smit) Cc: vijay@umbc.edu, cengiz@packetdesign.com, prz@net4u.ch, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 23 Dec 2000 01:28:34 +0100 (MET) Content-Transfer-Encoding: 7bit > Tony Prz wrote: > > > IMHO, that only makes sense if you remain completely > > backwards-compatible with the existing implementations. If you intend > > to change the hello interval fields or their semantics in the existing > > hello-packets than I would say, you rather sit on the sidelines until > > a new version of IS-IS happens that will not be compatible with the > > deployed one or convince some preople to do it under the wraps as > > proprietary thing or move the work into IRTF since I would be most > > reluctant to open the "new ISIS-version" can of worms right now. > > Tony, maybe you should do a little technical thinking before we > start the politics. ;-) Doing sub-second holdtimers in a backward > compatible manner is *very* simple. All we need is a new TLV to be > included in the IIHs. Read once more through my mail: I did _not_ say that it could _not_ be done ;-) Thanks for your proposal, I assume you'll go ahead and help with the draft then ? -- 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 Dec 22 19:42:24 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 TAA16642 for ; Fri, 22 Dec 2000 19:42:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA32605; Fri, 22 Dec 2000 17:06:04 -0800 (PST) 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 RAA32593 for ; Fri, 22 Dec 2000 17:05:26 -0800 (PST) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.8.7) with ESMTP id QAA31546; Fri, 22 Dec 2000 16:39:02 -0800 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 BAA01482; Sat, 23 Dec 2000 01:48:17 +0100 Message-Id: <200012230048.BAA01482@kraak.procket.com> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers To: prz@net4u.ch (Tony Przygienda) Cc: henk@procket.com (Henk Smit), vijay@umbc.edu, cengiz@packetdesign.com, prz@net4u.ch, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net In-Reply-To: <200012230028.BAA07021@net4u.net4u.ch> from "Tony Przygienda" at Dec 23, 2000 01:28:34 AM 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 23 Dec 2000 01:48:17 +0100 (MET) Content-Transfer-Encoding: 7bit > Thanks for your proposal, I assume you'll go ahead and help with the draft > then ? I'd be happy to leave that for the people who are gonna implement this. At the moment I am spending my time doing other things than IS-IS. It is not gonna be more than 1 or 2 pages. And I think I have already seen people offering to write a draft. 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 Fri Dec 22 20:34: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 UAA17030 for ; Fri, 22 Dec 2000 20:34:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA32880; Fri, 22 Dec 2000 17:58:04 -0800 (PST) Received: from tcb.net (tcb.net [205.168.100.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA32868 for ; Fri, 22 Dec 2000 17:57:21 -0800 (PST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id SAA06831 for ; Fri, 22 Dec 2000 18:31:16 -0700 Message-Id: <200012230131.SAA06831@tcb.net> X-Mailer: exmh version 2.0.3 To: isis-wg@spider.juniper.net From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 22 Dec 2000 18:31:16 -0700 > Most of this "empirical experience" is based on very old networks > built out of routers with 20 MHz processors (cisco 7000s come to mind). > And in those days the queuing strategies on linecards, and between > linecards and control planes was all less elaborate. > > FYI, when I worked at cisco, I have worked with customers that used > holdtimes of only several seconds, but those were not ISPs. Actually, at a previous job [] in a very large [but newer, not legacy] network I did a lot of fumbling with really low hello intervals (1s), and multipliers of 4 & 5s. The primary driver for this at the time was to provide a mechanism for detection of a "new neighbor" on a point-to-point links when using inter-router SONET APS schemes. The problem was that APS switches on the remote end occur without the local router knowing, and as such, the fastest detection mechanism to trigger an adjacency tear-down and re-initialization was reception of a Hello message from an "unknown neighbor" on a point-to-point network. Other 'hacks' were experimented with as well, though their impact on network stability was even more questionable (right Henk :-). So, obviously, increasing the frequency @ which Hellos are transmitted (by an order of magnitude) had a significant impact on convergence. This had an even further reaching impact when considering that many implementations throttle initial or SPF reruns and if I could get the new adjacency established and LSPs flooded before the first SPF was executed, then the network was a lot happier in the long run (as were attentive customers :-). Fortunately, we didn't have tons of pseudo-nodes or large NBMA clouds with lots of neighbors, the network was composed mostly of point-to-point POS connections. As well, removing Hello padding [after adjacency establishment] enabled us to not use quite as much bandwidth [though it's never been the size of the packets as much as the volume], and it wasn't really negligible anyways. Then again, I recall working on another very large, very complex network that was configured with things such as Hellos (and every LSP/SNP [re]transmit interval and SPF throttle know possible) WAY throttled, and 200+ neighbors on a single NBMA (w/point-to-point VCs) interface consumed a steady 1.5% of the usable bandwidth on the connection. Of course, this was the network that encouraged Dave to add all those IOS knobs in order to increase stability, not improve convergence times :-) I think the work has merit here, though I agree that manipulation of such parameters is extremely sensitive. Fortunately, as Henk allluded to, a significant portion of this work can remain spec-independent. That is, anything with a Hello Multiplier >= 1s is doable without changes to the protocol, it's just a matter of the implementation supporting it. As such, perhaps something informational along these lines, or at best, experimental, is in order? As Vijay suggest, more experience is probably in order before messing with the new TLVs and the like. -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 Fri Dec 22 22:07: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 WAA18559 for ; Fri, 22 Dec 2000 22:07:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA33307; Fri, 22 Dec 2000 19:31:04 -0800 (PST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA33295 for ; Fri, 22 Dec 2000 19:30:39 -0800 (PST) Received: from redback.com ([63.200.50.42]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5Z008OZTJ12N@mta5.snfc21.pbi.net> for isis-wg@external.juniper.net; Fri, 22 Dec 2000 15:35:25 -0800 (PST) From: Tony Przygienda To: isis-wg@spider.juniper.net Message-id: <3A43D697.CD46A48C@redback.com> Organization: Siara Systems MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Subject: [Isis-wg] last call for IPv6 in ISIS .... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 22 Dec 2000 14:32:55 -0800 Content-Transfer-Encoding: 7bit Draft draft-ietf-isis-ipv6-01 goes last call as agreed in the meeting. Last call will end in 2 weeks from now thanks -- 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 Dec 23 01:30: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 BAA24211 for ; Sat, 23 Dec 2000 01:30:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA34113; Fri, 22 Dec 2000 22:54:04 -0800 (PST) Received: from mx3out.umbc.edu (mx3out.umbc.edu [130.85.253.53]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA34101 for ; Fri, 22 Dec 2000 22:53:11 -0800 (PST) Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx3out.umbc.edu (8.9.3/8.9.3) with ESMTP id BAA28453; Sat, 23 Dec 2000 01:26:46 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id BAA306746; Sat, 23 Dec 2000 01:26:46 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs From: Vijay Gill X-Sender: vijay@irix2.gl.umbc.edu To: Henk Smit cc: Cengiz Alaettinoglu , Tony Przygienda , Jeff Parker , hshah@tenornetworks.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <200012230035.BAA01424@kraak.procket.com> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 23 Dec 2000 01:26:46 -0500 On Sat, 23 Dec 2000, Henk Smit wrote: > > Vijay wrote: > Most of this "empirical experience" is based on very old networks > built out of routers with 20 MHz processors (cisco 7000s come to mind). > And in those days the queuing strategies on linecards, and between > linecards and control planes was all less elaborate. I am not going to sit and explain to my management why we made the front page of the WSJ. If I do have to do it, I better have a very good story, and given our past experiences, I'm going to err on the side of caution, till at least someone else of large size has done this and I trust the people running that network. > Thank you very much. But you are exaggerating. I don't think low > holdtimers are the tricky thing to implement fast convergence. The > tricky part is to react quickly to events in your network, without > ever risking a meltdown. There is more to it than just faster hellos. Given the quality of implementations, I think we will just have to agree to disagree ;) (this isn't a slam on any implementation, it is just that operational experience has shown that there are some very subtle and strange interactions in large networks that can cause meltdowns due to combinations of bugs that individually are just annoying.) We are paranoid and crazy for good reason ;) /vijay _______________________________________________ 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 Dec 23 01:36:21 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 BAA25005 for ; Sat, 23 Dec 2000 01:36:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA34195; Fri, 22 Dec 2000 23:00:04 -0800 (PST) Received: from alpha-tony.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA34155 for ; Fri, 22 Dec 2000 22:59:03 -0800 (PST) Received: (from tli@localhost) by alpha-tony.procket.com (8.9.3/8.9.3) id WAA15845; Fri, 22 Dec 2000 22:31:55 -0800 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tony.procket.com: tli set sender to tli@alpha-tony.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14916.18139.104873.14754@alpha-tony.procket.com> To: Tony Przygienda Cc: cengiz@packetdesign.com, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <200012222123.WAA05244@net4u.net4u.ch> References: <14915.39280.503477.749864@localhost.localdomain> <200012222123.WAA05244@net4u.net4u.ch> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 22 Dec 2000 22:31:55 -0800 (PST) Content-Transfer-Encoding: 7bit | thta's all modulo other Tony's opinion of course since I didn't have any | chance to syn up with him on that topic yet ... I'll take that as an invitation to opine: The proposal that has been put forth is a reasonable WG work item. There is clearly an audience and sufficient technical opinion. Therefore, it seems appropriate for the WG to entertain the work. However, I can't believe that this is the best way of solving this problem. The issue that I have with this approach is that it implies that the responsiveness of our systems is now going to drop to sub-second levels. While I can believe that there are real-time systems that can be built with the required responsiveness, not all of them were originally designed this way and the resulting modifications might be more than challenging. Comparatively, the protocol changes are trivial. Are there other things that we can do? Certainly. Make better use of SONET. Make more use of Ethernet link failures. Somehow, just making everything run faster seems like the brute force solution and puts stability at risk. 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 Dec 23 11:09: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 LAA05268 for ; Sat, 23 Dec 2000 11:09:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA38478; Sat, 23 Dec 2000 08:33:05 -0800 (PST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA38466 for ; Sat, 23 Dec 2000 08:32:26 -0800 (PST) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id IAA08794; Sat, 23 Dec 2000 08:06:00 -0800 (PST) From: Mike Truskowski Message-Id: <200012231606.IAA08794@diablo.cisco.com> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers To: tli@procket.com (Tony Li) Cc: prz@net4u.ch, cengiz@packetdesign.com, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net In-Reply-To: <14916.18139.104873.14754@alpha-tony.procket.com>; from "Tony Li" at Dec 22, 100 10:31 pm X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 23 Dec 2000 8:06:00 PST I agree... while you can make the protocols run faster you put a burden on the cpu and bandwidth which generates and transport the intelligence... I do not understand the referal to better use of sonet and/or ethernet link information... I understand the local significance but not the remote side.... Maybe I took this wrong. Mike > > > | thta's all modulo other Tony's opinion of course since I didn't have any > | chance to syn up with him on that topic yet ... > > > I'll take that as an invitation to opine: > > > The proposal that has been put forth is a reasonable WG work item. There > is clearly an audience and sufficient technical opinion. Therefore, it > seems appropriate for the WG to entertain the work. > > > > However, I can't believe that this is the best way of solving this problem. > The issue that I have with this approach is that it implies that the > responsiveness of our systems is now going to drop to sub-second levels. > While I can believe that there are real-time systems that can be built with > the required responsiveness, not all of them were originally designed this > way and the resulting modifications might be more than challenging. > Comparatively, the protocol changes are trivial. > > Are there other things that we can do? Certainly. Make better use of > SONET. Make more use of Ethernet link failures. > > Somehow, just making everything run faster seems like the brute force > solution and puts stability at risk. > > > 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 Tue Dec 26 18:21:05 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 SAA26593 for ; Tue, 26 Dec 2000 18:21:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA56715; Tue, 26 Dec 2000 15:44:05 -0800 (PST) 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 PAA56703 for ; Tue, 26 Dec 2000 15:43:11 -0800 (PST) X-JNPR-Received-From: outside Received: from tcb.net (tcb.net [205.168.100.1]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id PAA27462 for ; Tue, 26 Dec 2000 15:16:21 -0800 (PST) (envelope-from danny@sofos.tcb.net) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id XAA15582 for ; Tue, 26 Dec 2000 23:24:39 -0700 Message-Id: <200012270624.XAA15582@tcb.net> X-Mailer: exmh version 2.0.3 To: isis-wg@juniper.net From: Danny McPherson Reply-To: danny@ambernetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] draft-mcpherson-isis-transient-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Dec 2000 23:24:39 -0700 FYI... It should show up on the IETF ftp server by Thursday. -danny ------------------------------------------------------------------------- Network Working Group Danny McPherson INTERNET DRAFT Amber Networks, Inc. December 2000 IS-IS Transient Blackhole Avoidance 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. 2. Abstract This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. McPherson, D. [Page 1] INTERNET DRAFT December 2000 3. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 4. Introduction When an IS-IS router that was previously a transit router becomes unavailable as a result of some transient condition such as a reboot, other routers within the routing domain must select an alternative path to reach destinations which had previously transited the failed router. Presumably, the newly selected router(s) comprising the path have been available for some time and, as a result, have complete forwarding information bases (FIBs) which contain a full set of reachability information for both internal and external (e.g. BGP) destination networks. When the previously failed router becomes available again, in only a few seconds paths that had previously transited the router are again selected as the optimal path by the IGP. As a result, forwarding tables are updated and packets are once again forwarded along the path. Unfortunately, external destination reachability information (e.g. learned via BGP) is not yet available to the router, and as a result, packets bound for destinations not learned via the IGP are unnecessarily discarded. A mechanism to alleviate the offshoot associated with this deterministic behavior is discussed below. 5. Discussion This document describes a simple, interoperable mechanism that can be employed in IS-IS [1] and [2] networks in order to avoid transition to a newly available path until other associated routing protocols such as BGP have had sufficient time to converge. The benefits of such a mechanism can realized when considering the following scenario. McPherson, D. [Page 2] INTERNET DRAFT December 2000 D.1 | +-------+ | RtrD | +-------+ / \ / \ +-------+ +-------+ | RtrB | | RtrC | +-------+ +-------+ \ / \ / +-------+ | RtrA | +-------+ | S.1 Host S.1 is transmitting data to destination D.1 via a primary path of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to destination D.1 via BGP from RtrD. RtrA's primary path to D.1 is selected because when calculating the path to BGP NEXT_HOP of RtrD the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less than the sum of the metrics of the RtrA-RtrC-RtrD path. Assume RtrB becomes unavailable and as a result the RtrC path to RtrD is used. Once RtrA's FIB is updated and it begins forwarding packets to RtrC everything should behave properly as RtrC has existing forwarding information regarding destination D.1's availability via BGP NEXT_HOP RtrD. Assume now that RtrB comes back online. In only a few seconds IS-IS neighbor state has been established with RtrA and RtrD and database synchronization has occurred. RtrA now realizes that the best path to destination D.1 is via RtrB, and therefore updates it FIB appropriately. RtrA begins to forward packets destined to D.1 to RtrB. Though, because RtrB has yet to establish and synchronization it's BGP neighbor relationship and routing information with RtrD, RtrB has no knowledge regarding reachability of destination D.1, and therefore discards the packets received from RtrA destined to D.1. If RtrB were to temporarily set it's LSP Overload bit while synchronizing BGP tables with it's neighbors, RtrA would continue to use the working RtrA->RtrC->RtrD path, and the LSP should only be used to obtain reachability to locally connected networks (rather than for calculating transit paths through the router, as defined in [1]). McPherson, D. [Page 3] INTERNET DRAFT December 2000 After initial synchronization of BGP tables with neighboring routers, RtrB would generate a new LSP, clearing the Overload bit, and RtrA could again begin using the optimal path via RtrB. Typically, in service provider networks IBGP connections are done via peerings with 'loopback' addresses. As such, the newly available router must advertise it's own loopback, as well as associated adjacencies, in order to make the loopbacks accessible to other routers within the routing domain. It's because of this that simply flooding an empty LSP is not sufficient. 6. Deployment Considerations Such a mechanism increases overall network availability and allows network operators to alleviate the deterministic blackholing behavior introduced in this scenario. Similar mechanisms [3] have been defined for OSPF, though only after realizing similar usefulness obtained from that of the IS-IS Overload bit. This mechanism has been deployed in several large IS-IS networks for several of years. Triggers for setting the Overload bit as described are left to the implementor. Some potential triggers could perhaps include "N seconds after booting", or "N number of BGP prefixes in the BGP Loc- RIB". Unlike similar mechanisms employed in [3], if the Overload bit is set in a router's LSP, NO transit paths are calculated through the router. As such, if no alternative paths are available to the destination network, employing such a mechanism may actually have a negative impact on convergence. Finally, if all systems within an IS-IS routing domain haven't implemented the Overload bit correctly, forwarding loops may occur. McPherson, D. [Page 4] INTERNET DRAFT December 2000 7. Security Considerations The mechanisms specified in this memo introduces no new security issues to IS-IS. 8. Acknowledgements The author of this document makes no claim to the originality of the idea. Others To be supplied... 9. References [1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992. [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. [3] Retana et al., "OSPF Stub Router Advertisement", "Work in Progress", November 2000. 10. Authors' Address Danny McPherson Amber Networks, Inc. 48664 Milmont Drive Fremont, CA 94538 Phone: 510.687.5200 Email: danny@ambernetworks.com McPherson, D. [Page 5] _______________________________________________ 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 Dec 26 18:25:52 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 SAA26655 for ; Tue, 26 Dec 2000 18:25:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA56776; Tue, 26 Dec 2000 15:50:04 -0800 (PST) Received: from cisco.com (frogger.cisco.com [171.71.161.88]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA56761 for ; Tue, 26 Dec 2000 15:49:57 -0800 (PST) Received: from cwhytent2 (cwhyte-isdn1.cisco.com [10.19.229.234]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id PAA09498; Tue, 26 Dec 2000 15:20:58 -0800 (PST) Message-ID: <039201c06f92$5cb136c0$eae5130a@cisco.com> Reply-To: "Chris Whyte" From: "Chris Whyte" To: "Vijay Gill" , "Henk Smit" Cc: "Cengiz Alaettinoglu" , "Tony Przygienda" , "Jeff Parker" , , References: Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers Organization: cisco Systems, Inc. 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Dec 2000 15:19:55 -0800 Content-Transfer-Encoding: 7bit > On Sat, 23 Dec 2000, Henk Smit wrote: > > > > > Vijay wrote: > > > Most of this "empirical experience" is based on very old networks > > built out of routers with 20 MHz processors (cisco 7000s come to mind). > > And in those days the queuing strategies on linecards, and between > > linecards and control planes was all less elaborate. > > I am not going to sit and explain to my management why we made the front > page of the WSJ. If I do have to do it, I better have a very good story, > and given our past experiences, I'm going to err on the side of caution, > till at least someone else of large size has done this and I trust the > people running that network. > And one could argue that some ISPs are making, or will make, the front page of the WSJ because of the additional complexity they're putting in their network just to get around the fact that we can't do sub-second, or just plain faster, igp restoration. My experience says there's a lot of interest in achieving this goal without adding another protocol, technology or whatever to the equation. I would really love to see the WG look long and hard at changing the protocol, if necessary, in order to achieve it. I guess I'm just not convinced that any one specific group has looked at the routing protocols as much as they've looked at other (newer) protocols or technologies which attempt to achieve this goal. I think it would be nice to be able to possibly optimize something that people already know, love and understand than to start somewhat fresh with a new approach that will just add more complexity since the routing protocol certainly isn't going away. > > Thank you very much. But you are exaggerating. I don't think low > > holdtimers are the tricky thing to implement fast convergence. The > > tricky part is to react quickly to events in your network, without > > ever risking a meltdown. There is more to it than just faster hellos. > > Given the quality of implementations, I think we will just have to agree > to disagree ;) (this isn't a slam on any implementation, it is just that > operational experience has shown that there are some very subtle and > strange interactions in large networks that can cause meltdowns due to > combinations of bugs that individually are just annoying.) We are paranoid > and crazy for good reason ;) But I'm really curious, how much experimentation has been done in this area in the last year or so? I really don't know but I suspect it's been minimal. I understand the paranoia but I also believe that some, or much, of this paranoia can be attributed to historical issues that don't necessarily apply to more recent router implementations. And I'd hate to see it continue to gate any possible progress in this area since we have much better separation between data and control planes, faster CPUs and, overall, a much better understanding of some of the fundamental implementation and network design issues that can be done in order to avoid meltdown these days. Thanks, Chris > > /vijay > > > _______________________________________________ > 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 Dec 26 18:58:59 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 SAA27043 for ; Tue, 26 Dec 2000 18:58:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA57042; Tue, 26 Dec 2000 16:23:04 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA56986 for ; Tue, 26 Dec 2000 16:18:01 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14B3s6-000Ezy-00; Tue, 26 Dec 2000 15:51:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Chris Whyte Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <039201c06f92$5cb136c0$eae5130a@cisco.com> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Dec 2000 15:51:10 -0800 Content-Transfer-Encoding: 7bit >> I am not going to sit and explain to my management why we made the front >> page of the WSJ. If I do have to do it, I better have a very good story, >> and given our past experiences, I'm going to err on the side of caution, >> till at least someone else of large size has done this and I trust the >> people running that network. > > And one could argue that some ISPs are making, or will make, the front page > of the WSJ because of the additional complexity they're putting in their > network just to get around the fact that we can't do sub-second, or just > plain faster, igp restoration. yes, but it would be hard to support. e.g. there is a reason for danny's recent draft-mcpherson-isis-transient-00.txt. but we foolish operators do appreciate your concern for us. > My experience says there's a lot of interest in achieving this goal without > adding another protocol, technology or whatever to the equation. I would > really love to see the WG look long and hard at changing the protocol, if > necessary, in order to achieve it. once again, do you really think that this should be a high priority effort given the other problems we face? randy _______________________________________________ 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 Dec 26 19:03:59 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 TAA27133 for ; Tue, 26 Dec 2000 19:03:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA57101; Tue, 26 Dec 2000 16:28:04 -0800 (PST) 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 QAA57089 for ; Tue, 26 Dec 2000 16:27:51 -0800 (PST) X-JNPR-Received-From: outside Received: from tcb.net (tcb.net [205.168.100.1]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id QAA28016 for ; Tue, 26 Dec 2000 16:01:00 -0800 (PST) (envelope-from danny@sofos.tcb.net) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id AAA15973 for ; Wed, 27 Dec 2000 00:09:17 -0700 Message-Id: <200012270709.AAA15973@tcb.net> X-Mailer: exmh version 2.0.3 To: isis-wg@juniper.net From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: [Isis-wg] draft-mcpherson-isis-transient-00.txt 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 00:09:17 -0700 Folks, I also plan to detail an alternative solution here (much more similar to the OSPF Stub Router stuff), which employs really high link metrics during transient conditions in order to make transiting a router less desirable than 'normal' paths. I'll add this once I get a little more feedback on this version of the draft. -danny > > FYI... It should show up on the IETF ftp server by Thursday. > > -danny > > ------------------------------------------------------------------------- > Network Working Group Danny McPherson > INTERNET DRAFT Amber Networks, Inc. > December 2000 > > > > IS-IS Transient Blackhole Avoidance > > > > 1. Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > 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. > > > 2. Abstract > > This document describes a simple, interoperable mechanism that can be > employed in IS-IS networks in order to decrease data loss associated > with deterministic blackholing of packets during transient network > conditions. The mechanism proposed here requires no IS-IS protocol > changes and is completely interoperable with the existing IS-IS > specification. > > > > > > > > > > > McPherson, D. [Page 1] > > > > > > INTERNET DRAFT December 2000 > > > 3. Specification of Requirements > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC 2119]. > > > 4. Introduction > > When an IS-IS router that was previously a transit router becomes > unavailable as a result of some transient condition such as a reboot, > other routers within the routing domain must select an alternative > path to reach destinations which had previously transited the failed > router. Presumably, the newly selected router(s) comprising the path > have been available for some time and, as a result, have complete > forwarding information bases (FIBs) which contain a full set of > reachability information for both internal and external (e.g. BGP) > destination networks. > > When the previously failed router becomes available again, in only a > few seconds paths that had previously transited the router are again > selected as the optimal path by the IGP. As a result, forwarding > tables are updated and packets are once again forwarded along the > path. Unfortunately, external destination reachability information > (e.g. learned via BGP) is not yet available to the router, and as a > result, packets bound for destinations not learned via the IGP are > unnecessarily discarded. > > A mechanism to alleviate the offshoot associated with this > deterministic behavior is discussed below. > > > 5. Discussion > > This document describes a simple, interoperable mechanism that can be > employed in IS-IS [1] and [2] networks in order to avoid transition > to a newly available path until other associated routing protocols > such as BGP have had sufficient time to converge. > > The benefits of such a mechanism can realized when considering the > following scenario. > > > > > > > > > > > McPherson, D. [Page 2] > > > > > > INTERNET DRAFT December 2000 > > > D.1 > | > +-------+ > | RtrD | > +-------+ > / \ > / \ > +-------+ +-------+ > | RtrB | | RtrC | > +-------+ +-------+ > \ / > \ / > +-------+ > | RtrA | > +-------+ > | > S.1 > > Host S.1 is transmitting data to destination D.1 via a primary path > of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to > destination D.1 via BGP from RtrD. RtrA's primary path to D.1 is > selected because when calculating the path to BGP NEXT_HOP of RtrD > the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less > than the sum of the metrics of the RtrA-RtrC-RtrD path. > > Assume RtrB becomes unavailable and as a result the RtrC path to RtrD > is used. Once RtrA's FIB is updated and it begins forwarding packets > to RtrC everything should behave properly as RtrC has existing > forwarding information regarding destination D.1's availability via > BGP NEXT_HOP RtrD. > > Assume now that RtrB comes back online. In only a few seconds IS-IS > neighbor state has been established with RtrA and RtrD and database > synchronization has occurred. RtrA now realizes that the best path > to destination D.1 is via RtrB, and therefore updates it FIB > appropriately. RtrA begins to forward packets destined to D.1 to > RtrB. Though, because RtrB has yet to establish and synchronization > it's BGP neighbor relationship and routing information with RtrD, > RtrB has no knowledge regarding reachability of destination D.1, and > therefore discards the packets received from RtrA destined to D.1. > > If RtrB were to temporarily set it's LSP Overload bit while > synchronizing BGP tables with it's neighbors, RtrA would continue to > use the working RtrA->RtrC->RtrD path, and the LSP should only be > used to obtain reachability to locally connected networks (rather > than for calculating transit paths through the router, as defined in > [1]). > > > > > McPherson, D. [Page 3] > > > > > > INTERNET DRAFT December 2000 > > > After initial synchronization of BGP tables with neighboring routers, > RtrB would generate a new LSP, clearing the Overload bit, and RtrA > could again begin using the optimal path via RtrB. > > Typically, in service provider networks IBGP connections are done via > peerings with 'loopback' addresses. As such, the newly available > router must advertise it's own loopback, as well as associated > adjacencies, in order to make the loopbacks accessible to other > routers within the routing domain. It's because of this that simply > flooding an empty LSP is not sufficient. > > > 6. Deployment Considerations > > Such a mechanism increases overall network availability and allows > network operators to alleviate the deterministic blackholing behavior > introduced in this scenario. Similar mechanisms [3] have been > defined for OSPF, though only after realizing similar usefulness > obtained from that of the IS-IS Overload bit. > > This mechanism has been deployed in several large IS-IS networks for > several of years. > > Triggers for setting the Overload bit as described are left to the > implementor. Some potential triggers could perhaps include "N > seconds after booting", or "N number of BGP prefixes in the BGP Loc- > RIB". > > Unlike similar mechanisms employed in [3], if the Overload bit is set > in a router's LSP, NO transit paths are calculated through the > router. As such, if no alternative paths are available to the > destination network, employing such a mechanism may actually have a > negative impact on convergence. > > Finally, if all systems within an IS-IS routing domain haven't > implemented the Overload bit correctly, forwarding loops may occur. > > > > > > > > > > > > > > > > McPherson, D. [Page 4] > > > > > > INTERNET DRAFT December 2000 > > > 7. Security Considerations > > The mechanisms specified in this memo introduces no new security > issues to IS-IS. > > > 8. Acknowledgements > > The author of this document makes no claim to the originality of the > idea. Others To be supplied... > > > 9. References > > [1] ISO, "Intermediate system to Intermediate system routeing > information exchange protocol for use in conjunction with the > Protocol for providing the Connectionless-mode Network Service > (ISO 8473)," ISO/IEC 10589:1992. > > [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, > December 1990. > > [3] Retana et al., "OSPF Stub Router Advertisement", "Work in > Progress", November 2000. > > > > 10. Authors' Address > > Danny McPherson > Amber Networks, Inc. > 48664 Milmont Drive > Fremont, CA 94538 > Phone: 510.687.5200 > Email: danny@ambernetworks.com > > > > > > > > > > > > > > > > > McPherson, D. [Page 5] > > > > > _______________________________________________ > 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 Dec 26 19:25:05 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 TAA27364 for ; Tue, 26 Dec 2000 19:25:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA57269; Tue, 26 Dec 2000 16:49:04 -0800 (PST) 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 QAA57257 for ; Tue, 26 Dec 2000 16:48:36 -0800 (PST) X-JNPR-Received-From: outside Received: from tcb.net (tcb.net [205.168.100.1]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id QAA28246 for ; Tue, 26 Dec 2000 16:21:45 -0800 (PST) (envelope-from danny@sofos.tcb.net) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id AAA16210 for ; Wed, 27 Dec 2000 00:29:59 -0700 Message-Id: <200012270729.AAA16210@tcb.net> X-Mailer: exmh version 2.0.3 To: isis-wg@juniper.net From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 00:29:59 -0700 > yes, but it would be hard to support. e.g. there is a reason for danny's > recent draft-mcpherson-isis-transient-00.txt. Perhaps we should refocus our efforts here, coupling them with IDR, and coming up with a mechanism to get sub-second BGP table synchronization :-) -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 Dec 26 20:04: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 UAA27762 for ; Tue, 26 Dec 2000 20:04:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA57480; Tue, 26 Dec 2000 17:28:04 -0800 (PST) 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 RAA57468 for ; Tue, 26 Dec 2000 17:27:16 -0800 (PST) X-JNPR-Received-From: outside Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id RAA28711 for ; Tue, 26 Dec 2000 17:00:25 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14B4x2-000FhC-00; Tue, 26 Dec 2000 17:00:20 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Danny McPherson Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012270729.AAA16210@tcb.net> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Dec 2000 17:00:20 -0800 Content-Transfer-Encoding: 7bit > Perhaps we should refocus our efforts here, coupling them > with IDR, and coming up with a mechanism to get sub-second > BGP table synchronization :-) i'll settle for 30 second, see abha's, abhijit's, and craig's most excellent http://www.acm.org/sigcomm2000/conf/paper/sigcomm2000-5-2.ps.gz and http://www.nanog.org/mtg-0010/labovitz.html but more germane to is-is, cengiz's, haobo's, and van's http://www.nanog.org/mtg-0010/ppt/cengiz.pdf which does suggest finer timers, but only after more modern spf calculation. and it neglects to consider such silly operational concers as addressed by your draft. randy _______________________________________________ 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 Dec 26 20:06:59 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 UAA27780 for ; Tue, 26 Dec 2000 20:06:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA57525; Tue, 26 Dec 2000 17:31:04 -0800 (PST) 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 RAA57513 for ; Tue, 26 Dec 2000 17:30:34 -0800 (PST) X-JNPR-Received-From: outside Received: from tcb.net (tcb.net [205.168.100.1]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id RAA28732 for ; Tue, 26 Dec 2000 17:03:43 -0800 (PST) (envelope-from danny@sofos.tcb.net) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id BAA16580; Wed, 27 Dec 2000 01:11:59 -0700 Message-Id: <200012270811.BAA16580@tcb.net> X-Mailer: exmh version 2.0.3 To: Randy Bush cc: isis-wg@juniper.net From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 01:11:59 -0700 > i'll settle for 30 second, see abha's, abhijit's, and craig's most excellent > > http://www.acm.org/sigcomm2000/conf/paper/sigcomm2000-5-2.ps.gz > and http://www.nanog.org/mtg-0010/labovitz.html > > but more germane to is-is, cengiz's, haobo's, and van's > > http://www.nanog.org/mtg-0010/ppt/cengiz.pdf > > which does suggest finer timers, but only after more modern spf calculation. Seen both the above documents (a few times), though the pointers should certainly be of benefit to others on the list. > and it neglects to consider such silly operational concers as addressed by > your draft. Hence the timing :-) -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 Wed Dec 27 02:31:43 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 CAA15108 for ; Wed, 27 Dec 2000 02:31:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA59090; Tue, 26 Dec 2000 23:55:04 -0800 (PST) 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 XAA59075 for ; Tue, 26 Dec 2000 23:54:26 -0800 (PST) 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 XAA22342; Tue, 26 Dec 2000 23:25:27 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id XAA17692; Tue, 26 Dec 2000 23:25:27 -0800 (PST) Message-Id: <200012270725.XAA17692@cirrus.juniper.net> From: Dave Katz To: cwhyte@cisco.com CC: vijay@umbc.edu, henk@procket.com, cengiz@packetdesign.com, prz@net4u.ch, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net In-reply-to: <039201c06f92$5cb136c0$eae5130a@cisco.com> (cwhyte@cisco.com) Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Dec 2000 23:25:27 -0800 (PST) Simple issue. This is not really a protocol issue, but a fundamental implementation issue. At least at this time, the dominant implementations are done in run-to-completion schedulers, and as such are a train wreck in the making. The protocol can do one second hold times now, and a trivial extension could choose something even shorter, but until we all reimplement our routers with true real-time o/s's this will never work (for large values of "work," as in "you bet your business on it.") Then if some of us fix it, we will get interesting partial collapses instead (I've alread seen this multiple times involving another familiar link-state IGP.) My mantra for years has been, "the implementations have a long way to go before we hit the fundamental limitations of the protocols" and I still believe this to be true in multiple dimensions. Reply-To: "Chris Whyte" From: "Chris Whyte" Cc: "Cengiz Alaettinoglu" , "Tony Przygienda" , "Jeff Parker" , , References: Organization: cisco Systems, Inc. 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Dec 2000 15:19:55 -0800 > On Sat, 23 Dec 2000, Henk Smit wrote: > > > > > Vijay wrote: > > > Most of this "empirical experience" is based on very old networks > > built out of routers with 20 MHz processors (cisco 7000s come to mind). > > And in those days the queuing strategies on linecards, and between > > linecards and control planes was all less elaborate. > > I am not going to sit and explain to my management why we made the front > page of the WSJ. If I do have to do it, I better have a very good story, > and given our past experiences, I'm going to err on the side of caution, > till at least someone else of large size has done this and I trust the > people running that network. > And one could argue that some ISPs are making, or will make, the front page of the WSJ because of the additional complexity they're putting in their network just to get around the fact that we can't do sub-second, or just plain faster, igp restoration. My experience says there's a lot of interest in achieving this goal without adding another protocol, technology or whatever to the equation. I would really love to see the WG look long and hard at changing the protocol, if necessary, in order to achieve it. I guess I'm just not convinced that any one specific group has looked at the routing protocols as much as they've looked at other (newer) protocols or technologies which attempt to achieve this goal. I think it would be nice to be able to possibly optimize something that people already know, love and understand than to start somewhat fresh with a new approach that will just add more complexity since the routing protocol certainly isn't going away. > > Thank you very much. But you are exaggerating. I don't think low > > holdtimers are the tricky thing to implement fast convergence. The > > tricky part is to react quickly to events in your network, without > > ever risking a meltdown. There is more to it than just faster hellos. > > Given the quality of implementations, I think we will just have to agree > to disagree ;) (this isn't a slam on any implementation, it is just that > operational experience has shown that there are some very subtle and > strange interactions in large networks that can cause meltdowns due to > combinations of bugs that individually are just annoying.) We are paranoid > and crazy for good reason ;) But I'm really curious, how much experimentation has been done in this area in the last year or so? I really don't know but I suspect it's been minimal. I understand the paranoia but I also believe that some, or much, of this paranoia can be attributed to historical issues that don't necessarily apply to more recent router implementations. And I'd hate to see it continue to gate any possible progress in this area since we have much better separation between data and control planes, faster CPUs and, overall, a much better understanding of some of the fundamental implementation and network design issues that can be done in order to avoid meltdown these days. Thanks, Chris > > /vijay > > > _______________________________________________ > 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 Wed Dec 27 12:07: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 MAA19524 for ; Wed, 27 Dec 2000 12:07:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA61554; Wed, 27 Dec 2000 09:31:04 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA61542 for ; Wed, 27 Dec 2000 09:30:28 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01399; Wed, 27 Dec 2000 09:03:30 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA17816; Wed, 27 Dec 2000 12:03:29 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id eBRH3dJ145161; Wed, 27 Dec 2000 12:03:39 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14922.8426.701703.522053@gargle.gargle.HOWL> From: James Carlson To: Mike Truskowski Cc: tli@procket.com (Tony Li), prz@net4u.ch, cengiz@packetdesign.com, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: Mike Truskowski's message of 23 December 2000 08:06:00 References: <14916.18139.104873.14754@alpha-tony.procket.com> <200012231606.IAA08794@diablo.cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 12:03:38 -0500 (EST) Content-Transfer-Encoding: 7bit Mike Truskowski writes: > I do not understand the referal to better use of sonet > and/or ethernet link information... I understand the > local significance but not the remote side.... Maybe > I took this wrong. For SONET, you could reasonably send RDI-P upstream if something untoward happens to your local routing process or your ability to forward received packets. On detecting a positive loss of service by reception of RDI-P at the other end, you could remove the link from your database and start negotiation over from scratch when the defect disappears. On point-to-point Ethernet, you could probably do something similar by taking the link out of sync intentionally for the duration of your local outage. Assuming the peer has been properly implemented to monitor link status, this should give rapid and accurate indication of remote failure. For multi-access Ethernet, there's obviously a problem. However, since there are few 10BASE5 systems left, the worst problem can be ignored. For the remainder, it'd be helpful to get the bridge ("switch") vendors to support notification of link loss in a manner that'd work well with routing protocol implementations. I can see how detecting failure at the routing protocol level might not be avoidable in some situations, but I think fast-hello is a band-aid at best, and a likely source of instability and scalability trouble. The detection and propagation of failure information isn't just a routing protocol issue; it's a system issue. I don't think that this should be carried to the other extreme either (lengthening the hello interval). The hello exchange provides a reliable upper bound on the delay of upper level failure detection in case the other failure notification mechanisms themselves fail. It's important, but it shouldn't be the only means of detecting problems. (For what it's worth, similar issues occur with many other protocols, such as RIP. Most of these protocols have a "goodbye" mechanism [such as sending out infinite hop count routes] that can be used to speed up failure detection.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp _______________________________________________ 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 Dec 27 13:50: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 NAA20304 for ; Wed, 27 Dec 2000 13:50:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA61998; Wed, 27 Dec 2000 11:14:04 -0800 (PST) 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 LAA61986 for ; Wed, 27 Dec 2000 11:13:56 -0800 (PST) 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 KAA14290; Wed, 27 Dec 2000 10:47:00 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id KAA18750; Wed, 27 Dec 2000 10:47:00 -0800 (PST) Message-Id: <200012271847.KAA18750@cirrus.juniper.net> From: Dave Katz To: rbush@bainbridge.verio.net CC: isis-wg@spider.juniper.net In-reply-to: (message from Randy Bush on Wed, 27 Dec 2000 06:59:12 -0800) Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 10:47:00 -0800 (PST) what do you think of van's point that waiting for three hello timeouts, as opposed to noticing the physical (or framing) link going down, may be contributing the largest part of convergence delay? and, if you believe it, how might making such a change affect stability? randy Well, if there is physical evidence that the link has gone down, every implementation that I know of will respond to it. The hello timeout is definitely the slowest part of the *IGP* convergence (assuming that there is no low-level signalling to glean), but in the kinds of networks I'm familiar with (big, expensive, and full of ~100K BGP routes) the problem is much broader. If you have to change the next hops on tens of thousands of routes, this can take a sizable chunk of time (no, I don't have any hard numbers). The IGP implementations that I'm familiar with (one of which I haven't seen the innards of in almost four years, so I can't vouch for its current state) are pretty heavily biased toward stability at the expense of convergence, due to "interesting" field experience. We haven't seen an IGP meltdown (well, at least an ISIS meltdown) in a major network in quite awhile, knock on wood. Given this, perhaps its not a bad time to open up the covers again and think about convergence improvements *very* carefully (I really don't want to see a New York Times article with the headline, "MegaNet down for 19 hours; programmer sought") but part of this careful analysis has to be looking at what the *real* issues are, and where the target-rich environments lie. For example, how often do links fail, in real life, in such a way that nobody tells the protocol and it has to time out? (And how many of those failures-to-communicate are due to bugs?) What are the factors that contribute to global convergence (as opposed to a localized picture of IGP convergence?) Like all cases of premature optimization, it's at best a waste of time (and at worst destabilizing) to start playing with things without really knowing what's going on. All of this can be done outside the protocol spec, which is why I don't feel that there's any real pressure in tinkering with the protocol at this time. If it turns out that the holdtime delay is truly important, and reducing it by an order of magnitude will truly reap more than negligible benefits (I'm skeptical) then we've got some interesting software architectural work ahead of us to pull this off in a way that won't endanger the stability of the infrastructure. It's a *lot* more work than just twisting timers. (For fun, go set the hello interval to 1 and the hold time to 3 and then take a major transient, say, in BGP, and then see how things hold up...) --Dave _______________________________________________ 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 Dec 27 14:38: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 OAA23161 for ; Wed, 27 Dec 2000 14:38:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA62255; Wed, 27 Dec 2000 12:03:04 -0800 (PST) Received: from cisco.com (frogger.cisco.com [171.71.161.88]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA62243 for ; Wed, 27 Dec 2000 12:02:11 -0800 (PST) Received: from cwhytent2 (cwhyte-isdn1.cisco.com [10.19.229.234]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id LAA16547; Wed, 27 Dec 2000 11:33:36 -0800 (PST) Message-ID: <004b01c0703b$cdbc3960$eae5130a@cisco.com> Reply-To: "Chris Whyte" From: "Chris Whyte" To: "Dave Katz" Cc: , , , , , , References: <200012270725.XAA17692@cirrus.juniper.net> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers Organization: cisco Systems, Inc. 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 11:32:50 -0800 Content-Transfer-Encoding: 7bit Ok. I have two questions/comments then... 1. So are you saying that the suggestions made in draft-alaettinoglu-isis-convergence-00.txt, which do involve a change to is-is, aren't worth pursuing because of the reason(s) below? 2. Forgive my ignorance but it's not clear to me why we shouldn't continue to pursue changes to spec (eg shorter hold times), which ISPs appear to be interested in, given that there are at least some vendors working on true real-time o/s router implementations. Don't we always want to be in the situation where "the implementations have a long way to go before we hit the fundamental limitations of the protocols"? Thanks, Chris > Simple issue. This is not really a protocol issue, but a fundamental > implementation issue. At least at this time, the dominant > implementations are done in run-to-completion schedulers, and as such > are a train wreck in the making. > > The protocol can do one second hold times now, and a trivial extension > could choose something even shorter, but until we all reimplement our > routers with true real-time o/s's this will never work (for large > values of "work," as in "you bet your business on it.") > > Then if some of us fix it, we will get interesting partial collapses > instead (I've alread seen this multiple times involving another familiar > link-state IGP.) > > My mantra for years has been, "the implementations have a long way to go > before we hit the fundamental limitations of the protocols" and I still > believe this to be true in multiple dimensions. > > Reply-To: "Chris Whyte" > From: "Chris Whyte" > Cc: "Cengiz Alaettinoglu" , > "Tony Przygienda" , "Jeff Parker" , > , > References: > Organization: cisco Systems, Inc. > 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-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Tue, 26 Dec 2000 15:19:55 -0800 > > > On Sat, 23 Dec 2000, Henk Smit wrote: > > > > > > > > Vijay wrote: > > > > > Most of this "empirical experience" is based on very old networks > > > built out of routers with 20 MHz processors (cisco 7000s come to mind). > > > And in those days the queuing strategies on linecards, and between > > > linecards and control planes was all less elaborate. > > > > I am not going to sit and explain to my management why we made the front > > page of the WSJ. If I do have to do it, I better have a very good story, > > and given our past experiences, I'm going to err on the side of caution, > > till at least someone else of large size has done this and I trust the > > people running that network. > > > > And one could argue that some ISPs are making, or will make, the front page > of the WSJ because of the additional complexity they're putting in their > network just to get around the fact that we can't do sub-second, or just > plain faster, igp restoration. > > My experience says there's a lot of interest in achieving this goal without > adding another protocol, technology or whatever to the equation. I would > really love to see the WG look long and hard at changing the protocol, if > necessary, in order to achieve it. > > I guess I'm just not convinced that any one specific group has looked at the > routing protocols as much as they've looked at other (newer) protocols or > technologies which attempt to achieve this goal. I think it would be nice to > be able to possibly optimize something that people already know, love and > understand than to start somewhat fresh with a new approach that will just > add more complexity since the routing protocol certainly isn't going away. > > > > Thank you very much. But you are exaggerating. I don't think low > > > holdtimers are the tricky thing to implement fast convergence. The > > > tricky part is to react quickly to events in your network, without > > > ever risking a meltdown. There is more to it than just faster hellos. > > > > Given the quality of implementations, I think we will just have to agree > > to disagree ;) (this isn't a slam on any implementation, it is just that > > operational experience has shown that there are some very subtle and > > strange interactions in large networks that can cause meltdowns due to > > combinations of bugs that individually are just annoying.) We are paranoid > > and crazy for good reason ;) > > But I'm really curious, how much experimentation has been done in this area > in the last year or so? I really don't know but I suspect it's been minimal. > I understand the paranoia but I also believe that some, or much, of this > paranoia can be attributed to historical issues that don't necessarily apply > to more recent router implementations. And I'd hate to see it continue to > gate any possible progress in this area since we have much better separation > between data and control planes, faster CPUs and, overall, a much better > understanding of some of the fundamental implementation and network design > issues that can be done in order to avoid meltdown these days. > > Thanks, > > Chris > > > > > /vijay > > > > > > _______________________________________________ > > 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 Wed Dec 27 16:06: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 QAA24430 for ; Wed, 27 Dec 2000 16:06:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA62638; Wed, 27 Dec 2000 13:30:05 -0800 (PST) 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 NAA62623 for ; Wed, 27 Dec 2000 13:29:36 -0800 (PST) Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by postal.redback.com (Postfix) with ESMTP id 2078117BC04; Wed, 27 Dec 2000 13:02:29 -0800 (PST) Message-ID: <3A4A49BE.DC8E34A0@redback.com> From: Tony Przygienda Organization: Siara Systems X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dave Katz Cc: cwhyte@cisco.com, vijay@umbc.edu, henk@procket.com, cengiz@packetdesign.com, prz@net4u.ch, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012270725.XAA17692@cirrus.juniper.net> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 11:57:50 -0800 Content-Transfer-Encoding: 7bit Dave Katz wrote: > Simple issue. This is not really a protocol issue, but a fundamental > implementation issue. At least at this time, the dominant > implementations are done in run-to-completion schedulers, and as such > are a train wreck in the making. yes and no, if you go away from the run-to-completion scheduler and _even_ if you implement the whole thing on a real-time scheduler, let's say understanding priority and relative & absolute slip, you face another monster, namely locking of which a protocol like ISIS will have plenty, even in the hello processing/generation ;-) It is a perversity well-known in the database world (and IGPs are nothing else but distributed, loosely synchronized, real-time databases) that once you go into pre-emption, not your procedural/task design determines runtime behavior but primarily your locking disciplines/granularity/frequence/priority inheritance. Therefore you design high-performance databases these days starting from the locking disciplines & granularity and not from task/operating system side. At least last time I checked (and I admit it's a while) ;-) So, my strong feeling is that once you go into this realm you end up being very disappointed with what you can achieve by just adding preemptive, real-time tasks unless you start from designing your database specifically for the performance profile you want to achieve. Nobody tackled that one yet as far as I know in the IP world. Again, to prevent bashing, I'm _not_ saying it can_not_ be done, I'm just pointing out another piece of the dragon you get out the cave when you grab the beatiful end of the tail sticking out ;-) > The protocol can do one second hold times now, and a trivial extension > could choose something even shorter, but until we all reimplement our > routers with true real-time o/s's this will never work (for large > values of "work," as in "you bet your business on it.") > > Then if some of us fix it, we will get interesting partial collapses > instead (I've alread seen this multiple times involving another familiar > link-state IGP.) > > My mantra for years has been, "the implementations have a long way to go > before we hit the fundamental limitations of the protocols" and I still > believe this to be true in multiple dimensions. yes ;-) ... thanks --- 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 Wed Dec 27 16:08:49 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 QAA24465 for ; Wed, 27 Dec 2000 16:08:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA62673; Wed, 27 Dec 2000 13:33:05 -0800 (PST) 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 NAA62654 for ; Wed, 27 Dec 2000 13:32:00 -0800 (PST) Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by postal.redback.com (Postfix) with ESMTP id A22FB17BC05; Wed, 27 Dec 2000 13:04:58 -0800 (PST) Message-ID: <3A4A4A54.8EDDFF83@redback.com> From: Tony Przygienda Organization: Siara Systems X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dave Katz Cc: cwhyte@cisco.com, vijay@umbc.edu, henk@procket.com, cengiz@packetdesign.com, prz@net4u.ch, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012270725.XAA17692@cirrus.juniper.net> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 12:00:20 -0800 Content-Transfer-Encoding: 7bit Dave Katz wrote: > Simple issue. This is not really a protocol issue, but a fundamental > implementation issue. At least at this time, the dominant > implementations are done in run-to-completion schedulers, and as such > are a train wreck in the making. yes and no, if you go away from the run-to-completion scheduler and _even_ if you implement the whole thing on a real-time scheduler, let's say understanding priority and relative & absolute slip, you face another monster, namely locking ;-) It is a perversity well-known in the database world (and IGPs are nothing else but distributed, loosely synchronized, real-time databases) that once you go into pre-emption, not your procedural/task design determines runtime behavior but primarily your locking disciplines/granularity/frequence/priority inheritance. Therefore you design high-performance databases these days starting from the locking disciplines & granularity and not from task/operating system side. At least last time I checked (and I admit it's a while) ;-) So, my strong feeling is that once you go into this realm you end up being very disappointed with what you can achieve unless you start to design your protocol starting from the locking behavior and as far I know nobody tried that in the IP world yet. > The protocol can do one second hold times now, and a trivial extension > could choose something even shorter, but until we all reimplement our > routers with true real-time o/s's this will never work (for large > values of "work," as in "you bet your business on it.") > > Then if some of us fix it, we will get interesting partial collapses > instead (I've alread seen this multiple times involving another familiar > link-state IGP.) > > My mantra for years has been, "the implementations have a long way to go > before we hit the fundamental limitations of the protocols" and I still > believe this to be true in multiple dimensions. yes ;-) ... --- 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 Wed Dec 27 16:11: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 QAA24553 for ; Wed, 27 Dec 2000 16:11:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA62716; Wed, 27 Dec 2000 13:36:05 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA61065 for ; Wed, 27 Dec 2000 07:26:08 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14BI2q-0005Gd-00; Wed, 27 Dec 2000 06:59:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Dave Katz Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <039201c06f92$5cb136c0$eae5130a@cisco.com> <200012270725.XAA17692@cirrus.juniper.net> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 06:59:12 -0800 Content-Transfer-Encoding: 7bit dave, what do you think of van's point that waiting for three hello timeouts, as opposed to noticing the physical (or framing) link going down, may be contributing the largest part of convergence delay? and, if you believe it, how might making such a change affect stability? randy _______________________________________________ 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 Dec 27 16:44: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 QAA25140 for ; Wed, 27 Dec 2000 16:44:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA63007; Wed, 27 Dec 2000 14:09:05 -0800 (PST) Received: from nasty.xebeo.com (gw.xebeo.com [204.192.44.242]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA62892 for ; Wed, 27 Dec 2000 13:56:39 -0800 (PST) Received: from bigbird.xebeo.com (IDENT:root@bigbird [192.168.0.3]) by nasty.xebeo.com (8.9.3/8.9.3) with ESMTP id RAA29808; Wed, 27 Dec 2000 17:30:07 -0500 Received: from bigbird.xebeo.com (IDENT:rohit@localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id QAA24794; Wed, 27 Dec 2000 16:24:15 -0500 Message-Id: <200012272124.QAA24794@bigbird.xebeo.com> To: Tony Przygienda cc: Dave Katz , cwhyte@cisco.com, vijay@umbc.edu, henk@procket.com, cengiz@packetdesign.com, prz@net4u.ch, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: Your message of "Wed, 27 Dec 2000 12:00:20 PST." <3A4A4A54.8EDDFF83@redback.com> From: Rohit Dube Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 16:24:15 -0500 On Wed, 27 Dec 2000 12:00:20 -0800 Tony Przygienda writes: => =>Dave Katz wrote: => =>> Simple issue. This is not really a protocol issue, but a fundamental =>> implementation issue. At least at this time, the dominant =>> implementations are done in run-to-completion schedulers, and as such =>> are a train wreck in the making. => =>yes and no, if you go away from the run-to-completion scheduler and _even_ =>if you implement the whole thing on a real-time scheduler, let's say understa >nding =>priority and relative & absolute slip, you face another monster, namely locki >ng ;-) => =>It is a perversity well-known in the database world (and IGPs are nothing els >e =>but distributed, loosely synchronized, real-time databases) that once you go >into =>pre-emption, not your procedural/task design determines runtime behavior =>but primarily your locking disciplines/granularity/frequence/priority inherit >ance. =>Therefore you design high-performance databases these days starting from =>the locking disciplines & granularity and not from task/operating system sid >e. At least =>last time I checked (and I admit it's a while) ;-) And don't forget you access methods - concurrent B+-tree access and the like. (And those who use lower fan-out balanced trees may want to check out some work by Sabine Hanke et al - http://www.imada.ou.dk/~kslarsen/RelBal/) From my own experience doing similar work both with Databases and IGPs/Route-table managers, optimizing performance with locking can get fairly hairy and depends not just on granualrity and locking disciplines but also on workloads (number of readers, writers) and lock-timeout algorithms in addition to the points that you mention. FWIW, --rohit. _______________________________________________ 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 Dec 27 18:34:44 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 SAA26150 for ; Wed, 27 Dec 2000 18:34:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA63487; Wed, 27 Dec 2000 15:59:05 -0800 (PST) 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 PAA63475 for ; Wed, 27 Dec 2000 15:58:55 -0800 (PST) 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 PAA29226; Wed, 27 Dec 2000 15:29:49 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id PAA19459; Wed, 27 Dec 2000 15:29:49 -0800 (PST) Message-Id: <200012272329.PAA19459@cirrus.juniper.net> From: Dave Katz To: cwhyte@cisco.com CC: vijay@umbc.edu, henk@procket.com, cengiz@packetdesign.com, prz@net4u.ch, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net In-reply-to: <004b01c0703b$cdbc3960$eae5130a@cisco.com> (cwhyte@cisco.com) Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 15:29:49 -0800 (PST) 1. So are you saying that the suggestions made in draft-alaettinoglu-isis-convergence-00.txt, which do involve a change to is-is, aren't worth pursuing because of the reason(s) below? I haven't had time to read this in detail, though I did have a private discussion with Van & Co. about the contents, and a brief reading seemed to line up with the discussion. There are certainly things in these implementations that could be done better, and some of them would be quite easy (though others may not be). The reservation I have with this work is that it does not characterize the potential gains in real world environments, and we should all be loathe to open the covers on our protocol implementations without understanding what the real gains will be. I just don't like making front page news, and as a matter of principle I don't like to do something this risky without a clear idea of why. The stakes are just too high. It's worth noting that, no matter how hard they hammered on the implementations, they couldn't make them fall over. There is a reason for this. I'm not opposed to the suggestions made, either in implementation issues or in protocol extensions. It's a very useful thing for someone to have taken a look at this stuff and to have made a reasoned and intelligent analysis. My only point is that, from a pragmatic standpoint with deployed products and operational networks, we have lots of room for improvement in other areas before doing invasive surgery on the IGPs. Convergence is a much broader issue, with many interesting (and unexpected) interactions, than simply finishing an SPF quickly. 2. Forgive my ignorance but it's not clear to me why we shouldn't continue to pursue changes to spec (eg shorter hold times), which ISPs appear to be interested in, given that there are at least some vendors working on true real-time o/s router implementations. I have no objection to pursuing protocol extensions, particularly backward compatible ones, if people want to do this. I don't think, however, that ISPs are interested in protocol changes; rather, they are interested in improving overall convergence times while maintaining the stability of their networks. Those that are convinced that speeding up hello times or SPF implementations will make their networks much better have been sold a bill of goods--it's just not that simple. A vendor that can field a very large network that will remain stable while maintaining one second hold times will have done very impressive work deserving of high profit margins, without having touched the protocol. It should be interesting to see. Having done that, said vendor should be well positioned to explore the subsecond realm. Don't we always want to be in the situation where "the implementations have a long way to go before we hit the fundamental limitations of the protocols"? Absolutely not. Where we want to be is in the position where the networks have a long way to go before they hit the fundamental limitations of the protocol implementations. Only then will the fundamental limitations of the protocol prove really interesting. _______________________________________________ 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 Dec 27 18:42: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 SAA26193 for ; Wed, 27 Dec 2000 18:42:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA63546; Wed, 27 Dec 2000 16:07:04 -0800 (PST) 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 QAA63534 for ; Wed, 27 Dec 2000 16:06:19 -0800 (PST) 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 PAA29863; Wed, 27 Dec 2000 15:37:17 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id PAA19479; Wed, 27 Dec 2000 15:37:17 -0800 (PST) Message-Id: <200012272337.PAA19479@cirrus.juniper.net> From: Dave Katz To: prz@redback.com CC: cwhyte@cisco.com, vijay@umbc.edu, henk@procket.com, cengiz@packetdesign.com, prz@net4u.ch, jparker@axiowave.com, hshah@tenornetworks.com, isis-wg@spider.juniper.net In-reply-to: <3A4A49BE.DC8E34A0@redback.com> (message from Tony Przygienda on Wed, 27 Dec 2000 11:57:50 -0800) Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 15:37:17 -0800 (PST) X-JNPR-Received-From: outside yes and no, if you go away from the run-to-completion scheduler and _even_ if you implement the whole thing on a real-time scheduler, let's say understanding priority and relative & absolute slip, you face another monster, namely locking of which a protocol like ISIS will have plenty, even in the hello processing/generation ;-) No argument here. I would, in fact, like all of my competitors to port all of their code to a preemptive o/s immediately. ;-) I've had to talk people out of this idea many times over the years--you trade an obvious problem for a whole bunch of really subtle ones. Even naive protocol implementations are difficult. Scalable, stable ones are very difficult (look at how many are out there.) Scalable, stable, fast ones are even harder still. --Dave _______________________________________________ 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 Dec 27 18:57:16 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 SAA26331 for ; Wed, 27 Dec 2000 18:57:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA63678; Wed, 27 Dec 2000 16:22:04 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA63666 for ; Wed, 27 Dec 2000 16:21:12 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14BQOc-000AcJ-00; Wed, 27 Dec 2000 15:54:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Katz Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012271847.KAA18750@cirrus.juniper.net> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 15:54:14 -0800 Content-Transfer-Encoding: 7bit > what do you think of van's point that waiting for three hello timeouts, > as opposed to noticing the physical (or framing) link going down, may > be contributing the largest part of convergence delay? and, if you > believe it, how might making such a change affect stability? > Well, if there is physical evidence that the link has gone down, every > implementation that I know of will respond to it. i would have thought so. but van seems to think otherwise, and claims measurement to boot. > The IGP implementations that I'm familiar with (one of which I haven't > seen the innards of in almost four years, so I can't vouch for its current > state) are pretty heavily biased toward stability at the expense of > convergence, due to "interesting" field experience. i assure you that some of us deeply appreciate this spoilsport approach, boring though others may think it. randy _______________________________________________ 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 Dec 27 19:27:16 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 TAA26715 for ; Wed, 27 Dec 2000 19:27:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA63834; Wed, 27 Dec 2000 16:52:04 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA63822 for ; Wed, 27 Dec 2000 16:51:24 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14BQrq-000Aw4-00; Wed, 27 Dec 2000 16:24:26 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Katz Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 16:24:26 -0800 Content-Transfer-Encoding: 7bit > I have no objection to pursuing protocol extensions, particularly > backward compatible ones, if people want to do this. I don't think, > however, that ISPs are interested in protocol changes wrongo! to paraphrase mo, i want lots of them made available. so my competitors can try them. randy _______________________________________________ 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 Dec 27 19:44: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 TAA26833 for ; Wed, 27 Dec 2000 19:44:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA63973; Wed, 27 Dec 2000 17:09:05 -0800 (PST) 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 RAA63961 for ; Wed, 27 Dec 2000 17:08:11 -0800 (PST) Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by postal.redback.com (Postfix) with ESMTP id 5A7F217BC0C; Wed, 27 Dec 2000 16:41:14 -0800 (PST) Message-ID: <3A4A7D03.48E913F6@redback.com> From: Tony Przygienda Organization: Siara Systems X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush Cc: Dave Katz , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 15:36:35 -0800 Content-Transfer-Encoding: 7bit Randy Bush wrote: > > I have no objection to pursuing protocol extensions, particularly > > backward compatible ones, if people want to do this. I don't think, > > however, that ISPs are interested in protocol changes > > wrongo! to paraphrase mo, i want lots of them made available. so my > competitors can try them. carefull Randy, some people on this list MAY take you literally ;-) -- 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 Wed Dec 27 21:00:30 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 VAA27409 for ; Wed, 27 Dec 2000 21:00:29 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA64401; Wed, 27 Dec 2000 18:25:05 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA64339 for ; Wed, 27 Dec 2000 18:18:45 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14BSEM-000Bmc-00; Wed, 27 Dec 2000 17:51:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Tony Przygienda Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> <3A4A7D03.48E913F6@redback.com> Message-Id: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 17:51:46 -0800 Content-Transfer-Encoding: 7bit >>> I have no objection to pursuing protocol extensions, particularly >>> backward compatible ones, if people want to do this. I don't think, >>> however, that ISPs are interested in protocol changes >> wrongo! to paraphrase mo, i want lots of them made available. so my >> competitors can try them. > carefull Randy, some people on this list MAY take you literally ;-) but we just *love* to read about our competitors's meltdowns in the wsj. after all, what's the fun in running a boring network when you can look oh so modern and clever in front of your drinking friends at nanog? randy _______________________________________________ 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 Dec 28 00:43: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 AAA01175 for ; Thu, 28 Dec 2000 00:43:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA65363; Wed, 27 Dec 2000 22:07:04 -0800 (PST) Received: from cisco.com (frogger.cisco.com [171.71.161.88]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA65351 for ; Wed, 27 Dec 2000 22:06:13 -0800 (PST) Received: from cwhytent2 (cwhyte-isdn1.cisco.com [10.19.229.234]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id VAA09634; Wed, 27 Dec 2000 21:38:42 -0800 (PST) Message-ID: <009c01c07090$551d50c0$eae5130a@cisco.com> Reply-To: "Chris Whyte" From: "Chris Whyte" To: "Randy Bush" , "Tony Przygienda" Cc: References: <004b01c0703b$cdbc3960$eae5130a@cisco.com><200012272329.PAA19459@cirrus.juniper.net><3A4A7D03.48E913F6@redback.com> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers Organization: cisco Systems, Inc. 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Dec 2000 21:37:55 -0800 Content-Transfer-Encoding: 7bit > >>> I have no objection to pursuing protocol extensions, particularly > >>> backward compatible ones, if people want to do this. I don't think, > >>> however, that ISPs are interested in protocol changes > >> wrongo! to paraphrase mo, i want lots of them made available. so my > >> competitors can try them. > > carefull Randy, some people on this list MAY take you literally ;-) > > but we just *love* to read about our competitors's meltdowns in the wsj. > after all, what's the fun in running a boring network when you can look > oh so modern and clever in front of your drinking friends at nanog? > Well hell, I love boring and simplistic but maybe someone can explain why changes to the protocol to achieve something like faster restoration is more operationally complex than a large mesh of TE and bypass tunnels (ie FRR), which also requires changes to the protocol. And certainly running a network that uses the latter approach is no walk in the park. I realize I'm mixing a bit of operational complexity concern with protocol implementation issues but is it simply that the risk of meltdown is much greater? And if so, are there not things we can do like using an spf backoff algorithm in the face of instability to prevent meltdown (very similar to Henk's old work)? And if this is not interesting to others, or is beyond the scope of the mailing list, please respond to me offlist. I would be more than fascinated to hear people's opinions/answers. Thanks, Chris > randy > _______________________________________________ > 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 Dec 28 03:09:44 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 DAA14346 for ; Thu, 28 Dec 2000 03:09:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA65972; Thu, 28 Dec 2000 00:33:05 -0800 (PST) Received: from alpha-tony.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA65960 for ; Thu, 28 Dec 2000 00:32:57 -0800 (PST) Received: (from tli@localhost) by alpha-tony.procket.com (8.9.3/8.9.3) id AAA28062; Thu, 28 Dec 2000 00:05:36 -0800 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tony.procket.com: tli set sender to tli@alpha-tony.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14922.62544.735986.360952@alpha-tony.procket.com> To: "Chris Whyte" Cc: "Randy Bush" , "Tony Przygienda" , Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <009c01c07090$551d50c0$eae5130a@cisco.com> References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> <3A4A7D03.48E913F6@redback.com> <009c01c07090$551d50c0$eae5130a@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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 28 Dec 2000 00:05:36 -0800 (PST) Content-Transfer-Encoding: 7bit Chris, | Well hell, I love boring and simplistic but maybe someone can explain why | changes to the protocol to achieve something like faster restoration is more | operationally complex than a large mesh of TE and bypass tunnels (ie FRR), | which also requires changes to the protocol. And certainly running a network | that uses the latter approach is no walk in the park. One last time: it's not the changes to the protocol. It's the changes to the rest of the system. For the routing protocol to detect a loss of adjacency at the rates that are proposed, the routing protocol process must run at much higher rates to generate the hello packets, receive them, and time out failed adjacencies. Given the current run-to-completion operating system schedulers that we all seem to use, you basically have two choices: either try to run to completion with MUCH tighter timers throughout the ENTIRE operating system or convert to a pre-emptive scheduling mechanism. Both are fraught with risk. Whereas if you take a look at a TE approach, you find that the underlying protocol has NOT changed in any substantive way. It's being (ab)used as a mechanism for transporting unnatural information, but the dynamics of the protocol itself has not changed one whit. It's absolutely true that there's more complexity in the TE code. But when (not if) it breaks, all it does is to cause localized failures in the TE subsystem. Basic unicast routing should be very much unaffected. | I realize I'm mixing a bit of operational complexity concern with protocol | implementation issues but is it simply that the risk of meltdown is much | greater? And if so, are there not things we can do like using an spf backoff | algorithm in the face of instability to prevent meltdown (very similar to | Henk's old work)? Again, it's not the speed of SPFs that matter. It's that you now have to be able to respond to a timer expiration within 10ms or so. That's about three orders of magnitude faster than today. 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 Dec 29 05:24:44 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 FAA08576 for ; Fri, 29 Dec 2000 05:24:42 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA72307; Fri, 29 Dec 2000 02:49:04 -0800 (PST) Received: from c000.zsm.cp.net (c000-h007.c000.zsm.cp.net [209.228.56.66]) by external.juniper.net (8.9.3/8.9.3) with SMTP id CAA72295 for ; Fri, 29 Dec 2000 02:48:14 -0800 (PST) From: navaneeth@www.com Received: (cpmta 9092 invoked from network); 29 Dec 2000 02:21:06 -0800 Message-ID: <20001229102106.9091.cpmta@c000.zsm.cp.net> X-Sent: 29 Dec 2000 10:21:06 GMT Received: from [202.106.13.250] by mail.www.com with HTTP; 29 Dec 2000 02:21:06 PST Content-Type: text/plain; charset=unicode-1-1-utf-8 Content-Disposition: inline Mime-Version: 1.0 To: isis-wg@spider.juniper.net X-Mailer: Web Mail 3.0 Subject: [Isis-wg] Clarification on isisCommands... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 29 Dec 2000 02:21:06 -0800 Hi, Can anybody clarify the use of the Cisco Commandline default-information originate (IS-IS): From the Cli doc of cisco START :: To generate a default route into an IS-IS routing domain, use the default-information originate router configuration command. To disable this feature, use the no form of this command. default-information originate [route-map map-name] no default-information originate [route-map map-name] END:: What does this commsnd do? In the explanation it says, if the command is used without routemap option, the IS has to advertise the default route in its L2 Lsps. If the route map is specified, based on the route map, the default route must be conditinally advertised in the L1 LSPs. What is the use of this default route being advertised in the LSPs? How is the advertised default route processed? Thanx and Regards Navaneeth. ______________________________________________________ Listen to your favorite music while you work! - http://www.com/ ------- End of forwarded message ------- ______________________________________________________ Listen to your favorite music while you work! - http://www.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 Fri Dec 29 09:28:21 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 JAA09490 for ; Fri, 29 Dec 2000 09:28:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA73282; Fri, 29 Dec 2000 06:53:05 -0800 (PST) Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA73270 for ; Fri, 29 Dec 2000 06:52:54 -0800 (PST) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JYA504ZJ3E0001T7@research.kpn.com> for isis-wg@spider.juniper.net; Fri, 29 Dec 2000 15:25:43 +0100 Received: by L04 with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Dec 2000 15:25:39 +0100 Content-return: allowed From: "Metz, E.T." Subject: RE: [Isis-wg] [IS-IS WG] Subsecond Timers To: "'Tony Li'" , Chris Whyte Cc: Randy Bush , Tony Przygienda , isis-wg@spider.juniper.net Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A711@L04> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 29 Dec 2000 15:25:36 +0100 > > Given the current run-to-completion operating system > schedulers that we all > seem to use, you basically have two choices: either try to run to > completion with MUCH tighter timers throughout the ENTIRE > operating system > or convert to a pre-emptive scheduling mechanism. Both are > fraught with > risk. > If implementation of "very tight timers" is a real big issue (and I'll gladly take your word for that), how does this relate to protocols like LMP? This relies on timers in the milli-second range, which is hard, if not impossible if I understand correctly. Would these protocols (FLIP is the other I believe) require a complete re-do of the router OS, or can they implemented in another way. cheers, Eduard ps could someone elaborate on the (possible) side-effects of subsecond timers in ISIS (or any IGP)? there were some hints to things go wrong, but without revealing what and why ... thanks. _______________________________________________ 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 Dec 29 15:07:52 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 PAA12503 for ; Fri, 29 Dec 2000 15:07:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA74593; Fri, 29 Dec 2000 12:32:05 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA74581 for ; Fri, 29 Dec 2000 12:31:41 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id UAA05885; Fri, 29 Dec 2000 20:57:22 +0100 From: Tony Przygienda Message-Id: <200012291957.UAA05885@net4u.net4u.ch> Subject: Re: [Isis-wg] Clarification on isisCommands... In-Reply-To: <20001229102106.9091.cpmta@c000.zsm.cp.net> from "navaneeth@www.com" at "Dec 29, 2000 2:21: 6 am" To: navaneeth@www.com Cc: isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 29 Dec 2000 20:57:22 +0100 (MET) Content-Transfer-Encoding: 7bit Questions about syntax/semantics of specific vendor implementaions should NOT be posted to this forum. This is rather a qeustion for a vendor support organization or maybe nanog. --- 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 Dec 29 15:14: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 PAA12569 for ; Fri, 29 Dec 2000 15:14:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA74669; Fri, 29 Dec 2000 12:39:05 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA74632 for ; Fri, 29 Dec 2000 12:37:59 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id VAA05987; Fri, 29 Dec 2000 21:03:18 +0100 From: Tony Przygienda Message-Id: <200012292003.VAA05987@net4u.net4u.ch> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <59063B5B4D98D311BC0D0001FA7E45220316A711@L04> from "Metz, E.T." at "Dec 29, 2000 3:25:36 pm" To: E.T.Metz@kpn.com (Metz, E.T.) Cc: tli@procket.com, cwhyte@cisco.com, rbush@bainbridge.verio.net, prz@redback.com, isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 29 Dec 2000 21:03:17 +0100 (MET) Content-Transfer-Encoding: 7bit > > > > > Given the current run-to-completion operating system > > schedulers that we all > > seem to use, you basically have two choices: either try to run to > > completion with MUCH tighter timers throughout the ENTIRE > > operating system > > or convert to a pre-emptive scheduling mechanism. Both are > > fraught with > > risk. > > > > If implementation of "very tight timers" is a real big issue (and I'll > gladly take your word for that), how does this relate to protocols like LMP? > This relies on timers in the milli-second range, which is hard, if not > impossible if I understand correctly. Would these protocols (FLIP is the > other I believe) require a complete re-do of the router OS, or can they > implemented in another way. this is a very deep question to which a simplistic answer is "depends on the layer". Analogy: it is hard to handle interrupts in unix user space, not so hard in well-written kernel drivers. Therefore certain protocols, especially those very close to hardware (e.g. BLSR ;-) can run in a very fine resolution. Traditionally, layer 3 protocols like ISIS are not that close to hardware in many respects and there having such fast answer times or what I use to call "small intertia" is hard ... Although there are people who tried OSPF in ASICs, at least the design ;-) > ps could someone elaborate on the (possible) side-effects of subsecond > timers in ISIS (or any IGP)? there were some hints to things go wrong, but > without revealing what and why ... thanks. I would encourage this discussion to happen rather on a protocol implementation related list, gated or zebra comes into my mind. This list & group is concerned with the specification, interoperability and deployment issues of the protocol and NOT implementation techniques. Otherwise all the ISPs will become bored and run away and will start to do geeks-cool-things instead of the right-for-customer-things. thanks -- 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 Dec 29 18:18:53 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 SAA14045 for ; Fri, 29 Dec 2000 18:18:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA75404; Fri, 29 Dec 2000 15:43:05 -0800 (PST) Received: from cisco.com (frogger.cisco.com [171.71.161.88]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA75392 for ; Fri, 29 Dec 2000 15:42:20 -0800 (PST) Received: from cwhytent2 (cwhyte-isdn1.cisco.com [10.19.229.234]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id PAA04264; Fri, 29 Dec 2000 15:14:19 -0800 (PST) Message-ID: <022901c071ec$f50db270$eae5130a@cisco.com> Reply-To: "Chris Whyte" From: "Chris Whyte" To: "Tony Li" Cc: "Randy Bush" , "Tony Przygienda" , References: <004b01c0703b$cdbc3960$eae5130a@cisco.com><200012272329.PAA19459@cirrus.juniper.net><3A4A7D03.48E913F6@redback.com><009c01c07090$551d50c0$eae5130a@cisco.com> <14922.62544.735986.360952@alpha-tony.procket.com> Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers Organization: cisco Systems, Inc. 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-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 29 Dec 2000 15:13:28 -0800 Content-Transfer-Encoding: 7bit > > Chris, > > | Well hell, I love boring and simplistic but maybe someone can explain why > | changes to the protocol to achieve something like faster restoration is more > | operationally complex than a large mesh of TE and bypass tunnels (ie FRR), > | which also requires changes to the protocol. And certainly running a network > | that uses the latter approach is no walk in the park. > > > One last time: it's not the changes to the protocol. It's the changes to > the rest of the system. For the routing protocol to detect a loss of > adjacency at the rates that are proposed, the routing protocol process must > run at much higher rates to generate the hello packets, receive them, and > time out failed adjacencies. Yes, I understood that. Sorry, I'm quite stubburn. I sometimes ask people to repeat things more than once. :-) > > Given the current run-to-completion operating system schedulers that we all > seem to use, you basically have two choices: either try to run to > completion with MUCH tighter timers throughout the ENTIRE operating system > or convert to a pre-emptive scheduling mechanism. Both are fraught with > risk. Ok. I think that one has sunk in. > > Whereas if you take a look at a TE approach, you find that the underlying > protocol has NOT changed in any substantive way. It's being (ab)used as a > mechanism for transporting unnatural information, but the dynamics of the > protocol itself has not changed one whit. It's absolutely true that > there's more complexity in the TE code. But when (not if) it breaks, all > it does is to cause localized failures in the TE subsystem. Basic unicast > routing should be very much unaffected. So everything above clearly helps me understand the protocol differences and how they impact the (rest of the) system but it what about the operational differences? My experience says there are also lots of big problems in networks due to operational complexity. And, as you admitted, since there's more complexity in the TE code then this clearly should increase operational challenges. Yes, I know... this is something that I'm sure you all would prefer to discuss somewhere else. My only goal (other than learning from this thread) is that I would like to see if there are any changes to the protocol that can be made in order to achieve convergence in the neighborhood of hundreds of milliseconds (I'm not necessarily stuck on some number like 50ms) yet not substantially increase operational complexity (or at least what I consider to be operational complexity :-)). And as someone else mentioned to me recently; convergence goals of milliseconds really requires better abstraction boundaries along with some richer metrics (eg 1-prop delay + 2-some link quality indicator to weight 1). I believe the former requires a slight fundamental change in how we design networks today (maybe not) and the latter has challenges in how we can make a multi-metric truly useful. Anyway, you get my point. > > > | I realize I'm mixing a bit of operational complexity concern with protocol > | implementation issues but is it simply that the risk of meltdown is much > | greater? And if so, are there not things we can do like using an spf backoff > | algorithm in the face of instability to prevent meltdown (very similar to > | Henk's old work)? > > > Again, it's not the speed of SPFs that matter. It's that you now have to > be able to respond to a timer expiration within 10ms or so. That's about > three orders of magnitude faster than today. I never said 10ms. I'd be very happy with 3 x 200ms (like I said above). :-) But hey, if you think I'm just wasting your time (and my time), I'll shut up. Thanks, Chris > > 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 Sun Dec 31 01:58:27 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 BAA13082 for ; Sun, 31 Dec 2000 01:58:27 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA84636; Sat, 30 Dec 2000 23:22:06 -0800 (PST) Received: from c000.zsm.cp.net (c000-h003.c000.zsm.cp.net [209.228.56.62]) by external.juniper.net (8.9.3/8.9.3) with SMTP id XAA84624 for ; Sat, 30 Dec 2000 23:21:07 -0800 (PST) From: navaneeth@www.com Received: (cpmta 11601 invoked from network); 30 Dec 2000 22:53:47 -0800 Message-ID: <20001231065347.11600.cpmta@c000.zsm.cp.net> X-Sent: 31 Dec 2000 06:53:47 GMT Received: from [61.135.3.208] by mail.www.com with HTTP; 30 Dec 2000 22:53:47 PST Content-Type: text/plain; charset=unicode-1-1-utf-8 Content-Disposition: inline Mime-Version: 1.0 To: isis-wg@spider.juniper.net X-Mailer: Web Mail 3.0 Subject: [Isis-wg] Clarification Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 30 Dec 2000 22:53:47 -0800 Hi All, Considering the functionality of a default route, do we at any time need to advertise the default route in the L1 / L2 LSPs. If so what are the conditions under which we advertise these and when we receive, how do we process the default route.( in case we already have a nearest L2 IS). Thanx and Regards Navaneeth. ______________________________________________________ Listen to your favorite music while you work! - http://www.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 Sun Dec 31 05:14: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 FAA07090 for ; Sun, 31 Dec 2000 05:14:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA85580; Sun, 31 Dec 2000 02:39:04 -0800 (PST) Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA85568 for ; Sun, 31 Dec 2000 02:38:37 -0800 (PST) Received: from localnet.cwnt.co.il (ras6-p82.hfa.netvision.net.il [62.0.101.82]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id MAA24062; Sun, 31 Dec 2000 12:11:06 +0200 (IST) Received: from 192.168.0.44 ([192.168.0.44]) by localnet.cwnt.co.il (WinRoute 3.04g) with SMTP; Sun, 31 Dec 2000 11:38:23 +0200 Message-ID: <012101c0731f$3e8aad30$2c00a8c0@amir> From: "Amir H." To: Cc: "ISIS-wg" References: <20001231065347.11600.cpmta@c000.zsm.cp.net> Subject: Re: [Isis-wg] Clarification Organization: Charlotte's Web Networks LTD MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 31 Dec 2000 11:45:59 -0000 Content-Transfer-Encoding: 7bit Navaneeth, There is a difference between a default route injected into the IS-IS domain, and the route to the nearest L2 IS. A router advertising a default route is attracting traffic which fits into that prefix (which actually is all traffic). So, if there is no more specific prefix for a given IP address, this route will be used. In this context, this is no different than any another route. So, you'd process it just like you'd process other IP External Reachability entries. This is relevant in both level-1 and level-2 routers. The nearest L2 IS is only relevant in level-1 (and level-2 un-attached routers), and is used when a destination is not within an area, according to RFC1195. However, RFC1195 does not allow external prefixes to be injected into a level-1 area, whereas the current practice and recent drafts do allow it. I'd say that this changes a bit the definition in the RFC1195, to destinations not _advertised_ within an area. So, if a router advertises a default route into the area, it should be used, just like other external prefixes not in the area, and not the nearest L2 IS (even if it's closer in metric). The same is for a level-2 unattached router. Note, however, that injection of default routes into the IS-IS domain should be done VERY carefully. Hope this helps, Amir. -- Amir Hermelin mailto:amir@cwnt.com ----- Original Message ----- From: To: Sent: Sunday, December 31, 2000 6:53 AM Subject: [Isis-wg] Clarification > Hi All, > > Considering the functionality of a default route, > do we at any time need to advertise the default route in the L1 / L2 LSPs. If so what are the conditions under which we advertise these and when we receive, how do we process the default route.( in case we already have a nearest L2 IS). > > Thanx and Regards > Navaneeth. > > > ______________________________________________________ > Listen to your favorite music while you work! > - http://www.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 From isis-wg-admin@spider.juniper.net Sun Dec 31 15:37: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 PAA08527 for ; Sun, 31 Dec 2000 15:37:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA88001; Sun, 31 Dec 2000 13:02:05 -0800 (PST) Received: from c000.zsm.cp.net (c000-h009.c000.zsm.cp.net [209.228.56.68]) by external.juniper.net (8.9.3/8.9.3) with SMTP id CAA72121 for ; Fri, 29 Dec 2000 02:12:47 -0800 (PST) From: navaneeth@www.com Received: (cpmta 24006 invoked from network); 29 Dec 2000 01:45:39 -0800 Message-ID: <20001229094539.24005.cpmta@c000.zsm.cp.net> X-Sent: 29 Dec 2000 09:45:39 GMT Received: from [202.106.6.222] by mail.www.com with HTTP; 29 Dec 2000 01:45:39 PST Content-Type: text/plain; charset=unicode-1-1-utf-8 Content-Disposition: inline Mime-Version: 1.0 To: isis-wg@spider.juniper.net Cc: navaneeth@www.com X-Mailer: Web Mail 3.0 Subject: [Isis-wg] Clarification on isisCommands... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 29 Dec 2000 01:45:39 -0800 Hi, Can anybody clarify the use of the Cisco Commandline default-information originate (IS-IS): From the Cli doc of cisco START :: To generate a default route into an IS-IS routing domain, use the default-information originate router configuration command. To disable this feature, use the no form of this command. default-information originate [route-map map-name] no default-information originate [route-map map-name] END:: What does this commsnd do? In the explanation it says, if the command is used without routemap option, the IS has to advertise the default route in its L2 Lsps. If the route map is specified, based on the route map, the default route must be conditinally advertised in the L1 LSPs. What is the use of this default route being advertised in the LSPs? How is the advertised default route processed? Thanx and Regards Navaneeth. ______________________________________________________ Listen to your favorite music while you work! - http://www.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 Sun Dec 31 15:38: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 PAA08539 for ; Sun, 31 Dec 2000 15:38:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA88020; Sun, 31 Dec 2000 13:03:05 -0800 (PST) Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA87293 for ; Sun, 31 Dec 2000 10:03:34 -0800 (PST) Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 9B86E82651 for ; Sun, 31 Dec 2000 12:35:02 -0500 (EST) Message-Id: <5.0.0.25.2.20001231121912.00a01ca0@gnat.inet.org> X-Sender: rja@gnat.inet.org X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: isis-wg@spider.juniper.net From: RJ Atkinson In-Reply-To: <039201c06f92$5cb136c0$eae5130a@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Isis-wg] Re: [IS-IS WG] Subsecond Timers Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 31 Dec 2000 12:27:34 -0500 At 18:19 26/12/00, Chris Whyte wrote: >And one could argue that some ISPs are making, or will make, >the front page of the WSJ because of the additional complexity >they're putting in their network just to get around the fact >that we can't do sub-second, or just plain faster, igp restoration. One could argue anything I suppose; the particular example above would be a false argument as it happens. >But I'm really curious, how much experimentation has been done >in this area in the last year or so? I really don't know >but I suspect it's been minimal. Hence the desire to do some *science* with some *controlled experiments* on any proposal in this area BEFORE the IETF *standardises* any changes to a protocol that works. On this list, so far, folks are NOT saying "never change the protocol". Folks ARE saying, please let the interested folks run some scientific private experiments, document the changes made, and their results, and let the proposal have some good peer review -- BEFORE we *standardise* a change to the protocol. None of these items require ANY IETF action be taken *yet*. Folks like Van have, for many years, done the science and run appropriate experiments *before* coming to an IETF WG to propose changes to standards. If folks have documented results from some small scale or large scale experiments, please post a pointer to the documentation on the change made, the experimental setup, and the results. If folks have small scale results that are positive and want to try a large scale experiment, one approach would be to describe the change and the experiment in an EXPERIMENTAL RFC. Then, AFTER there is a high level of confidence in the proposal, based on such experiments, one could move the potential spec change into a non-experimental RFC. 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 Sun Dec 31 15:38: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 PAA08549 for ; Sun, 31 Dec 2000 15:38:24 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA88036; Sun, 31 Dec 2000 13:03:13 -0800 (PST) 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 KAA87350 for ; Sun, 31 Dec 2000 10:14:39 -0800 (PST) X-JNPR-Received-From: outside Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id JAA06743 for ; Sun, 31 Dec 2000 09:47:15 -0800 (PST) (envelope-from rja@inet.org) Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 0AEF482651 for ; Sun, 31 Dec 2000 12:46:07 -0500 (EST) Message-Id: <5.0.0.25.2.20001231123511.00a01870@gnat.inet.org> X-Sender: rja@gnat.inet.org X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: isis-wg@juniper.net From: RJ Atkinson In-Reply-To: <022901c071ec$f50db270$eae5130a@cisco.com> References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> <3A4A7D03.48E913F6@redback.com> <009c01c07090$551d50c0$eae5130a@cisco.com> <14922.62544.735986.360952@alpha-tony.procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Isis-wg] Re: [IS-IS WG] Subsecond Timers Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 31 Dec 2000 12:38:38 -0500 At 18:13 29/12/00, someone wrote: >My only goal (other than learning from this thread) is that >I would like to see if there are any changes to the protocol >that can be made in order to achieve convergence in the >neighborhood of hundreds of milliseconds (I'm not necessarily >stuck on some number like 50ms) yet not substantially increase >operational complexity (or at least what I consider to be >operational complexity :-)). It is fascinating to me that there is still interest in "changes to the protocol" after several folks have suggested that convergence time improvements by tuning one's implementation (without a protocol change) are more likely to be a ripe opportunity. My guess would be that whoever had good/valid/stable ideas about tuning without a protocol change and made them work would sell a lot more product than one who wanted/needed to change the protocol. Ran _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg