From isis-wg-bounces@ietf.org Thu Mar 02 11:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqzN-0005Ft-2w; Thu, 02 Mar 2006 11:49:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqzL-0005C0-Du for isis-wg@ietf.org; Thu, 02 Mar 2006 11:49:15 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEqzK-0006VR-5H for isis-wg@ietf.org; Thu, 02 Mar 2006 11:49:15 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 02 Mar 2006 08:49:13 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k22GnDGv001094; Thu, 2 Mar 2006 08:49:13 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 08:49:12 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 08:49:11 -0800 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 02 Mar 2006 10:49:13 -0600 From: David Ward To: , David Ward , Christian Hopps Message-ID: Thread-Topic: Call for agenda topics Thread-Index: AcY+GTwYercYBKoMEdqdTgAKlcR7kg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Mar 2006 16:49:11.0954 (UTC) FILETIME=[3B792F20:01C63E19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Isis-wg] Call for agenda topics X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org All - Please reply to Chris and myself if you would like an agenda slot in our next WG meeting in Dallas. Thanks -DWard, Chopps _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Mar 09 17:05:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTGB-0004Hs-CW; Thu, 09 Mar 2006 17:05:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTG9-0004Cc-I5 for isis-wg@ietf.org; Thu, 09 Mar 2006 17:05:25 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSLF-0001yR-Cv for isis-wg@ietf.org; Thu, 09 Mar 2006 16:06:37 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FHSAR-0005nZ-1i for isis-wg@ietf.org; Thu, 09 Mar 2006 15:55:33 -0500 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k29KtPi9005413 for ; Thu, 9 Mar 2006 12:55:25 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id k29KtO5r005403 for ; Thu, 9 Mar 2006 12:55:25 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 9 Mar 2006 12:55:24 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: isis mailing list Subject: Re: [Isis-wg] Re: Protocol Action: 'Management Information Base for IS-IS' to Proposed Standard In-Reply-To: <254CE58D-1A43-434B-9849-2F18BA14EA0B@rawdofmt.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org IANA has assigned a top level node for this MIB module: isisMIB MODULE-IDENTITY [ ... ] ::= { mib-2 138} This is recorded in http://www.iana.org/assignments/smi-numbers Let the implementations proceed! //cmh On Fri, 20 Jan 2006, Christian Hopps wrote: > I'd like to take this opportunity to thank Jeff for all the work he > put in on this. Thanks also to the many people who reviewed the > document and helped to finally bring it home. > > Chris. > > On Jan 20, 2006, at 7:31 AM, The IESG wrote: > > > The IESG has approved the following document: > > > > - 'Management Information Base for IS-IS ' > > as a Proposed Standard > > > > This document is the product of the IS-IS for IP Internets Working > > Group. > > > > The IESG contact persons are Alex Zinin and Bill Fenner. > > > > A URL of this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-26.txt > > > > Technical Summary > > > > This document describes a management information base for the IS-IS > > Routing protocol when it is used to construct routing tables for IP > > networks. > > > > Working Group Summary > > > > The WG had a consensus on progressing this document. > > > > Protocol Quality > > > > The document has been reviewed by Mike Heard, Bert Wijnen, and Alex Zinin > > for the IESG. > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Mar 13 14:00:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsHg-0001aO-Tz; Mon, 13 Mar 2006 14:00:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsHf-0001aJ-MG for isis-wg@ietf.org; Mon, 13 Mar 2006 14:00:47 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIsHe-0000mg-D5 for isis-wg@ietf.org; Mon, 13 Mar 2006 14:00:47 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 13 Mar 2006 11:00:46 -0800 X-IronPort-AV: i="4.02,187,1139212800"; d="scan'208"; a="313765888:sNHT41983900" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2DJ0g7b008275; Mon, 13 Mar 2006 11:00:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 11:00:43 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 11:00:43 -0800 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Mar 2006 13:00:42 -0600 From: David Ward To: isis mailing list , David Ward Message-ID: Thread-Topic: Agenda for ISIS WG meeting Thread-Index: AcZG0GzZq36OhrLDEdqtwgAKlcR7kg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Mar 2006 19:00:43.0506 (UTC) FILETIME=[6DBFB520:01C646D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Isis-wg] Agenda for ISIS WG meeting X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org All - We have 1 hour slot on Thurs, March 23: ISIS Session 1 (1 hour) Thursday, Afternoon Session II 1510-1610 Room Name: Cortez AB So far we have only a few items: Administrivia Eric Gray - TRILL impact on IGP routing - 20 mins Les Ginsberg - Splitting LSP space - 30 mins Others? We may finish early -DWard _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Mar 25 02:06:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN2qm-0005Lg-CZ; Sat, 25 Mar 2006 02:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN2qk-0005LT-LP for isis-wg@ietf.org; Sat, 25 Mar 2006 02:06:14 -0500 Received: from rrcs-66-91-145-219.west.biz.rr.com ([66.91.145.219] helo=apollo.adtech-inc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN2qj-0000Vw-CK for isis-wg@ietf.org; Sat, 25 Mar 2006 02:06:14 -0500 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4G2N0>; Fri, 24 Mar 2006 21:07:03 -1000 Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA2051383D9@apollo.adtech-inc.com> From: "Kandula, Ramesh" To: "'isis-wg@ietf.org'" Date: Fri, 24 Mar 2006 21:07:00 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Isis-wg] Question about IS-IS Restart Signaling X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hi all, According to RFC 3847, if multiple routers on a broadcast network restart around the same time, is the helper (receiving) router supposed to include multiple instances of Restart TLVs with RA bit set (one for each restarting router) in it's hellos? thanks ramesh _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Mar 25 03:15:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN3sI-0000wn-HI; Sat, 25 Mar 2006 03:11:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN3sG-0000uh-Op for isis-wg@ietf.org; Sat, 25 Mar 2006 03:11:52 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN3jU-0002F9-De for isis-wg@ietf.org; Sat, 25 Mar 2006 03:02:49 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 25 Mar 2006 00:02:48 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2P82lGv002365; Sat, 25 Mar 2006 00:02:47 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Mar 2006 00:02:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Date: Sat, 25 Mar 2006 00:02:46 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Question about IS-IS Restart Signaling Thread-Index: AcZP2qca9+E0vJvmSWSE9zTq9x9QowABSTWg From: "Les Ginsberg \(ginsberg\)" To: "Kandula, Ramesh" , X-OriginalArrivalTime: 25 Mar 2006 08:02:47.0824 (UTC) FILETIME=[815DA900:01C64FE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hmmm...an interesting question. I would have to say that the RFC is not explicit on this point. >From an interoperability standpoint, I would be concerned that implementations might not parse past the initial restart TLV and therefore might not process a second restart TLV. This would not be fatal as the restarting router would eventually retransmit an IIH-RR (presumably by this time the other restarting router would have seen its RA) - but would be suboptimal as it would delay the reestablishment of the adjacency on the part of the restarting router. On the other hand, it would provide a means of decreasing the total number of IIH-RAs sent in response to the IIH-RRs in such a case. This is, of course, a very unlikely case for two reasons: 1)It is unlikely that two routers would restart "at the same time" 2)As the requirement on sending the IIH-RA is to send it "immediately" (with jitter on the LAN) the interval between receipt of IIH-RR from two different routers would need to be quite small. In the conservative spirit of being "strict in what you send" I would be inclined to NOT include multiple restart TLVs in the same IIH. I would recommend sending two IIHs one immediately after the other. Note that such short bursts are already allowed in the case of LSP/CSNP transmissions. Les > -----Original Message----- > From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] > Sent: Friday, March 24, 2006 11:07 PM > To: 'isis-wg@ietf.org' > Subject: [Isis-wg] Question about IS-IS Restart Signaling >=20 > Hi all, >=20 > According to RFC 3847, if multiple routers on a broadcast network restart > around the same time, is the helper (receiving) router supposed to include > multiple instances of Restart TLVs with RA bit set (one for each > restarting > router) in it's hellos? >=20 > thanks > ramesh >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Mar 25 07:41:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN84n-0004Y5-U7; Sat, 25 Mar 2006 07:41:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN84m-0004WT-8x for isis-wg@ietf.org; Sat, 25 Mar 2006 07:41:04 -0500 Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN84k-0005Xc-Qm for isis-wg@ietf.org; Sat, 25 Mar 2006 07:41:04 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.36 ; Sat, 25 Mar 2006 07:41:00 -0500 Received: from seahawk.middlebury.edu ([140.233.2.56]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Sat, 25 Mar 2006 07:41:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Date: Sat, 25 Mar 2006 07:39:30 -0500 Message-ID: <66356C9E5BCEB143AFF94ED511CD6F8D220959@seahawk.middlebury.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Question about IS-IS Restart Signaling Thread-Index: AcZP2qca9+E0vJvmSWSE9zTq9x9QowABSTWgAApXTrM= References: From: "Parker, Jeff" To: "Les Ginsberg \(ginsberg\)" , "Kandula, Ramesh" , X-OriginalArrivalTime: 25 Mar 2006 12:41:00.0597 (UTC) FILETIME=[5F08AE50:01C65009] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org I would think that losing power in a building and recovering might well = give you several routers rebooting at once. =20 =20 - jeff parker ________________________________ From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sat 3/25/2006 3:02 AM To: Kandula, Ramesh; isis-wg@ietf.org Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Hmmm...an interesting question. I would have to say that the RFC is not explicit on this point. >From an interoperability standpoint, I would be concerned that implementations might not parse past the initial restart TLV and therefore might not process a second restart TLV. This would not be fatal as the restarting router would eventually retransmit an IIH-RR (presumably by this time the other restarting router would have seen its RA) - but would be suboptimal as it would delay the reestablishment of the adjacency on the part of the restarting router. On the other hand, it would provide a means of decreasing the total number of IIH-RAs sent in response to the IIH-RRs in such a case. This is, of course, a very unlikely case for two reasons: 1)It is unlikely that two routers would restart "at the same time" 2)As the requirement on sending the IIH-RA is to send it "immediately" (with jitter on the LAN) the interval between receipt of IIH-RR from two different routers would need to be quite small. In the conservative spirit of being "strict in what you send" I would be inclined to NOT include multiple restart TLVs in the same IIH. I would recommend sending two IIHs one immediately after the other. Note that such short bursts are already allowed in the case of LSP/CSNP transmissions. Les > -----Original Message----- > From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] > Sent: Friday, March 24, 2006 11:07 PM > To: 'isis-wg@ietf.org' > Subject: [Isis-wg] Question about IS-IS Restart Signaling > > Hi all, > > According to RFC 3847, if multiple routers on a broadcast network restart > around the same time, is the helper (receiving) router supposed to include > multiple instances of Restart TLVs with RA bit set (one for each > restarting > router) in it's hellos? > > thanks > ramesh > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 26 12:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNZJu-0003IO-Lz; Sun, 26 Mar 2006 12:46:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNZJu-0003IJ-2G for isis-wg@ietf.org; Sun, 26 Mar 2006 12:46:30 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNZJs-0000WO-Ls for isis-wg@ietf.org; Sun, 26 Mar 2006 12:46:30 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 26 Mar 2006 09:46:28 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2QHkR7T004520; Sun, 26 Mar 2006 09:46:28 -0800 (PST) Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 26 Mar 2006 09:46:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Date: Sun, 26 Mar 2006 09:46:25 -0800 Message-ID: <08BF8CFFE33CE9409CD93E39F1F635EB01BCDD3E@xmb-sjc-231.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Question about IS-IS Restart Signaling Thread-Index: AcZP2qca9+E0vJvmSWSE9zTq9x9QowABSTWgAApXTrMAJ6szgA== From: "Sandip Devnath \(sadevnat\)" To: "Parker, Jeff" , "Les Ginsberg \(ginsberg\)" , "Kandula, Ramesh" , X-OriginalArrivalTime: 26 Mar 2006 17:46:27.0562 (UTC) FILETIME=[352B5CA0:01C650FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Wouldn't it cause whole forwarding to go away? Graceful restart's requirement is to have the forwarding intact, while routing protocol restarts (across different cards or same card). Regards Sandip=20 -----Original Message----- From: Parker, Jeff [mailto:jeffp@middlebury.edu]=20 Sent: Saturday, March 25, 2006 4:40 AM To: Les Ginsberg (ginsberg); Kandula, Ramesh; isis-wg@ietf.org Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling I would think that losing power in a building and recovering might well give you several routers rebooting at once. =20 =20 - jeff parker ________________________________ From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sat 3/25/2006 3:02 AM To: Kandula, Ramesh; isis-wg@ietf.org Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Hmmm...an interesting question. I would have to say that the RFC is not explicit on this point. >From an interoperability standpoint, I would be concerned that implementations might not parse past the initial restart TLV and therefore might not process a second restart TLV. This would not be fatal as the restarting router would eventually retransmit an IIH-RR (presumably by this time the other restarting router would have seen its RA) - but would be suboptimal as it would delay the reestablishment of the adjacency on the part of the restarting router. On the other hand, it would provide a means of decreasing the total number of IIH-RAs sent in response to the IIH-RRs in such a case. This is, of course, a very unlikely case for two reasons: 1)It is unlikely that two routers would restart "at the same time" 2)As the requirement on sending the IIH-RA is to send it "immediately" (with jitter on the LAN) the interval between receipt of IIH-RR from two different routers would need to be quite small. In the conservative spirit of being "strict in what you send" I would be inclined to NOT include multiple restart TLVs in the same IIH. I would recommend sending two IIHs one immediately after the other. Note that such short bursts are already allowed in the case of LSP/CSNP transmissions. Les > -----Original Message----- > From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] > Sent: Friday, March 24, 2006 11:07 PM > To: 'isis-wg@ietf.org' > Subject: [Isis-wg] Question about IS-IS Restart Signaling > > Hi all, > > According to RFC 3847, if multiple routers on a broadcast network restart > around the same time, is the helper (receiving) router supposed to include > multiple instances of Restart TLVs with RA bit set (one for each > restarting > router) in it's hellos? > > thanks > ramesh > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 26 14:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNavj-00037l-5P; Sun, 26 Mar 2006 14:29:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNavh-00037g-PW for isis-wg@ietf.org; Sun, 26 Mar 2006 14:29:37 -0500 Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNavf-0004w8-3Z for isis-wg@ietf.org; Sun, 26 Mar 2006 14:29:37 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.36 ; Sun, 26 Mar 2006 14:29:18 -0500 Received: from seahawk.middlebury.edu ([140.233.2.56]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Sun, 26 Mar 2006 14:29:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Date: Sun, 26 Mar 2006 14:27:32 -0500 Message-ID: <66356C9E5BCEB143AFF94ED511CD6F8D22095F@seahawk.middlebury.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Question about IS-IS Restart Signaling Thread-Index: AcZP2qca9+E0vJvmSWSE9zTq9x9QowABSTWgAApXTrMAJ6szgAAY358x References: <08BF8CFFE33CE9409CD93E39F1F635EB01BCDD3E@xmb-sjc-231.amer.cisco.com> From: "Parker, Jeff" To: "Sandip Devnath \(sadevnat\)" , "Les Ginsberg \(ginsberg\)" , "Kandula, Ramesh" , X-OriginalArrivalTime: 26 Mar 2006 19:29:17.0816 (UTC) FILETIME=[92ED6780:01C6510B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org I don't think this is a case we should alter the design for. I can imagine a scenario where some routers are on a UPS, and others are = not. =20 Again, this is an existence proof that the problem can happen, not = something we need to engineer for. =20 - jdp ________________________________ From: Sandip Devnath (sadevnat) [mailto:sadevnat@cisco.com] Sent: Sun 3/26/2006 12:46 PM To: Parker, Jeff; Les Ginsberg (ginsberg); Kandula, Ramesh; = isis-wg@ietf.org Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Wouldn't it cause whole forwarding to go away? Graceful restart's requirement is to have the forwarding intact, while routing protocol restarts (across different cards or same card). Regards Sandip -----Original Message----- From: Parker, Jeff [mailto:jeffp@middlebury.edu] Sent: Saturday, March 25, 2006 4:40 AM To: Les Ginsberg (ginsberg); Kandula, Ramesh; isis-wg@ietf.org Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling I would think that losing power in a building and recovering might well give you several routers rebooting at once.=20 - jeff parker ________________________________ From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sat 3/25/2006 3:02 AM To: Kandula, Ramesh; isis-wg@ietf.org Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Hmmm...an interesting question. I would have to say that the RFC is not explicit on this point. >From an interoperability standpoint, I would be concerned that implementations might not parse past the initial restart TLV and therefore might not process a second restart TLV. This would not be fatal as the restarting router would eventually retransmit an IIH-RR (presumably by this time the other restarting router would have seen its RA) - but would be suboptimal as it would delay the reestablishment of the adjacency on the part of the restarting router. On the other hand, it would provide a means of decreasing the total number of IIH-RAs sent in response to the IIH-RRs in such a case. This is, of course, a very unlikely case for two reasons: 1)It is unlikely that two routers would restart "at the same time" 2)As the requirement on sending the IIH-RA is to send it "immediately" (with jitter on the LAN) the interval between receipt of IIH-RR from two different routers would need to be quite small. In the conservative spirit of being "strict in what you send" I would be inclined to NOT include multiple restart TLVs in the same IIH. I would recommend sending two IIHs one immediately after the other. Note that such short bursts are already allowed in the case of LSP/CSNP transmissions. Les > -----Original Message----- > From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] > Sent: Friday, March 24, 2006 11:07 PM > To: 'isis-wg@ietf.org' > Subject: [Isis-wg] Question about IS-IS Restart Signaling > > Hi all, > > According to RFC 3847, if multiple routers on a broadcast network restart > around the same time, is the helper (receiving) router supposed to include > multiple instances of Restart TLVs with RA bit set (one for each > restarting > router) in it's hellos? > > thanks > ramesh > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 26 15:51:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNcCw-0006pr-TR; Sun, 26 Mar 2006 15:51:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNcCv-0006pm-Pj for isis-wg@ietf.org; Sun, 26 Mar 2006 15:51:29 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNcCv-00083W-FR for isis-wg@ietf.org; Sun, 26 Mar 2006 15:51:29 -0500 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 26 Mar 2006 12:51:28 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,130,1141632000"; d="scan'208"; a="535978203:sNHT25006016" Received: from [172.26.200.94] ([172.26.200.94]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Mar 2006 12:51:26 -0800 Message-ID: <4426FEC7.8040101@juniper.net> Date: Sun, 26 Mar 2006 22:51:19 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" Subject: Re: [Isis-wg] Question about IS-IS Restart Signaling References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2006 20:51:28.0441 (UTC) FILETIME=[0DCF1290:01C65117] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: isis-wg@ietf.org, "Kandula, Ramesh" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org hi les, some disagreement from my side - see comments inline; Les Ginsberg (ginsberg) wrote: > Hmmm...an interesting question. > > I would have to say that the RFC is not explicit on this point. > >>From an interoperability standpoint, I would be concerned that > implementations might not parse past the initial restart TLV and > therefore might not process a second restart TLV. This would not be > fatal as the restarting router would eventually retransmit an IIH-RR > (presumably by this time the other restarting router would have seen its > RA) - but would be suboptimal as it would delay the reestablishment of > the adjacency on the part of the restarting router. On the other hand, > it would provide a means of decreasing the total number of IIH-RAs sent > in response to the IIH-RRs in such a case. > > This is, of course, a very unlikely case for two reasons: > > 1)It is unlikely that two routers would restart "at the same time" what about a buffer overrun during LSP parsing and a subsequent crash in the isis module ? - since GR is engineered for control-plane failure this *is* the case we are trying to address. > 2)As the requirement on sending the IIH-RA is to send it "immediately" > (with jitter on the LAN) the interval between receipt of IIH-RR from two > different routers would need to be quite small. the IIHs with the restart request could have been batched up, until the adjacency mgmt module drains the IO queue making them appear to have arrived simultaneous. > In the conservative spirit of being "strict in what you send" I would be > inclined to NOT include multiple restart TLVs in the same IIH. I would > recommend sending two IIHs one immediately after the other. Note that > such short bursts are already allowed in the case of LSP/CSNP > transmissions. i fail to see a violation of the "strict in what you send" by packing multiple restart TLVs in a single IIH. what you are proposing actually is a violation of "be liberal what you receive" principle by ruling out a ligitimate way of encoding information in a single IIH. an implementation note: most implementations have an internal representation of the data found in TLVs. it is highly recommended to store any data found in tree / list representation i.e. you may append information at any time. so ruling out "data may be spread over multiple TLVs" is like encouraging bad coding habits ;-) /hannes >>-----Original Message----- >>From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] >>Sent: Friday, March 24, 2006 11:07 PM >>To: 'isis-wg@ietf.org' >>Subject: [Isis-wg] Question about IS-IS Restart Signaling >> >>Hi all, >> >>According to RFC 3847, if multiple routers on a broadcast network > > restart > >>around the same time, is the helper (receiving) router supposed to > > include > >>multiple instances of Restart TLVs with RA bit set (one for each >>restarting >>router) in it's hellos? >> >>thanks >>ramesh >> >>_______________________________________________ >>Isis-wg mailing list >>Isis-wg@ietf.org >>https://www1.ietf.org/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 26 18:36:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNemm-0004Hw-Uq; Sun, 26 Mar 2006 18:36:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNeml-0004Hr-Pc for isis-wg@ietf.org; Sun, 26 Mar 2006 18:36:39 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNeml-0006Tv-BD for isis-wg@ietf.org; Sun, 26 Mar 2006 18:36:39 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 26 Mar 2006 15:36:36 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2QNaaGv025573; Sun, 26 Mar 2006 15:36:36 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 26 Mar 2006 15:36:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Date: Sun, 26 Mar 2006 15:36:34 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Question about IS-IS Restart Signaling Thread-Index: AcZP2qca9+E0vJvmSWSE9zTq9x9QowABSTWgAApXTrMAJ6szgAAY358xAAh+fDA= From: "Les Ginsberg \(ginsberg\)" To: "Parker, Jeff" , "Sandip Devnath \(sadevnat\)" , "Kandula, Ramesh" , X-OriginalArrivalTime: 26 Mar 2006 23:36:36.0097 (UTC) FILETIME=[1F3B6710:01C6512E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Jeff - I think Sandip's point is of significance. In order for the scenario you raise to be relevant here you have to have some routers in which the forwarding plane is protected by UPS but the control plane is not - while other routers are fully protected (or otherwise isolated from the power failure). Nevertheless, I agree that the scenario raised by Ramesh needs to be considered - and to the extent your example suggests ways in which it might occur - however unlikely - that is helpful. Les > -----Original Message----- > From: Parker, Jeff [mailto:jeffp@middlebury.edu] > Sent: Sunday, March 26, 2006 11:28 AM > To: Sandip Devnath (sadevnat); Les Ginsberg (ginsberg); Kandula, Ramesh; > isis-wg@ietf.org > Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling >=20 > I don't think this is a case we should alter the design for. > I can imagine a scenario where some routers are on a UPS, and others are > not. >=20 > Again, this is an existence proof that the problem can happen, not > something we need to engineer for. >=20 > - jdp >=20 > ________________________________ >=20 > From: Sandip Devnath (sadevnat) [mailto:sadevnat@cisco.com] > Sent: Sun 3/26/2006 12:46 PM > To: Parker, Jeff; Les Ginsberg (ginsberg); Kandula, Ramesh; isis- > wg@ietf.org > Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling >=20 >=20 >=20 > Wouldn't it cause whole forwarding to go away? Graceful restart's > requirement is to have the forwarding intact, while routing protocol > restarts (across different cards or same card). >=20 > Regards > Sandip >=20 > -----Original Message----- > From: Parker, Jeff [mailto:jeffp@middlebury.edu] > Sent: Saturday, March 25, 2006 4:40 AM > To: Les Ginsberg (ginsberg); Kandula, Ramesh; isis-wg@ietf.org > Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling >=20 > I would think that losing power in a building and recovering might well > give you several routers rebooting at once. >=20 > - jeff parker >=20 > ________________________________ >=20 > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sat 3/25/2006 3:02 AM > To: Kandula, Ramesh; isis-wg@ietf.org > Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling >=20 >=20 >=20 > Hmmm...an interesting question. >=20 > I would have to say that the RFC is not explicit on this point. >=20 > >From an interoperability standpoint, I would be concerned that > implementations might not parse past the initial restart TLV and > therefore might not process a second restart TLV. This would not be > fatal as the restarting router would eventually retransmit an IIH-RR > (presumably by this time the other restarting router would have seen its > RA) - but would be suboptimal as it would delay the reestablishment of > the adjacency on the part of the restarting router. On the other hand, > it would provide a means of decreasing the total number of IIH-RAs sent > in response to the IIH-RRs in such a case. >=20 > This is, of course, a very unlikely case for two reasons: >=20 > 1)It is unlikely that two routers would restart "at the same time" > 2)As the requirement on sending the IIH-RA is to send it "immediately" > (with jitter on the LAN) the interval between receipt of IIH-RR from two > different routers would need to be quite small. >=20 > In the conservative spirit of being "strict in what you send" I would be > inclined to NOT include multiple restart TLVs in the same IIH. I would > recommend sending two IIHs one immediately after the other. Note that > such short bursts are already allowed in the case of LSP/CSNP > transmissions. >=20 > Les >=20 >=20 > > -----Original Message----- > > From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] > > Sent: Friday, March 24, 2006 11:07 PM > > To: 'isis-wg@ietf.org' > > Subject: [Isis-wg] Question about IS-IS Restart Signaling > > > > Hi all, > > > > According to RFC 3847, if multiple routers on a broadcast network > restart > > around the same time, is the helper (receiving) router supposed to > include > > multiple instances of Restart TLVs with RA bit set (one for each > > restarting > > router) in it's hellos? > > > > thanks > > ramesh > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg >=20 >=20 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Mar 26 18:59:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNf8V-000871-8b; Sun, 26 Mar 2006 18:59:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNf8T-00086q-Qe for isis-wg@ietf.org; Sun, 26 Mar 2006 18:59:05 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNf8T-0007aM-8G for isis-wg@ietf.org; Sun, 26 Mar 2006 18:59:05 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 26 Mar 2006 15:59:06 -0800 X-IronPort-AV: i="4.03,131,1141632000"; d="scan'208"; a="1788452024:sNHT33139300" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2QNx4w1013655; Sun, 26 Mar 2006 15:59:04 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 26 Mar 2006 15:59:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling Date: Sun, 26 Mar 2006 15:59:03 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Question about IS-IS Restart Signaling Thread-Index: AcZRFw5/92I87lYjTNmXjv3pVOfwjwAFyA4A From: "Les Ginsberg \(ginsberg\)" To: "Hannes Gredler" X-OriginalArrivalTime: 26 Mar 2006 23:59:04.0531 (UTC) FILETIME=[42F61A30:01C65131] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: isis-wg@ietf.org, "Kandula, Ramesh" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes - > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Sunday, March 26, 2006 12:51 PM > To: Les Ginsberg (ginsberg) > Cc: Kandula, Ramesh; isis-wg@ietf.org > Subject: Re: [Isis-wg] Question about IS-IS Restart Signaling >=20 > hi les, >=20 > some disagreement from my side - see comments inline; >=20 > Les Ginsberg (ginsberg) wrote: > > Hmmm...an interesting question. > > > > I would have to say that the RFC is not explicit on this point. > > > >>From an interoperability standpoint, I would be concerned that > > implementations might not parse past the initial restart TLV and > > therefore might not process a second restart TLV. This would not be > > fatal as the restarting router would eventually retransmit an IIH-RR > > (presumably by this time the other restarting router would have seen its > > RA) - but would be suboptimal as it would delay the reestablishment of > > the adjacency on the part of the restarting router. On the other hand, > > it would provide a means of decreasing the total number of IIH-RAs sent > > in response to the IIH-RRs in such a case. > > > > This is, of course, a very unlikely case for two reasons: > > > > 1)It is unlikely that two routers would restart "at the same time" >=20 > what about a buffer overrun during LSP parsing and a subsequent crash > in the isis module ? - since GR is engineered for control-plane failure > this *is* the case we are trying to address. >=20 The primary application of GR is in the case of controlled restarts (e.g. software upgrade). To the extent that the technology is also useful in unexpected control plane failure cases I would argue that it is most useful in cases of hardware component failure (assuming a redundant component is available). The case you cite is a very problematic use of GR. Knowledgeable customers are going to ask why they should have confidence that the same software which just failed is likely to survive when faced with the same link state database which caused the failure. While it is possible that a reboot might clear whatever set of conditions caused the original failure, it is hardly assured - and this is NOT the primary case GR is designed to address. BTW, this is EXACTLY why RFC 3847 specifies rules to prevent the helper router from supporting multiple restarts from the same router within a short period of time. > > 2)As the requirement on sending the IIH-RA is to send it "immediately" > > (with jitter on the LAN) the interval between receipt of IIH-RR from two > > different routers would need to be quite small. >=20 > the IIHs with the restart request could have been batched up, > until the adjacency mgmt module drains the IO queue making > them appear to have arrived simultaneous. >=20 > > In the conservative spirit of being "strict in what you send" I would be > > inclined to NOT include multiple restart TLVs in the same IIH. I would > > recommend sending two IIHs one immediately after the other. Note that > > such short bursts are already allowed in the case of LSP/CSNP > > transmissions. >=20 > i fail to see a violation of the "strict in what you send" by packing > multiple restart TLVs in a single IIH. what you are proposing actually > is a violation of "be liberal what you receive" principle by ruling > out a ligitimate way of encoding information in a single IIH. As the RFC does NOT specifically state that multiple restart TLVs can be included in an IIH I can imagine that implementations might be written to only parse for the first occurrence. If I want to have the highest confidence that what I send will be correctly interpreted by all conforming implementations, then sending two IIHs with a single restart TLV in each is clearly the way to go. Any implementation which cannot correctly process such an IIH is flawed. If however, I send a single IIH with multiple restart TLVs, I leave open the possibility that some implementations might not look at the second restart TLV. At that point there is a legitimate discussion (as demonstrated by this thread) as to whether the sender or the receiver is non-conformant. Such an argument is not one that any customer would appreciate. So, as the sender I choose the more conservative path. >=20 > an implementation note: > most implementations have an internal representation of the data > found in TLVs. it is highly recommended to store any data found > in tree / list representation i.e. you may append information at any > time. so ruling out "data may be spread over multiple TLVs" is like > encouraging bad coding habits ;-) >=20 If you are saying that you know of one implementation of RFC 3847 that would correctly process multiple restart TLVs in a single IIH, that is a worthwhile data point. In fact, I invite all implementers of RFC 3847 to let me know how their implementations handle this case in both roles (i.e. sender and receiver). It would be useful to the community to publish the results of that survey. Les > /hannes >=20 > >>-----Original Message----- > >>From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] > >>Sent: Friday, March 24, 2006 11:07 PM > >>To: 'isis-wg@ietf.org' > >>Subject: [Isis-wg] Question about IS-IS Restart Signaling > >> > >>Hi all, > >> > >>According to RFC 3847, if multiple routers on a broadcast network > > > > restart > > > >>around the same time, is the helper (receiving) router supposed to > > > > include > > > >>multiple instances of Restart TLVs with RA bit set (one for each > >>restarting > >>router) in it's hellos? > >> > >>thanks > >>ramesh > >> > >>_______________________________________________ > >>Isis-wg mailing list > >>Isis-wg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg