From isis-wg-bounces@ietf.org Wed Apr 2 10:28:04 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FFF3A6AEE; Wed, 2 Apr 2008 10:28:04 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B013828C3CB for ; Wed, 2 Apr 2008 10:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAMZgbphQRsY for ; Wed, 2 Apr 2008 10:28:02 -0700 (PDT) Received: from smtp108.biz.mail.mud.yahoo.com (smtp108.biz.mail.mud.yahoo.com [68.142.201.177]) by core3.amsl.com (Postfix) with SMTP id D36D828C32D for ; Wed, 2 Apr 2008 10:28:01 -0700 (PDT) Received: (qmail 62394 invoked from network); 2 Apr 2008 17:28:03 -0000 Received: from unknown (HELO ?171.70.244.166?) (chopps@rawdofmt.org@171.70.244.166 with plain) by smtp108.biz.mail.mud.yahoo.com with SMTP; 2 Apr 2008 17:28:02 -0000 X-Yahoo-Newman-Property: ymail-3 Message-Id: <2CC6D283-535C-4117-9D6C-6BFC922EA2FB@rawdofmt.org> From: Christian Hopps To: Christian Hopps In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 10:28:03 -0700 References: X-Mailer: Apple Mail (2.919.2) Cc: "David Ward \(wardd\)" , isis mailing list Subject: [Isis-wg] Corrected IETF-71 Minutes posted. X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org An corrected set of minutes are now available at the below URL. Changed sections have been marked "[corr]". http://www.ietf.org/proceedings/08mar/minutes/isis.txt Chris & Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Apr 2 12:00:08 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947FC28C59E; Wed, 2 Apr 2008 12:00:08 -0700 (PDT) X-Original-To: isis-wg@ietf.org Delivered-To: isis-wg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1E62F28C43F; Wed, 2 Apr 2008 12:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080402190002.1E62F28C43F@core3.amsl.com> Date: Wed, 2 Apr 2008 12:00:02 -0700 (PDT) Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-rfc3373bis-00.txt Pages : 14 Date : 2008-4-2 The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc3373bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isis-rfc3373bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-2115203.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Thu Apr 3 06:36:25 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA313A6BC9; Thu, 3 Apr 2008 06:36:25 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905823A6BC9 for ; Thu, 3 Apr 2008 06:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqmIPLMEJttn for ; Thu, 3 Apr 2008 06:36:24 -0700 (PDT) Received: from softy.ision.net (softy.ision.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id B394B3A6B7F for ; Thu, 3 Apr 2008 06:36:24 -0700 (PDT) Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1JhPcB-0001Hu-0H for isis-wg@ietf.org; Thu, 03 Apr 2008 15:36:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 15:36:27 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interface loop detection in IS-IS Thread-Index: AciVj7b0Sj+WHvICT+uFHIAaANSrEQ== From: "Ilya Varlashkin" To: "IETF IS-IS" Subject: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, With current trend using Ethernet for backbone links and running IS-IS (often using p2p hello) would it be not good idea to add extra level of protection in IS-IS to detect interfaces which are looped? With traditional serial interfaces one could force interface to go down when a loop detected, with Ethernet this is most of the time not the case. I've observed in personal practice that certain types of IS-IS implementations get at least upset if they see HELLO with the same sys-id, worst case I've seen was messed up LSDB on all routers that share it (i.e. all level-2 routers) and some traffic was blackholed. Simple solution to the interface loop could be adding some sort of a cookie to hello PDU. If a router detects HELLO with its own sys-id which also contains cookie that this router send, then it can deduce that there is a loop on the interface and should stop further processing of such HELLO. The cookie could be implemented either by introducing new TLV or extending existing TLV. Taking into account that there is currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis), one approach would be to add cookie field at the end of TLV #240. Is there interest in this group to consider such functionality extention for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis in general are wrong place for this, would it be of interest to have separate draft for interface loop detection mechanism for IS-IS? Cheers, iLya _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 08:17:10 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466E228C6FE; Thu, 3 Apr 2008 08:17:10 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07E828C6F2 for ; Thu, 3 Apr 2008 08:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oQ0CPwsNNac for ; Thu, 3 Apr 2008 08:17:08 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D2F8328C71B for ; Thu, 3 Apr 2008 08:16:43 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m33FGke2024551 for ; Thu, 3 Apr 2008 15:16:47 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m33FGjhN012889 for ; Thu, 3 Apr 2008 11:16:45 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m33EvrN8020469; Thu, 3 Apr 2008 10:57:53 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m33EvdRY020464; Thu, 3 Apr 2008 10:57:39 -0400 (EDT) MIME-Version: 1.0 Message-ID: <18420.61539.233292.175886@gargle.gargle.HOWL> Date: Thu, 3 Apr 2008 10:57:39 -0400 From: James Carlson To: Ilya Varlashkin In-Reply-To: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Ilya Varlashkin writes: > Simple solution to the interface loop could be adding some sort of a > cookie to hello PDU. If a router detects HELLO with its own sys-id which Such a cookie already exists, at least on media that have multiple connected endpoints and MAC-layer addresses: the source MAC address will tell you whether what you've received is one of your own messages with a fairly high degree of confidence. For media without MAC-layer addresses (point-to-point), the link layer should have its own looped-back detection, but checking System ID alone should be good enough. The only thing I could see a cookie helping with would be a spoofed (or manually misconfigured) source MAC address ... but it doesn't sound like that's the concern here. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 08:19:15 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45603A6BF7; Thu, 3 Apr 2008 08:19:15 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAAC3A6929 for ; Thu, 3 Apr 2008 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhTBF6HuDLLj for ; Thu, 3 Apr 2008 08:19:13 -0700 (PDT) Received: from t40.gredler.at (unknown [88.116.9.78]) by core3.amsl.com (Postfix) with ESMTP id 8742428C6ED for ; Thu, 3 Apr 2008 08:19:11 -0700 (PDT) Received: from t40.gredler.at (t40.gredler.at [127.0.0.1]) by t40.gredler.at (8.14.0/8.14.0) with ESMTP id m33FJYG0006458; Thu, 3 Apr 2008 17:19:34 +0200 Received: (from hannes@localhost) by t40.gredler.at (8.14.0/8.14.0/Submit) id m33FJWaC006457; Thu, 3 Apr 2008 17:19:32 +0200 Date: Thu, 3 Apr 2008 17:19:32 +0200 From: Hannes Gredler To: Ilya Varlashkin Message-ID: <20080403151931.GA6439@juniper.net> References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Thu, Apr 03, 2008 at 03:36:27PM +0200, Ilya Varlashkin wrote: | With current trend using Ethernet for backbone links and running IS-IS | (often using p2p hello) would it be not good idea to add extra level of | protection in IS-IS to detect interfaces which are looped? With | traditional serial interfaces one could force interface to go down when | a loop detected, with Ethernet this is most of the time not the case. | I've observed in personal practice that certain types of IS-IS | implementations get at least upset if they see HELLO with the same | sys-id, worst case I've seen was messed up LSDB on all routers that | share it (i.e. all level-2 routers) and some traffic was blackholed. | Simple solution to the interface loop could be adding some sort of a | cookie to hello PDU. If a router detects HELLO with its own sys-id which | also contains cookie that this router send, then it can deduce that | there is a loop on the interface and should stop further processing of | such HELLO. The cookie could be implemented either by introducing new | TLV or extending existing TLV. Taking into account that there is | currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis), | one approach would be to add cookie field at the end of TLV #240. | | Is there interest in this group to consider such functionality extention | for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis | in general are wrong place for this, would it be of interest to have | separate draft for interface loop detection mechanism for IS-IS? ilya, can you explain why matching our own sysid against the sysid in the IIH (and subsequent discard of such PDUs) is not sufficient for loop prevention ? /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 08:57:06 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1CC3A6C56; Thu, 3 Apr 2008 08:57:06 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A21D3A6C88 for ; Thu, 3 Apr 2008 08:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IauYnbHwO-O for ; Thu, 3 Apr 2008 08:57:00 -0700 (PDT) Received: from catapult.middlebury.edu (catapult.middlebury.edu [140.233.2.12]) by core3.amsl.com (Postfix) with ESMTP id 8264E3A6C56 for ; Thu, 3 Apr 2008 08:57:00 -0700 (PDT) X-ASG-Debug-ID: 1207238222-608400190000-JVPge0 X-ASG-Debug-ID: 1207238222-608400190000-JVPge0 X-ASG-Debug-ID: 1207238222-608400190000-JVPge0 X-Barracuda-URL: http://140.233.2.12:80/cgi-bin/mark.cgi Received: from junglecat.middlebury.edu (junglecat.middlebury.edu [140.233.2.175]) by catapult.middlebury.edu (Spam Firewall) with ESMTP id 800F115359E; Thu, 3 Apr 2008 11:57:02 -0400 (EDT) Received: from junglecat.middlebury.edu (junglecat.middlebury.edu [140.233.2.175]) by catapult.middlebury.edu with ESMTP id 8Y8QSnRoPGpcLfgE (version=TLSv1 cipher=RC4-MD5 bits=128 verify=NO); Thu, 03 Apr 2008 11:57:02 -0400 (EDT) Received: from PANTHER.middlebury.edu ([140.233.2.171]) by junglecat.middlebury.edu ([140.233.2.175]) with mapi; Thu, 3 Apr 2008 11:57:02 -0400 From: "Parker, Jeff" To: Hannes Gredler , Ilya Varlashkin Date: Thu, 3 Apr 2008 11:56:01 -0400 X-ASG-Orig-Subj: RE: [Isis-wg] Interface loop detection in IS-IS Thread-Topic: [Isis-wg] Interface loop detection in IS-IS Thread-Index: AciVnipuaAZjc6kiTb25FDRvvlvcSAABQxAJ Message-ID: References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net>, <20080403151931.GA6439@juniper.net> In-Reply-To: <20080403151931.GA6439@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Barracuda-Connect: junglecat.middlebury.edu[140.233.2.175] X-Barracuda-Start-Time: 1207238222 X-Barracuda-Encrypted: RC4-MD5 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at middlebury.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.46730 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I assume this is to distinguish between the case of a duplicate SysID and the case of a looped interface. - jeff parker ________________________________________ From: isis-wg-bounces@ietf.org [isis-wg-bounces@ietf.org] On Behalf Of Hannes Gredler [hannes@juniper.net] Sent: Thursday, April 03, 2008 11:19 AM To: Ilya Varlashkin Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS On Thu, Apr 03, 2008 at 03:36:27PM +0200, Ilya Varlashkin wrote: | With current trend using Ethernet for backbone links and running IS-IS | (often using p2p hello) would it be not good idea to add extra level of | protection in IS-IS to detect interfaces which are looped? With | traditional serial interfaces one could force interface to go down when | a loop detected, with Ethernet this is most of the time not the case. | I've observed in personal practice that certain types of IS-IS | implementations get at least upset if they see HELLO with the same | sys-id, worst case I've seen was messed up LSDB on all routers that | share it (i.e. all level-2 routers) and some traffic was blackholed. | Simple solution to the interface loop could be adding some sort of a | cookie to hello PDU. If a router detects HELLO with its own sys-id which | also contains cookie that this router send, then it can deduce that | there is a loop on the interface and should stop further processing of | such HELLO. The cookie could be implemented either by introducing new | TLV or extending existing TLV. Taking into account that there is | currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis), | one approach would be to add cookie field at the end of TLV #240. | | Is there interest in this group to consider such functionality extention | for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis | in general are wrong place for this, would it be of interest to have | separate draft for interface loop detection mechanism for IS-IS? ilya, can you explain why matching our own sysid against the sysid in the IIH (and subsequent discard of such PDUs) is not sufficient for loop prevention ? /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 09:12:27 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D6728C6EF; Thu, 3 Apr 2008 09:12:27 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F72028C71F for ; Thu, 3 Apr 2008 09:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnxVQu0PBZ+a for ; Thu, 3 Apr 2008 09:12:18 -0700 (PDT) Received: from t40.gredler.at (unknown [88.116.9.78]) by core3.amsl.com (Postfix) with ESMTP id BF9DA3A6F6E for ; Thu, 3 Apr 2008 09:10:38 -0700 (PDT) Received: from t40.gredler.at (t40.gredler.at [127.0.0.1]) by t40.gredler.at (8.14.0/8.14.0) with ESMTP id m33GAxTY006765; Thu, 3 Apr 2008 18:11:00 +0200 Received: (from hannes@localhost) by t40.gredler.at (8.14.0/8.14.0/Submit) id m33GAv4O006764; Thu, 3 Apr 2008 18:10:57 +0200 Date: Thu, 3 Apr 2008 18:10:57 +0200 From: Hannes Gredler To: "Parker, Jeff" Message-ID: <20080403161056.GA6737@juniper.net> References: <20080403151931.GA6439@juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org well, whats the point distinguishing those two cases ? the ultimate action -> "log and discard" is the same. for troubleshooting purposes looking at the contents (extended local circuit-id!) and length of TLV #240, should provide enough information to distinguish between the two. /hannes On Thu, Apr 03, 2008 at 11:56:01AM -0400, Parker, Jeff wrote: | I assume this is to distinguish between the case of a duplicate SysID | and the case of a looped interface. | | - jeff parker | ________________________________________ | From: Hannes Gredler [hannes@juniper.net] | Sent: Thursday, April 03, 2008 11:19 AM | To: Ilya Varlashkin | Cc: IETF IS-IS | Subject: Re: [Isis-wg] Interface loop detection in IS-IS | | On Thu, Apr 03, 2008 at 03:36:27PM +0200, Ilya Varlashkin wrote: | | With current trend using Ethernet for backbone links and running IS-IS | | (often using p2p hello) would it be not good idea to add extra level of | | protection in IS-IS to detect interfaces which are looped? With | | traditional serial interfaces one could force interface to go down when | | a loop detected, with Ethernet this is most of the time not the case. | | I've observed in personal practice that certain types of IS-IS | | implementations get at least upset if they see HELLO with the same | | sys-id, worst case I've seen was messed up LSDB on all routers that | | share it (i.e. all level-2 routers) and some traffic was blackholed. | | Simple solution to the interface loop could be adding some sort of a | | cookie to hello PDU. If a router detects HELLO with its own sys-id which | | also contains cookie that this router send, then it can deduce that | | there is a loop on the interface and should stop further processing of | | such HELLO. The cookie could be implemented either by introducing new | | TLV or extending existing TLV. Taking into account that there is | | currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis), | | one approach would be to add cookie field at the end of TLV #240. | | | | Is there interest in this group to consider such functionality extention | | for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis | | in general are wrong place for this, would it be of interest to have | | separate draft for interface loop detection mechanism for IS-IS? | | ilya, | | can you explain why matching our own sysid against the sysid in the IIH | (and subsequent discard of such PDUs) is not sufficient for loop prevention ? | | /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 09:22:48 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA8528C23F; Thu, 3 Apr 2008 09:22:48 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729D128C172 for ; Thu, 3 Apr 2008 09:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nMKw+d3xEWP for ; Thu, 3 Apr 2008 09:22:47 -0700 (PDT) Received: from catapult.middlebury.edu (catapult.middlebury.edu [140.233.2.12]) by core3.amsl.com (Postfix) with ESMTP id 3A1893A6F5A for ; Thu, 3 Apr 2008 09:22:46 -0700 (PDT) X-ASG-Debug-ID: 1207239644-74f600130000-JVPge0 X-ASG-Debug-ID: 1207239644-74f600130000-JVPge0 X-ASG-Debug-ID: 1207239644-74f600130000-JVPge0 X-Barracuda-URL: http://140.233.2.12:80/cgi-bin/mark.cgi Received: from junglecat.middlebury.edu (junglecat.middlebury.edu [140.233.2.175]) by catapult.middlebury.edu (Spam Firewall) with ESMTP id 7E490127618; Thu, 3 Apr 2008 12:20:44 -0400 (EDT) Received: from junglecat.middlebury.edu (junglecat.middlebury.edu [140.233.2.175]) by catapult.middlebury.edu with ESMTP id FKcr3VVuL0pcLDbQ (version=TLSv1 cipher=RC4-MD5 bits=128 verify=NO); Thu, 03 Apr 2008 12:20:44 -0400 (EDT) Received: from baycat.middlebury.edu (140.233.2.176) by junglecat.middlebury.edu (140.233.2.175) with Microsoft SMTP Server (TLS) id 8.1.263.0; Thu, 3 Apr 2008 12:20:43 -0400 Received: from PANTHER.middlebury.edu ([140.233.2.171]) by baycat.middlebury.edu ([140.233.2.176]) with mapi; Thu, 3 Apr 2008 12:20:43 -0400 From: "Parker, Jeff" To: Hannes Gredler Date: Thu, 3 Apr 2008 12:18:08 -0400 X-ASG-Orig-Subj: RE: [Isis-wg] Interface loop detection in IS-IS Thread-Topic: [Isis-wg] Interface loop detection in IS-IS Thread-Index: AciVpVi0acnrVEdATU6LEzL1vtMnMwAAPUpN Message-ID: References: <20080403151931.GA6439@juniper.net> , <20080403161056.GA6737@juniper.net> In-Reply-To: <20080403161056.GA6737@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Barracuda-Connect: junglecat.middlebury.edu[140.233.2.175] X-Barracuda-Start-Time: 1207239644 X-Barracuda-Encrypted: RC4-MD5 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at middlebury.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.46732 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org One case is due to misconfiguration, and takes human intervention to chance the system ID of one of the two boxes using the same ID. I think we introduced an SNMP trap for just this purpose. The other case could be dealt with mechanically, as Ilya is suggesting, as a bridge would when it detects a loop. - jeff parker ________________________________________ From: Hannes Gredler [hannes@juniper.net] Sent: Thursday, April 03, 2008 12:10 PM To: Parker, Jeff Cc: Ilya Varlashkin; IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS well, whats the point distinguishing those two cases ? the ultimate action -> "log and discard" is the same. for troubleshooting purposes looking at the contents (extended local circuit-id!) and length of TLV #240, should provide enough information to distinguish between the two. /hannes On Thu, Apr 03, 2008 at 11:56:01AM -0400, Parker, Jeff wrote: | I assume this is to distinguish between the case of a duplicate SysID | and the case of a looped interface. | | - jeff parker | ________________________________________ | From: Hannes Gredler [hannes@juniper.net] | Sent: Thursday, April 03, 2008 11:19 AM | To: Ilya Varlashkin | Cc: IETF IS-IS | Subject: Re: [Isis-wg] Interface loop detection in IS-IS | | On Thu, Apr 03, 2008 at 03:36:27PM +0200, Ilya Varlashkin wrote: | | With current trend using Ethernet for backbone links and running IS-IS | | (often using p2p hello) would it be not good idea to add extra level of | | protection in IS-IS to detect interfaces which are looped? With | | traditional serial interfaces one could force interface to go down when | | a loop detected, with Ethernet this is most of the time not the case. | | I've observed in personal practice that certain types of IS-IS | | implementations get at least upset if they see HELLO with the same | | sys-id, worst case I've seen was messed up LSDB on all routers that | | share it (i.e. all level-2 routers) and some traffic was blackholed. | | Simple solution to the interface loop could be adding some sort of a | | cookie to hello PDU. If a router detects HELLO with its own sys-id which | | also contains cookie that this router send, then it can deduce that | | there is a loop on the interface and should stop further processing of | | such HELLO. The cookie could be implemented either by introducing new | | TLV or extending existing TLV. Taking into account that there is | | currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis), | | one approach would be to add cookie field at the end of TLV #240. | | | | Is there interest in this group to consider such functionality extention | | for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis | | in general are wrong place for this, would it be of interest to have | | separate draft for interface loop detection mechanism for IS-IS? | | ilya, | | can you explain why matching our own sysid against the sysid in the IIH | (and subsequent discard of such PDUs) is not sufficient for loop prevention ? | | /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 09:24:21 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F213A6F68; Thu, 3 Apr 2008 09:24:21 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9FF3A6F62 for ; Thu, 3 Apr 2008 09:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfT5kv2k29-4 for ; Thu, 3 Apr 2008 09:24:15 -0700 (PDT) Received: from softy.ision.net (softy.ision.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id 897783A6F5D for ; Thu, 3 Apr 2008 09:24:15 -0700 (PDT) Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1JhSEb-0007Bg-Cd; Thu, 03 Apr 2008 18:24:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 18:24:17 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240138D3B9@paul.adoffice.local.de.easynet.net> In-Reply-To: <20080403151931.GA6439@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Interface loop detection in IS-IS Thread-Index: AciVnhPz7s49ugIOStCk5rExlTVjDQAAMNNQ References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> <20080403151931.GA6439@juniper.net> From: "Ilya Varlashkin" To: "IETF IS-IS" Cc: Hannes Gredler Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > -----Original Message----- [...] > | Is there interest in this group to consider such functionality > | extention for IS-IS? If yes, but you think TLV #240 and > | draft-ietf-isis-rfc3373bis in general are wrong place for > this, would > | it be of interest to have separate draft for interface loop > detection mechanism for IS-IS? > > ilya, > > can you explain why matching our own sysid against the sysid > in the IIH (and subsequent discard of such PDUs) is not > sufficient for loop prevention ? > Hi Hannes, Sysid can be misconfigured (e.g. when using config templates). It might well be that some implementations treat duplicate SysID exactly as configuration issue. On the other hand, a cookie can be generated in such way as to insure that it's unique with sufficiently high probability (i.e. generated in such way that virtually guarantees that only this given system could have generated that cookie and not any other even if they use same algorithm). Because of such difference cookie is more sure way to tell a loop from misconfiguration. /iLya _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 09:30:00 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6BA28C66B; Thu, 3 Apr 2008 09:30:00 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D9928C65E for ; Thu, 3 Apr 2008 09:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya7njg7bYvcA for ; Thu, 3 Apr 2008 09:29:54 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id AE22D3A6CCF for ; Thu, 3 Apr 2008 09:29:53 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.25,599,1199664000"; d="scan'208,217";a="143072679" Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4-priv.tellabs.com with ESMTP; 03 Apr 2008 16:28:29 +0000 Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 11:28:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 11:24:20 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt Thread-Index: AciU9JxL4uxD3vfcSkG1TttzPtoPXAAso9UO References: <20080402190002.1E62F28C43F@core3.amsl.com> From: "Sadler, Jonathan B." To: X-OriginalArrivalTime: 03 Apr 2008 16:28:29.0215 (UTC) FILETIME=[BFED82F0:01C895A7] Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1886315526==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1886315526== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C895A7.BFA2DEB1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C895A7.BFA2DEB1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I noticed in my skim of this I-D that the reference to ISO 10589:1992 versi= on and not the 2002 version. The 2002 version is the one that is available= for free download here(http://standards.iso.org/ittf/PubliclyAvailableStan= dards/index.html) -- should we change the reference to keep people from thi= nking there is some dependancy on the older version? AFAIK, there is no su= bstantive difference between 1992 and 2002 for the purposes of this I-D... =20 Thoughts? =20 Jonathan Sadler ________________________________ From: isis-wg-bounces@ietf.org on behalf of Internet-Drafts@ietf.org Sent: Wed 4/2/2008 2:00 PM To: i-d-announce@ietf.org Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of th= e IETF. Title : Three-Way Handshake for Intermediate System to In= termediate System (IS-IS) Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-rfc3373bis-00.txt Pages : 14 Date : 2008-4-2 =20 The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc3373bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C895A7.BFA2DEB1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt
Hi all,
 
I noticed in my skim of this I-D= that the=20 reference to ISO 10589:1992 version and not the 2002 version.  The 200= 2=20 version is the one that is available for free download here(http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html)=20 -- should we change the reference to keep people from thinking there is som= e=20 dependancy on the older version?  AFAIK, there is no substantive diffe= rence=20 between 1992 and 2002 for the purposes of this I-D...
 
Thoughts?
 
Jonathan=20 Sadler

From: isis-wg-bounces@ietf.org on behal= f of=20 Internet-Drafts@ietf.org
Sent: Wed 4/2/2008 2:00 PM
To:=20 i-d-announce@ietf.org
Cc: isis-wg@ietf.org
Subject:=20 [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt

A New Internet-Draft is available from the on-line=20 Internet-Drafts
directories.
This draft is a work item of the IS-IS f= or IP=20 Internets Working Group of the=20 IETF.

        Title  =20         : Three-Way Handshake for=20 Intermediate System to Intermediate System (IS-IS) Point-to-Point=20 Adjacencies
       =20 Author(s)       : D. Katz, R.=20 Saluja
       =20 Filename        :=20 draft-ietf-isis-rfc3373bis-00.txt
      &n= bsp;=20 Pages           :=20 14
        Date   =20         :=20 2008-4-2
       
The IS-IS routing=20 protocol (Intermediate System to Intermediate
   System, ISO 1= 0589)=20 requires reliable protocols at the link layer for
   point-to-= point=20 links.  As a result, it does not use a three-way
   hands= hake=20 when establishing adjacencies on point-to- point media.
   Thi= s=20 paper defines a backward-compatible extension to the protocol
 &nbs= p;=20 that provides for a three-way handshake.  It is fully=20 interoperable
   with systems that do not support the=20 extension.

   Additionally, the extension allows the robus= t=20 operation of more than
   256 point-to-point links on a single=20 router.

   This extension has been implemented by multiple=20 router vendors; this
   paper is provided as information to th= e=20 Internet community in order
   to allow interoperable=20 implementations to be built by other vendors.

A URL for this=20 Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc3373bis-00.txt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-dr= afts/

Below=20 is the data which will enable a MIME compliant mail reader
implementatio= n to=20 automatically retrieve the ASCII version of=20 the
Internet-Draft.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C895A7.BFA2DEB1-- --===============1886315526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg --===============1886315526==-- From isis-wg-bounces@ietf.org Thu Apr 3 09:31:04 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77B428C6F2; Thu, 3 Apr 2008 09:31:04 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948D728C6E2 for ; Thu, 3 Apr 2008 09:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ff8qn3W3z+t for ; Thu, 3 Apr 2008 09:30:57 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6F40228C6E0 for ; Thu, 3 Apr 2008 09:30:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,599,1199682000"; d="scan'208";a="4003706" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2008 12:30:18 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m33GUIh4000939; Thu, 3 Apr 2008 12:30:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m33GUINn027035; Thu, 3 Apr 2008 16:30:18 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 12:30:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 12:29:51 -0400 Message-ID: <65702C7AB4261A41BC636B64CC5A489F0506A97C@xmb-rtp-203.amer.cisco.com> In-Reply-To: <7000E71D8C525042A815432358B2F1240138D3B9@paul.adoffice.local.de.easynet.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Interface loop detection in IS-IS Thread-Index: AciVnhPz7s49ugIOStCk5rExlTVjDQAAMNNQAAJCOJA= From: "Jeff Learman (jlearman)" To: "Ilya Varlashkin" , "IETF IS-IS" X-OriginalArrivalTime: 03 Apr 2008 16:30:18.0115 (UTC) FILETIME=[00D65530:01C895A8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1619; t=1207240218; x=1208104218; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jlearman@cisco.com; z=From:=20=22Jeff=20Learman=20(jlearman)=22=20 |Subject:=20RE=3A=20[Isis-wg]=20Interface=20loop=20detectio n=20in=20IS-IS |Sender:=20 |To:=20=22Ilya=20Varlashkin=22=20,=0A=20=20=20=20=20=20=20=20=22IETF=20IS-IS=22=20; bh=HkRDf4VZcnqyU2I5d7Gq8ajhSyHo/JfCCxuWeBWgBU0=; b=MAjThpihLgDhvSZkUUWTWZw514kZWBbFernF8KrsK8bAbWXMXohNUGiuuo 3m+10nJICYpYTb25ZCVa7WcbPmoADI53axF/m9e+XTlN+sF0yRr0bMcR0ayP 00dc5HAgoj; Authentication-Results: rtp-dkim-2; header.From=jlearman@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Hannes Gredler Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org What would be the difference in behavior for looped vs. duplicate SysID? Thanks, Jeff -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of Ilya Varlashkin Sent: Thursday, April 03, 2008 12:24 PM To: IETF IS-IS Cc: Hannes Gredler Subject: Re: [Isis-wg] Interface loop detection in IS-IS > -----Original Message----- [...] > | Is there interest in this group to consider such functionality > | extention for IS-IS? If yes, but you think TLV #240 and > | draft-ietf-isis-rfc3373bis in general are wrong place for > this, would > | it be of interest to have separate draft for interface loop > detection mechanism for IS-IS? > > ilya, > > can you explain why matching our own sysid against the sysid > in the IIH (and subsequent discard of such PDUs) is not > sufficient for loop prevention ? > Hi Hannes, Sysid can be misconfigured (e.g. when using config templates). It might well be that some implementations treat duplicate SysID exactly as configuration issue. On the other hand, a cookie can be generated in such way as to insure that it's unique with sufficiently high probability (i.e. generated in such way that virtually guarantees that only this given system could have generated that cookie and not any other even if they use same algorithm). Because of such difference cookie is more sure way to tell a loop from misconfiguration. /iLya _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 09:33:19 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7632F28C6EF; Thu, 3 Apr 2008 09:33:19 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FC828C6EF for ; Thu, 3 Apr 2008 09:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsEkOd8PKWLI for ; Thu, 3 Apr 2008 09:33:17 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 175AC28C6C2 for ; Thu, 3 Apr 2008 09:33:16 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.25,599,1199664000"; d="scan'208,217";a="143073867" Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4-priv.tellabs.com with ESMTP; 03 Apr 2008 16:33:19 +0000 Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 11:33:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 11:30:15 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Interface loop detection in IS-IS Thread-Index: AciVnhPz7s49ugIOStCk5rExlTVjDQAAMNNQAAJKDU0= References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net><20080403151931.GA6439@juniper.net> <7000E71D8C525042A815432358B2F1240138D3B9@paul.adoffice.local.de.easynet.net> From: "Sadler, Jonathan B." To: "Ilya Varlashkin" , "IETF IS-IS" X-OriginalArrivalTime: 03 Apr 2008 16:33:19.0303 (UTC) FILETIME=[6CD56D70:01C895A8] Cc: Hannes Gredler Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1814380698==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1814380698== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C895A8.6C755B2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C895A8.6C755B2C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It seems that using the MAC address as suggested by James Carlson would suf= fice for the case where config templates were in use -- and it would also g= ive enough resolution to distinguish if an SNMP trap should be sent... =20 Or are you suggesting that the config templates affect the i/f's MAC addres= s? That would cause a whole host of other problems that adding a cookie wo= uldn't be able to solve... =20 Jonathan Sadler ________________________________ From: isis-wg-bounces@ietf.org on behalf of Ilya Varlashkin Sent: Thu 4/3/2008 11:24 AM To: IETF IS-IS Cc: Hannes Gredler Subject: Re: [Isis-wg] Interface loop detection in IS-IS > -----Original Message----- [=2E..] > | Is there interest in this group to consider such functionality > | extention for IS-IS? If yes, but you think TLV #240 and > | draft-ietf-isis-rfc3373bis in general are wrong place for > this, would > | it be of interest to have separate draft for interface loop > detection mechanism for IS-IS? > > ilya, > > can you explain why matching our own sysid against the sysid > in the IIH (and subsequent discard of such PDUs) is not > sufficient for loop prevention ? > Hi Hannes, Sysid can be misconfigured (e.g. when using config templates). It might well be that some implementations treat duplicate SysID exactly as configuration issue. On the other hand, a cookie can be generated in such way as to insure that it's unique with sufficiently high probability (i.e. generated in such way that virtually guarantees that only this given system could have generated that cookie and not any other even if they use same algorithm). Because of such difference cookie is more sure way to tell a loop from misconfiguration. /iLya _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C895A8.6C755B2C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] Interface loop detection in IS-IS
It seems that us= ing the MAC=20 address as suggested by James Carlson would suffice for the case where conf= ig=20 templates were in use -- and it would also give enough resolution to=20 distinguish if an SNMP trap should be sent...
 
