From isis-wg-admin@ietf.org Tue Apr 1 06:57:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05360 for ; Tue, 1 Apr 2003 06:57:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31CEoK22666; Tue, 1 Apr 2003 07:14:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31CDYK22587 for ; Tue, 1 Apr 2003 07:13:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04867; Tue, 1 Apr 2003 06:49:19 -0500 (EST) Message-Id: <200304011149.GAA04867@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-auto-encap-03.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 01 Apr 2003 06:49:19 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Automatic Encapsulation Author(s) : P. Christian Filename : draft-ietf-isis-auto-encap-03.txt Pages : 24 Date : 2003-3-31 RFC 1195 [1] documents a dual routing protocol that can be used to route both CLNP and IPv4, that is Integrated IS-IS. Integrated IS- IS can now also be used to route IPv6 [12]. RFC 1195 [1] places certain topological restrictions on networks that are routed using Integrated IS-IS, specifically that every Intermediate System in a level-1 area must be able to forward all network layer protocols that are present in that area, and that every level-2 Intermediate System must be able to forward all network layer protocols present in the routing domain. The mechanism described in this document enables an Intermediate System or a group of Intermediate Systems that do not support a particular network layer protocol to be used in a level-1 area or level-2 subdomain where that network layer protocol is present. Specifically the mechanism provides automatic encapsulation and unencapsulation so that a packet or PDU may pass through an Intermediate System that would not normally be able to forward that type of packet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-auto-encap-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-auto-encap-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-31124543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-auto-encap-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-auto-encap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-31124543.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Apr 3 04:37:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11482 for ; Thu, 3 Apr 2003 04:37:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339YXK25573; Thu, 3 Apr 2003 04:34:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339XIK25499 for ; Thu, 3 Apr 2003 04:33:18 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11249 for ; Thu, 3 Apr 2003 04:30:35 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Apr 2003 01:33:04 -0800 Received: from 203.200.20.226 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 03 Apr 2003 09:33:03 GMT X-Originating-IP: [203.200.20.226] X-Originating-Email: [isis_fumes@hotmail.com] From: "Jeff Beck" To: isis-wg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Apr 2003 09:33:04.0195 (UTC) FILETIME=[06C00930:01C2F9C4] Subject: [Isis-wg] Demand Circuits on ISIS Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 03 Apr 2003 11:33:03 +0200 Hello, Season's greetings! I am newbie and want some help or advice. Are there any extensions in ISIS which support turning of my periodic protocol HELLOs/LSP expiries on my link. SAy, something like Demand Circuit support where i incur some cost each time i send a packet out ! Thanks! _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Apr 3 10:05:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22678 for ; Thu, 3 Apr 2003 10:05:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33F0QK21559; Thu, 3 Apr 2003 10:00:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33ExeK21380 for ; Thu, 3 Apr 2003 09:59:40 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22052 for ; Thu, 3 Apr 2003 09:56:51 -0500 (EST) Received: from dingdong.cisco.com (IDENT:mirapoint@dingdong.cisco.com [64.102.17.16]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h33ExGkh006157; Thu, 3 Apr 2003 09:59:16 -0500 (EST) Received: from jlearman-w2k01.cisco.com (rtp-vpn2-903.cisco.com [10.82.243.135]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACA59359; Thu, 3 Apr 2003 09:59:13 -0500 (EST) Message-Id: <4.3.2.7.2.20030403093013.042a06c8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Jeff Beck" From: Jeff Learman Subject: Re: [Isis-wg] Demand Circuits on ISIS Cc: isis-wg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 03 Apr 2003 09:38:43 -0500 ISIS has very limited support for dynamically assigned circuits. It supports sending data traffic over them, but it does not support running the routing protocol over them. This is covered in ISO 10589. At 04:33 AM 4/3/2003, Jeff Beck wrote: >Hello, >Season's greetings! > >I am newbie and want some help or advice. > >Are there any extensions in ISIS which support turning of my periodic protocol HELLOs/LSP expiries on my link. SAy, something like Demand Circuit support where i incur some cost each time i send a packet out ! > >Thanks! > > > > > > > >_________________________________________________________________ >MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus > >_______________________________________________ >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-admin@ietf.org Thu Apr 3 10:44:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25863 for ; Thu, 3 Apr 2003 10:44:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Fd4K25942; Thu, 3 Apr 2003 10:39:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FZjK24834 for ; Thu, 3 Apr 2003 10:35:45 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25184 for ; Thu, 3 Apr 2003 10:32:54 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jeff Beck'" , isis-wg@ietf.org Subject: RE: [Isis-wg] Demand Circuits on ISIS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 3 Apr 2003 10:35:13 -0500 > Are there any extensions in ISIS which support turning of my periodic > protocol HELLOs/LSP expiries on my link. SAy, something like > Demand Circuit > support where i incur some cost each time i send a packet out ! Jeff B - There is a notion of Dynamically Assigned (DA) circuits described in section 8.3.2 of 10589. I don't know how widely used this is. - jeff p _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Apr 3 16:34:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15271 for ; Thu, 3 Apr 2003 16:34:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LUMK31911; Thu, 3 Apr 2003 16:30:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LTXK31854 for ; Thu, 3 Apr 2003 16:29:33 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14850 for ; Thu, 3 Apr 2003 16:26:35 -0500 (EST) Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Updates to the IS-IS MIB Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 3 Apr 2003 16:29:03 -0500 Bill Fenner's html web page has shamed me into resubmitting the IS-IS MIB to clear up the issues he found. Here are the list of differences, followed by the diff's of the files. -- Changes in version 12 -- -- Clarify how isisSysLevelOverloadState gets it's value -- Clarify values of isisLSPTLVIndex -- Address issues from htmllint website -- http://www.icir.org/fenner/mibs/htmllint/ISIS-MIB.html -- date specification `200302401200Z' contains an illegal day -- index element `isisLSPTLVIndex' of row `isisLSPTLVEntry' should -- be not-accessible in SMIv2 MIB -- name `isisOriginatingLSPBufferSizeMismatch' longer than 32 -- Add new conformance section that covers all groups - jeff parker - axiowave networks 40c28 < LAST-UPDATED "200302401200Z" -- UTC date of the most recent REVISION. --- > LAST-UPDATED "200304031200Z" 1079,1081c1067,1069 < The administrator may set the state to 'waiting' when < the router is initializing by setting the object < isisSysLevelSetOverload. --- > The administrator may indirectly force the state to > 'waiting' when the router is initializing by setting > the object isisSysLevelSetOverload. 3093c3081 < MAX-ACCESS read-only --- > MAX-ACCESS not-accessible 3096c3084,3085 < "The index of this TLV in the LSP." --- > "The index of this TLV in the LSP. The first TLV has index 1 > and the Nth TLV has an index on N." *Note: "on" changed to "of" in version 13 3192c3181 < isisSystemInstance OBJECT-TYPE -- Cannot use isisSysInstance, as it is 'not-accessible' --- > isisSystemInstance OBJECT-TYPE 3591,3592c3580 < for a circuit. < --- > for the circuit. 3599c3587 < isisOriginatingLSPBufferSizeMismatch NOTIFICATION-TYPE --- > isisOrigLSPBuffSizeMismatch NOTIFICATION-TYPE 3685a3674,3693 > -- List of all groups, manditory and optional > isisAdvancedCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for agents that support > the IS-IS MIB" > MODULE -- this module > MANDATORY-GROUPS { > isisSystemGroup, > isisCircuitGroup, > isisISAdjGroup, > isisNotificationObjectGroup, > isisNotificationGroup, > isisISPDUCounterGroup, > isisRATableGroup, > isisISIPRADestGroup, > isisLSPGroup > } > ::= { isisCompliances 2 } > 3844c3852 < isisOriginatingLSPBufferSizeMismatch, --- > isisOrigLSPBuffSizeMismatch, 3917d3924 < isisLSPTLVIndex, _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 7 07:19:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15480 for ; Mon, 7 Apr 2003 07:19:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BIJ801387; Mon, 7 Apr 2003 07:18:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BEX801227 for ; Mon, 7 Apr 2003 07:14:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14921; Mon, 7 Apr 2003 07:09:52 -0400 (EDT) Message-Id: <200304071109.HAA14921@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-12.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Apr 2003 07:09:51 -0400 --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 : Management Information Base for IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-wg-mib-12.txt Pages : 92 Date : 2003-4-4 This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner [1]. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-mib-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-4115724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-4115724.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 7 11:48:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24223 for ; Mon, 7 Apr 2003 11:48:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37FeK820704; Mon, 7 Apr 2003 11:40:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37FZH819708 for ; Mon, 7 Apr 2003 11:35:17 -0400 Received: from thurn.corp.titan.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23714 for ; Mon, 7 Apr 2003 11:30:28 -0400 (EDT) Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5]) by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h37FWirF011948; Mon, 7 Apr 2003 08:32:46 -0700 Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55) id <2B4PBJDQ>; Mon, 7 Apr 2003 11:31:57 -0400 Message-ID: <561621C69F17D511A3A20050047340EC01AAF662@VCMD-NT1> From: "Ferrell, William" To: "'Jeff Parker'" , "'Jonnala, Nagi'" , "'rja@extremenetworks.com'" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 11:31:51 -0400 How far did this draft go ? There are some issues that stood to evolve since then : "This mechanism does not prevent replay attacks, however such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information. Denial of service attacks are not generally preventable in a useful networking protocol [4]." While I agree tht the HMAC-MD-5 will not stop replay attacks alone but when used in conjuction with the protocol will work with the timers and other mechanism to render the attack useless. My exception is with what clearly seems to be opinion " Denial of service attacks are not generally preventable in a useful networking protocol" Before "getting bent out of shape" I realize that there is always a chance of mis-communication would like a full and clearer explanation. The other expanation is that this rfc and the writer's opinion has indeed evolved. Will _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 7 12:33:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26274 for ; Mon, 7 Apr 2003 12:33:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GT6824568; Mon, 7 Apr 2003 12:29:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GKs823986 for ; Mon, 7 Apr 2003 12:20:54 -0400 Received: from thurn.corp.titan.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25209 for ; Mon, 7 Apr 2003 12:16:07 -0400 (EDT) Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5]) by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h37GIQrF016255; Mon, 7 Apr 2003 09:18:28 -0700 Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55) id <2B4PBJG8>; Mon, 7 Apr 2003 12:17:40 -0400 Message-ID: <561621C69F17D511A3A20050047340EC01AAF663@VCMD-NT1> From: "Ferrell, William" To: "'Jeff Parker'" , "'Jonnala, Nagi'" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] RE: draft-ietf-isis-wg-mib-12.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 12:17:28 -0400 SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. While I agree with you here Jeff, SNMP v1 is vulnerable, We've found that SNMP v3 is having many implementation issues accross managment platform . Like HPOV and espeacally EnterPol. I guess that where Im goiing is that maybe we could dig a bit deeprer and offer a real solution for secure manage ment _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 7 14:24:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29845 for ; Mon, 7 Apr 2003 14:24:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37IKG800678; Mon, 7 Apr 2003 14:20:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37IHZ800559 for ; Mon, 7 Apr 2003 14:17:35 -0400 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29571 for ; Mon, 7 Apr 2003 14:12:45 -0400 (EDT) Message-ID: From: Jeff Parker To: "'Ferrell, William'" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 14:15:09 -0400 > How far did this draft go ? There are some issues that stood > to evolve since then : While the expiration date on the draft is in the past, I think this document is very much alive. > > "This mechanism does not prevent replay attacks, however such > attacks would trigger existing mechanisms in the IS-IS > protocol that would effectively reject old information. > Denial of service attacks are not generally preventable > in a useful networking protocol [4]." > > > While I agree tht the HMAC-MD-5 will not stop replay > attacks alone but when used in conjuction with the > protocol will work with the timers and other > mechanism to render the attack useless. > > My exception is with what clearly seems to be opinion " > Denial of service attacks are not generally preventable > in a useful networking protocol" > > Before "getting bent out of shape" I realize that there > is always a chance of mis-communication would like a > full and clearer explanation. The other expanation is > that this rfc and the writer's opinion has indeed evolved. > Will Will - First, this proposal is a real advance over prior art. It was much worse before this. As to the statement above, it -is- quite difficult to have a useful routing protocol that doesn't involve trusting the information provided by a third party. If you are open to peering with new neighbors, as any IGP with a hello protocol is, you are subject to DOS attackts. If you compromise a router in the network, you can inject false information into the network, and thus misroute and blackhole traffic, and waste router cycles with spurious SPF recomputations. There are things that you can do to mitigate these effects, but it isn't clear that outlining this is within the scope of this group. While the language above is blunt, those are the realities. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 7 14:30:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00044 for ; Mon, 7 Apr 2003 14:30:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37IQn800904; Mon, 7 Apr 2003 14:26:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37ION800798 for ; Mon, 7 Apr 2003 14:24:23 -0400 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29750 for ; Mon, 7 Apr 2003 14:19:32 -0400 (EDT) Message-ID: From: Jeff Parker To: "'Ferrell, William'" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] RE: draft-ietf-isis-wg-mib-12.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 14:21:59 -0400 > SNMPv1 by itself is not a secure environment. Even if the network > itself is secure (for example by using IPSec), even then, > there is no > control as to who on the secure network is allowed to access and > GET/SET (read/change/create/delete) the objects in this MIB. > > It is recommended that the implementers consider the security > features as provided by the SNMPv3 framework. > Specifically, the use > of the User-based Security Model RFC 2574 [RFC2574] and the View- > based Access Control Model RFC 2575 [RFC2575] is recommended. > > > While I agree with you here Jeff, SNMP v1 is vulnerable, > We've found that SNMP v3 is having many implementation > issues accross managment platform . > Like HPOV and espeacally EnterPol. > I guess that where Im goiing is that maybe we could dig > a bit deeprer and > offer a real solution for secure manage > > ment Will - Help me understand what you are requesting. Is there something in the IS-IS MIB today that prevents an implementation from using SNMP v3? If so, I'll see what I can do to remove it. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 7 15:17:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02701 for ; Mon, 7 Apr 2003 15:17:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37JDp804574; Mon, 7 Apr 2003 15:13:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37JBF804459 for ; Mon, 7 Apr 2003 15:11:15 -0400 Received: from thurn.corp.titan.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01278 for ; Mon, 7 Apr 2003 15:06:23 -0400 (EDT) Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5]) by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h37J8hrF032465; Mon, 7 Apr 2003 12:08:44 -0700 Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55) id <2B4PBJT5>; Mon, 7 Apr 2003 15:07:56 -0400 Message-ID: <561621C69F17D511A3A20050047340EC01AAF667@VCMD-NT1> From: "Ferrell, William" To: "'Jeff Parker'" , "Ferrell, William" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Apr 2003 15:07:52 -0400 Jeff Blunt is cool, and to say that this is an evolution ...WOW. I agree that there are many mitigation techniques the simplest of course is to ACL with only trusted peers. Thier in lies my issue with most of these drafts, not much in-depth focus on the security issues. Will -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Monday, April 07, 2003 2:15 PM To: 'Ferrell, William' Cc: ISIS-WG (E-mail) Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt > How far did this draft go ? There are some issues that stood > to evolve since then : While the expiration date on the draft is in the past, I think this document is very much alive. > > "This mechanism does not prevent replay attacks, however such > attacks would trigger existing mechanisms in the IS-IS > protocol that would effectively reject old information. > Denial of service attacks are not generally preventable > in a useful networking protocol [4]." > > > While I agree tht the HMAC-MD-5 will not stop replay > attacks alone but when used in conjuction with the > protocol will work with the timers and other > mechanism to render the attack useless. > > My exception is with what clearly seems to be opinion " > Denial of service attacks are not generally preventable > in a useful networking protocol" > > Before "getting bent out of shape" I realize that there > is always a chance of mis-communication would like a > full and clearer explanation. The other expanation is > that this rfc and the writer's opinion has indeed evolved. > Will Will - First, this proposal is a real advance over prior art. It was much worse before this. As to the statement above, it -is- quite difficult to have a useful routing protocol that doesn't involve trusting the information provided by a third party. If you are open to peering with new neighbors, as any IGP with a hello protocol is, you are subject to DOS attackts. If you compromise a router in the network, you can inject false information into the network, and thus misroute and blackhole traffic, and waste router cycles with spurious SPF recomputations. There are things that you can do to mitigate these effects, but it isn't clear that outlining this is within the scope of this group. While the language above is blunt, those are the realities. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 8 10:01:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10377 for ; Tue, 8 Apr 2003 10:01:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38E0R826721; Tue, 8 Apr 2003 10:00:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38DvK826530 for ; Tue, 8 Apr 2003 09:57:20 -0400 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10052 for ; Tue, 8 Apr 2003 09:52:05 -0400 (EDT) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 35CAB3444E; Tue, 8 Apr 2003 06:08:12 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h38DsbYB009347; Tue, 8 Apr 2003 06:54:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt Message-ID: Thread-Topic: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt Thread-Index: AcL9OvkTYqoYhV5zS5+iRqim5ziUPgAj2gXA From: "Tony Li" To: "Ferrell, William" , "Jeff Parker" Cc: "ISIS-WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h38DvL826535 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 06:54:36 -0700 Content-Transfer-Encoding: 8bit So you're suggesting that we trust source addresses? Tony | -----Original Message----- | From: Ferrell, William [mailto:William.Ferrell@titan.com] | Sent: Monday, April 07, 2003 12:08 PM | To: 'Jeff Parker'; Ferrell, William | Cc: ISIS-WG (E-mail) | Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt | | | Jeff | Blunt is cool, and to say that this is an evolution ...WOW. | I agree that there are many mitigation techniques the | simplest of course is | to ACL with only trusted peers. Thier in lies my issue | with most of these | drafts, not much in-depth focus on the security issues. | Will | | -----Original Message----- | From: Jeff Parker [mailto:jparker@axiowave.com] | Sent: Monday, April 07, 2003 2:15 PM | To: 'Ferrell, William' | Cc: ISIS-WG (E-mail) | Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt | | | | > How far did this draft go ? There are some issues that stood | > to evolve since then : | | While the expiration date on the draft is in the past, I think | this document is very much alive. | > | > "This mechanism does not prevent replay attacks, | however such | > attacks would trigger existing mechanisms in the IS-IS | > protocol that would effectively reject old information. | > Denial of service attacks are not generally preventable | > in a useful networking protocol [4]." | > | > | > While I agree tht the HMAC-MD-5 will not stop replay | > attacks alone but when used in conjuction with the | > protocol will work with the timers and other | > mechanism to render the attack useless. | > | > My exception is with what clearly seems to be opinion " | > Denial of service attacks are not generally preventable | > in a useful networking protocol" | > | > Before "getting bent out of shape" I realize that there | > is always a chance of mis-communication would like a | > full and clearer explanation. The other expanation is | > that this rfc and the writer's opinion has indeed evolved. | > Will | | Will - | First, this proposal is a real advance over prior art. | It was much worse before this. | As to the statement above, it -is- quite difficult to | have a useful routing protocol that doesn't involve trusting | the information provided by a third party. | If you are open to peering with new neighbors, as | any IGP with a hello protocol is, you are subject to | DOS attackts. | If you compromise a router in the network, you | can inject false information into the network, and thus | misroute and blackhole traffic, and waste router cycles | with spurious SPF recomputations. | There are things that you can do to mitigate these | effects, but it isn't clear that outlining this is within | the scope of this group. While the language above is blunt, | those are the realities. | | - jeff parker | _______________________________________________ | Isis-wg mailing list | Isis-wg@ietf.org | https://www1.ietf.org/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 8 13:00:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22085 for ; Tue, 8 Apr 2003 13:00:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38H0V810188; Tue, 8 Apr 2003 13:00:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GtZ809893 for ; Tue, 8 Apr 2003 12:55:35 -0400 Received: from thurn.corp.titan.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21547 for ; Tue, 8 Apr 2003 12:50:15 -0400 (EDT) Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5]) by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h38GqerF025653; Tue, 8 Apr 2003 09:52:42 -0700 Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55) id <2B4PBL37>; Tue, 8 Apr 2003 12:51:53 -0400 Message-ID: <561621C69F17D511A3A20050047340EC01AAF66A@VCMD-NT1> From: "Ferrell, William" To: "'Tony Li '" , "'Jeff Parker '" Cc: "'ISIS-WG (E-mail) '" Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 12:51:50 -0400 Hmm... Tony From what you can tell thats the summ of my discussion ? from an IA (Info. Assur.)opinion this is a well balanced and in-depth draft. "Andersson, et al. RFC 3036 LDP Specification" Though its not "short and sweet" This guy showed a deeper knowledge for operations as well as the true security implications to include real risk -mitigation. Which concretely conludes that he is profoundly knowledgable of the technology. On a lighter note he didnt seem to capture it all into one shallow statement/question ie. " So you're suggesting that we trust source addresses?" Will -----Original Message----- From: Tony Li To: Ferrell, William; Jeff Parker Cc: ISIS-WG (E-mail) Sent: 4/8/03 9:54 AM Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt So you're suggesting that we trust source addresses? Tony | -----Original Message----- | From: Ferrell, William [mailto:William.Ferrell@titan.com] | Sent: Monday, April 07, 2003 12:08 PM | To: 'Jeff Parker'; Ferrell, William | Cc: ISIS-WG (E-mail) | Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt | | | Jeff | Blunt is cool, and to say that this is an evolution ...WOW. | I agree that there are many mitigation techniques the | simplest of course is | to ACL with only trusted peers. Thier in lies my issue | with most of these | drafts, not much in-depth focus on the security issues. | Will | | -----Original Message----- | From: Jeff Parker [mailto:jparker@axiowave.com] | Sent: Monday, April 07, 2003 2:15 PM | To: 'Ferrell, William' | Cc: ISIS-WG (E-mail) | Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt | | | | > How far did this draft go ? There are some issues that stood | > to evolve since then : | | While the expiration date on the draft is in the past, I think | this document is very much alive. | > | > "This mechanism does not prevent replay attacks, | however such | > attacks would trigger existing mechanisms in the IS-IS | > protocol that would effectively reject old information. | > Denial of service attacks are not generally preventable | > in a useful networking protocol [4]." | > | > | > While I agree tht the HMAC-MD-5 will not stop replay | > attacks alone but when used in conjuction with the | > protocol will work with the timers and other | > mechanism to render the attack useless. | > | > My exception is with what clearly seems to be opinion " | > Denial of service attacks are not generally preventable | > in a useful networking protocol" | > | > Before "getting bent out of shape" I realize that there | > is always a chance of mis-communication would like a | > full and clearer explanation. The other expanation is | > that this rfc and the writer's opinion has indeed evolved. | > Will | | Will - | First, this proposal is a real advance over prior art. | It was much worse before this. | As to the statement above, it -is- quite difficult to | have a useful routing protocol that doesn't involve trusting | the information provided by a third party. | If you are open to peering with new neighbors, as | any IGP with a hello protocol is, you are subject to | DOS attackts. | If you compromise a router in the network, you | can inject false information into the network, and thus | misroute and blackhole traffic, and waste router cycles | with spurious SPF recomputations. | There are things that you can do to mitigate these | effects, but it isn't clear that outlining this is within | the scope of this group. While the language above is blunt, | those are the realities. | | - jeff parker | _______________________________________________ | Isis-wg mailing list | Isis-wg@ietf.org | https://www1.ietf.org/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 8 14:12:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24495 for ; Tue, 8 Apr 2003 14:12:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IBF816440; Tue, 8 Apr 2003 14:11:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38I8b816322 for ; Tue, 8 Apr 2003 14:08:37 -0400 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24199 for ; Tue, 8 Apr 2003 14:03:18 -0400 (EDT) Message-ID: From: Jeff Parker To: "'Ferrell, William'" , "'Tony Li '" , Jeff Parker Cc: "'ISIS-WG (E-mail) '" Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 14:05:39 -0400 > From what you can tell thats the summ of my discussion ? > > This guy showed a deeper knowledge for operations as > well as the true security implications to include real > risk-mitigation. Which concretely conludes that he is > profoundly knowledgable of the technology. > > Will > > > So you're suggesting that we trust source addresses? > > > Tony > > > | -----Original Message----- > | From: Ferrell, William [mailto:William.Ferrell@titan.com] > | I agree that there are many mitigation techniques the > | simplest of course is to ACL with only trusted peers. Will - I can't speak for Tony, but suspect that this was the comment he was responding to. In the case of an IGP, the peers are machines, and all we have to judge them by are some bits in a packet. As you know, those are easy to fake. Currently, IS-IS is deployed in some important spots. Any change to IS-IS that involves large changes is a non- starter. Thus security changes that involve major changes in the protocol are out of the question. We don't have the luxury of starting over. You might get more traction if you start out with some specific suggestions. These documents are not RFCs yet, and improvement is always possible. But suggesting that the authors don't understand operations or security isn't likely to get you very far. - jeff parker - You can catch more flies with honey than with vinegar _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 8 15:04:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26955 for ; Tue, 8 Apr 2003 15:04:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Ixr819678; Tue, 8 Apr 2003 14:59:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IvF819556 for ; Tue, 8 Apr 2003 14:57:15 -0400 Received: from thurn.corp.titan.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26287 for ; Tue, 8 Apr 2003 14:51:54 -0400 (EDT) Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5]) by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h38IsErF004164; Tue, 8 Apr 2003 11:54:15 -0700 Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55) id <2B4PBL8K>; Tue, 8 Apr 2003 14:53:27 -0400 Message-ID: <561621C69F17D511A3A20050047340EC01AAF66C@VCMD-NT1> From: "Ferrell, William" To: "'Jeff Parker '" , "Ferrell, William" , "''Tony Li ' '" Cc: "''ISIS-WG (E-mail) ' '" Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 14:53:27 -0400 Jeff /T Your right Jeff, absolutely right . Thats the troubles of my team...how to mitagte the faked bits etc. How to tust our peers, MD-5 over ISIS hasnt been standardized and the two major vendors have a slighty different implementations.(not that MD-5 is the greatest anyway) I've gotta secure accross our entire network, multi-vendor I agree we cant re-start my focus is can we start to integrate the secure perspective not only the operational view. Tony... no disrespect intended and Im sure none taken... I think that you missed my point and wasnt humble in doing so. If I was crude then I apologize.. respectfully. I thoroughly respect your contribution and knowledge to ISIS and MPLS. Hey, BTW did anyone see the difference and/or detailed attention to the security implications in that doc ? Will - I never knew why I should wanna catch flies -----Original Message----- From: Jeff Parker To: 'Ferrell, William'; 'Tony Li '; Jeff Parker Cc: 'ISIS-WG (E-mail) ' Sent: 4/8/03 2:05 PM Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt > From what you can tell thats the summ of my discussion ? > > This guy showed a deeper knowledge for operations as > well as the true security implications to include real > risk-mitigation. Which concretely conludes that he is > profoundly knowledgable of the technology. > > Will > > > So you're suggesting that we trust source addresses? > > > Tony > > > | -----Original Message----- > | From: Ferrell, William [mailto:William.Ferrell@titan.com] > | I agree that there are many mitigation techniques the > | simplest of course is to ACL with only trusted peers. Will - I can't speak for Tony, but suspect that this was the comment he was responding to. In the case of an IGP, the peers are machines, and all we have to judge them by are some bits in a packet. As you know, those are easy to fake. Currently, IS-IS is deployed in some important spots. Any change to IS-IS that involves large changes is a non- starter. Thus security changes that involve major changes in the protocol are out of the question. We don't have the luxury of starting over. You might get more traction if you start out with some specific suggestions. These documents are not RFCs yet, and improvement is always possible. But suggesting that the authors don't understand operations or security isn't likely to get you very far. - jeff parker - You can catch more flies with honey than with vinegar _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 8 15:41:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29408 for ; Tue, 8 Apr 2003 15:41:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Jf8823656; Tue, 8 Apr 2003 15:41:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38JcX823521 for ; Tue, 8 Apr 2003 15:38:33 -0400 Received: from ghostrider.gredler.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29045 for ; Tue, 8 Apr 2003 15:33:08 -0400 (EDT) Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h38JZI818913; Tue, 8 Apr 2003 21:35:18 +0200 From: Hannes Gredler To: "Ferrell, William" Cc: "'Jeff Parker '" , "''Tony Li ' '" , "''ISIS-WG (E-mail) ' '" Subject: Re: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt Message-ID: <20030408193518.GA18882@juniper.net> References: <561621C69F17D511A3A20050047340EC01AAF66C@VCMD-NT1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561621C69F17D511A3A20050047340EC01AAF66C@VCMD-NT1> User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 21:35:18 +0200 On Tue, Apr 08, 2003 at 02:53:27PM -0400, Ferrell, William wrote: | Jeff /T | | Your right Jeff, absolutely right . Thats the troubles of my team...how to | mitagte the faked bits etc. How to tust our peers, MD-5 over ISIS hasnt been | standardized and the two major vendors have a slighty different | implementations.(not that MD-5 is the greatest anyway) william, i hope that the implementations are different somehow ;-) - last time i have looked we had all the knobs ready on both implementations for full-scale interoperability [even on different understanding what PDUs should be authenticated by default]; -- try to see it the other way around: by not including an explicit crypto-seq-number what we have got is a simple uniform authentication method across all PDU types; if we would have got the crypt-seq number explicilty included in teh auth TLV then a whole set of questions needs to be answered: - do we need crypt-seq-numbers for LSPs ... most likely not as we already got the LSP sequence number ... - do we need b/c of this differnt per-PDU auth TLVs ? ... you see there is some additional complexity involved here ... if SPs are facing _real_ replay attacks on IIHs which may or may not not [based on implementation] tear down an adjacency then we can define a sequence number TLV to adress that issue in the future; the open nature of the authentication TLV which is build across the whole PDU does permit that; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 8 18:23:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06148 for ; Tue, 8 Apr 2003 18:23:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MMi804652; Tue, 8 Apr 2003 18:22:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MJn804437 for ; Tue, 8 Apr 2003 18:19:49 -0400 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05685 for ; Tue, 8 Apr 2003 18:14:24 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 1931Of-000HbZ-00; Tue, 08 Apr 2003 15:16:53 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4524623516.20030408151209@psg.com> To: Hannes Gredler CC: "Ferrell, William" , "'Jeff Parker '" , "''Tony Li ' '" , "''ISIS-WG (E-mail) ' '" Subject: Re: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt In-Reply-To: <20030408193518.GA18882@juniper.net> References: <561621C69F17D511A3A20050047340EC01AAF66C@VCMD-NT1> <20030408193518.GA18882@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Apr 2003 15:12:09 -0700 Content-Transfer-Encoding: 7bit Hannes, Ferrell- > if SPs are facing _real_ replay attacks on IIHs which may or > may not not [based on implementation] tear down an adjacency > then we can define a sequence number TLV to adress that issue > in the future; the open nature of the authentication TLV which > is build across the whole PDU does permit that; A while ago, I came to the WG with a proposal implementing the crypto seq numbers and the key id for easier key transition, see http://psg.com/~zinin/ietf/draft-zinin-isis-auth-anti-replay-00.txt We had a discussion at a face-to-face meeting, and I think the main objection was that the crypto seq number does not protect from replays completely. In particular, when one of the routers on the segment goes down, an attacker can successfully replay packets that it recorded. This is possible because the neighbor's crypto state is maintained together with the regular adjacency state and is removed once the neighbor is lost. There was a proposal to look at whether a nonce can be used to seed packet exchange with every new neighbor. The problem could also be mitigated by retaining the state for lost neighbors (e.g., in a Dead state) and checking the seq numbers when a new adjacency with the router is established. At that time there was clearly no agreement on what level of protection in routing protocols is really needed (e.g., do we really need replay protection given the nature of SP links in general, and the properties of ISIS encapsulation in particular), and I got enough of a push-back to drop the draft. On the other hand, we realized that we need to bring routing and security people on the same page, so we later started the RPSEC WG, which I think I should encourage Ferrell to join. Regards. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 9 08:20:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25289 for ; Wed, 9 Apr 2003 08:20:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39CFd807085; Wed, 9 Apr 2003 08:15:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39CCh806970 for ; Wed, 9 Apr 2003 08:12:43 -0400 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24953 for ; Wed, 9 Apr 2003 08:07:01 -0400 (EDT) Received: from net4u.ch (zux006-019-035.adsl.green.ch [81.6.19.35]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h39C9IQ18138; Wed, 9 Apr 2003 14:09:18 +0200 Message-ID: <3E940C52.2050503@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: Hannes Gredler , "Ferrell, William" , "'Jeff Parker '" , "''Tony Li ' '" , "''ISIS-WG (E-mail) ' '" Subject: Re: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt References: <561621C69F17D511A3A20050047340EC01AAF66C@VCMD-NT1> <20030408193518.GA18882@juniper.net> <4524623516.20030408151209@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Apr 2003 14:04:34 +0200 Content-Transfer-Encoding: 7bit Alex Zinin wrote: >Hannes, Ferrell- > > > > > >>if SPs are facing _real_ replay attacks on IIHs which may or >>may not not [based on implementation] tear down an adjacency >>then we can define a sequence number TLV to adress that issue >>in the future; the open nature of the authentication TLV which >>is build across the whole PDU does permit that; >> >> > >A while ago, I came to the WG with a proposal implementing the crypto >seq numbers and the key id for easier key transition, see >http://psg.com/~zinin/ietf/draft-zinin-isis-auth-anti-replay-00.txt > >We had a discussion at a face-to-face meeting, and I think the main >objection was that the crypto seq number does not protect from replays >completely. In particular, when one of the routers on the segment goes >down, an attacker can successfully replay packets that it recorded. >This is possible because the neighbor's crypto state is maintained >together with the regular adjacency state and is removed once the >neighbor is lost. There was a proposal to look at whether a nonce can >be used to seed packet exchange with every new neighbor. The problem >could also be mitigated by retaining the state for lost neighbors >(e.g., in a Dead state) and checking the seq numbers when a new >adjacency with the router is established. > >At that time there was clearly no agreement on what level of >protection in routing protocols is really needed (e.g., do we really >need replay protection given the nature of SP links in general, and >the properties of ISIS encapsulation in particular), and I got enough >of a push-back to drop the draft. On the other hand, we realized that >we need to bring routing and security people on the same page, so we >later started the RPSEC WG, which I think I should encourage Ferrell >to join. > > The push back to summarize again was: either leave a half-backed '80% problem solved with 20% solved' thing (hmac today) in place with the excuse that it was done and deployed quickly to solve real customer problems (which in context of ISIS I'm perfectly fine with) OR sit down and spend serious amount of time to solve authentication and privacy and integrity in a single swoop so future generations don't split their sides laughing at an incompetent effort. It can be done (look at PNNI security with the chain-of-trust, nonces and so on) but it is quite a lot of work. My opinion still stands thanks -- tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 9 10:08:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28967 for ; Wed, 9 Apr 2003 10:08:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39E7W816043; Wed, 9 Apr 2003 10:07:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39E4Y815229 for ; Wed, 9 Apr 2003 10:04:34 -0400 Received: from web21503.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28087 for ; Wed, 9 Apr 2003 09:58:50 -0400 (EDT) Message-ID: <20030409140123.3965.qmail@web21503.mail.yahoo.com> Received: from [149.254.120.136] by web21503.mail.yahoo.com via HTTP; Wed, 09 Apr 2003 15:01:23 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Isis-wg] draft-ietf-isis-auto-encap-03.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Apr 2003 15:01:23 +0100 (BST) Content-Transfer-Encoding: 8bit I was having some list trouble when draft-ietf-isis-auto-encap-03.txt was announced to the list. Basically there were two events. 1. The history section was updated given that the ITU-T version of the document has passed last call. 2. A new section 5.2 has been added. This suggests that ISs SHOULD ignore the LAN ID from ISs that they don't consider to be DIS. I believe that ISO 10589 specifies what to do with the LAN ID from the DIS, but it it makes no mention of what to do with the LAN ID from __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 9 10:10:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29225 for ; Wed, 9 Apr 2003 10:10:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39EAq816345; Wed, 9 Apr 2003 10:10:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39E8L816202 for ; Wed, 9 Apr 2003 10:08:21 -0400 Received: from thurn.corp.titan.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28331 for ; Wed, 9 Apr 2003 10:02:37 -0400 (EDT) Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5]) by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h39E52rF017646; Wed, 9 Apr 2003 07:05:04 -0700 Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55) id <2B4PBNKB>; Wed, 9 Apr 2003 10:04:15 -0400 Message-ID: <561621C69F17D511A3A20050047340EC01AAF676@VCMD-NT1> From: "Ferrell, William" To: "'Tony Przygienda '" , "'Alex Zinin '" Cc: "'Hannes Gredler '" , "Ferrell, William" , "''Jeff Parker ' '" , "'''Tony Li ' ' '" , "'''ISIS-WG (E-mail) ' ' '" Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Apr 2003 10:04:14 -0400 I'm in accord Will -----Original Message----- From: Tony Przygienda To: Alex Zinin Cc: Hannes Gredler; Ferrell, William; 'Jeff Parker '; ''Tony Li ' '; ''ISIS-WG (E-mail) ' ' Sent: 4/9/03 8:04 AM Subject: Re: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt Alex Zinin wrote: >Hannes, Ferrell- > > > > > >>if SPs are facing _real_ replay attacks on IIHs which may or >>may not not [based on implementation] tear down an adjacency >>then we can define a sequence number TLV to adress that issue >>in the future; the open nature of the authentication TLV which >>is build across the whole PDU does permit that; >> >> > >A while ago, I came to the WG with a proposal implementing the crypto >seq numbers and the key id for easier key transition, see >http://psg.com/~zinin/ietf/draft-zinin-isis-auth-anti-replay-00.txt > >We had a discussion at a face-to-face meeting, and I think the main >objection was that the crypto seq number does not protect from replays >completely. In particular, when one of the routers on the segment goes >down, an attacker can successfully replay packets that it recorded. >This is possible because the neighbor's crypto state is maintained >together with the regular adjacency state and is removed once the >neighbor is lost. There was a proposal to look at whether a nonce can >be used to seed packet exchange with every new neighbor. The problem >could also be mitigated by retaining the state for lost neighbors >(e.g., in a Dead state) and checking the seq numbers when a new >adjacency with the router is established. > >At that time there was clearly no agreement on what level of >protection in routing protocols is really needed (e.g., do we really >need replay protection given the nature of SP links in general, and >the properties of ISIS encapsulation in particular), and I got enough >of a push-back to drop the draft. On the other hand, we realized that >we need to bring routing and security people on the same page, so we >later started the RPSEC WG, which I think I should encourage Ferrell >to join. > > The push back to summarize again was: either leave a half-backed '80% problem solved with 20% solved' thing (hmac today) in place with the excuse that it was done and deployed quickly to solve real customer problems (which in context of ISIS I'm perfectly fine with) OR sit down and spend serious amount of time to solve authentication and privacy and integrity in a single swoop so future generations don't split their sides laughing at an incompetent effort. It can be done (look at PNNI security with the chain-of-trust, nonces and so on) but it is quite a lot of work. My opinion still stands thanks -- tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 9 10:13:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29627 for ; Wed, 9 Apr 2003 10:13:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39EDq816557; Wed, 9 Apr 2003 10:13:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39EBM816403 for ; Wed, 9 Apr 2003 10:11:22 -0400 Received: from web21505.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28628 for ; Wed, 9 Apr 2003 10:05:38 -0400 (EDT) Message-ID: <20030409140811.18222.qmail@web21505.mail.yahoo.com> Received: from [149.254.120.136] by web21505.mail.yahoo.com via HTTP; Wed, 09 Apr 2003 15:08:11 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Isis-wg] draft-ietf-isis-auto-encap-03 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Apr 2003 15:08:11 +0100 (BST) Content-Transfer-Encoding: 8bit I was having some list trouble when draft-ietf-isis-auto-encap-03 was announced to the list. Basically there were two changes. 1. The history section was updated given that the ITU-T version of the document has passed last call. 2. A new section 5.2 has been added. This suggests that ISs SHOULD ignore the LAN ID from ISs that they don't consider to be DIS. I believe that ISO 10589 specifies what to do with the LAN ID from the DIS, but it it makes no mention of what to do with the LAN ID from a none-DIS. Given that an auto-encap IS may misreport the LAN ID of the DIS in certain circumstances this needed clarifying. If anyone has any comments on the new section 5.2 then I would appreciate them. There are quite a lot of typos which have been pointed out to me, and the LAN ID thing needs to be fed to the ITU-T, so I will need to do some more work anyway. The draft can be downloaded from http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-03.txt Regards, Philip Christian __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 9 18:28:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18450 for ; Wed, 9 Apr 2003 18:28:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39MRv802221; Wed, 9 Apr 2003 18:27:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39MOZ802056 for ; Wed, 9 Apr 2003 18:24:35 -0400 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17969 for ; Wed, 9 Apr 2003 18:18:39 -0400 (EDT) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h39ML9gG009556; Wed, 9 Apr 2003 15:21:10 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-213.cisco.com [128.107.163.213]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFI75428; Wed, 9 Apr 2003 15:19:34 -0700 (PDT) Message-Id: <4.3.2.7.2.20030409151136.00b9ee70@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: philip.christian@christiantena.co.uk From: Les Ginsberg Subject: Re: [Isis-wg] draft-ietf-isis-auto-encap-03 Cc: isis-wg@ietf.org In-Reply-To: <20030409140811.18222.qmail@web21505.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17320315==_.ALT" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Apr 2003 15:21:08 -0700 --=====================_17320315==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Philip - I am not clear on why Section 5.2 is required. ISO 10589 says in Section 8.4.5: The LAN ID field in the LAN IIH PDUs transmitted by this system shall be set to the value of the LAN ID field reported in the LAN IIH PDU (for the appropriate level) received from the system which this system considers to be the Designated Intermediate System. This value shall also be passed to the Update Process, as the pseudonode ID, to enable Link State PDUs to be issued for this system claiming connectivity to the pseudonode As you point out, 10589 makes no mention of doing anything with the LANID from systems which the local system does not consider DIS. Why would/should it? If I pick Router A as the DIS and copy the LANID from Router A's IIH into my IIH and Router B's IIH does not agree, what can I do?? This certainly occurs as a transient situation if DIS is changing. What is most important (and I believe unstated by 10589) is that the DIS that we choose should also think that it is DIS and therefore advertise a LANID in its IIHs where the first 6 octets match its own systemID. If it does not, then there will be problems. What was it that motivated you to add 5.2 to your document? Les At 03:08 PM 4/9/2003 +0100, Philip Christian wrote: >I was having some list trouble when >draft-ietf-isis-auto-encap-03 was announced to the >list. > >Basically there were two changes. > >1. The history section was updated given that the >ITU-T version of the document has passed last call. > >2. A new section 5.2 has been added. This suggests >that ISs SHOULD ignore the LAN ID from ISs that they >don't consider to be DIS. I believe that ISO 10589 >specifies what to do with the LAN ID from the DIS, but >it it makes no mention of what to do with the LAN ID >from a none-DIS. Given that an auto-encap IS may >misreport the LAN ID of the DIS in certain >circumstances this needed clarifying. > >If anyone has any comments on the new section 5.2 then >I would appreciate them. > >There are quite a lot of typos which have been pointed >out to me, and the LAN ID thing needs to be fed to the >ITU-T, so I will need to do some more work anyway. > >The draft can be downloaded from >http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-03.txt > >Regards, Philip Christian > >__________________________________________________ >Yahoo! Plus >For a better Internet experience >http://www.yahoo.co.uk/btoffer >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg --=====================_17320315==_.ALT Content-Type: text/html; charset="us-ascii" Philip -

I am not clear on why Section 5.2 is required. ISO 10589 says in Section 8.4.5:

The LAN ID field in the LAN IIH PDUs transmitted by this system shall be set to the value of the LAN ID field reported in the LAN IIH PDU (for the appropriate level) received from the system which this system considers to be the Designated Intermediate System. This value shall also be passed to the Update Process, as the pseudonode ID, to enable Link State PDUs to be issued for this system claiming connectivity to the pseudonode

As you point out, 10589 makes no mention of doing anything with the LANID from systems which the local system does not consider DIS. Why would/should it? If I pick Router A as the DIS and copy the LANID from Router A's IIH into my IIH and Router B's IIH does not agree, what can I do?? This certainly occurs as a transient situation if DIS is changing. What is most important (and I believe unstated by 10589) is that the DIS that we choose should also think that it is DIS and therefore advertise a LANID in its IIHs where the first 6 octets match its own systemID. If it does not, then there will be problems.

What was it that motivated you to add 5.2 to your document?

   Les

At 03:08 PM 4/9/2003 +0100, Philip Christian wrote:
I was having some list trouble when
draft-ietf-isis-auto-encap-03 was announced to the
list.

Basically there were two changes.

1. The history section was updated given that the
ITU-T version of the document has passed last call.

2. A new section 5.2 has been added.  This suggests
that ISs SHOULD ignore the LAN ID from ISs that they
don't consider to be DIS.  I believe that ISO 10589
specifies what to do with the LAN ID from the DIS, but
it it makes no mention of what to do with the LAN ID
from a none-DIS.  Given that an auto-encap IS may
misreport the LAN ID of the DIS in certain
circumstances this needed clarifying.