Or are you sugge= sting that=20 the config templates affect the i/f's MAC address?  That would cause a=20 whole host of other problems that adding a cookie wouldn't be able to=20 solve...
 
Jonathan Sadler

From: isis-wg-bounces@ietf.org on behal= f of Ilya=20 Varlashkin
Sent: Thu 4/3/2008 11:24 AM
To: IETF=20 IS-IS
Cc: Hannes Gredler
Subject: Re: [Isis-wg] Interfa= ce=20 loop detection in IS-IS

> -----Original Message-----
[...]
> | Is the= re=20 interest in this group to consider such functionality
> | extention f= or=20 IS-IS? If yes, but you think TLV #240 and
> | draft-ietf-isis-rfc3373= bis=20 in general are wrong place for
> this, would
> | it be of inter= est=20 to have separate draft for interface loop
> detection mechanism for=20 IS-IS?
>
> ilya,
>
> can you explain why matching o= ur=20 own sysid against the sysid
> in the IIH (and subsequent discard of s= uch=20 PDUs) is not
> sufficient for loop prevention ?
>

Hi=20 Hannes,

Sysid can be misconfigured (e.g. when using config templates= )=2E It=20 might
well be that some implementations treat duplicate SysID exactly=20 as
configuration issue. On the other hand, a cookie can be generated=20 in
such way as to insure that it's unique with sufficiently=20 high
probability (i.e. generated in such way that virtually guarantees=20 that
only this given system could have generated that cookie and not=20 any
other even if they use same algorithm).