If anyone has any comments on the new section 5.2 then
I would appreciate them.

There are quite a lot of typos which have been pointed
out to me, and the LAN ID thing needs to be fed to the
ITU-T, so I will need to do some more work anyway.

The draft can be downloaded from
http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-03.txt

Regards, Philip Christian

__________________________________________________
Yahoo! Plus
For a better Internet experience
http://www.yahoo.co.uk/btoffer
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
--=====================_17320315==_.ALT-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Apr 10 05:04:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12588 for ; Thu, 10 Apr 2003 05:04:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A94a823370; Thu, 10 Apr 2003 05:04:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A915823261 for ; Thu, 10 Apr 2003 05:01:05 -0400 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12390 for ; Thu, 10 Apr 2003 04:54:58 -0400 (EDT) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3A8vQmi015939; Thu, 10 Apr 2003 01:57:27 -0700 (PDT) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4198.cisco.com [10.61.80.101]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA27624; Thu, 10 Apr 2003 09:57:22 +0100 (BST) Message-Id: <4.3.2.7.2.20030410093902.04921648@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: mike shand Subject: Re: [Isis-wg] draft-ietf-isis-auto-encap-03 Cc: philip.christian@christiantena.co.uk, isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030409151136.00b9ee70@mira-sjc5-3.cisco.com> References: <20030409140811.18222.qmail@web21505.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 09:57:18 +0100 Philip, I rather think that this is going down the slippery slope of specifying that you should not do something which is not required by the standard. There are two problems with this. Firstly it is unnecessary bloat in the spec. Secondly, and more importantly, it encourages the thinking that you are allowed to do anything, however stupid, provided that you haven't been explicitly told not to do it. Rather in the same way that painting "no parking" lines around streets encourages people to park where ever there are no lines, however stupid a place that might be. Mike At 15:21 09/04/2003 -0700, Les Ginsberg wrote: >Philip - > >I am not clear on why Section 5.2 is required. ISO 10589 says in Section >8.4.5: > >The LAN ID field in the LAN IIH PDUs transmitted by this system shall be >set to the value of the LAN ID field reported in the LAN IIH PDU (for the >appropriate level) received from the system which this system considers to >be the Designated Intermediate System. This value shall also be passed to >the Update Process, as the pseudonode ID, to enable Link State PDUs to be >issued for this system claiming connectivity to the pseudonode > >As you point out, 10589 makes no mention of doing anything with the LANID >from systems which the local system does not consider DIS. Why >would/should it? If I pick Router A as the DIS and copy the LANID from >Router A's IIH into my IIH and Router B's IIH does not agree, what can I >do?? This certainly occurs as a transient situation if DIS is changing. >What is most important (and I believe unstated by 10589) is that the DIS >that we choose should also think that it is DIS and therefore advertise a >LANID in its IIHs where the first 6 octets match its own systemID. If it >does not, then there will be problems. > >What was it that motivated you to add 5.2 to your document? > > Les > >At 03:08 PM 4/9/2003 +0100, Philip Christian wrote: >>I was having some list trouble when >>draft-ietf-isis-auto-encap-03 was announced to the >>list. >> >>Basically there were two changes. >> >>1. The history section was updated given that the >>ITU-T version of the document has passed last call. >> >>2. A new section 5.2 has been added. This suggests >>that ISs SHOULD ignore the LAN ID from ISs that they >>don't consider to be DIS. I believe that ISO 10589 >>specifies what to do with the LAN ID from the DIS, but >>it it makes no mention of what to do with the LAN ID >>from a none-DIS. Given that an auto-encap IS may >>misreport the LAN ID of the DIS in certain >>circumstances this needed clarifying. >> >>If anyone has any comments on the new section 5.2 then >>I would appreciate them. >> >>There are quite a lot of typos which have been pointed >>out to me, and the LAN ID thing needs to be fed to the >>ITU-T, so I will need to do some more work anyway. >> >>The draft can be downloaded from >>http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-03.txt >> >>Regards, Philip Christian >> >>__________________________________________________ >>Yahoo! Plus >>For a better Internet experience >>http://www.yahoo.co.uk/btoffer >>_______________________________________________ >>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-admin@ietf.org Thu Apr 10 05:12:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12789 for ; Thu, 10 Apr 2003 05:12:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A9Ct824564; Thu, 10 Apr 2003 05:12:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A9AE824443 for ; Thu, 10 Apr 2003 05:10:14 -0400 Received: from web21502.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12603 for ; Thu, 10 Apr 2003 05:04:07 -0400 (EDT) Message-ID: <20030410090641.26730.qmail@web21502.mail.yahoo.com> Received: from [149.254.120.136] by web21502.mail.yahoo.com via HTTP; Thu, 10 Apr 2003 10:06:41 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: Re: [Isis-wg] draft-ietf-isis-auto-encap-03 To: Les Ginsberg , isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030409151136.00b9ee70@mira-sjc5-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 10:06:41 +0100 (BST) Content-Transfer-Encoding: 8bit > > What was it that motivated you to add 5.2 to your > document? > Two reasons. 1. If a dual autoencap IS is on a LAN with both IPv4-only and IPv6-only ISs where it looses both pseudonode elections, then it is not clear which LAN ID it should put in its own Hellos. It can only put one. Does it put the IPv4 DIS LAN ID? or the IPv6 DIS LAN ID? or some other LAN ID (like its own or a special one). Section 5.2 is worth having at least to clarify this point. I would appreciate any thoughts on what the right answer is in this scenario (if it really matters at all). 2. I was imagining some implementation that might check the LAN IDs from all of the ISs on the LAN to make sure that they agree who is DIS, or something non-10589 like that. We have seen situations like this before, where implementation A will interwork with 10589 and implementation B will interwork with 10589 but A won't work with B. Remember the ISH discussions (A doesn't sent ISH and B won't do anything till it gets an ISH). A dual autoencap is forced to put the "wrong" LAN ID in Hellos in certain circumstances. This shouldn't matter provided that everyone ignores the LAN ID from non-DIS. As 10589 doesn't actually state that though, then it is an assumption not a fact. Assumptions should be stated, I would have thought. It is not clear in my mind why non-DISs echo the DIS LAN ID back onto the LAN if everyone is ignoring it anyway. It is almost as if 10589 was architected for some sort of checking, but then it got forgotten or something. As no-one checks the LAN ID from non-DISs, then why does a non-DIS even bother copying the LAN ID of the DIS into its own Hellos? okay it might be useful if you network is broken and you have a LAN analyser, but I don't think that that is what the original authors had in mind... Probably it could be worded better. Or maybe I think too much and it isn't really necessary. Philip __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Apr 10 05:29:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13207 for ; Thu, 10 Apr 2003 05:29:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A9TY825319; Thu, 10 Apr 2003 05:29:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A9Qe825217 for ; Thu, 10 Apr 2003 05:26:40 -0400 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12966 for ; Thu, 10 Apr 2003 05:20:32 -0400 (EDT) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3A9N1gE012489; Thu, 10 Apr 2003 02:23:02 -0700 (PDT) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4296.cisco.com [10.61.80.199]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA28387; Thu, 10 Apr 2003 10:23:00 +0100 (BST) Message-Id: <4.3.2.7.2.20030410101819.049fba00@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: philip.christian@christiantena.co.uk From: mike shand Subject: Re: [Isis-wg] draft-ietf-isis-auto-encap-03 Cc: Les Ginsberg , isis-wg@ietf.org In-Reply-To: <20030410090641.26730.qmail@web21502.mail.yahoo.com> References: <4.3.2.7.2.20030409151136.00b9ee70@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 10:22:22 +0100 At 10:06 10/04/2003 +0100, Philip Christian wrote: >It is not clear in my mind why non-DISs echo the DIS >LAN ID back onto the LAN if everyone is ignoring it >anyway. It is almost as if 10589 was architected for >some sort of checking, but then it got forgotten or >something. As no-one checks the LAN ID from non-DISs, >then why does a non-DIS even bother copying the LAN ID >of the DIS into its own Hellos? okay it might be >useful if you network is broken and you have a LAN >analyser, but I don't think that that is what the >original authors had in mind... Exactly so. I seem to recall that it was thought it might be a useful diagnostic tool. You could tell without having to use "management" what everyone's view of the DIS was. There was a particular concern about broken receivers, which of course cause you to elect yourself DIS, since you can't hear anyone else. Mike _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Apr 10 06:05:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13818 for ; Thu, 10 Apr 2003 06:05:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AA6A827736; Thu, 10 Apr 2003 06:06:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AA3q827621 for ; Thu, 10 Apr 2003 06:03:52 -0400 Received: from web21504.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13688 for ; Thu, 10 Apr 2003 05:57:44 -0400 (EDT) Message-ID: <20030410100018.4023.qmail@web21504.mail.yahoo.com> Received: from [149.254.120.136] by web21504.mail.yahoo.com via HTTP; Thu, 10 Apr 2003 11:00:18 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk Subject: RE: [Isis-wg] draft-ietf-isis-auto-encap-03 To: mike shand , Isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030410104529.0493c0c0@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 11:00:18 +0100 (BST) Content-Transfer-Encoding: 8bit That's another thing I don't understand. If you don't have any up neighbour, and you don't put yourself in LAN ID of your Hellos, then what do you put as LAN ID ? A random number ? Philip --- mike shand wrote: > Ah yes. I forgot we added that. But you can still > get strange connectivity > when you have pieces of ethernet cable that are too > long etc. etc. > > Mike > > At 05:34 10/04/2003 -0400, Jonnala, Nagi wrote: > > > >At 10:06 10/04/2003 +0100, Philip Christian wrote: > > >It is not clear in my mind why non-DISs echo the > DIS > > >LAN ID back onto the LAN if everyone is ignoring > it > > >anyway. It is almost as if 10589 was architected > for > > >some sort of checking, but then it got forgotten > or > > >something. As no-one checks the LAN ID from > non-DISs, > > >then why does a non-DIS even bother copying the > LAN ID > > >of the DIS into its own Hellos? okay it might be > > >useful if you network is broken and you have a > LAN > > >analyser, but I don't think that that is what the > > >original authors had in mind... > > > >Exactly so. I seem to recall that it was thought it > might be a useful > >diagnostic tool. You could tell without having to > use "management" what > >everyone's view of the DIS was. There was a > particular concern about broken > >receivers, which of course cause you to elect > yourself DIS, since you can't > >hear anyone else. > > > > > >I thought broken receivers do not have any DIS > since the election process > >needs atleast one "UP" neighbor. Am I wrong? > > > >thanks > >Nagi. > > > > > >_______________________________________________ > >Isis-wg mailing list > >Isis-wg@ietf.org > >https://www1.ietf.org/mailman/listinfo/isis-wg > __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Apr 10 06:19:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14145 for ; Thu, 10 Apr 2003 06:19:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AAJs829152; Thu, 10 Apr 2003 06:19:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AAFq829007 for ; Thu, 10 Apr 2003 06:15:52 -0400 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13921 for ; Thu, 10 Apr 2003 06:09:42 -0400 (EDT) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h3AABimZ000747 for ; Thu, 10 Apr 2003 03:11:44 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id DAA14704 for ; Thu, 10 Apr 2003 03:12:15 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CMJV>; Thu, 10 Apr 2003 06:12:08 -0400 Message-ID: From: "Jonnala, Nagi" To: "'philip.christian@christiantena.co.uk'" , mike shand , Isis-wg@ietf.org Subject: RE: [Isis-wg] draft-ietf-isis-auto-encap-03 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 06:13:50 -0400 ISO-10589 says: Circuit-ID(System-ID + Local octet) needs to be put. 1) when IS sends the IIHs initially(before DIS election happens) 2) Incase IS is not participating in DIS election process at all. -Nagi. -----Original Message----- From: Philip Christian [mailto:christian_tena@yahoo.co.uk] Sent: Thursday, April 10, 2003 3:30 PM To: mike shand; Isis-wg@ietf.org Subject: RE: [Isis-wg] draft-ietf-isis-auto-encap-03 That's another thing I don't understand. If you don't have any up neighbour, and you don't put yourself in LAN ID of your Hellos, then what do you put as LAN ID ? A random number ? Philip --- mike shand wrote: > Ah yes. I forgot we added that. But you can still > get strange connectivity > when you have pieces of ethernet cable that are too > long etc. etc. > > Mike > > At 05:34 10/04/2003 -0400, Jonnala, Nagi wrote: > > > >At 10:06 10/04/2003 +0100, Philip Christian wrote: > > >It is not clear in my mind why non-DISs echo the > DIS > > >LAN ID back onto the LAN if everyone is ignoring > it > > >anyway. It is almost as if 10589 was architected > for > > >some sort of checking, but then it got forgotten > or > > >something. As no-one checks the LAN ID from > non-DISs, > > >then why does a non-DIS even bother copying the > LAN ID > > >of the DIS into its own Hellos? okay it might be > > >useful if you network is broken and you have a > LAN > > >analyser, but I don't think that that is what the > > >original authors had in mind... > > > >Exactly so. I seem to recall that it was thought it > might be a useful > >diagnostic tool. You could tell without having to > use "management" what > >everyone's view of the DIS was. There was a > particular concern about broken > >receivers, which of course cause you to elect > yourself DIS, since you can't > >hear anyone else. > > > > > >I thought broken receivers do not have any DIS > since the election process > >needs atleast one "UP" neighbor. Am I wrong? > > > >thanks > >Nagi. > > > > > >_______________________________________________ > >Isis-wg mailing list > >Isis-wg@ietf.org > >https://www1.ietf.org/mailman/listinfo/isis-wg > __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer _______________________________________________ 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-admin@ietf.org Thu Apr 10 06:20:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14200 for ; Thu, 10 Apr 2003 06:20:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AALl829292; Thu, 10 Apr 2003 06:21:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AAHa829082 for ; Thu, 10 Apr 2003 06:17:36 -0400 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13961 for ; Thu, 10 Apr 2003 06:11:27 -0400 (EDT) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3AADvgE029798; Thu, 10 Apr 2003 03:13:57 -0700 (PDT) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4296.cisco.com [10.61.80.199]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA00049; Thu, 10 Apr 2003 11:13:55 +0100 (BST) Message-Id: <4.3.2.7.2.20030410110709.04889558@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: philip.christian@christiantena.co.uk From: mike shand Subject: RE: [Isis-wg] draft-ietf-isis-auto-encap-03 Cc: Isis-wg@ietf.org In-Reply-To: <20030410100018.4023.qmail@web21504.mail.yahoo.com> References: <4.3.2.7.2.20030410104529.0493c0c0@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Apr 2003 11:13:54 +0100 At 11:00 10/04/2003 +0100, Philip Christian wrote: >That's another thing I don't understand. If you don't >have any up neighbour, and you don't put yourself in >LAN ID of your Hellos, then what do you put as LAN ID >? A random number ? No you DO put your own LAN ID in there to begin with. Even if you have no neighbors. However what you don't do is start sending CSNPs and generating a pseudonode (and, worse, purging any "old" pseudonode), etc. see ISO/IEC 10589:1992 8.4.1 (a) >Philip > > > --- mike shand wrote: > Ah yes. I >forgot we added that. But you can still > > get strange connectivity > > when you have pieces of ethernet cable that are too > > long etc. etc. > > > > Mike > > > > At 05:34 10/04/2003 -0400, Jonnala, Nagi wrote: > > > > > > >At 10:06 10/04/2003 +0100, Philip Christian wrote: > > > >It is not clear in my mind why non-DISs echo the > > DIS > > > >LAN ID back onto the LAN if everyone is ignoring > > it > > > >anyway. It is almost as if 10589 was architected > > for > > > >some sort of checking, but then it got forgotten > > or > > > >something. As no-one checks the LAN ID from > > non-DISs, > > > >then why does a non-DIS even bother copying the > > LAN ID > > > >of the DIS into its own Hellos? okay it might be > > > >useful if you network is broken and you have a > > LAN > > > >analyser, but I don't think that that is what the > > > >original authors had in mind... > > > > > >Exactly so. I seem to recall that it was thought it > > might be a useful > > >diagnostic tool. You could tell without having to > > use "management" what > > >everyone's view of the DIS was. There was a > > particular concern about broken > > >receivers, which of course cause you to elect > > yourself DIS, since you can't > > >hear anyone else. > > > > > > > > >I thought broken receivers do not have any DIS > > since the election process > > >needs atleast one "UP" neighbor. Am I wrong? > > > > > >thanks > > >Nagi. > > > > > > > > >_______________________________________________ > > >Isis-wg mailing list > > >Isis-wg@ietf.org > > >https://www1.ietf.org/mailman/listinfo/isis-wg > > > >__________________________________________________ >Yahoo! Plus >For a better Internet experience >http://www.yahoo.co.uk/btoffer _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Apr 11 05:47:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05215 for ; Fri, 11 Apr 2003 05:47:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B9mV810813; Fri, 11 Apr 2003 05:48:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B9jp810728 for ; Fri, 11 Apr 2003 05:45:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05010 for ; Fri, 11 Apr 2003 05:39:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193ujz-0000Vy-00 for Isis-wg@ietf.org; Fri, 11 Apr 2003 05:22:35 -0400 Received: from web21512.mail.yahoo.com ([66.163.169.51]) by ietf-mx with smtp (Exim 4.12) id 193ujz-0000Vu-00 for Isis-wg@ietf.org; Fri, 11 Apr 2003 05:22:35 -0400 Message-ID: <20030411094148.29200.qmail@web21512.mail.yahoo.com> Received: from [149.254.120.136] by web21512.mail.yahoo.com via HTTP; Fri, 11 Apr 2003 10:41:48 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: philip.christian@christiantena.co.uk To: mike shand , ginsberg@cisco.com, Isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030410110709.04889558@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Isis-wg] simpler draft-ietf-isis-auto-encap section 5.2 proposal Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Apr 2003 10:41:48 +0100 (BST) Content-Transfer-Encoding: 8bit Would you guys prefer this text over what is there now? Personally I think something should be there given the slight deviance from 10589, even if it seems obvious to some of us. Philip 5.2. LAN ID ISO/IEC 10589 [6] states than an IS shall take the LAN ID from the neighbour that it considers to be the DIS and use it as the LAN ID in its own Hello PDUs. If there are two or more DISs on a LAN then an automatically encapsulating IS will be able to use only one of these LAN IDs in its own Hellos. Clearly if an automatically encapsulating IS is elected DIS by either OSI, IPv4 or IPv6 ISs then it MUST use its own LAN ID in Hello PDUs as per ISO/IEC 10589. If an automatically encapsulating IS is elected DIS by no subset of the LAN and if there are multiple DISs on the LAN with which the automatically encapsulating IS has up adjacencies, then an implementer will need to decide which LAN ID the automatically encapsulating IS puts in its Hello PDUs. Whichever LAN ID is chosen, other ISs on the LAN SHOULD in any case ignore it if they do not consider the automatically encapsulating IS to be DIS. __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Apr 11 06:12:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05651 for ; Fri, 11 Apr 2003 06:12:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BAD1812590; Fri, 11 Apr 2003 06:13:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BAA9812513 for ; Fri, 11 Apr 2003 06:10:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05474 for ; Fri, 11 Apr 2003 06:03:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193v7V-0000eL-00 for Isis-wg@ietf.org; Fri, 11 Apr 2003 05:46:53 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 193v7V-0000eI-00 for Isis-wg@ietf.org; Fri, 11 Apr 2003 05:46:53 -0400 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h3BA5vna010008 for ; Fri, 11 Apr 2003 03:05:58 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id DAA26522 for ; Fri, 11 Apr 2003 03:06:05 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45C3NQ>; Fri, 11 Apr 2003 06:05:08 -0400 Message-ID: From: "Jonnala, Nagi" To: "'philip.christian@christiantena.co.uk'" , mike shand , ginsberg@cisco.com, Isis-wg@ietf.org Subject: RE: [Isis-wg] simpler draft-ietf-isis-auto-encap section 5.2 prop osal MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Apr 2003 06:06:50 -0400 Philip and all, Currently an IS ignores the LAN-ID from non-DIS systems. I'm not aware any implementations who really use the non-DIS' LAN-ID. So IMO, that does not need to be stated again here. However, capturing that information is essential so that future generations know what to do and what not to do. I think a simple note is good enough rather than explanatory paragraph. Thanks Nagi. -----Original Message----- From: Philip Christian [mailto:christian_tena@yahoo.co.uk] Sent: Friday, April 11, 2003 3:12 PM To: mike shand; ginsberg@cisco.com; Isis-wg@ietf.org Subject: [Isis-wg] simpler draft-ietf-isis-auto-encap section 5.2 proposal Would you guys prefer this text over what is there now? Personally I think something should be there given the slight deviance from 10589, even if it seems obvious to some of us. Philip 5.2. LAN ID ISO/IEC 10589 [6] states than an IS shall take the LAN ID from the neighbour that it considers to be the DIS and use it as the LAN ID in its own Hello PDUs. If there are two or more DISs on a LAN then an automatically encapsulating IS will be able to use only one of these LAN IDs in its own Hellos. Clearly if an automatically encapsulating IS is elected DIS by either OSI, IPv4 or IPv6 ISs then it MUST use its own LAN ID in Hello PDUs as per ISO/IEC 10589. If an automatically encapsulating IS is elected DIS by no subset of the LAN and if there are multiple DISs on the LAN with which the automatically encapsulating IS has up adjacencies, then an implementer will need to decide which LAN ID the automatically encapsulating IS puts in its Hello PDUs. Whichever LAN ID is chosen, other ISs on the LAN SHOULD in any case ignore it if they do not consider the automatically encapsulating IS to be DIS. __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer _______________________________________________ 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-admin@ietf.org Thu Apr 17 21:48:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16509 for ; Thu, 17 Apr 2003 21:48:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I1pe827248; Thu, 17 Apr 2003 21:51:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I1lV827129 for ; Thu, 17 Apr 2003 21:47:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16283 for ; Thu, 17 Apr 2003 21:37:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196KrF-00041C-00 for isis-wg@ietf.org; Thu, 17 Apr 2003 21:40:05 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 196KrF-00040x-00 for isis-wg@ietf.org; Thu, 17 Apr 2003 21:40:05 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id B32F023C4D for ; Thu, 17 Apr 2003 18:29:04 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3I1dmYD014214 for ; Thu, 17 Apr 2003 18:39:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: Work schedule Thread-Index: AcMFS2X70WDQJgiqRiKsoyXu5Y4LxQ== From: "Tony Li" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3I1lV827130 Subject: [Isis-wg] Work schedule Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 17 Apr 2003 18:39:48 -0700 Content-Transfer-Encoding: 8bit Folks, I've put a copy of our work schedule as: http://skat.usc.edu/~tli/Schedule.htm I will attempt to keep it reasonably up to date. Please feel free to remind me. ;-) Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 22 02:35:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27975 for ; Tue, 22 Apr 2003 02:35:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M6em810548; Tue, 22 Apr 2003 02:40:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M6bO809937 for ; Tue, 22 Apr 2003 02:37:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27716 for ; Tue, 22 Apr 2003 02:25:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197rFu-0006aL-00 for isis-wg@ietf.org; Tue, 22 Apr 2003 02:27:50 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 197rFu-0006a3-00 for isis-wg@ietf.org; Tue, 22 Apr 2003 02:27:50 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id AB47F23C39 for ; Mon, 21 Apr 2003 23:16:49 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3M6RgYB010891 for ; Mon, 21 Apr 2003 23:27:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: Next meeting... Thread-Index: AcMImEcOV3pCEy0hRtiNRlseBQOxNA== From: "Tony Li" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3M6bO809938 Subject: [Isis-wg] Next meeting... Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 21 Apr 2003 23:27:41 -0700 Content-Transfer-Encoding: 8bit Folks, The IETF secretariat is already accepting requests for meeting slots for July. We should figure out if we need to meet in person and if so, what we need to cover. Any issues, anyone? Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 22 03:16:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28565 for ; Tue, 22 Apr 2003 03:16:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M7IG812745; Tue, 22 Apr 2003 03:18:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M7C1812548 for ; Tue, 22 Apr 2003 03:12:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28335 for ; Tue, 22 Apr 2003 03:00:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197rnO-0006zC-00 for isis-wg@ietf.org; Tue, 22 Apr 2003 03:02:26 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 197rnO-0006z9-00 for isis-wg@ietf.org; Tue, 22 Apr 2003 03:02:26 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 6B12723C39 for ; Mon, 21 Apr 2003 23:51:27 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3M72IYB013307 for ; Tue, 22 Apr 2003 00:02:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: Minutes Thread-Index: AcMInRzzu1SwCq6oQqis1RSTMelqrA== From: "Tony Li" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3M7C1812549 Subject: [Isis-wg] Minutes Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Apr 2003 00:02:18 -0700 Content-Transfer-Encoding: 8bit All, Papadimitriou Dimitri was kind enough to take copious notes during the last meeting. Unfortunately, these just popped to the top of my work stack. My bad, sorry. Tony IS-IS Working Group (isis) Tuesday, March 18 - 17:00-18:00 =============================== Meeting Minutes: --------------- 1) IS-IS document status: - MIB for IS-IS: Updated 6/03 - IS-IS Cryptographic Authentication: Revisions needed (moving forward) - IS-IS extensions for Traffic Engineering: Under IESG evaluation - Routing IPv6 with IS-IS: Under AD evaluation - IS-IS Extensions in Support of GMPLS: Under AD evaluation - M-ISIS Multi Topology (MT) Routing in IS-IS: Revisions needed - Extended Ethernet Frame Size Support: Push Back from IESG WG killed this i-d - Restart signaling for IS-IS: Updated 6/03 - Point-to-point operation over LAN in link-state routing protocols: Under AD evaluation - Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit: In RFC editor queue - IS-IS Automatic Encapsulation: due 6/03 - Policy Control Mechanism is IS-IS Using Administrative Tags: Under AD evaluation - TLV for Proprietary Use: - Recommendations for Interoperable IP Networks using IS-IS: Under AD evaluation - Recommendations for Interoperable Networks using IS-IS: Under AD evaluation - TLV for Experimental Use: Updated 6/03 Discussions: ----------- Tony Li: Any question ? Note: No questions from the group ------------------------------------------------------------------------ -------- 2) Multi-Level IS-IS Without Protocol Extensions (Jonathan Sadler) draft-sadler-isis-ml-bcp-00.txt Summary: ------- o Problem statement: - Context of Sonet/SDH networks using ASON and GMPLS routing - Not the same use of IS-IS as in DCN networks - The scale of Sonet/SDH networks is larger than IP networks with sometimes more than 10.000 switching nodes (OXCs and ADMs) to be managed hierarchically (using more than two levels of hierachy) - Sometimes political/geographical/administrative boundaries defining these hierarchical levels o Picture showing typical transport networks topology (remark from the author: in general no nice construction of the control plane topology) o Approach: This is not a new question, back in '98 concerning multi-level IS-IS approaches: 1) distance vector 2) stick to isis levels Here proposed approach without protocol extensions, nothing to be added concerning the bits on the wire (except concerning the use of the RFC 2966 up/down bit to prevent looping) Nodes participating to multi-level at the same time makes use of GRE tunnels to have such kind of aggregations (remark from the author: new item in the charter ?) o What is needed - Rules for info exchange between levels - Rules for info exchange within a level - Rules for route preference o Scoped Problem Statement - How to deal with prefix propagation between levels ? By extending the RFC 2966 up/down bit semantic (keeping track of the instance top->down and bottom->up) here this mechanism can used between level n <-> n+1 - Within a level ? in the present context, level 2 doesn't have anymore a specific status, the announcement of prefixes should allow -> usage of RFC 1195 and (transit) areas that can be used as tansit for higher levels Discussion on how a level n can provide transit capabilities -> create neighbor adjacencies (GRE tunnels) between devices in order to create this "tunneling". - Also there is the need to define preference rules in RFC 2966. o Conclusion: - Requires work on multi-level hierarchies to be taken out of hibernation (any specific charter issue ?) - Can be done without any extensions to IS-IS o Questions: - Is the IS-IS wg interested ? (remark from the author: i hope yes pointing also to the Q14/SG15 request) - Is this work in the charter ? (remark from the author: quite open question but doesn't seem to be out of charter) - Proposals to the group: working group i-d ? - Number of items have been identified as places for further work to support multi-level, for instance automation of peer-wise adjacency establishment, also what happens on LAN interfaces... there are lot's of interesting things to be discussed (that are **NOT** solved by the present document) Discussions: ----------- - Tony Li: Questioning the group "Is this useful ?" Note: 2 or 3 people raise their hand - Tony Li: key question, making appropriate protocol changes to define packets going at level 3, 4, 5 ? Addressing the group "Has somebody taken a look at this alternative approach ?" - Jonathan Sadler: level 2 lsp can be used with some extensions with specific markup - Tony Li: recollection from the lsp pdu format, 8 bits are available and it is trivial to take this lsp pdu and define all these other bits - Jonathan Sadler: carry the level information ? here we need to be capable to insert level in between levels, thus it seems to be better to keep the relationship between the levels so that you can (more easily) insert them - Tony Li: here limited to level2-level3 ? given there is not a lot of demand, proposes to take this discussion on the mailing list since it doesn't seem this i-d has an exciting demand - Jonathan Sadler: understood (and seems to agree) - Steve Throwbridge: Liaison from Q14/SG15, present the motivation for such i-d, Steve encourages (the group) for reading G.7715 to address the Q14/SG15 requirements and asks for receiving the input from the ietf routing expets - Naiming Shen: on the link we are obliged to tell at which level the neighbors are sitting thus we have a need for identifiying the level - Jonathan Sadler: agrees this is needed to route protocol traffic but here the approach with the GRE tunnels is proposed - Naiming Shen: with tunneling limited to point-to-point interfaces - Jonathan Sadler: agrees, and underlines that this is a serious limitation that requires more work from the working group ------------------------------------------------------------------------ -------- 2) Protocol Topology Support for IS-IS (Kay Nogushi) draft-noguchi-isis-protocol-topology-01.txt Summary: ------- o RFC 1195 Restitctions: - Every router in a level-1 area must be capable of all network layer protocols that are present in that area - Protocol support must be identical on all interfaces. Thus the protocol capabilities must be made available on all interfaces (node oriented support capabilities). Thus can't mix IPv4 only and IPv6 only in areas o Goals: - IPv4, IPv6 and IPv4/v6 dual routers can coexist with different protocol support on each interface o New TLV and new sub-TLV (Changes to RFC 1195): - New TLV: Interface Protocols Supported TLV in IS-IS Hellos, - New sub-TLV: Protocols Supported sub-TLV (in Extended IS Reachability TLV) o Adjacency formation: Modified rules of when to establish an adjacency: each router must drop IS-IS hello which doesn't carry interface protocols supported TLV on point-to-point interfaces (must not form an adjacency if at least one of the protocol capabilities is not met by the neighboring router) o LSP encoding: The rules for encoding the Protocols Supported sub-TLV depend on the type of interface: - for point-to-point interface: ANDing the local side of interface oriented protocol support capability with the remote side of interface oriented protocol support capability - broadcast interfaces using two Protocols Supported sub-TLV: one in regular lsp and one in pseudo-node lsp o SPF Calculation: - Changes must be calculated separately for each layer network supported - New Protocol Supported sub-TLV must be used instead of old (ie previously defined) Protocol Supported sub-TLV o Migration mechanism: - Start advertising new TLV and sub-TLV in addition to the old tlv - Change the adjacency formation and spf calculation based on this draft - Stop advertising the old Protocols Supported TLV in IS-IS Hello's - Reconfigure the interface protocol capabilities when applicable Discussions: ----------- - Acee Lindem: there is an existing igp capability draft that you can use since there is a limited number of AF that you can support (on a node basis) as opposed to an a per interface support - Rahul Aggarwal: this has been worked out at the ospf working group; - Albert Tian: What enables this new approach compared to the existing M-ISIS ? - Kay Noguchi: showing an additional slide o non M-ISIS IPv4 router and M-ISIS IPv6 router -> how to make the adjacency ? o non M-ISIS IPv4/IPv6 dual router and M-ISIS IPv4/IPv6 -> possible routing loop o IPv6 reachability TLV and MT Reachable IPv6 Prefixes (M-ISIS) -> Do we need both ? Discussion on the first point: ----------------------------- - Naiming Shen: intent is to describe the mechanismn, here we need to have an interoperability document explaining interoperability issues between non M-ISIS and with M-ISIS with lot of details. Currently, how they do this ? the check is performed on the subnet using the hello packet for this particular interface that then can setup the adjacencies But this possible when configured with IPv4, they are supposed to build these adjacencies, otherwise they will refuse to build up these adjacencies (here only IPv4 used as workaround) - Kay Noguchi: do we have some draft that describes this ? - Naiming Shen: no we don't; this a workaround, there is a way to get outside of it and this is obvious (pointing to the first bullet), how to make them work is by putting or configuring IPv4 within the packet ... but if you reboot you need to setup the adjacency again - Kay Noguchi: do you mean reboot the IPv4 router ? - Naiming Shen: yes, or "no IPv4 checking" is to be configured - Kay Noguchi: so we need to change the code - Naiming Shen: you have delivered one - Kai Noguchi: do we need a document for that purpose ? - Naiming Shen: yes we probably need an M-ISIS interop draft to explain the interoperability between non-M-ISIS and M-ISIS nodes Discussion of the second point (on routing loop) ------------------------------ - Naiming Shen: in the latest revision of the M-ISIS draft, two types... - Kay Noguchi: two types meaning here ? - Naiming Shen: the M-ISIS draft defines different types of reachable prefixes in specific TLVs and these two types shouldn't be mixed up; - Kay Noguchi: this one is not for reachability but for IS Reachability TLV - Alex Zinin: they just can't mix - Naiming Shen: concerning the prefixes they shouldn't mix since we have two types of prefixes (thus on different spf trees) - Kay Noguchi: here we speak about IS reachability TLV's - Naiming Shen: no mix between M-ISIS and no M-ISIS - Kay Noguchi: is there a standard policy for M-ISIS ? - Naiming Shen: it can't be the same address corresponding to the same topology, this problem is already in IPv4/v6, but here we have two different topologies within M-ISIS - Kay Noguchi: my draft solves only the IPv4 issue - Naiming Shen: no, the core router won't understand the IPv6 adjacency, and it will not understand the adjacency since we speak about different TLV's (not on the spf tree) - Kay Noguchi: here we speak about Extended IS Reachability - Naiming Shen: here we should support both IPv4/IPv6, thus there is no difference - Kay Noguchi: this is exactly the problem - Naiming Shen: correct, here we speak about a specific IPv6 adjacency or a specific IPv4 adjacency, thus i don't understand where the problem is - Kay Noguchi: my argumentation is in terms of dual routers - Tony Li: we need only one solution thus please find a compromise - Kay Noguchi: today ? - Tony Li: through the mailing list - (?): you should give the proper credit from people having done this before - please reference where this draft is positioned with respect to prior work - Kay Noguchi: agrees ------------------------------------------------------------------------ -------- 3) JTC1 Liaison (Alex Zinin) Announcement: agreement with the JTC1 has been signed and IETF will sign from its side during this week Meeting is adjourned. ======================================================================== ======== _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Apr 24 07:40:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11908 for ; Thu, 24 Apr 2003 07:40:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OBc0802263; Thu, 24 Apr 2003 07:38:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OBYt801294 for ; Thu, 24 Apr 2003 07:34:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11398; Thu, 24 Apr 2003 07:31:50 -0400 (EDT) Message-Id: <200304241131.HAA11398@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-04.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Apr 2003 07:31:49 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-04.txt Pages : 6 Date : 2003-4-23 This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm as found in RFC 2104. IS-IS is specified in ISO 10589 and RFC 1142, with extensions to support IPv4 described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-hmac-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-hmac-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-23134717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-23134717.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Apr 25 08:37:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06788 for ; Fri, 25 Apr 2003 08:37:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCcn821761; Fri, 25 Apr 2003 08:38:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCbQ821533 for ; Fri, 25 Apr 2003 08:37:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06677 for ; Fri, 25 Apr 2003 08:33:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1992Qy-00009o-00 for isis-wg@ietf.org; Fri, 25 Apr 2003 08:36:08 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1992Qx-00009k-00 for isis-wg@ietf.org; Fri, 25 Apr 2003 08:36:07 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h3PCaa2i008590 for ; Fri, 25 Apr 2003 05:36:36 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h3PCbeTi017202 for ; Fri, 25 Apr 2003 07:37:41 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Apr 2003 08:36:22 -0400 Message-ID: From: "Jonnala, Nagi" To: "'Jeff Parker'" Cc: "''ISIS-WG (E-mail) ' '" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Use of isisSysReceiveLSPBufferSize Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 25 Apr 2003 08:38:03 -0400 Jeff, Could you please explain the use of this object? It seems to me that if I receive a PDU which size is greater than isisSysReceiveLSPBufferSize should be dropped. Is that correct? I've a couple of questions in this context. 1) How come the major vendors don't allow this object to be configured? 2) What was the primary intention of this object? Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Apr 25 09:16:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07764 for ; Fri, 25 Apr 2003 09:16:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDHM824742; Fri, 25 Apr 2003 09:17:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDES824564 for ; Fri, 25 Apr 2003 09:14:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07583 for ; Fri, 25 Apr 2003 09:10:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19930n-0000RQ-00 for isis-wg@ietf.org; Fri, 25 Apr 2003 09:13:09 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19930n-0000Qx-00 for isis-wg@ietf.org; Fri, 25 Apr 2003 09:13:09 -0400 Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" Cc: "''ISIS-WG (E-mail) ' '" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 25 Apr 2003 09:13:03 -0400 > Jeff, > > Could you please explain the use of this object? > > It seems to me that if I receive a PDU which size > is greater than isisSysReceiveLSPBufferSize > should be dropped. Is that correct? > > I've a couple of questions in this context. > > 1) How come the major vendors don't allow > this object to be configured? > > 2) What was the primary intention of this object? > > Thanks > Nagi. Nagi - The text below tries to capture the issues involved. Briefly, to take advantage of large MTU, and to allow a system to generate more than 1492 x 256 bytes of content, we may wish to increase the LSP buffer size. This option exists on boxes today, deployed in a network near you. But when you use a non-standard buffer size, you run the risk that some routers won't be able to store all the data. Since many configurations fit inside a small PDU, it may take some time for the problem to occur, and could take much longer for the problem to be diagnosed. This variable is one of many features used to help track problems should this be deployed. So in response to your questions Q) Should I drop this? 0) No, don't drop the packet. As below: Do not discard large PDUs by default. Storing and processing them as normal PDUs may help maintain coherence in a miscon- figured network. Q) Why isn't this configurable everywhere? 1) For all the usual reasons. This is a 'new' feature that does not provide any new capability. My marketing guy doesn't see any value in this, and I'm sure your's won't either. And you know how much adding a knob as like this can disrupt a release. Remember, that having this variable does not mean that it must be settable, from SNMP or from the CLI. It just provides a way to make your value visible from SNMP. Q) What is this for? 2) To allow you to assure that a network is well configured, and to debug problems if it isn't. The text below describing the issue is up for review, so any suggestions in content or exposition are welcome. - jeff parker Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002 9. ReceiveLSPBufferSize Since IS-IS does not allow segmentation of protocol PDUs, Link State PDUs (LSPs) must be propagated without modification on all IS-IS enabled links throughout the area/domain. Thus it is essential to configure a maximum size that all routers can forward, receive, and store. This affects three aspects, which we discuss in turn: (1) The largest LSP we can receive (ReceiveLSPBufferSize) (2) The size of the largest LSP we can generate (originatingL1LSPBufferSize and originatingL2LSPBufferSize) (3) Available Link MTU for supported Circuits (MTU). Note this often differs from the MTU available to IP clients. ISO 10589 defines the architectural constant ReceiveLSPBufferSize with value 1492 bytes, and two private management parameters, originatingL1LSPBufferSize for level 1 PDUs and originatingL2LSPBufferSize for level 2 PDUs. The originating buffer size parameters define the maximum size of an LSP that a router can generate. ISO 10589 directs the implementor to treat a PDU larger than ReceiveLSPBufferSize as an error. It is crucial that originatingL1LSPBufferSize <= ReceiveLSPBufferSize originatingL2LSPBufferSize <= ReceiveLSPBufferSize and that for all L1 links in the area originatingL1LSPBufferSize <= MTU and for all L2 links in the domain originatingL2LSPBufferSize <= MTU The original thought was that operators could decrease the originat- ing Buffer size when dealing with smaller MTUs, but would not need to increase ReceiveLSPBufferSize beyond 1492. With the definition of new information to be advertised in LSPs, such as the Traffic Engineering TLVs, the limited space of the LSP data- base which may be generated by each router (256 * 1492 bytes at each level) has become an issue. Given that modern networks with MTUs larger than 1492 on all links are not uncommon, one method which can be used to expand the LSP database size is to allow values of ReceiveLSPBufferSize greater than 1492. Allowing ReceiveLSPBUfferSize to become a configurable parameter rather than an architectural constant must be done with care: if any system in the network does not support values larger than 1492 or one or more link MTUs used by IS-IS anywhere in the area/domain is smaller than the largest LSP which may be generated by any router, then full propagation of all LSPs may not be possible, resulting in routing loops and black holes. The steps below are recommended when changing ReceiveLSPBufferSize. (1) Set the ReceiveLSPBufferSize to a consistent value throughout the network. (2) The implementation MUST not enable IS-IS on circuits which do not support an MTU at least as large as the originating Buf- ferSize at the appropriate level. (3) Include an originatingLSPBufferSize TLV when generating LSPs, as described in section 9.8 of the 2001 revision of ISO 10589 [2]. (4) When receiving LSPs, check for an originatingLSPBufferSize TLV, and report the receipt of values larger than the local value of ReceiveLSPBufferSize through the defined Notifica- tions and Alarms. (5) Report the receipt of a PDU larger than the local ReceiveL- SPBufferSize through the defined Notifications and Alarms. (6) Do not discard large PDUs by default. Storing and processing them as normal PDUs may help maintain coherence in a miscon- figured network. Steps 1 and 2 are enough by themselves, but the consequences of mismatch are serious enough and difficult enough to detect, that steps 3-6 are recommended to help track down and correct problems. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat Apr 26 14:30:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24942 for ; Sat, 26 Apr 2003 14:30:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3QITc817887; Sat, 26 Apr 2003 14:29:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3QIPK817752 for ; Sat, 26 Apr 2003 14:25:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24751 for ; Sat, 26 Apr 2003 14:21:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199UKa-0000jf-00 for isis-wg@ietf.org; Sat, 26 Apr 2003 14:23:24 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 199UKZ-0000jT-00 for isis-wg@ietf.org; Sat, 26 Apr 2003 14:23:23 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h3QIN6o08445; Sat, 26 Apr 2003 20:23:06 +0200 From: Hannes Gredler To: "Jonnala, Nagi" Cc: "'Jeff Parker'" , "''ISIS-WG (E-mail) ' '" Subject: Re: [Isis-wg] Use of isisSysReceiveLSPBufferSize Message-ID: <20030426182306.GA8351@juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 26 Apr 2003 20:23:06 +0200 On Fri, Apr 25, 2003 at 08:38:03AM -0400, Jonnala, Nagi wrote: | 1) How come the major vendors don't allow | this object to be configured? 'cause in both implementations the MAX_LSP_SIZE is hardcoded; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 28 06:15:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25583 for ; Mon, 28 Apr 2003 06:15:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SAFr827791; Mon, 28 Apr 2003 06:15:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SACM827724 for ; Mon, 28 Apr 2003 06:12:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25429 for ; Mon, 28 Apr 2003 06:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A5Zn-0001mV-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 06:09:35 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19A5Zm-0001mR-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 06:09:35 -0400 Received: from there (ams-clip-vpn-dhcp83.cisco.com [10.61.64.83]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h3SA92R28000; Mon, 28 Apr 2003 12:09:02 +0200 (CEST) Message-Id: <200304281009.h3SA92R28000@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Hannes Gredler , "Jonnala, Nagi" Subject: Re: [Isis-wg] Use of isisSysReceiveLSPBufferSize X-Mailer: KMail [version 1.3.1] Cc: "'Jeff Parker'" , "''ISIS-WG (E-mail) ' '" References: <20030426182306.GA8351@juniper.net> In-Reply-To: <20030426182306.GA8351@juniper.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3SACM827725 Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 28 Apr 2003 12:08:52 +0200 Content-Transfer-Encoding: 8bit On Saturday 26 April 2003 20:23, Hannes Gredler wrote: > On Fri, Apr 25, 2003 at 08:38:03AM -0400, Jonnala, Nagi wrote: > > | 1) How come the major vendors don't allow > | this object to be configured? > > 'cause in both implementations the MAX_LSP_SIZE is hardcoded; I know an implementation where it's not... s. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 28 10:01:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01177 for ; Mon, 28 Apr 2003 10:01:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SE3a812161; Mon, 28 Apr 2003 10:03:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SE2q812124 for ; Mon, 28 Apr 2003 10:02:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01034 for ; Mon, 28 Apr 2003 09:57:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A9Am-00035j-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 10:00:00 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19A9Am-00035H-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 10:00:00 -0400 Message-ID: From: Jeff Parker To: "Jonnala, Nagi" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 28 Apr 2003 09:59:58 -0400 In response to Nagi's original question, I will add some text about the meaning of this variable to the description clause in the document. Once again, being able to see the value of this variable is useful, even if we can't change it. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 28 10:15:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02495 for ; Mon, 28 Apr 2003 10:15:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEIA813611; Mon, 28 Apr 2003 10:18:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEHm813593 for ; Mon, 28 Apr 2003 10:17:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02224 for ; Mon, 28 Apr 2003 10:12:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A9PE-0003AP-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 10:14:56 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19A9PE-0003AL-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 10:14:56 -0400 Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" , Jeff Parker Cc: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 28 Apr 2003 10:14:56 -0400 > Why is that a major vendor... sends PDUs > with size 1497 on Fast-Ethernet interfaces. > (I don't think we have modified any default parameters.) > > If that is true, Do you think we need to increase the > default value of this object to 1492? > > -Nagi. Nagi - Now I'm confused. Do you mean increast from 1492? 1492 is the current default value. If someone is using 1497 packets after stipping the link level overhead, that is an error. The size 1492 is based on the standard encapsulation on ordinary ethernet, and isn't up for negotiation. And even if this is going on, are 1497 byte LSPs being generated, or just Hello packets? The rules are different. The new text is below. I toyed with saying something like "We will store LSPs of size isisSysReceiveLSPBufferSize unless we are in overload condition. Larger LSPs will be saved as resources permit. - jeff parker isisSysReceiveLSPBufferSize OBJECT-TYPE SYNTAX Unsigned16TC (1492..65535) UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "Size of the largest Buffer we are designed or configured to store. This should be at least as big as the maximum isisSysOrigLSPBuffSize supported by the system. If resources allow, we will store and flood LSPs larger than isisSysReceiveLSPBufferSize, as this can help avoid problems in networks with different values for isisSysOrigLSPBuffSize. We always store LSPs of size isisSysReceiveLSPBufferSize unless we are in overload condition. Larger LSPs will be saved as resources permit." DEFVAL { 1492 } ::= { isisSysEntry 14 } _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 28 10:37:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03213 for ; Mon, 28 Apr 2003 10:37:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEeJ815601; Mon, 28 Apr 2003 10:40:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEdL815536 for ; Mon, 28 Apr 2003 10:39:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03078 for ; Mon, 28 Apr 2003 10:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A9k4-0003GP-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 10:36:28 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19A9k4-0003GM-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 10:36:28 -0400 Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" Subject: FW: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 28 Apr 2003 10:36:30 -0400 > Jeff, > My flaky memory prompts me to recall that the > value of 1492 is actually an anachronism caused by DEC's > original use of a SNAP-SAP Ethernet encoding.... > Hence we COULD have used 1497 as the default, but since > we had deployed a bunch with a value of 1492 and it was > then an architectural constant we didn't want to change > it. We figured nobody would worry about an odd 5 bytes. > > But I agree the standard says 1492 and that is > what it should be limited to. > > Mike [Shand] Mike - Shame on me for not looking at the encoding before replying. Nagi - I'm still interested in hearing if anyone is using 1497 byte LSPs. I suspect a lot of systems will break if they do. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Apr 28 17:42:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15353 for ; Mon, 28 Apr 2003 17:42:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SLdc817029; Mon, 28 Apr 2003 17:39:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SLaV816091 for ; Mon, 28 Apr 2003 17:36:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15078 for ; Mon, 28 Apr 2003 17:31:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AGFe-0005Ye-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 17:33:30 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19AGFd-0005YL-00 for isis-wg@ietf.org; Mon, 28 Apr 2003 17:33:29 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3SLX008017522; Mon, 28 Apr 2003 14:33:01 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-213.cisco.com [128.107.163.213]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFT30053; Mon, 28 Apr 2003 14:26:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20030428142002.00b95268@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: Re: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize Cc: "'Jonnala, Nagi'" , Jeff Parker , "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 28 Apr 2003 14:32:59 -0700 At 10:14 AM 4/28/2003 -0400, Jeff Parker wrote: > > Why is that a major vendor... sends PDUs > > with size 1497 on Fast-Ethernet interfaces. > > (I don't think we have modified any default parameters.) > > > > If that is true, Do you think we need to increase the > > default value of this object to 1492? > > > > -Nagi. > >Nagi - > Now I'm confused. Do you mean increast from 1492? >1492 is the current default value. If someone is using 1497 >packets after stipping the link level overhead, that is >an error. The size 1492 is based on the standard encapsulation >on ordinary ethernet, and isn't up for negotiation. > And even if this is going on, are 1497 byte LSPs being >generated, or just Hello packets? The rules are different. > > The new text is below. I toyed with saying something >like "We will store LSPs of size isisSysReceiveLSPBufferSize >unless we are in overload condition. Larger LSPs will be >saved as resources permit. Jeff - I think you are on slippery ground here. The issue with larger LSPs is not whether the receiving system has enough memory to store them - but rather with whether the LSPs can be propagated successfully throughout the network (due to link layer MTU constraints). If a system can successfully receive the larger LSPs it should certainly NOT distinguish between the two sized LSPs as far as storage is concerned. To do so would introduce two potential interpretations for the OL bit without the ability to advertise which of the two meanings is correct. I also do not see how a selective storage policy helps achieve qualitatively better convergence. We have provided mechanisms to advertise the local supported value for "originatingLxLSPBufferSize" to allow mismatches to be detected before they become a problem. We have also defined alarms to note when LSPs are actually received which are too big to propagate everywhere. Let that be enough. Les >- jeff parker > > isisSysReceiveLSPBufferSize OBJECT-TYPE > SYNTAX Unsigned16TC (1492..65535) > UNITS "bytes" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Size of the largest Buffer we are designed or > configured to store. This should be at least > as big as the maximum isisSysOrigLSPBuffSize > supported by the system. > > If resources allow, we will store and flood LSPs > larger than isisSysReceiveLSPBufferSize, as this > can help avoid problems in networks with different > values for isisSysOrigLSPBuffSize. > > We always store LSPs of size isisSysReceiveLSPBufferSize > unless we are in overload condition. Larger LSPs > will be saved as resources permit." > DEFVAL { 1492 } > ::= { isisSysEntry 14 } >_______________________________________________ >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-admin@ietf.org Tue Apr 29 08:51:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15139 for ; Tue, 29 Apr 2003 08:51:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TCrB805288; Tue, 29 Apr 2003 08:53:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TCpm805227 for ; Tue, 29 Apr 2003 08:51:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15022 for ; Tue, 29 Apr 2003 08:46:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AUX6-0002Fy-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 08:48:28 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19AUX5-0002Fd-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 08:48:27 -0400 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" Cc: "'Jonnala, Nagi'" , "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 08:48:25 -0400 Les - If we do not distinguish between PDUs greater than isisSysReceiveLSPBufferSize and those less than or equal to it, then there isn't much point in having the value. Are you proposing that we drop isisSysReceiveLSPBufferSize? I know of more than one implementation that uses a buffer pool scheme to deal with memory fragmentation issues. Even if such implementations can deal with large LSPs, there is a prefered size. - jeff parker > Jeff - > > I think you are on slippery ground here. > > The issue with larger LSPs is not whether the receiving > system has enough > memory to store them - but rather with whether the LSPs can > be propagated > successfully throughout the network (due to link layer MTU > constraints). If > a system can successfully receive the larger LSPs it should > certainly NOT > distinguish between the two sized LSPs as far as storage is > concerned. To > do so would introduce two potential interpretations for the > OL bit without > the ability to advertise which of the two meanings is > correct. I also do > not see how a selective storage policy helps achieve > qualitatively better > convergence. > > We have provided mechanisms to advertise the local supported > value for > "originatingLxLSPBufferSize" to allow mismatches to be > detected before they > become a problem. We have also defined alarms to note when LSPs are > actually received which are too big to propagate everywhere. > Let that be > enough. > > > Les > > isisSysReceiveLSPBufferSize OBJECT-TYPE > > SYNTAX Unsigned16TC (1492..65535) > > UNITS "bytes" > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Size of the largest Buffer we are designed or > > configured to store. This should be at least > > as big as the maximum isisSysOrigLSPBuffSize > > supported by the system. > > > > If resources allow, we will store and flood LSPs > > larger than isisSysReceiveLSPBufferSize, as this > > can help avoid problems in networks with different > > values for isisSysOrigLSPBuffSize. > > > > We always store LSPs of size > isisSysReceiveLSPBufferSize > > unless we are in overload condition. Larger LSPs > > will be saved as resources permit." > > DEFVAL { 1492 } > > ::= { isisSysEntry 14 } > >_______________________________________________ > >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-admin@ietf.org Tue Apr 29 09:28:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17033 for ; Tue, 29 Apr 2003 09:28:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TDVF809515; Tue, 29 Apr 2003 09:31:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TDUK808751 for ; Tue, 29 Apr 2003 09:30:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16458 for ; Tue, 29 Apr 2003 09:24:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AV8N-0002Zq-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 09:26:59 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19AV8M-0002YH-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 09:26:58 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TDR3504687 for ; Tue, 29 Apr 2003 09:27:03 -0400 (EDT) Received: by II0015EXCH002U with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 18:41:43 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D202A6B44D@II0015EXCH002U> From: "Ramalingam, Swaminathan (Swaminathan)" To: Jeff Parker Cc: "'Jonnala, Nagi'" , "ISIS-WG (E-mail)" , "'Les Ginsberg'" Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 18:41:42 +0530 Jeff - I guess, Les trying to point out isisSysReceiveLSPBufferSize is more of related to MTU, not how you store in the system. Even I am with Les, it should more of MTU related constraint. If it is related to storage problem, why let the user to configure that variable?. It can be hard coded with a value, whichever vendor feels good for its implementation. I feel, isisSysReceiveLSPBufferSize should be maintained in the MIB with description pointing out more of MTU constraint. Thanks, Swami -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Tuesday, April 29, 2003 6:18 PM To: 'Les Ginsberg' Cc: 'Jonnala, Nagi'; ISIS-WG (E-mail) Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize Les - If we do not distinguish between PDUs greater than isisSysReceiveLSPBufferSize and those less than or equal to it, then there isn't much point in having the value. Are you proposing that we drop isisSysReceiveLSPBufferSize? I know of more than one implementation that uses a buffer pool scheme to deal with memory fragmentation issues. Even if such implementations can deal with large LSPs, there is a prefered size. - jeff parker > Jeff - > > I think you are on slippery ground here. > > The issue with larger LSPs is not whether the receiving > system has enough > memory to store them - but rather with whether the LSPs can > be propagated > successfully throughout the network (due to link layer MTU > constraints). If > a system can successfully receive the larger LSPs it should > certainly NOT > distinguish between the two sized LSPs as far as storage is > concerned. To > do so would introduce two potential interpretations for the > OL bit without > the ability to advertise which of the two meanings is > correct. I also do > not see how a selective storage policy helps achieve > qualitatively better > convergence. > > We have provided mechanisms to advertise the local supported > value for > "originatingLxLSPBufferSize" to allow mismatches to be > detected before they > become a problem. We have also defined alarms to note when LSPs are > actually received which are too big to propagate everywhere. > Let that be > enough. > > > Les > > isisSysReceiveLSPBufferSize OBJECT-TYPE > > SYNTAX Unsigned16TC (1492..65535) > > UNITS "bytes" > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Size of the largest Buffer we are designed or > > configured to store. This should be at least > > as big as the maximum isisSysOrigLSPBuffSize > > supported by the system. > > > > If resources allow, we will store and flood LSPs > > larger than isisSysReceiveLSPBufferSize, as this > > can help avoid problems in networks with different > > values for isisSysOrigLSPBuffSize. > > > > We always store LSPs of size > isisSysReceiveLSPBufferSize > > unless we are in overload condition. Larger LSPs > > will be saved as resources permit." > > DEFVAL { 1492 } > > ::= { isisSysEntry 14 } > >_______________________________________________ > >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-admin@ietf.org Tue Apr 29 09:40:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17760 for ; Tue, 29 Apr 2003 09:40:41 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TDhk811201; Tue, 29 Apr 2003 09:43:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TDgG811161 for ; Tue, 29 Apr 2003 09:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17568 for ; Tue, 29 Apr 2003 09:36:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AVJu-0002su-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 09:38:54 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19AVJt-0002s8-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 09:38:53 -0400 Message-ID: From: Jeff Parker To: "'Ramalingam, Swaminathan (Swaminathan)'" Cc: "ISIS-WG (E-mail)" Subject: [Isis-wg] Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 09:38:55 -0400 > I guess, Les trying to point out isisSysReceiveLSPBufferSize > is more of > related to MTU, not how you store in the system. Even I am > with Les, it > should more of MTU related constraint. Swami - There are a number of variables here. MTU is one. Originating size is another. But Rx buffer size is a third. They all play a part. Is a system with 1492 byte LSP buffers compliant? Is it complaint if it is deployed in a network with only 4K MTU links? I think the answer is yes in both cases. The MTU does not tell you what the isisSysReceiveLSPBufferSize is. > If it is related to storage problem, why let the user > to configure that variable? I'm suggesting that you can read it. You may be able to set it, but you might not be able to. Most people get to read then number of valves in their car's engine. It doesn't mean they can configure this parameter, much less change it while they are driving. > It can be hard coded with a value, whichever > vendor feels good for its implementation. Exactly. Just like the car makers do. But they still let us find out what that value is. > I feel, isisSysReceiveLSPBufferSize should be > maintained in the MIB with description > pointing out more of MTU constraint. > > Thanks, > Swami If the issue is the text of the description clause, I will be happy to accept suggestions on how to clear up the meaning. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 29 13:54:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03601 for ; Tue, 29 Apr 2003 13:54:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THvf804943; Tue, 29 Apr 2003 13:57:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3THtp804842 for ; Tue, 29 Apr 2003 13:55:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03463 for ; Tue, 29 Apr 2003 13:50:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZHE-0006aM-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 13:52:24 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19AZHE-0006aC-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 13:52:24 -0400 Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" Subject: FW: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 13:52:28 -0400 > From: Les Ginsberg [mailto:ginsberg@cisco.com] > Sent: Tuesday, April 29, 2003 1:37 PM > To: Jeff Parker > Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize > > I haven't been following the MIB as closely lately. It isn't something everyone scans over breakfast, is it? > In looking at it today I see: > > isisSysReceiveLSPBufferSize OBJECT-TYPE > SYNTAX Unsigned16TC (1492..65535) > > isisOriginatingBufferSize OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > > So why is one variable 16 bits and the other 32 bits?? Thanks. It now reads isisOriginatingBufferSize OBJECT-TYPE SYNTAX Integer32 (512..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Holds the size of isisSysOrigLSPBuffSize advertised by peer in TLV." ::= { isisNotificationEntry 9 } - jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 29 14:07:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04083 for ; Tue, 29 Apr 2003 14:07:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TIB8807234; Tue, 29 Apr 2003 14:11:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TIAu807219 for ; Tue, 29 Apr 2003 14:10:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04012 for ; Tue, 29 Apr 2003 14:05:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZVo-0006hb-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 14:07:28 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19AZVn-0006hU-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 14:07:27 -0400 Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" Subject: [Isis-wg] Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 14:07:32 -0400 Les and I have been having a back-channel discussion on this > >My reading of this focuses on "by default". Don't discard > >this -if you have a choice-. That is, we make a best effort > >attempt to keep the large ones. The regular size ones we always > >keep - unless we are overloaded. > > If you can't allocate memory to store the larger LSP, then > obviously you must discard it - and you should not acknowledge > receipt of the LSP either. > This is equivalent to having a link MTU too small except the limiting > factor here is the L3 buffer size. I have no problem with > this because it > is an implementation issue. Good. I suspect that fixed size LSP buffers are a common implementation. This variable just recognizes the fact, and may help diagnose things. How about dropping the last paragraph? It still gives me the "resources allow" escape hatch. > > > isisSysReceiveLSPBufferSize OBJECT-TYPE > > > SYNTAX Unsigned16TC (1492..65535) > > > UNITS "bytes" > > > MAX-ACCESS read-create > > > STATUS current > > > DESCRIPTION > > > "Size of the largest Buffer we are designed or > > > configured to store. This should be at least > > > as big as the maximum isisSysOrigLSPBuffSize > > > supported by the system. > > > > > > If resources allow, we will store and flood LSPs > > > larger than isisSysReceiveLSPBufferSize, as this > > > can help avoid problems in networks with different > > > values for isisSysOrigLSPBuffSize." > > > DEFVAL { 1492 } > > > ::= { isisSysEntry 14 } - jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 29 14:30:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04760 for ; Tue, 29 Apr 2003 14:30:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TIYB809116; Tue, 29 Apr 2003 14:34:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TIXl809100 for ; Tue, 29 Apr 2003 14:33:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04652 for ; Tue, 29 Apr 2003 14:28:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZrv-0006tV-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 14:30:19 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19AZru-0006tR-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 14:30:19 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3TITpQi020953; Tue, 29 Apr 2003 11:29:52 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-213.cisco.com [128.107.163.213]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFT86612; Tue, 29 Apr 2003 11:23:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20030429112501.03cd0da8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: Re: [Isis-wg] Use of isisSysReceiveLSPBufferSize Cc: "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5451298==_.ALT" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 11:29:51 -0700 --=====================_5451298==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:07 PM 4/29/2003 -0400, Jeff Parker wrote: >Les and I have been having a back-channel discussion on this > > > >My reading of this focuses on "by default". Don't discard > > >this -if you have a choice-. That is, we make a best effort > > >attempt to keep the large ones. The regular size ones we always > > >keep - unless we are overloaded. > > > > If you can't allocate memory to store the larger LSP, then > > obviously you must discard it - and you should not acknowledge > > receipt of the LSP either. > > This is equivalent to having a link MTU too small except the limiting > > factor here is the L3 buffer size. I have no problem with > > this because it > > is an implementation issue. > >Good. I suspect that fixed size LSP buffers are a common >implementation. This variable just recognizes the fact, >and may help diagnose things. > >How about dropping the last paragraph? It still gives >me the "resources allow" escape hatch. > > > > > isisSysReceiveLSPBufferSize OBJECT-TYPE > > > > SYNTAX Unsigned16TC (1492..65535) > > > > UNITS "bytes" > > > > MAX-ACCESS read-create > > > > STATUS current > > > > DESCRIPTION > > > > "Size of the largest Buffer we are designed or > > > > configured to store. This should be at least > > > > as big as the maximum isisSysOrigLSPBuffSize > > > > supported by the system. > > > > > > > > If resources allow, we will store and flood LSPs > > > > larger than isisSysReceiveLSPBufferSize, as this > > > > can help avoid problems in networks with different > > > > values for isisSysOrigLSPBuffSize." > > > > DEFVAL { 1492 } > > > > ::= { isisSysEntry 14 } The correct behavior for handling receipt of an LSP which is too large to store is specified in ISO 10589 7.3.14.2: The maximum size control PDU (Link State PDU or Sequence Numbers PDU) which a system expects to receive shall be ReceiveLSPBufferSize octets. (i.e. the Update process must provide buffers of at least this size for the reception, storage and forwarding of received Link State PDUs and Sequence Numbers PDUs.) If a control PDU larger than this size is received, it shall be treated as if it had an invalid checksum (i.e. ignored by the Update Process and a corruptedLSPReceived event generated). If you can store an LSP, then you should ACK reception, store it, and flood it. If you can't store it then you behave as described in 10589. There is no need for additional specification. Les >- jeff >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg --=====================_5451298==_.ALT Content-Type: text/html; charset="us-ascii" At 02:07 PM 4/29/2003 -0400, Jeff Parker wrote:
Les and I have been having a back-channel discussion on this

> >My reading of this focuses on "by default".  Don't discard
> >this -if you have a choice-.  That is, we make a best effort
> >attempt to keep the large ones.  The regular size ones we always
> >keep - unless we are overloaded.
>
> If you can't allocate memory to store the larger LSP, then
> obviously you must discard it - and you should not acknowledge
> receipt of the LSP either.
> This is equivalent to having a link MTU too small except the limiting
> factor here is the L3 buffer size. I have no problem with
> this because it
> is an implementation issue.

Good.  I suspect that fixed size LSP buffers are a common
implementation.  This variable just recognizes the fact,
and may help diagnose things. 

How about dropping the last paragraph?  It still gives
me the "resources allow" escape hatch. 

> > >     isisSysReceiveLSPBufferSize OBJECT-TYPE
> > >         SYNTAX Unsigned16TC (1492..65535)
> > >         UNITS "bytes"
> > >         MAX-ACCESS read-create
> > >         STATUS current
> > >         DESCRIPTION
> > >             "Size of the largest Buffer we are designed or
> > >              configured to store.  This should be at least
> > >              as big as the maximum isisSysOrigLSPBuffSize
> > >              supported by the system.
> > >
> > >              If resources allow, we will store and flood LSPs
> > >              larger than isisSysReceiveLSPBufferSize, as this
> > >              can help avoid problems in networks with different
> > >              values for isisSysOrigLSPBuffSize."
> > >         DEFVAL { 1492 }
> > >     ::= { isisSysEntry 14 }