Because of such diffe= rence=20 cookie is more sure way to tell a loop=20 from
misconfiguration.

/iLya
_________________________________= ______________
Isis-wg=20 mailing list
Isis-wg@ietf.org
https://www.ietf.org= /mailman/listinfo/isis-wg

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C895A8.6C755B2C-- --===============1814380698== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg --===============1814380698==-- From isis-wg-bounces@ietf.org Thu Apr 3 09:34:31 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5DC328C6FD; Thu, 3 Apr 2008 09:34:31 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589693A69CD for ; Thu, 3 Apr 2008 09:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMCp7ZtoV52V for ; Thu, 3 Apr 2008 09:34:26 -0700 (PDT) Received: from softy.ision.net (softy.ision.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id 7903328C6FE for ; Thu, 3 Apr 2008 09:34:26 -0700 (PDT) Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1JhSOT-0000rh-Ly; Thu, 03 Apr 2008 18:34:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 18:34:29 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240138D3BA@paul.adoffice.local.de.easynet.net> In-Reply-To: <18420.61539.233292.175886@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Interface loop detection in IS-IS Thread-Index: AciVnCxi5Tk4f9XbSj+ExM7u36SSqQACzI6Q References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> <18420.61539.233292.175886@gargle.gargle.HOWL> From: "Ilya Varlashkin" To: "James Carlson" Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Thursday, April 03, 2008 4:58 PM > To: Ilya Varlashkin > Cc: IETF IS-IS > Subject: Re: [Isis-wg] Interface loop detection in IS-IS > [...] > Such a cookie already exists, at least on media that have > multiple connected endpoints and MAC-layer addresses: the > source MAC address will tell you whether what you've received > is one of your own messages with a fairly high degree of confidence. > James, There is even keepalive mechanism on Ethernet to detect more complex loop scenarios than simple interface loop. However, IS-IS does not rely on such mechanism. Moreover not every router implementation will even shut down the interface if it detects a loop. My motivation of writing original mail was that I've observed on moderate sized network that when interface was unexpectedly looped back, it werecked havoc in IS-IS causing distruption for some prefixes for which affected system was next-hop. I agree that MAC addresses could serve as a cookie, but IS-IS should have a mechanism to detect loops (either directly via MAC or more generic cookie check or indirectly via e.g. BFD). /iLya _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 09:42:13 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108C43A6C57; Thu, 3 Apr 2008 09:42:13 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E013A6AB5 for ; Thu, 3 Apr 2008 09:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O2sI+P8EMvZ for ; Thu, 3 Apr 2008 09:42:10 -0700 (PDT) Received: from t40.gredler.at (unknown [88.116.9.78]) by core3.amsl.com (Postfix) with ESMTP id 2BFE73A6C57 for ; Thu, 3 Apr 2008 09:42:09 -0700 (PDT) Received: from t40.gredler.at (t40.gredler.at [127.0.0.1]) by t40.gredler.at (8.14.0/8.14.0) with ESMTP id m33GgYil006842; Thu, 3 Apr 2008 18:42:34 +0200 Received: (from hannes@localhost) by t40.gredler.at (8.14.0/8.14.0/Submit) id m33GgYUT006841; Thu, 3 Apr 2008 18:42:34 +0200 Date: Thu, 3 Apr 2008 18:42:34 +0200 From: Hannes Gredler To: "Parker, Jeff" Message-ID: <20080403164233.GA6774@juniper.net> References: <20080403151931.GA6439@juniper.net> <20080403161056.GA6737@juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org IMO we have already everything that we need. - for broadcast media one can look at the mac adress as a "cookie" (as previously suggested on the list) - for p2p media (C-HDLC, PPP) we have magic-numbers, mineseen yourseen etc. to detect loops) - as soon as the interface is loop detected and downed, higher layers (=IS-IS) won't see the PDUs anyway. /hannes On Thu, Apr 03, 2008 at 12:18:08PM -0400, Parker, Jeff wrote: | One case is due to misconfiguration, and takes human intervention to chance the system ID of one of the two boxes using the same ID. | I think we introduced an SNMP trap for just this purpose. | | The other case could be dealt with mechanically, as Ilya is suggesting, as a bridge would when it detects a loop. | | - jeff parker | ________________________________________ | From: Hannes Gredler [hannes@juniper.net] | Sent: Thursday, April 03, 2008 12:10 PM | To: Parker, Jeff | Cc: Ilya Varlashkin; IETF IS-IS | Subject: Re: [Isis-wg] Interface loop detection in IS-IS | | well, whats the point distinguishing those two cases ? | the ultimate action -> "log and discard" is the same. | | for troubleshooting purposes looking at the contents | (extended local circuit-id!) and length of TLV #240, | should provide enough information to distinguish between | the two. | | /hannes | | On Thu, Apr 03, 2008 at 11:56:01AM -0400, Parker, Jeff wrote: | | I assume this is to distinguish between the case of a duplicate SysID | | and the case of a looped interface. | | | | - jeff parker | | ________________________________________ | | From: Hannes Gredler [hannes@juniper.net] | | Sent: Thursday, April 03, 2008 11:19 AM | | To: Ilya Varlashkin | | Cc: IETF IS-IS | | Subject: Re: [Isis-wg] Interface loop detection in IS-IS | | | | On Thu, Apr 03, 2008 at 03:36:27PM +0200, Ilya Varlashkin wrote: | | | With current trend using Ethernet for backbone links and running IS-IS | | | (often using p2p hello) would it be not good idea to add extra level of | | | protection in IS-IS to detect interfaces which are looped? With | | | traditional serial interfaces one could force interface to go down when | | | a loop detected, with Ethernet this is most of the time not the case. | | | I've observed in personal practice that certain types of IS-IS | | | implementations get at least upset if they see HELLO with the same | | | sys-id, worst case I've seen was messed up LSDB on all routers that | | | share it (i.e. all level-2 routers) and some traffic was blackholed. | | | Simple solution to the interface loop could be adding some sort of a | | | cookie to hello PDU. If a router detects HELLO with its own sys-id which | | | also contains cookie that this router send, then it can deduce that | | | there is a loop on the interface and should stop further processing of | | | such HELLO. The cookie could be implemented either by introducing new | | | TLV or extending existing TLV. Taking into account that there is | | | currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis), | | | one approach would be to add cookie field at the end of TLV #240. | | | | | | Is there interest in this group to consider such functionality extention | | | for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis | | | in general are wrong place for this, would it be of interest to have | | | separate draft for interface loop detection mechanism for IS-IS? | | | | ilya, | | | | can you explain why matching our own sysid against the sysid in the IIH | | (and subsequent discard of such PDUs) is not sufficient for loop prevention ? | | | | /hannes | | _______________________________________________ | Isis-wg mailing list | Isis-wg@ietf.org | https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 09:42:43 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883483A6F6E; Thu, 3 Apr 2008 09:42:43 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1CA3A6BAF for ; Thu, 3 Apr 2008 09:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUwo131LjjoC for ; Thu, 3 Apr 2008 09:42:41 -0700 (PDT) Received: from softy.ision.net (softy.ision.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id BA3AB28C165 for ; Thu, 3 Apr 2008 09:42:41 -0700 (PDT) Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1JhSWS-0001qU-Dv; Thu, 03 Apr 2008 18:42:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 18:42:44 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240138D3BB@paul.adoffice.local.de.easynet.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Interface loop detection in IS-IS Thread-Index: AciVnhPz7s49ugIOStCk5rExlTVjDQAAMNNQAAJKDU0AACy3QA== References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net><20080403151931.GA6439@juniper.net> <7000E71D8C525042A815432358B2F1240138D3B9@paul.adoffice.local.de.easynet.net> From: "Ilya Varlashkin" To: "Sadler, Jonathan B." , "IETF IS-IS" Cc: Hannes Gredler Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Jonathan, I agree with James suggestion. My idea with cookies was just one of the possible solutions. The concern here is that there should be clear mechanism how to deal with such situation, and implementations should stick to such mechanism. Unfortunately I don't have access to original ISO 10589 and couldn't find anything in IETF documents how proper implementation should behave in case of seeing itsown system id, only saw how practical implementations behave. /iLya ________________________________ From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Thursday, April 03, 2008 6:30 PM To: Ilya Varlashkin; IETF IS-IS Cc: Hannes Gredler Subject: RE: [Isis-wg] Interface loop detection in IS-IS It seems that using the MAC address as suggested by James Carlson would suffice for the case where config templates were in use -- and it would also give enough resolution to distinguish if an SNMP trap should be sent... Or are you suggesting that the config templates affect the i/f's MAC address? That would cause a whole host of other problems that adding a cookie wouldn't be able to solve... Jonathan Sadler ________________________________ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 09:48:58 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8161728C33D; Thu, 3 Apr 2008 09:48:58 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EC228C33D for ; Thu, 3 Apr 2008 09:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up4yv1EQ2tot for ; Thu, 3 Apr 2008 09:48:56 -0700 (PDT) Received: from softy.ision.net (softy.ision.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id EF6E828C1C1 for ; Thu, 3 Apr 2008 09:48:55 -0700 (PDT) Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1JhScU-0002VW-T8; Thu, 03 Apr 2008 18:48:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 18:48:58 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240138D3BC@paul.adoffice.local.de.easynet.net> In-Reply-To: <20080403164233.GA6774@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Interface loop detection in IS-IS Thread-Index: AciVqbAAaJhIQT1VRcyHXVtgukT0PAAACNHw References: <20080403151931.GA6439@juniper.net><20080403161056.GA6737@juniper.net> <20080403164233.GA6774@juniper.net> From: "Ilya Varlashkin" To: "Hannes Gredler" , "Parker, Jeff" Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > -----Original Message----- > From: isis-wg-bounces@ietf.org > [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes Gredler > Sent: Thursday, April 03, 2008 6:43 PM > To: Parker, Jeff > Cc: IETF IS-IS > Subject: Re: [Isis-wg] Interface loop detection in IS-IS > > IMO we have already everything that we need. > > - for broadcast media one can look at the mac adress as a "cookie" > (as previously suggested on the list) > Agree that mac address can be used as a cookie so a tool is given. But is it used in practice? I saw that apparently that's not the case. The question comes whether or not it's clearly defined in IS-IS specification how to deal with the problem and if not, whether or not should/can this be added to specification to provide clear guidelines for how to properly implement this part of the protocol. > - for p2p media (C-HDLC, PPP) we have magic-numbers, mineseen yourseen > etc. to detect loops) - as soon as the interface is loop detected > and downed, higher layers (=IS-IS) won't see the PDUs anyway. > My initial concern was only about Ethernet (and alike) since serial p2p interfaces on many platforms have option to shutdown whole interface if it's looped. On the other hand, for operational/troubleshooting reason it might be desirable not to shutdown interface itself so then situation is the same as with Ethernet - IS-IS should detect and deal with such interface loops on its own, i.e. it should be robust enough to sustain such situations. /iLya _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 10:08:10 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E2728C2D2; Thu, 3 Apr 2008 10:08:10 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2020528C2D2 for ; Thu, 3 Apr 2008 10:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSwCVoE2HCVF for ; Thu, 3 Apr 2008 10:08:08 -0700 (PDT) Received: from softy.ision.net (softy.ision.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id 123C728C1E5 for ; Thu, 3 Apr 2008 10:08:07 -0700 (PDT) Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1JhSv4-0004zC-VN; Thu, 03 Apr 2008 19:08:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 19:08:10 +0200 Message-ID: <7000E71D8C525042A815432358B2F1240138D3BD@paul.adoffice.local.de.easynet.net> In-Reply-To: <18421.2891.816582.341529@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Interface loop detection in IS-IS Thread-Index: AciVrC47bMBO9zgvQb2d5Ed/bzgj9gAAFvzw References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net><18420.61539.233292.175886@gargle.gargle.HOWL><7000E71D8C525042A815432358B2F1240138D3BA@paul.adoffice.local.de.easynet.net> <18421.2891.816582.341529@gargle.gargle.HOWL> From: "Ilya Varlashkin" To: "James Carlson" , "IETF IS-IS" Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Thursday, April 03, 2008 6:52 PM > To: Ilya Varlashkin > Cc: IETF IS-IS > Subject: RE: [Isis-wg] Interface loop detection in IS-IS > [...] > Given that there are in fact suitable mechanisms that would > avoid damage caused by loops _today_, and that some seem to > be unable to employ those existing mechanisms, how does it > help to invent a new mechanism that the same designers would > (presumably) just ignore as well? > > How does this bit of added complexity solve a new problem? > Although there are in some cases mechanisms outside of IS-IS to deal with loop problems, such mechanism may not always be in place for various reasons (e.g. not implemented by specific platform or deliberately switched off for troubleshooting purpose). Shouldn't IS-IS be robust enough to deal with a problem if it faces one? The issue with looped interface is of the same sort as one addresses by 3-way handshake - link-level issues which are not necessary considered as a problem or not detected by link-level. /iLya _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 10:11:42 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF1728C1C1; Thu, 3 Apr 2008 10:11:42 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDCD3A68B1 for ; Thu, 3 Apr 2008 10:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pei31quRPjL for ; Thu, 3 Apr 2008 10:11:37 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 51F2428C731 for ; Thu, 3 Apr 2008 10:11:20 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m33HBLnA025343 for ; Thu, 3 Apr 2008 17:11:21 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m33HBLXo049167 for ; Thu, 3 Apr 2008 13:11:21 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m33Gqbqk021236; Thu, 3 Apr 2008 12:52:37 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m33GqR43021231; Thu, 3 Apr 2008 12:52:27 -0400 (EDT) MIME-Version: 1.0 Message-ID: <18421.2891.816582.341529@gargle.gargle.HOWL> Date: Thu, 3 Apr 2008 12:52:27 -0400 From: James Carlson To: Ilya Varlashkin In-Reply-To: <7000E71D8C525042A815432358B2F1240138D3BA@paul.adoffice.local.de.easynet.net> References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> <18420.61539.233292.175886@gargle.gargle.HOWL> <7000E71D8C525042A815432358B2F1240138D3BA@paul.adoffice.local.de.easynet.net> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Ilya Varlashkin writes: > There is even keepalive mechanism on Ethernet to detect more complex > loop scenarios than simple interface loop. However, IS-IS does not rely > on such mechanism. Moreover not every router implementation will even > shut down the interface if it detects a loop. My motivation of writing > original mail was that I've observed on moderate sized network that when > interface was unexpectedly looped back, it werecked havoc in IS-IS > causing distruption for some prefixes for which affected system was > next-hop. I guess I don't quite understand. Given that there are in fact suitable mechanisms that would avoid damage caused by loops _today_, and that some seem to be unable to employ those existing mechanisms, how does it help to invent a new mechanism that the same designers would (presumably) just ignore as well? How does this bit of added complexity solve a new problem? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 10:16:44 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7CA28C2B8; Thu, 3 Apr 2008 10:16:44 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271153A6A1C for ; Thu, 3 Apr 2008 10:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlkbRpJMWe8D for ; Thu, 3 Apr 2008 10:16:42 -0700 (PDT) Received: from chip3og53.obsmtp.com (chip3og53.obsmtp.com [64.18.14.171]) by core3.amsl.com (Postfix) with ESMTP id B97B928C3B9 for ; Thu, 3 Apr 2008 10:16:40 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob53.postini.com ([64.18.6.12]) with SMTP; Thu, 03 Apr 2008 10:15:30 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 10:16:41 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m33HGeD11861; Thu, 3 Apr 2008 10:16:40 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-Id: <4A417F2E-49A8-4A94-A9B7-DB836A8E3D9E@juniper.net> From: Dave Katz To: James Carlson In-Reply-To: <18421.2891.816582.341529@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 11:16:40 -0600 References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> <18420.61539.233292.175886@gargle.gargle.HOWL> <7000E71D8C525042A815432358B2F1240138D3BA@paul.adoffice.local.de.easynet.net> <18421.2891.816582.341529@gargle.gargle.HOWL> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 03 Apr 2008 17:16:41.0270 (UTC) FILETIME=[7BBA1560:01C895AE] Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Exactly. Broken implementations are unlikely to become unbroken by the invention of a redundant mechanism. The right answer is to threaten to throw away the broken boxes. This has been effective when used against my code in the past. ;-) --Dave On Apr 3, 2008, at 10:52 AM, James Carlson wrote: > Ilya Varlashkin writes: >> There is even keepalive mechanism on Ethernet to detect more complex >> loop scenarios than simple interface loop. However, IS-IS does not >> rely >> on such mechanism. Moreover not every router implementation will even >> shut down the interface if it detects a loop. My motivation of >> writing >> original mail was that I've observed on moderate sized network that >> when >> interface was unexpectedly looped back, it werecked havoc in IS-IS >> causing distruption for some prefixes for which affected system was >> next-hop. > > I guess I don't quite understand. > > Given that there are in fact suitable mechanisms that would avoid > damage caused by loops _today_, and that some seem to be unable to > employ those existing mechanisms, how does it help to invent a new > mechanism that the same designers would (presumably) just ignore as > well? > > How does this bit of added complexity solve a new problem? > > -- > James Carlson, Solaris Networking > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 > 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 > 1677 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 10:34:02 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0743228C6D3; Thu, 3 Apr 2008 10:34:02 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C0128C6F7 for ; Thu, 3 Apr 2008 10:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJbKj78FnKiy for ; Thu, 3 Apr 2008 10:33:55 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id A603628C6E6 for ; Thu, 3 Apr 2008 10:33:54 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m33HXvAm017529 for ; Thu, 3 Apr 2008 17:33:58 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m33HXvGd060855 for ; Thu, 3 Apr 2008 13:33:57 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m33HFA4N021384; Thu, 3 Apr 2008 13:15:10 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m33HFAp0021381; Thu, 3 Apr 2008 13:15:10 -0400 (EDT) MIME-Version: 1.0 Message-ID: <18421.4254.350266.677477@gargle.gargle.HOWL> Date: Thu, 3 Apr 2008 13:15:10 -0400 From: James Carlson To: Ilya Varlashkin In-Reply-To: <7000E71D8C525042A815432358B2F1240138D3BD@paul.adoffice.local.de.easynet.net> References: <7000E71D8C525042A815432358B2F1240138D3B6@paul.adoffice.local.de.easynet.net> <18420.61539.233292.175886@gargle.gargle.HOWL> <7000E71D8C525042A815432358B2F1240138D3BA@paul.adoffice.local.de.easynet.net> <18421.2891.816582.341529@gargle.gargle.HOWL> <7000E71D8C525042A815432358B2F1240138D3BD@paul.adoffice.local.de.easynet.net> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: IETF IS-IS Subject: Re: [Isis-wg] Interface loop detection in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Ilya Varlashkin writes: > > How does this bit of added complexity solve a new problem? > > > Although there are in some cases mechanisms outside of IS-IS to deal > with loop problems, such mechanism may not always be in place for > various reasons (e.g. not implemented by specific platform or > deliberately switched off for troubleshooting purpose). Shouldn't IS-IS > be robust enough to deal with a problem if it faces one? The issue with > looped interface is of the same sort as one addresses by 3-way handshake > - link-level issues which are not necessary considered as a problem or > not detected by link-level. Noticing that the System ID is wrong and dropping the packet gives you that level of protection already. As you've noted, there may be implementations that fail to check System ID. I still don't see why, if they fail to check that, they're going to suddenly start checking some _new_ parameter that's yet to be defined. That seems like an unusual level of engagement where there was previously much less. If you mess up the existing features, why does adding more features address the problem? Isn't the real problem just a bug in some implementations rather than a missing feature in the specification? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 3 11:01:29 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1EDC28C6F8; Thu, 3 Apr 2008 11:01:28 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254FE3A6874 for ; Thu, 3 Apr 2008 11:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUGbuQSajWty for ; Thu, 3 Apr 2008 11:01:24 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 2E08C28C716 for ; Thu, 3 Apr 2008 11:00:37 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 95zT1Z00f0EZKEL5600100; Thu, 03 Apr 2008 17:59:28 +0000 Received: from TONYLTM9XP ([155.53.43.187]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 960Q1Z00D42Hpm33M00000; Thu, 03 Apr 2008 18:00:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=86U1H9NdAAAA:8 a=48vgC7mUAAAA:8 a=Ll7a58dRFqqmozrBCLMA:9 a=ZY_exFfT3pXN6ws1hy8A:7 a=Z0yLx4uhUhHDPyFq6xVuiKdH4W8A:4 a=lZB815dzVvQA:10 a=gJcimI5xSWUA:10 a=4iIrGrZ2hNTnM6WC0-oA:9 a=Owwmd5NaJzs2CDQ5KBYA:7 a=un3OJ85kuOn3AswM9W2brG--6_4A:4 a=AfD3MYMu9mQA:10 From: "Tony Li" To: "'Sadler, Jonathan B.'" , References: <20080402190002.1E62F28C43F@core3.amsl.com> Date: Thu, 3 Apr 2008 11:00:26 -0700 Message-ID: <00db01c895b4$9fc4b5e0$bb2b359b@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciU9JxL4uxD3vfcSkG1TttzPtoPXAAso9UOAANS2fA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1733132981==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1733132981== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DC_01C89579.F365DDE0" This is a multi-part message in MIME format. ------=_NextPart_000_00DC_01C89579.F365DDE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agreed. No point in referring to obsolete specs. Tony _____ From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of Sadler, Jonathan B. Sent: Thursday, April 03, 2008 9:24 AM To: isis-wg@ietf.org Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt Hi all, I noticed in my skim of this I-D that the reference to ISO 10589:1992 version and not the 2002 version. The 2002 version is the one that is available for free download here(http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html) -- should we change the reference to keep people from thinking there is some dependancy on the older version? AFAIK, there is no substantive difference between 1992 and 2002 for the purposes of this I-D... Thoughts? Jonathan Sadler _____ From: isis-wg-bounces@ietf.org on behalf of Internet-Drafts@ietf.org Sent: Wed 4/2/2008 2:00 PM To: i-d-announce@ietf.org Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-rfc3373bis-00.txt Pages : 14 Date : 2008-4-2 The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc3373bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ ------=_NextPart_000_00DC_01C89579.F365DDE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Isis-wg] I-D = ACTION:draft-ietf-isis-rfc3373bis-00.txt
 
Agreed.  No point in referring to obsolete=20 specs.
 
Tony
 

From: isis-wg-bounces@ietf.org=20 [mailto:isis-wg-bounces@ietf.org] On Behalf Of Sadler, Jonathan = B.
Sent: Thursday, April 03, 2008 9:24 AM
To:=20 isis-wg@ietf.org
Subject: Re: [Isis-wg] I-D=20 ACTION:draft-ietf-isis-rfc3373bis-00.txt

Hi = all,
 
I noticed in my skim of = this I-D that the=20 reference to ISO 10589:1992 version and not the 2002 version.  = The 2002=20 version is the one that is available for free download here(http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html)=20 -- should we change the reference to keep people from thinking there = is some=20 dependancy on the older version?  AFAIK, there is no substantive=20 difference between 1992 and 2002 for the purposes of this = I-D...
 
Thoughts?
 
Jonathan=20 Sadler

From: isis-wg-bounces@ietf.org on = behalf of=20 Internet-Drafts@ietf.org
Sent: Wed 4/2/2008 2:00 = PM
To:=20 i-d-announce@ietf.org
Cc: = isis-wg@ietf.org
Subject:=20 [Isis-wg] I-D = ACTION:draft-ietf-isis-rfc3373bis-00.txt

A New Internet-Draft is available from the on-line=20 Internet-Drafts
directories.
This draft is a work item of the = IS-IS for=20 IP Internets Working Group of the=20 IETF.

        = Title  =20         : Three-Way Handshake for=20 Intermediate System to Intermediate System (IS-IS) Point-to-Point=20 Adjacencies
       =20 Author(s)       : D. Katz, R.=20 Saluja
       =20 Filename        :=20 = draft-ietf-isis-rfc3373bis-00.txt
      =  =20 Pages           :=20 14
        = Date   =20         :=20 2008-4-2
       
The IS-IS = routing=20 protocol (Intermediate System to Intermediate
   System, = ISO=20 10589) requires reliable protocols at the link layer = for
  =20 point-to-point links.  As a result, it does not use a=20 three-way
   handshake when establishing adjacencies on = point-to-=20 point media.
   This paper defines a backward-compatible=20 extension to the protocol
   that provides for a = three-way=20 handshake.  It is fully interoperable
   with = systems that=20 do not support the extension.

   Additionally, the = extension=20 allows the robust operation of more than
   256 = point-to-point=20 links on a single router.

   This extension has been=20 implemented by multiple router vendors; this
   paper is = provided=20 as information to the Internet community in order
   to = allow=20 interoperable implementations to be built by other vendors.

A = URL for=20 this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc3373bis-00.t= xt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-= drafts/

Below=20 is the data which will enable a MIME compliant mail = reader
implementation=20 to automatically retrieve the ASCII version of=20 = the
Internet-Draft.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------=_NextPart_000_00DC_01C89579.F365DDE0-- --===============1733132981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg --===============1733132981==-- From isis-wg-bounces@ietf.org Thu Apr 3 12:24:44 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB5428C1F1; Thu, 3 Apr 2008 12:24:44 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92DF53A67D2 for ; Thu, 3 Apr 2008 12:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.793 X-Spam-Level: X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[AWL=1.805, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo1ruYQ-3ZLH for ; Thu, 3 Apr 2008 12:24:42 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id E55153A6C39 for ; Thu, 3 Apr 2008 12:24:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1207250684!26239813!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26834 invoked from network); 3 Apr 2008 19:24:44 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 3 Apr 2008 19:24:44 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m33JOdIR025334 for ; Thu, 3 Apr 2008 12:24:44 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id m33JOcKC022188 for ; Thu, 3 Apr 2008 14:24:38 -0500 (CDT) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id m33JOcD8022183 for ; Thu, 3 Apr 2008 14:24:38 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 15:24:36 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979003AD862B@de01exm64.ds.mot.com> In-Reply-To: <00db01c895b4$9fc4b5e0$bb2b359b@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt Thread-Index: AciU9JxL4uxD3vfcSkG1TttzPtoPXAAso9UOAANS2fAAAu+ZAA== References: <20080402190002.1E62F28C43F@core3.amsl.com> <00db01c895b4$9fc4b5e0$bb2b359b@ad.redback.com> From: "Eastlake III Donald-LDE008" To: X-CFilter-Loop: Reflected Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1900943196==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1900943196== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C895C0.5B914598" This is a multi-part message in MIME format. ------_=_NextPart_001_01C895C0.5B914598 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also agree with this change. Sorry I missed it before while editing the document. =20 Donald ________________________________ From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of Tony Li Sent: Thursday, April 03, 2008 2:00 PM To: 'Sadler, Jonathan B.'; isis-wg@ietf.org Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt =20 Agreed. No point in referring to obsolete specs. =20 Tony =20 ________________________________ From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of Sadler, Jonathan B. Sent: Thursday, April 03, 2008 9:24 AM To: isis-wg@ietf.org Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt =09 =09 Hi all, =20 I noticed in my skim of this I-D that the reference to ISO 10589:1992 version and not the 2002 version. The 2002 version is the one that is available for free download here(http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html ) -- should we change the reference to keep people from thinking there is some dependancy on the older version? AFAIK, there is no substantive difference between 1992 and 2002 for the purposes of this I-D... =20 Thoughts? =20 Jonathan Sadler ________________________________ From: isis-wg-bounces@ietf.org on behalf of Internet-Drafts@ietf.org Sent: Wed 4/2/2008 2:00 PM To: i-d-announce@ietf.org Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-00.txt =09 =09 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. =09 Title : Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-rfc3373bis-00.txt Pages : 14 Date : 2008-4-2 =20 The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. =09 Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. =09 This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc3373bis-00.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C895C0.5B914598 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Isis-wg] I-D = ACTION:draft-ietf-isis-rfc3373bis-00.txt
I also agree with this change. Sorry I missed = it before=20 while editing the document.
 
Donald

From: isis-wg-bounces@ietf.org=20 [mailto:isis-wg-bounces@ietf.org] On Behalf Of Tony = Li
Sent:=20 Thursday, April 03, 2008 2:00 PM
To: 'Sadler, Jonathan B.';=20 isis-wg@ietf.org
Subject: Re: [Isis-wg] I-D=20 ACTION:draft-ietf-isis-rfc3373bis-00.txt

 
Agreed.  No point in referring to obsolete=20 specs.
 
Tony
 

From: isis-wg-bounces@ietf.org=20 [mailto:isis-wg-bounces@ietf.org] On Behalf Of Sadler, Jonathan = B.
Sent: Thursday, April 03, 2008 9:24 AM
To:=20 isis-wg@ietf.org
Subject: Re: [Isis-wg] I-D=20 ACTION:draft-ietf-isis-rfc3373bis-00.txt

Hi = all,
 
I noticed in my skim of = this I-D that the=20 reference to ISO 10589:1992 version and not the 2002 version.  = The 2002=20 version is the one that is available for free download here(http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html)=20 -- should we change the reference to keep people from thinking there = is some=20 dependancy on the older version?  AFAIK, there is no substantive=20 difference between 1992 and 2002 for the purposes of this = I-D...
 
Thoughts?
 
Jonathan=20 Sadler

From: isis-wg-bounces@ietf.org on = behalf of=20 Internet-Drafts@ietf.org
Sent: Wed 4/2/2008 2:00 = PM
To:=20 i-d-announce@ietf.org
Cc: = isis-wg@ietf.org
Subject:=20 [Isis-wg] I-D = ACTION:draft-ietf-isis-rfc3373bis-00.txt

A New Internet-Draft is available from the on-line=20 Internet-Drafts
directories.
This draft is a work item of the = IS-IS for=20 IP Internets Working Group of the=20 IETF.

        = Title  =20         : Three-Way Handshake for=20 Intermediate System to Intermediate System (IS-IS) Point-to-Point=20 Adjacencies
       =20 Author(s)       : D. Katz, R.=20 Saluja
       =20 Filename        :=20 = draft-ietf-isis-rfc3373bis-00.txt
      =  =20 Pages           :=20 14
        = Date   =20         :=20 2008-4-2
       
The IS-IS = routing=20 protocol (Intermediate System to Intermediate
   System, = ISO=20 10589) requires reliable protocols at the link layer = for
  =20 point-to-point links.  As a result, it does not use a=20 three-way
   handshake when establishing adjacencies on = point-to-=20 point media.
   This paper defines a backward-compatible=20 extension to the protocol
   that provides for a = three-way=20 handshake.  It is fully interoperable
   with = systems that=20 do not support the extension.

   Additionally, the = extension=20 allows the robust operation of more than
   256 = point-to-point=20 links on a single router.

   This extension has been=20 implemented by multiple router vendors; this
   paper is = provided=20 as information to the Internet community in order
   to = allow=20 interoperable implementations to be built by other vendors.

A = URL for=20 this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc3373bis-00.t= xt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-= drafts/

Below=20 is the data which will enable a MIME compliant mail = reader
implementation=20 to automatically retrieve the ASCII version of=20 = the
Internet-Draft.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C895C0.5B914598-- --===============1900943196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg --===============1900943196==-- From c6fdf0a6@konferenz.com Fri Apr 11 02:53:49 2008 Return-Path: X-Original-To: ietfarch-isis-archive@core3.amsl.com Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5595628C28E; Fri, 11 Apr 2008 02:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -62.626 X-Spam-Level: X-Spam-Status: No, score=-62.626 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_DOLLAR_BONUS=10.357, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP2wv5Jw07W1; Fri, 11 Apr 2008 02:53:43 -0700 (PDT) Received: from 84.123.86.95.dyn.user.ono.com (84.123.86.95.dyn.user.ono.com [84.123.86.95]) by core3.amsl.com (Postfix) with SMTP id 7205828C2B1; Fri, 11 Apr 2008 02:53:35 -0700 (PDT) X-Originating-IP: 220.186.51.168 by smtp.84.123.86.95; Fri, 11 Apr 2008 05:54:03 -0500 Message-ID: From: "Jay Patel" Reply-To: "Jay Patel" To: ipr-wg-bounces@ietf.org Subject: Come and get your MASSIVE $2400 BONUS NOW! Date: Fri, 11 Apr 2008 05:54:03 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It's your lucky day...... and it's your turn to win HUGE............ Enjoy our MASSIVE $2400 bonus......... Join tens of thousands of LUCKY winners today........ We promise: Fair Gaming, Amazingly fast payouts.... and the best in live customer support... Enter here http://muhofuby24203.blogspot.com/ to download the world's leading online casino NOW... From c_kido@pearl-kg.co.jp Fri Apr 11 15:32:25 2008 Return-Path: X-Original-To: ietfarch-isis-archive@core3.amsl.com Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09973A6863; Fri, 11 Apr 2008 15:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.302 X-Spam-Level: X-Spam-Status: No, score=-87.302 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRVbYg3tlELm; Fri, 11 Apr 2008 15:32:25 -0700 (PDT) Received: from client-201.240.161.96.speedy.net.pe (unknown [201.240.161.96]) by core3.amsl.com (Postfix) with SMTP id BFE003A683D; Fri, 11 Apr 2008 15:32:13 -0700 (PDT) X-Originating-IP: 152.107.174.62 by smtp.201.240.161.96; Fri, 11 Apr 2008 18:32:41 -0500 Message-ID: From: "Arturo Cox" Reply-To: "Arturo Cox" To: ipr-wg-bounces@ietf.org Subject: Play at the world's leading online casino..... Date: Fri, 11 Apr 2008 18:32:41 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Amazing $2400 bonuses..... Amazing Customer Support...... Amazing games..... Play at the world's most prestigious online casino..... Come and get your MASSIVE $2400 BONUS NOW! Fair Gaming, Fast Payouts unrivalled customer support: GUARANTEED!!! Join the superstars and some of the world’s BIGGEST winners........ ENTER HERE http://fiwapywi71020.blogspot.com/ TO DOWNLOAD NOW! From c5.65ec8dcc@metroform.com Sat Apr 12 02:48:48 2008 Return-Path: X-Original-To: ietfarch-isis-archive@core3.amsl.com Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266A228C19B; Sat, 12 Apr 2008 02:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.003 X-Spam-Level: X-Spam-Status: No, score=-82.003 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_VIRTUACOMBR=1.193, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3a9ATy9v-69; Sat, 12 Apr 2008 02:48:47 -0700 (PDT) Received: from bd079458.virtua.com.br (unknown [189.7.148.88]) by core3.amsl.com (Postfix) with SMTP id 8B6EF3A6D8C; Sat, 12 Apr 2008 02:48:37 -0700 (PDT) X-Originating-IP: 42.98.25.142 by smtp.189.7.148.88; Sat, 12 Apr 2008 05:49:05 -0500 Message-ID: From: "Kory Vela" Reply-To: "Kory Vela" To: ipr-wg-bounces@ietf.org Subject: The safest and most secure Online casino in the world....... Date: Sat, 12 Apr 2008 05:49:05 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Play at the world's leading online casino..... Play NOW and get a HUGE $2400 Match Bonus!!!!!!!!!!!!!!! The safest and most secure Online casino in the world....... Play our COLLOSAL progressive slots... our amazing "Shopping Spree" Jackpot is now a MASSIVE $857,798.00..... It must payout soon!!!!!!!!!!! ........ GOOD LUCK!!!! Enter here http://nolocogu44830.blogspot.com to download the world's leading online casino NOW... From matsui.kunio@jp.fujitsu.com Mon Apr 14 09:40:57 2008 Return-Path: X-Original-To: ietfarch-isis-archive@core3.amsl.com Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937743A6969 for ; Mon, 14 Apr 2008 09:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.247 X-Spam-Level: ** X-Spam-Status: No, score=2.247 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj3GYOj4bL4X for ; Mon, 14 Apr 2008 09:40:52 -0700 (PDT) Received: from dcv128.neoplus.adsl.tpnet.pl (dcv128.neoplus.adsl.tpnet.pl [83.23.73.128]) by core3.amsl.com (Postfix) with ESMTP id 4EBBE3A67D8 for ; Mon, 14 Apr 2008 09:40:49 -0700 (PDT) Message-ID: <000901c89e4e$037a81b1$a5938f88@mxauslk> From: "daryle starbuck" To: Subject: Hermes Date: Mon, 14 Apr 2008 14:54:01 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C89E4E.0376804D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C89E4E.0376804D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable       =20   Click here Create your image.   =20       =20 ------=_NextPart_000_0006_01C89E4E.0376804D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
 

Click here

Create your image.

  
     
------=_NextPart_000_0006_01C89E4E.0376804D-- From isis-wg-bounces@ietf.org Wed Apr 16 06:01:38 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2FB3A6C10; Wed, 16 Apr 2008 06:01:38 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7B63A6BDD for ; Wed, 16 Apr 2008 06:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2UmPKFw37eZ for ; Wed, 16 Apr 2008 06:01:35 -0700 (PDT) Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by core3.amsl.com (Postfix) with SMTP id 576C63A6AAA for ; Wed, 16 Apr 2008 06:01:35 -0700 (PDT) Received: (qmail 88458 invoked from network); 16 Apr 2008 12:29:15 -0000 Received: from unknown (HELO ?192.168.0.3?) (chopps@rawdofmt.org@68.174.127.83 with plain) by smtp100.biz.mail.re2.yahoo.com with SMTP; 16 Apr 2008 12:29:15 -0000 X-YMail-OSG: jf2ztPcVM1lNRRrju78pnw3IjBnMbWzrADBondCPB0pcgYAy X-Yahoo-Newman-Property: ymail-3 Message-Id: From: Christian Hopps To: isis mailing list Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 08:29:14 -0400 X-Mailer: Apple Mail (2.919.2) Cc: Christian Hopps Subject: [Isis-wg] WG Last Call for Info to Std Track Documents. X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org We're having WG LC on all the RFCxxxxbis documents that are taking the informational RFCs to standards track. This LC is to make sure no errors have been introduced in the repackaging of the RFCs. The LC will end in 2 weeks. The list of documents follows. draft-ietf-isis-rfc2763bis (Proposed Standard) 00 draft-ietf-isis-rfc2966bis (Proposed Standard) 02 draft-ietf-isis-rfc3373bis (Proposed Standard) 00 draft-ietf-isis-rfc3567bis (Proposed Standard) 01 draft-ietf-isis-te-bis (Proposed Standard) 00 (rfc3784) draft-ietf-isis-rfc3847bis (Proposed Standard) 00 draft-ietf-isis-rfc4205bis (Proposed Standard) 00 Chris & Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Apr 16 06:50:39 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC143A6B9F; Wed, 16 Apr 2008 06:50:39 -0700 (PDT) X-Original-To: isis-wg@core3.amsl.com Delivered-To: isis-wg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505E23A692E for ; Wed, 16 Apr 2008 06:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3xJTE2gU-X7 for ; Wed, 16 Apr 2008 06:50:33 -0700 (PDT) Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by core3.amsl.com (Postfix) with SMTP id 5537028C1DA for ; Wed, 16 Apr 2008 06:50:25 -0700 (PDT) Received: (qmail 35592 invoked from network); 16 Apr 2008 13:07:21 -0000 Received: from unknown (HELO ?192.168.0.3?) (chopps@rawdofmt.org@68.174.127.83 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 16 Apr 2008 13:07:21 -0000 X-YMail-OSG: HhLOw5MVM1locx9kDBHRsUrAuTdWMeynzRAmDvFNPVRNbcWG X-Yahoo-Newman-Property: ymail-3 Message-Id: <8AB7E670-4AC8-4BE2-A8F3-F7B216430750@rawdofmt.org> From: Christian Hopps To: Christian Hopps In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 09:07:20 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: "David Ward \(wardd\)" , isis mailing list Subject: Re: [Isis-wg] WG Last Call for Info to Std Track Documents. X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Apr 16, 2008, at 8:29 AM, Christian Hopps wrote: > draft-ietf-isis-rfc3373bis (Proposed Standard) 00 Note: This actually will be the -01 version when posted with the updated reference as discussed recently on the list. > Chris & Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Apr 17 10:00:02 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF10828C587; Thu, 17 Apr 2008 10:00:02 -0700 (PDT) X-Original-To: isis-wg@ietf.org Delivered-To: isis-wg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 97CF528C586; Thu, 17 Apr 2008 10:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080417170001.97CF528C586@core3.amsl.com> Date: Thu, 17 Apr 2008 10:00:01 -0700 (PDT) Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-rfc3373bis-01.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-rfc3373bis-01.txt Pages : 14 Date : 2008-4-17 The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc3373bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isis-rfc3373bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-17095002.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Fri Apr 25 15:45:12 2008 Return-Path: X-Original-To: isis-archive@megatron.ietf.org Delivered-To: ietfarch-isis-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61FAB3A6D60; Fri, 25 Apr 2008 15:45:12 -0700 (PDT) X-Original-To: isis-wg@ietf.org Delivered-To: isis-wg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4FC973A6D58; Fri, 25 Apr 2008 15:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080425224501.4FC973A6D58@core3.amsl.com> Date: Fri, 25 Apr 2008 15:45:01 -0700 (PDT) Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D Action:draft-ietf-isis-rfc2966bis-03.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Domain-wide Prefix Distribution with Two-Level IS-IS Author(s) : T. Li, et al. Filename : draft-ietf-isis-rfc2966bis-03.txt Pages : 16 Date : 2008-04-25 This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc2966bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isis-rfc2966bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-25154337.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg --NextPart--