The correct behavior for handling receipt of an LSP which is too large to store is specified in ISO 10589 7.3.14.2:

The maximum size control PDU (Link State PDU or Sequence Numbers PDU) which a system expects to receive shall be ReceiveLSPBufferSize octets. (i.e. the Update process must provide buffers of at least this size for the reception, storage and forwarding of received Link State PDUs and Sequence Numbers PDUs.) If a control PDU larger than this size is received, it shall be treated as if it had an invalid checksum (i.e. ignored by the Update Process and a corruptedLSPReceived event generated).

If you can store an LSP, then you should ACK reception, store it, and flood it. If you can't store it then you behave as described in 10589. There is no need for additional specification.

   Les


- jeff
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
--=====================_5451298==_.ALT-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 29 15:01:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05719 for ; Tue, 29 Apr 2003 15:01:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJ4P812676; Tue, 29 Apr 2003 15:04:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJ3k812611 for ; Tue, 29 Apr 2003 15:03:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05582 for ; Tue, 29 Apr 2003 14:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AaKw-00075T-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 15:00:18 -0400 Received: from nn3.excitenetwork.com ([207.159.120.57] helo=xmxpita.excite.com) by ietf-mx with esmtp (Exim 4.12) id 19AaKv-00075J-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 15:00:17 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id F2B9C299BF; Tue, 29 Apr 2003 15:00:22 -0400 (EDT) To: jparker@axiowave.com, isis-wg@ietf.org Subject: FW: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize Received: from [64.47.48.10] by xprdmailfe22.nwk.excite.com via HTTP; Tue, 29 Apr 2003 15:00:22 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20030429190022.F2B9C299BF@xmxpita.excite.com> Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 15:00:22 -0400 (EDT) Content-Transfer-Encoding: 7bit Jeff, Shouldn't these both be defined as Unsigned32 (along with any of the other LSP Buffer attributes)? -don --- On Tue 04/29, Jeff Parker < jparker@axiowave.com > wrote: From: Jeff Parker [mailto: jparker@axiowave.com] To: isis-wg@ietf.org Date: Tue, 29 Apr 2003 13:52:28 -0400 Subject: FW: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize > From: Les Ginsberg [mailto:ginsberg@cisco.com] > Sent: Tuesday, April 29, 2003 1:37 PM > To: Jeff Parker > Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize > > I haven't been following the MIB as closely lately. It isn't something everyone scans over breakfast, is it? > In looking at it today I see: > > isisSysReceiveLSPBufferSize OBJECT-TYPE > SYNTAX Unsigned16TC (1492..65535) > > isisOriginatingBufferSize OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > > So why is one variable 16 bits and the other 32 bits?? Thanks. It now reads isisOriginatingBufferSize OBJECT-TYPE SYNTAX Integer32 (512..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Holds the size of isisSysOrigLSPBuffSize advertised by peer in TLV." ::= { isisNotificationEntry 9 } - jeff _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 29 15:04:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05870 for ; Tue, 29 Apr 2003 15:04:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJ73812883; Tue, 29 Apr 2003 15:07:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJ6M812799 for ; Tue, 29 Apr 2003 15:06:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05678 for ; Tue, 29 Apr 2003 15:00:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AaNS-00076z-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 15:02:54 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19AaNR-00076o-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 15:02:53 -0400 Message-ID: From: Jeff Parker To: "'dgoodspe@excite.com'" , isis-wg@ietf.org Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 15:02:52 -0400 > Jeff, > > Shouldn't these both be defined as Unsigned32 (along with any > of the other LSP Buffer attributes)? > > -don There was an effort awhile back to reduce the range on things to allow more error checking. Do you anticipate LSP's bigger than 16K? Bigger than 64K? - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 29 15:18:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07361 for ; Tue, 29 Apr 2003 15:18:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJMA814428; Tue, 29 Apr 2003 15:22:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJLm814412 for ; Tue, 29 Apr 2003 15:21:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07277 for ; Tue, 29 Apr 2003 15:16:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AacN-0007EW-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 15:18:19 -0400 Received: from nn1.excitenetwork.com ([207.159.120.55] helo=xmxpita.excite.com) by ietf-mx with esmtp (Exim 4.12) id 19AacN-0007ET-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 15:18:19 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id C7E7F3DC2; Tue, 29 Apr 2003 15:18:15 -0400 (EDT) To: jparker@axiowave.com, isis-wg@ietf.org Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize Received: from [64.47.48.10] by xprdmailfe12.nwk.excite.com via HTTP; Tue, 29 Apr 2003 15:18:15 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20030429191815.C7E7F3DC2@xmxpita.excite.com> Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 15:18:15 -0400 (EDT) Content-Transfer-Encoding: 7bit Jeff, No, this was not a range issue. I was just suggesting that since these values would never be negative to change them to Unsigned Integer values rather than Signed Integer values. -don P.S. My silly excite email messes up on HTML email messages when I reply to them, so apologies in advance if the original text below is "garbled". --- On Tue 04/29, Jeff Parker < jparker@axiowave.com > wrote: From: Jeff Parker [mailto: jparker@axiowave.com] To: dgoodspe@excite.com, isis-wg@ietf.org Date: Tue, 29 Apr 2003 15:02:52 -0400 Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize
> Jeff,
>
> Shouldn't these both be defined as Unsigned32 (along with any
> of the other LSP Buffer attributes)?
>
> -don

There was an effort awhile back to reduce the range on
things to allow more error checking. Do you anticipate
LSP's bigger than 16K? Bigger than 64K?

- jeff parker
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
_______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 29 15:25:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07653 for ; Tue, 29 Apr 2003 15:25:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJSE814730; Tue, 29 Apr 2003 15:28:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJRb814683 for ; Tue, 29 Apr 2003 15:27:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07490 for ; Tue, 29 Apr 2003 15:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Aai0-0007Gd-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 15:24:08 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19Aahz-0007GF-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 15:24:07 -0400 Message-ID: From: Jeff Parker To: "'dgoodspe@excite.com'" , isis-wg@ietf.org Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 15:24:02 -0400 > Jeff, > > No, this was not a range issue. I was just suggesting that since > these values would never be negative to change them to Unsigned > Integer values rather than Signed Integer values. > > -don > > P.S. My silly excite email messes up on HTML email messages when I > reply to them, so apologies in advance if the original text below > is "garbled". Don - With Les' help, I have just changed these to Unsigned 16. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Apr 29 16:05:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08764 for ; Tue, 29 Apr 2003 16:05:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TK8N819147; Tue, 29 Apr 2003 16:08:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TK7d819068 for ; Tue, 29 Apr 2003 16:07:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08665 for ; Tue, 29 Apr 2003 16:01:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AbKj-0007Vh-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 16:04:09 -0400 Received: from nn7.excitenetwork.com ([207.159.120.61] helo=xmxpita.excite.com) by ietf-mx with esmtp (Exim 4.12) id 19AbKi-0007VW-00 for isis-wg@ietf.org; Tue, 29 Apr 2003 16:04:08 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 74CF03D3F; Tue, 29 Apr 2003 16:04:15 -0400 (EDT) To: jparker@axiowave.com, isis-wg@ietf.org Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize Received: from [64.47.48.10] by xprdmailfe10.nwk.excite.com via HTTP; Tue, 29 Apr 2003 16:04:15 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20030429200415.74CF03D3F@xmxpita.excite.com> Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Apr 2003 16:04:15 -0400 (EDT) Content-Transfer-Encoding: 7bit Jeff, Les, Thanks! That will work just fine. -don "U16? You sank my battleship!" --- On Tue 04/29, Jeff Parker < jparker@axiowave.com > wrote: From: Jeff Parker [mailto: jparker@axiowave.com] To: dgoodspe@excite.com, isis-wg@ietf.org Date: Tue, 29 Apr 2003 15:24:02 -0400 Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize With Les' help, I have just changed these to Unsigned 16. - jeff parker _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 30 09:44:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03090 for ; Wed, 30 Apr 2003 09:44:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UDlr808205; Wed, 30 Apr 2003 09:47:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UDkT808117 for ; Wed, 30 Apr 2003 09:46:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02812 for ; Wed, 30 Apr 2003 09:40:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Arr3-00075Y-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 09:42:37 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19Arr1-00075E-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 09:42:36 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h3UDgm4A009806 for ; Wed, 30 Apr 2003 06:42:49 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h3UDgjnb011971 for ; Wed, 30 Apr 2003 08:42:45 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Apr 2003 09:42:34 -0400 Message-ID: From: "Jonnala, Nagi" To: "'Les Ginsberg'" , Jeff Parker Cc: "Jonnala, Nagi" , Jeff Parker , "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Apr 2003 09:38:33 -0400 >Nagi - > Now I'm confused. Do you mean increast from 1492? >1492 is the current default value. If someone is using 1497 >packets after stipping the link level overhead, that is >an error. The size 1492 is based on the standard encapsulation >on ordinary ethernet, and isn't up for negotiation. > And even if this is going on, are 1497 byte LSPs being >generated, or just Hello packets? The rules are different. > Yes, I have seen a box using 1497 Hello PDUs but not LSPs. It seems to me that LSPs are confined to 1492. My questions are: 1) Why is that 1497 Hellos are being generated. Does the difference between Ethernet and IEEE 802.3 packet sizes have any impact? 2) You said rules are different for LSPs and Hellos. What are those? Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 30 09:49:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03225 for ; Wed, 30 Apr 2003 09:49:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UDrD808525; Wed, 30 Apr 2003 09:53:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UDqq808485 for ; Wed, 30 Apr 2003 09:52:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03129 for ; Wed, 30 Apr 2003 09:46:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ArxE-0007B9-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 09:49:00 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19ArxD-0007Aw-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 09:48:59 -0400 Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Apr 2003 09:48:59 -0400 > >And even if this is going on, are 1497 byte LSPs being > >generated, or just Hello packets? The rules are different. > > Yes, I have seen a box using 1497 Hello PDUs but not LSPs. It seems > to me that LSPs are confined to 1492. > > My questions are: > > 1) Why is that 1497 Hellos are being generated. Does the difference > between Ethernet and IEEE 802.3 packet sizes have any impact? > > 2) You said rules are different for LSPs and Hellos. What are those? > > Thanks > Nagi. Nagi - Hellos may be padded to the MTU (or close to it) to discover misconfigurations: networks where one side thinks the MTU is bigger than the other. In part, this is to assure the network can carry the LSPs, but it is also to check these limits for ordinary traffic. The goal of the Hello packet is to get as close to the configured limit as possible. Mike Shand has filled us in on why there is some wiggle room between the size of the 'normal' LSP and the largest possible IS-IS packet on ethernet. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 30 10:18:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05671 for ; Wed, 30 Apr 2003 10:18:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UEM8816604; Wed, 30 Apr 2003 10:22:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UELM816566 for ; Wed, 30 Apr 2003 10:21:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05386 for ; Wed, 30 Apr 2003 10:15:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AsOn-0007W0-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 10:17:29 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19AsOm-0007Vp-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 10:17:29 -0400 Received: from dingdong.cisco.com (IDENT:mirapoint@dingdong.cisco.com [64.102.17.16]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3UEH4DP025888; Wed, 30 Apr 2003 10:17:04 -0400 (EDT) Received: from jlearman-w2k01.cisco.com (dhcp-64-102-83-190.cisco.com [64.102.83.190]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACH31598; Wed, 30 Apr 2003 10:17:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20030430101528.01eacba8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Jeff Learman Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize Cc: "'Jonnala, Nagi'" , "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Apr 2003 10:16:33 -0400 At 09:48 AM 4/30/2003, Jeff Parker wrote: >configured limit as possible. Mike Shand has filled us in >on why there is some wiggle room between the size of the >'normal' LSP and the largest possible IS-IS packet on >ethernet. It's simply because the smallest padding option is two bytes. So if you encoded your IIH and it happened to fill up to the MTU size minus one, you can't pad to the full length. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 30 10:34:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06220 for ; Wed, 30 Apr 2003 10:34:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UEYi822271; Wed, 30 Apr 2003 10:34:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UEVJ820361 for ; Wed, 30 Apr 2003 10:31:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05861 for ; Wed, 30 Apr 2003 10:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AsYQ-0007cX-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 10:27:26 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19AsYP-0007cJ-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 10:27:25 -0400 Message-ID: From: Jeff Parker To: "'Jeff Learman'" Cc: "ISIS-WG (E-mail)" Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Apr 2003 10:27:23 -0400 > At 09:48 AM 4/30/2003, Jeff Parker wrote: > >configured limit as possible. Mike Shand has filled us in > >on why there is some wiggle room between the size of the > >'normal' LSP and the largest possible IS-IS packet on > >ethernet. > > It's simply because the smallest padding option is two bytes. > So if you encoded your IIH and it happened to fill up to the > MTU size minus one, you can't pad to the full length. Jeff L - But with a modicum of inginuity, you could pad the previous TLV with 253 bytes, so you have the room you need. It has always amused me that the spec calls for great cleverness in some spots, and assumes you are an idiot here. - jeff P _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Apr 30 13:42:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14182 for ; Wed, 30 Apr 2003 13:42:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHkR807642; Wed, 30 Apr 2003 13:46:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHiw807354 for ; Wed, 30 Apr 2003 13:44:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14025 for ; Wed, 30 Apr 2003 13:38:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AvZg-0001pZ-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 13:40:56 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19AvZL-0001on-00 for isis-wg@ietf.org; Wed, 30 Apr 2003 13:40:35 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3UHcvxI011568; Wed, 30 Apr 2003 10:38:58 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-213.cisco.com [128.107.163.213]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFU60533; Wed, 30 Apr 2003 10:32:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20030430103219.00ba5ba8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Jonnala, Nagi" From: Les Ginsberg Subject: RE: [Isis-wg] RE: Use of isisSysReceiveLSPBufferSize Cc: Jeff Parker , "Jonnala, Nagi" , Jeff Parker , "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Apr 2003 10:38:56 -0700 At 09:38 AM 4/30/2003 -0400, Jonnala, Nagi wrote: > >Nagi - > > Now I'm confused. Do you mean increast from 1492? > >1492 is the current default value. If someone is using 1497 > >packets after stipping the link level overhead, that is > >an error. The size 1492 is based on the standard encapsulation > >on ordinary ethernet, and isn't up for negotiation. > > And even if this is going on, are 1497 byte LSPs being > >generated, or just Hello packets? The rules are different. > > > >Yes, I have seen a box using 1497 Hello PDUs but not LSPs. It seems >to me that LSPs are confined to 1492. > >My questions are: > >1) Why is that 1497 Hellos are being generated. Does the difference > between Ethernet and IEEE 802.3 packet sizes have any impact? > Yes. The ethernet MTU is 1500 bytes. But since IS-IS PDUs are always sent in 802.3 format, a three byte LLC1 header is always present. This makes the network layer MTU 1497. >2) You said rules are different for LSPs and Hellos. What are those? As Mike Shand has recounted, it was thought that a SNAP header might be used for LSPs. This would consume 5 bytes -> 1497-5 = 1492. I don't know of anyone that uses a SNAP header, so in theory we could use 1497 as the default maximum LSP size, but given the legacy problems this could cause and the rather minuscule extension to the LSP space, there is no reason to consider this. Les >Thanks >Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg