From isis-wg-bounces@ietf.org Tue Aug 3 15:01:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02720 for ; Tue, 3 Aug 2004 15:01:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs4RC-0000kT-Td; Tue, 03 Aug 2004 14:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs4E8-00070M-7x for isis-wg@megatron.ietf.org; Tue, 03 Aug 2004 14:41:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01370 for ; Tue, 3 Aug 2004 14:41:30 -0400 (EDT) From: jcucchiara@mindspring.com Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs4HE-0007Mk-G1 for isis-wg@ietf.org; Tue, 03 Aug 2004 14:44:45 -0400 Received: from [192.168.167.43] (helo=wamui05.slb.atl.earthlink.net) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Bs4Dx-0000CT-00; Tue, 03 Aug 2004 14:41:21 -0400 Message-ID: <3184791.1091558481469.JavaMail.root@wamui05.slb.atl.earthlink.net> Date: Tue, 3 Aug 2004 14:41:20 -0400 (GMT-04:00) To: jparker@axiowave.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org Subject: [Isis-wg] question on the isisSysProtSuppTable in draft-ietf-isis-wg-mib-16.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jcucchiara@mindspring.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Jeff, I have two question regarding the isisSysProtSuppTable: 1) Why can't this table be reduced to a scalar, read-only object with type BITS which can be queried by an operator to see what the router supports? 2) How is the operator going to know what protocols the router supports, because there doesn't exist any object which tells the operator? The current table assumes that the operator "knows" what protocols are supported and I don't see anything in the MIB that tells the operator this info. thanks, -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 3 16:00:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07545 for ; Tue, 3 Aug 2004 16:00:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs5Mh-0002qW-GB; Tue, 03 Aug 2004 15:54:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs5GC-0001nW-PG for isis-wg@megatron.ietf.org; Tue, 03 Aug 2004 15:47:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06702 for ; Tue, 3 Aug 2004 15:47:43 -0400 (EDT) Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs5JK-0008RD-6x for isis-wg@ietf.org; Tue, 03 Aug 2004 15:50:59 -0400 Message-ID: From: Jeff Parker To: "'jcucchiara@mindspring.com'" Date: Tue, 3 Aug 2004 15:47:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: isis-wg@ietf.org, James Halpin Subject: [Isis-wg] RE: question on the isisSysProtSuppTable in draft-ietf-isis-wg-mi b-16.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > Hi Jeff, > > I have two question regarding the isisSysProtSuppTable: > > 1) Why can't this table be reduced to a scalar, read-only > object with type BITS which > can be queried by an operator to see what the router supports? Yup, that could be done > > 2) How is the operator going to know what protocols the > router supports, because > there doesn't exist any object which tells the operator? I assume that the operator will do a get-next walk over the table, and retrieve the rows. Each row represents a different supported protocol IsisSysProtSuppEntry ::= SEQUENCE { isisSysProtSuppProtocol IsisSupportedProtocol, isisSysProtSuppExistState RowStatus } > The current table assumes that the operator "knows" what > protocols are supported and > I don't see anything in the MIB that tells the operator this info. > > thanks, > -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 3 17:49:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14856 for ; Tue, 3 Aug 2004 17:49:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs781-0000Rw-Dr; Tue, 03 Aug 2004 17:47:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs74C-0008Ez-Qv for isis-wg@megatron.ietf.org; Tue, 03 Aug 2004 17:43:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14488 for ; Tue, 3 Aug 2004 17:43:26 -0400 (EDT) Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs77K-00021X-1V for isis-wg@ietf.org; Tue, 03 Aug 2004 17:46:44 -0400 Received: from dgoodspeedpc ([192.168.3.247] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Aug 2004 14:42:54 -0700 From: "Don Goodspeed" To: "'Jeff Parker'" , Subject: RE: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ietf-isis-wg-mi b-16.txt Date: Tue, 3 Aug 2004 14:43:01 -0700 Message-ID: <003b01c479a2$da06d440$f703a8c0@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-OriginalArrivalTime: 03 Aug 2004 21:42:54.0937 (UTC) FILETIME=[D5A6FC90:01C479A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org, "'James Halpin'" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Don.Goodspeed@alcatel.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Jeff, Joan, If we are truly having this be a read-only table, then it can just be a scalar object with BITS as the definition, and each bit representing each protocol: isisSysProtSupported OBJECT-TYPE SYNTAX BITS { iso8473 (0), ipv4 (1), ipv6 (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the set of protocols supported by this Intermediate System." ::= { isisSysObject 12 } One could then get rid of the existing table and the TC SupportedProtocol. -don -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Jeff Parker Sent: Tuesday, August 03, 2004 12:47 PM To: 'jcucchiara@mindspring.com' Cc: isis-wg@ietf.org; James Halpin Subject: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ietf-isis-wg-mi b-16.txt > Hi Jeff, > > I have two question regarding the isisSysProtSuppTable: > > 1) Why can't this table be reduced to a scalar, read-only > object with type BITS which > can be queried by an operator to see what the router supports? Yup, that could be done > > 2) How is the operator going to know what protocols the > router supports, because > there doesn't exist any object which tells the operator? I assume that the operator will do a get-next walk over the table, and retrieve the rows. Each row represents a different supported protocol IsisSysProtSuppEntry ::= SEQUENCE { isisSysProtSuppProtocol IsisSupportedProtocol, isisSysProtSuppExistState RowStatus } > The current table assumes that the operator "knows" what > protocols are supported and > I don't see anything in the MIB that tells the operator this info. > > thanks, > -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 3 21:21:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29075 for ; Tue, 3 Aug 2004 21:21:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAMc-0001iK-Pi; Tue, 03 Aug 2004 21:14:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAKa-0001Jb-LK for isis-wg@megatron.ietf.org; Tue, 03 Aug 2004 21:12:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28471 for ; Tue, 3 Aug 2004 21:12:34 -0400 (EDT) From: jcucchiara@mindspring.com Received: from smtp10.atl.mindspring.net ([207.69.200.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsANk-0005d5-DU for isis-wg@ietf.org; Tue, 03 Aug 2004 21:15:53 -0400 Received: from h-66-167-185-246.cmbrmaor.dynamic.covad.net ([66.167.185.246] helo=jluciani-laptop) by smtp10.atl.mindspring.net with smtp (Exim 3.33 #1) id 1BsAKS-0000Ql-00; Tue, 03 Aug 2004 21:12:28 -0400 Message-Id: <3.0.1.32.20040803212050.0078f778@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 03 Aug 2004 21:20:50 -0400 To: , "'Jeff Parker'" Subject: RE: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ietf-isis-wg-mi b-16.txt In-Reply-To: <003b01c479a2$da06d440$f703a8c0@eng.timetra.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: isis-wg@ietf.org, "'James Halpin'" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi Don, At 02:43 PM 8/3/04 -0700, Don Goodspeed wrote: >Jeff, Joan, > >If we are truly having this be a read-only table, then >it can just be a scalar object with BITS as the definition, >and each bit representing each protocol: > > isisSysProtSupported OBJECT-TYPE > SYNTAX BITS { > iso8473 (0), > ipv4 (1), > ipv6 (2) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This attribute contains the set of protocols > supported by this Intermediate System." > ::= { isisSysObject 12 } Awesome! > >One could then get rid of the existing table and the TC >SupportedProtocol. > I agree. -Joan >-don > > >-----Original Message----- >From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On >Behalf Of Jeff Parker >Sent: Tuesday, August 03, 2004 12:47 PM >To: 'jcucchiara@mindspring.com' >Cc: isis-wg@ietf.org; James Halpin >Subject: [Isis-wg] RE: question on the isisSysProtSuppTable >indraft-ietf-isis-wg-mi b-16.txt > > > >> Hi Jeff, >> >> I have two question regarding the isisSysProtSuppTable: >> >> 1) Why can't this table be reduced to a scalar, read-only >> object with type BITS which >> can be queried by an operator to see what the router supports? > >Yup, that could be done >> >> 2) How is the operator going to know what protocols the >> router supports, because >> there doesn't exist any object which tells the operator? > >I assume that the operator will do a get-next walk over the table, and >retrieve the rows. Each row represents a different supported protocol > > IsisSysProtSuppEntry ::= > SEQUENCE { > isisSysProtSuppProtocol > IsisSupportedProtocol, > isisSysProtSuppExistState > RowStatus > } > >> The current table assumes that the operator "knows" what >> protocols are supported and >> I don't see anything in the MIB that tells the operator this info. >> >> thanks, >> -Joan > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Aug 4 10:03:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06113 for ; Wed, 4 Aug 2004 10:03:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsMKp-0002Yj-CQ; Wed, 04 Aug 2004 10:01:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsMKJ-00026H-Tz for isis-wg@megatron.ietf.org; Wed, 04 Aug 2004 10:01:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06001 for ; Wed, 4 Aug 2004 10:01:06 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsMNY-0000My-8h for isis-wg@ietf.org; Wed, 04 Aug 2004 10:04:32 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Aug 2004 15:00:23 +0100 Message-ID: <37701240971DD31193970000F6CCB9F7050424B3@duke.datcon.co.uk> From: Jonathan Harrison To: "'Don.Goodspeed@alcatel.com'" , "'Jeff Parker'" , jcucchiara@mindspring.com Subject: RE: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ie tf-isis-wg-mib-16.txt Date: Wed, 4 Aug 2004 15:00:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Don, Jeff, Joan, I agree that a single scalar BITS object is simpler than the current isisSysProtSupp table. However, I think that operators may want to configure the set of protocols (for example, to enable or disable IS-IS for IPv6), and so the object should have read-write access. Jon -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Don Goodspeed Sent: 03 August 2004 22:43 To: 'Jeff Parker'; jcucchiara@mindspring.com Cc: isis-wg@ietf.org; 'James Halpin' Subject: RE: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ietf-isis-wg-mi b-16.txt Jeff, Joan, If we are truly having this be a read-only table, then it can just be a scalar object with BITS as the definition, and each bit representing each protocol: isisSysProtSupported OBJECT-TYPE SYNTAX BITS { iso8473 (0), ipv4 (1), ipv6 (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the set of protocols supported by this Intermediate System." ::= { isisSysObject 12 } One could then get rid of the existing table and the TC SupportedProtocol. -don -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Jeff Parker Sent: Tuesday, August 03, 2004 12:47 PM To: 'jcucchiara@mindspring.com' Cc: isis-wg@ietf.org; James Halpin Subject: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ietf-isis-wg-mi b-16.txt > Hi Jeff, > > I have two question regarding the isisSysProtSuppTable: > > 1) Why can't this table be reduced to a scalar, read-only > object with type BITS which > can be queried by an operator to see what the router supports? Yup, that could be done > > 2) How is the operator going to know what protocols the > router supports, because > there doesn't exist any object which tells the operator? I assume that the operator will do a get-next walk over the table, and retrieve the rows. Each row represents a different supported protocol IsisSysProtSuppEntry ::= SEQUENCE { isisSysProtSuppProtocol IsisSupportedProtocol, isisSysProtSuppExistState RowStatus } > The current table assumes that the operator "knows" what > protocols are supported and > I don't see anything in the MIB that tells the operator this info. > > thanks, > -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Aug 4 10:22:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08312 for ; Wed, 4 Aug 2004 10:22:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsMXL-0007WU-EZ; Wed, 04 Aug 2004 10:14:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsMUg-0006r2-1Z for isis-wg@megatron.ietf.org; Wed, 04 Aug 2004 10:11:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07224 for ; Wed, 4 Aug 2004 10:11:47 -0400 (EDT) From: jcucchiara@mindspring.com Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsMXy-0000XO-0m for isis-wg@ietf.org; Wed, 04 Aug 2004 10:15:14 -0400 Received: from [192.168.167.41] (helo=wamui03.slb.atl.earthlink.net) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BsMUT-0007jG-00; Wed, 04 Aug 2004 10:11:37 -0400 Message-ID: <16888662.1091628697149.JavaMail.root@wamui03.slb.atl.earthlink.net> Date: Wed, 4 Aug 2004 10:11:35 -0400 (GMT-04:00) To: Jonathan Harrison , "'Don.Goodspeed@alcatel.com'" , "'Jeff Parker'" Subject: RE: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ie tf-isis-wg-mib-16.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jcucchiara@mindspring.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Jon, Perhaps 2 scalars are needed. One which is read-only which Don outlined, because the operator is going to need to know what protocols are supported by the router. Even though the MIB object specifies the possibility 3 different protocols, it might be that a router vendor does NOT support all 3 of these to begin with. It would be very clear to an operator what is or is not supported with this read-only object. This would be new to the MIB. The other object is read-write would be for the reasons you state below, and would replace the isisSysProtTable. I would be in favor of removing the isisSysProtSuppTable and replacing this with 2 scalars. thanks, - Joan -----Original Message----- From: Jonathan Harrison Sent: Aug 4, 2004 10:00 AM To: "'Don.Goodspeed@alcatel.com'" , 'Jeff Parker' , jcucchiara@mindspring.com Cc: isis-wg@ietf.org Subject: RE: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ie tf-isis-wg-mib-16.txt Don, Jeff, Joan, I agree that a single scalar BITS object is simpler than the current isisSysProtSupp table. However, I think that operators may want to configure the set of protocols (for example, to enable or disable IS-IS for IPv6), and so the object should have read-write access. Jon -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Don Goodspeed Sent: 03 August 2004 22:43 To: 'Jeff Parker'; jcucchiara@mindspring.com Cc: isis-wg@ietf.org; 'James Halpin' Subject: RE: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ietf-isis-wg-mi b-16.txt Jeff, Joan, If we are truly having this be a read-only table, then it can just be a scalar object with BITS as the definition, and each bit representing each protocol: isisSysProtSupported OBJECT-TYPE SYNTAX BITS { iso8473 (0), ipv4 (1), ipv6 (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute contains the set of protocols supported by this Intermediate System." ::= { isisSysObject 12 } One could then get rid of the existing table and the TC SupportedProtocol. -don -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Jeff Parker Sent: Tuesday, August 03, 2004 12:47 PM To: 'jcucchiara@mindspring.com' Cc: isis-wg@ietf.org; James Halpin Subject: [Isis-wg] RE: question on the isisSysProtSuppTable indraft-ietf-isis-wg-mi b-16.txt > Hi Jeff, > > I have two question regarding the isisSysProtSuppTable: > > 1) Why can't this table be reduced to a scalar, read-only > object with type BITS which > can be queried by an operator to see what the router supports? Yup, that could be done > > 2) How is the operator going to know what protocols the > router supports, because > there doesn't exist any object which tells the operator? I assume that the operator will do a get-next walk over the table, and retrieve the rows. Each row represents a different supported protocol IsisSysProtSuppEntry ::= SEQUENCE { isisSysProtSuppProtocol IsisSupportedProtocol, isisSysProtSuppExistState RowStatus } > The current table assumes that the operator "knows" what > protocols are supported and > I don't see anything in the MIB that tells the operator this info. > > thanks, > -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Aug 4 20:04:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22161 for ; Wed, 4 Aug 2004 20:04:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVdT-0007bS-MW; Wed, 04 Aug 2004 19:57:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsVXX-0006Mb-Ns for isis-wg@megatron.ietf.org; Wed, 04 Aug 2004 19:51:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21180 for ; Wed, 4 Aug 2004 19:51:22 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsVau-000341-E2 for isis-wg@ietf.org; Wed, 04 Aug 2004 19:54:53 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsVXU-000F3s-U1 for isis-wg@ietf.org; Wed, 04 Aug 2004 23:51:21 +0000 Date: Wed, 4 Aug 2004 16:51:16 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1578905612.20040804165116@psg.com> To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit A few comments I raised at the mic today: 1. One of the reasons that was mention was exhaustion of the TLV type space. Given that we have only 36 allocations in the registry now, I doubt this will be a problem any time soon. 2. Another reason was the size of the TLV. If this becomes a problem, my first question would be whether this is a good idea to announce such info in ISIS and/or whether it is properly encoded. This is not to say that we could never end up with having to announce something bigger than 255, but I'd like to see an example of where this becomes a problem we can't get around. 3. Naming mentioned in his slides that backwards-compatible deployment is possible. I wasn't sure it was. Now that I re-read the draft, I'm sure it is not possible. Routers not implementing this feature will encounter a TLV parsing error, since the what they believe is the 1-octet length field will contain wrong value for TLVs bigger than 255 octets. -- 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-bounces@ietf.org Wed Aug 4 21:04:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25964 for ; Wed, 4 Aug 2004 21:04:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsWeL-0004Hg-Ko; Wed, 04 Aug 2004 21:02:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsWbq-0003kH-68 for isis-wg@megatron.ietf.org; Wed, 04 Aug 2004 20:59:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25485 for ; Wed, 4 Aug 2004 20:59:52 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsWfD-0004I6-Hx for isis-wg@ietf.org; Wed, 04 Aug 2004 21:03:24 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Aug 2004 18:00:23 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i750xFVD009677; Wed, 4 Aug 2004 17:59:16 -0700 (PDT) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp7.cisco.com [10.61.64.7]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA16699; Thu, 5 Aug 2004 01:59:16 +0100 (BST) Message-Id: <4.3.2.7.2.20040805015229.02185a80@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Aug 2004 01:59:14 +0100 To: Alex Zinin From: mike shand Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt In-Reply-To: <1578905612.20040804165116@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 16:51 04/08/2004 -0700, Alex Zinin wrote: >A few comments I raised at the mic today: > >1. One of the reasons that was mention was exhaustion of the TLV type > space. Given that we have only 36 allocations in the registry now, > I doubt this will be a problem any time soon. I agree. And not only that, we have sub-TLVs for things that need a lot of code points. >2. Another reason was the size of the TLV. If this becomes a problem, > my first question would be whether this is a good idea to announce > such info in ISIS and/or whether it is properly encoded. This is not > to say that we could never end up with having to announce something > bigger than 255, but I'd like to see an example of where this becomes > a problem we can't get around. I agree. This seems to be a somewhat Draconian solution to a problem which we don't know we have yet, and which IF we do have may well be solvable by simpler techniques (such as defining the contents of TLVs to be additive, in the same way that we can have more prefixes than will fit in a single TLV by repeating the TLV and "adding" the prefixes together; I agree it is not quite as simple as that in some case, but that seems to me to be a less disruptive way of addressing the problem should it ever arise; and I sincerely hope it doesn't:-) >3. Naming mentioned in his slides that backwards-compatible deployment > is possible. I wasn't sure it was. Now that I re-read the draft, I'm > sure it is not possible. Routers not implementing this feature will > encounter a TLV parsing error, since the what they believe is the 1-octet > length field will contain wrong value for TLVs bigger than 255 octets. We well it does "work", but it doesn't buy you anything. Although the backwards compatibility lets you use long format TLVs before everyone understands them you can't have them longer than 255 octets. So the only use for this would be to extend the TLV code space, and we have already agreed that is not a problem in our lifetime! Mike >-- >Alex >http://www.psg.com/~zinin > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Aug 5 19:44:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26890 for ; Thu, 5 Aug 2004 19:44:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bsro2-0008JK-0Q; Thu, 05 Aug 2004 19:37:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsrmK-0007rH-Gv for isis-wg@megatron.ietf.org; Thu, 05 Aug 2004 19:36:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26462 for ; Thu, 5 Aug 2004 19:36:06 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsrpv-00089x-24 for isis-wg@ietf.org; Thu, 05 Aug 2004 19:39:51 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A086E651D36; Thu, 5 Aug 2004 16:35:53 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29730-08; Thu, 5 Aug 2004 16:35:53 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id D5447651D35; Thu, 5 Aug 2004 16:35:42 -0700 (PDT) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id QAA27329; Thu, 5 Aug 2004 16:35:41 -0700 (PDT) Message-Id: <200408052335.QAA27329@redback.com> To: Alex Zinin Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt In-reply-to: Mail from Alex Zinin dated Wed, 04 Aug 2004 16:51:16 PDT <1578905612.20040804165116@psg.com> Date: Thu, 05 Aug 2004 16:35:41 -0700 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Alex, ] A few comments I raised at the mic today: ] ] 1. One of the reasons that was mention was exhaustion of the TLV type ] space. Given that we have only 36 allocations in the registry now, ] I doubt this will be a problem any time soon. Agreed. But this code point is a side effect of the draft. I think anyone would agree that if we take the trouble to change the length field, the code field better to be changed at the same time. ] ] 2. Another reason was the size of the TLV. If this becomes a problem, ] my first question would be whether this is a good idea to announce ] such info in ISIS and/or whether it is properly encoded. This is not ] to say that we could never end up with having to announce something ] bigger than 255, but I'd like to see an example of where this becomes ] a problem we can't get around. Ok, let me list some of the reasoning here, others can contribute too, - network transition is not easy, it can takes years to finish, for all the boxes converge into the same capabilities. - a pure historical note: at the time we desgined the Multi-Topology IS-IS, there was a choice to use the existing TLV 22 and 135. But the major concern at the time was if there were multiple topologies using TE (not even talking about GMPLS), then the 255 bytes of the TLV would be a serious limitation and we could not make such a choice. Thus we now have the TLV 222 and 235. - as Dimitri yesterday mentioned, in gmpls application usage, the tlv limitation is a concern. - diffServ TE usage for isis, 'clasic TE' is only a special case in diffsrv TE. diffserv TE can contain a lot more data. - when we have something like isis capability tlv, there will be various 'features'/ 'capabilities' a system needs to announce, they could be split into multiple tlvs. then there is a concern how to keep track of the versions of the 'capability' changes if they spread over multiple tlvs/packets. it would be much easier, if the capability tlvs are kept within the same tlv, then there will be no mistake how to read the newer/older version of changes. (this was heavily discussed among the isis cap draft co-authors, and it was the trigger for me(us) to revisit this isis tlv limitation issue) i don't believe that we don't have a problem currently. we may not have a hard limit problem at hand right now, but why we are willing to live with this limitation for isis, and why not create the capability when the problem is still in a 'soft' state ? ] ] 3. Naming mentioned in his slides that backwards-compatible deployment ] is possible. I wasn't sure it was. Now that I re-read the draft, I'm ] sure it is not possible. Routers not implementing this feature will ] encounter a TLV parsing error, since the what they believe is the 1-octet ] length field will contain wrong value for TLVs bigger than 255 octets. during transitional tlv mode, a system is not allowed to generate this extended tlv larger than the 255 octets. this is mentioned in the network transition section of the draft. this is no different from the TE metric transition, the wide metric can not have the value over 63. this is why if we are going to move to this new scheme, better to do it long before when the >255 octect is really needed. thanks. ] ] -- ] Alex ] http://www.psg.com/~zinin ] ] ] _______________________________________________ ] Isis-wg mailing list ] Isis-wg@ietf.org ] https://www1.ietf.org/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Aug 6 14:13:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14912 for ; Fri, 6 Aug 2004 14:13:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt99P-0000jc-AJ; Fri, 06 Aug 2004 14:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bt975-0000Pu-U7 for isis-wg@megatron.ietf.org; Fri, 06 Aug 2004 14:06:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14602 for ; Fri, 6 Aug 2004 14:06:42 -0400 (EDT) Received: from bay2-f21.bay2.hotmail.com ([65.54.247.21] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bt9Aq-0002Av-8W for isis-wg@ietf.org; Fri, 06 Aug 2004 14:10:36 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 6 Aug 2004 11:06:11 -0700 Received: from 64.172.58.109 by by2fd.bay2.hotmail.msn.com with HTTP; Fri, 06 Aug 2004 18:06:11 GMT X-Originating-IP: [64.172.58.109] X-Originating-Email: [sboddapa@hotmail.com] X-Sender: sboddapa@hotmail.com From: "Suresh Boddapati" To: naiming@redback.com Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt Date: Fri, 06 Aug 2004 18:06:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Aug 2004 18:06:11.0991 (UTC) FILETIME=[0E882270:01C47BE0] X-Spam-Score: 2.4 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I think there are two questions to be answered here. 1) Is there an application where the data is large enough that it will not fit within one TLV? Note here we are talking about something that cannot be fit into a TLV using "additive" style like Mike mentioned. I believe Dimitri said that they had to get around the GMPLS problem by defining additional TLVs. I dont believe Dimitri said there is a problem currently. Dimitri, can you please elaborate on this? What is the diffserv data that you consider will require more than 255 bytes and cannot be intelligently broken down into multiple TLVs? 2) Suppose we assume that we have data that is large enough that it wont fit into one TLV which means the data is larger than 255 bytes. Why are we trying to solve it using a low byte and a high byte? Are you assuming that the data will not be larger than the most often used 1492 bytes of an ISIS LSP? The order of difference between 255 and 1492 (to be more precise 1469, after taking out 20 bytes of LSP header + 3 bytes for Type, low byte and high byte) is not too much. What if tomorrow there is a need to send 1500 bytes of data or more in an LSP because of some application. Your scheme will not work. If we are to conclude that there is a problem with sending large data in ISIS, then why dont we fix it once and for all by fragmenting the data and using fragment IDs for each chunk of the data in a new TLV, which then can be repeated as many times as desired. Then we dont even have to worry about backwards compatibility which your draft tries to deal with. We dont have to have these three modes; if an implementation does not support this new TLV, it will simply ignore it (and all occurrences of it). I would be happy to write this up. Heck, then we can even send MP3 files through ISIS :-) All said and done, it seems that we may be trying to solve a problem that does not yet exist. However, if we agree to the contrary, or we want to make this future proof, because we anticipate a problem in the future, then we should not try to solve this problem for an ISIS LSP alone. ISIS does not have fragmentation and reassembly like IP does. So to handle larger data, the solution needs to be something that can handle data that can span multiple LSPs. Suresh >From: Naiming Shen >To: Alex Zinin >CC: isis-wg@ietf.org >Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt >Date: Thu, 05 Aug 2004 16:35:41 -0700 > >Alex, > > ] A few comments I raised at the mic today: > ] > ] 1. One of the reasons that was mention was exhaustion of the TLV type > ] space. Given that we have only 36 allocations in the registry now, > ] I doubt this will be a problem any time soon. > >Agreed. But this code point is a side effect of the draft. I think anyone >would agree that if we take the trouble to change the length field, >the code field better to be changed at the same time. > > ] > ] 2. Another reason was the size of the TLV. If this becomes a problem, > ] my first question would be whether this is a good idea to announce > ] such info in ISIS and/or whether it is properly encoded. This is not > ] to say that we could never end up with having to announce something > ] bigger than 255, but I'd like to see an example of where this >becomes > ] a problem we can't get around. > >Ok, let me list some of the reasoning here, others can contribute too, > > - network transition is not easy, it can takes years to finish, for > all the boxes converge into the same capabilities. > > - a pure historical note: at the time we desgined the Multi-Topology > IS-IS, there was a choice to use the existing TLV 22 and 135. But the > major concern at the time was if there were multiple topologies using > TE (not even talking about GMPLS), then the 255 bytes of the TLV would > be a serious limitation and we could not make such a choice. Thus we > now have the TLV 222 and 235. > > - as Dimitri yesterday mentioned, in gmpls application usage, the > tlv limitation is a concern. > > - diffServ TE usage for isis, 'clasic TE' is only a special case in > diffsrv TE. diffserv TE can contain a lot more data. > > - when we have something like isis capability tlv, there will be various > 'features'/ 'capabilities' a system needs to announce, they could be > split into multiple tlvs. then there is a concern how to keep track > of the versions of the 'capability' changes if they spread over > multiple tlvs/packets. it would be much easier, if the capability > tlvs are kept within the same tlv, then there will be no mistake > how to read the newer/older version of changes. (this was heavily > discussed among the isis cap draft co-authors, and it was the trigger > for me(us) to revisit this isis tlv limitation issue) > >i don't believe that we don't have a problem currently. we may not >have a hard limit problem at hand right now, but why we are willing >to live with this limitation for isis, and why not create the capability >when the problem is still in a 'soft' state ? > > ] > ] 3. Naming mentioned in his slides that backwards-compatible deployment > ] is possible. I wasn't sure it was. Now that I re-read the draft, I'm > ] sure it is not possible. Routers not implementing this feature will > ] encounter a TLV parsing error, since the what they believe is the >1-octet > ] length field will contain wrong value for TLVs bigger than 255 >octets. > >during transitional tlv mode, a system is not allowed to generate this >extended tlv larger than the 255 octets. this is mentioned in the network >transition section of the draft. this is no different from the TE metric >transition, the wide metric can not have the value over 63. this is why >if we are going to move to this new scheme, better to do it long before >when >the >255 octect is really needed. > >thanks. > > ] > ] -- > ] Alex > ] http://www.psg.com/~zinin > ] > ] > ] _______________________________________________ > ] Isis-wg mailing list > ] Isis-wg@ietf.org > ] https://www1.ietf.org/mailman/listinfo/isis-wg > >- Naiming > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _________________________________________________________________ Discover the best of the best at MSN Luxury Living. http://lexus.msn.com/ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Aug 7 02:43:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08717 for ; Sat, 7 Aug 2004 02:43:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtKtz-0007tU-GU; Sat, 07 Aug 2004 02:41:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtKsN-0007lZ-EG for isis-wg@megatron.ietf.org; Sat, 07 Aug 2004 02:40:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08603 for ; Sat, 7 Aug 2004 02:40:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtKwE-0005Qe-LO for isis-wg@ietf.org; Sat, 07 Aug 2004 02:44:19 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BtKsI-000L2w-UE; Sat, 07 Aug 2004 06:40:17 +0000 Message-ID: <4114795E.9080204@psg.com> Date: Sat, 07 Aug 2004 08:40:30 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suresh Boddapati Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: naiming@redback.com, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Suresh Boddapati wrote: > I think there are two questions to be answered here. > > 1) Is there an application where the data is large enough that it will > not fit within one TLV? Note here we are talking about something that > cannot be fit into a TLV using "additive" style like Mike mentioned. I > believe Dimitri said that they had to get around the GMPLS problem by > defining additional TLVs. I dont believe Dimitri said there is a problem > currently. Dimitri, can you please elaborate on this? What is the > diffserv data that you consider will require more than 255 bytes and > cannot be intelligently broken down into multiple TLVs? the comment raised following the question whether there as ever been any application where data was so large that it would not fit within one TLV so that a dedicated TLV had to be defined; hence i pointed out to the SRLG TLV (Type 138) definition because the corr. SRLG sub-TLV would have not fit within the extended IS reachability TLV (Type 22) - now i am not aware of a topology that currently requires more than a single SRLG TLV > 2) Suppose we assume that we have data that is large enough that it wont > fit into one TLV which means the data is larger than 255 bytes. note that the maximum in the above was 255 octets minus 11 octets so effectively 244 octets > Why are > we trying to solve it using a low byte and a high byte? Are you assuming > that the data will not be larger than the most often used 1492 bytes of > an ISIS LSP? The order of difference between 255 and 1492 (to be more > precise 1469, after taking out 20 bytes of LSP header + 3 bytes for > Type, low byte and high byte) is not too much. What if tomorrow there is > a need to send 1500 bytes of data or more in an LSP because of some > application. Your scheme will not work. If we are to conclude that there > is a problem with sending large data in ISIS, then why dont we fix it > once and for all by fragmenting the data and using fragment IDs for each > chunk of the data in a new TLV, which then can be repeated as many times > as desired. Then we dont even have to worry about backwards > compatibility which your draft tries to deal with. We dont have to have > these three modes; if an implementation does not support this new TLV, > it will simply ignore it (and all occurrences of it). I would be happy > to write this up. Heck, then we can even send MP3 files through ISIS :-) > > All said and done, it seems that we may be trying to solve a problem > that does not yet exist. However, if we agree to the contrary, or we > want to make this future proof, because we anticipate a problem in the > future, then we should not try to solve this problem for an ISIS LSP > alone. ISIS does not have fragmentation and reassembly like IP does. So > to handle larger data, the solution needs to be something that can > handle data that can span multiple LSPs. > > Suresh > > >> From: Naiming Shen >> To: Alex Zinin >> CC: isis-wg@ietf.org >> Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt >> Date: Thu, 05 Aug 2004 16:35:41 -0700 >> >> Alex, >> >> ] A few comments I raised at the mic today: >> ] >> ] 1. One of the reasons that was mention was exhaustion of the TLV type >> ] space. Given that we have only 36 allocations in the registry now, >> ] I doubt this will be a problem any time soon. >> >> Agreed. But this code point is a side effect of the draft. I think anyone >> would agree that if we take the trouble to change the length field, >> the code field better to be changed at the same time. >> >> ] >> ] 2. Another reason was the size of the TLV. If this becomes a problem, >> ] my first question would be whether this is a good idea to announce >> ] such info in ISIS and/or whether it is properly encoded. This is >> not >> ] to say that we could never end up with having to announce something >> ] bigger than 255, but I'd like to see an example of where this >> becomes >> ] a problem we can't get around. >> >> Ok, let me list some of the reasoning here, others can contribute too, >> >> - network transition is not easy, it can takes years to finish, for >> all the boxes converge into the same capabilities. >> >> - a pure historical note: at the time we desgined the Multi-Topology >> IS-IS, there was a choice to use the existing TLV 22 and 135. But the >> major concern at the time was if there were multiple topologies using >> TE (not even talking about GMPLS), then the 255 bytes of the TLV would >> be a serious limitation and we could not make such a choice. Thus we >> now have the TLV 222 and 235. >> >> - as Dimitri yesterday mentioned, in gmpls application usage, the >> tlv limitation is a concern. >> >> - diffServ TE usage for isis, 'clasic TE' is only a special case in >> diffsrv TE. diffserv TE can contain a lot more data. >> >> - when we have something like isis capability tlv, there will be various >> 'features'/ 'capabilities' a system needs to announce, they could be >> split into multiple tlvs. then there is a concern how to keep track >> of the versions of the 'capability' changes if they spread over >> multiple tlvs/packets. it would be much easier, if the capability >> tlvs are kept within the same tlv, then there will be no mistake >> how to read the newer/older version of changes. (this was heavily >> discussed among the isis cap draft co-authors, and it was the trigger >> for me(us) to revisit this isis tlv limitation issue) >> >> i don't believe that we don't have a problem currently. we may not >> have a hard limit problem at hand right now, but why we are willing >> to live with this limitation for isis, and why not create the capability >> when the problem is still in a 'soft' state ? >> >> ] >> ] 3. Naming mentioned in his slides that backwards-compatible deployment >> ] is possible. I wasn't sure it was. Now that I re-read the draft, >> I'm >> ] sure it is not possible. Routers not implementing this feature will >> ] encounter a TLV parsing error, since the what they believe is >> the 1-octet >> ] length field will contain wrong value for TLVs bigger than 255 >> octets. >> >> during transitional tlv mode, a system is not allowed to generate this >> extended tlv larger than the 255 octets. this is mentioned in the network >> transition section of the draft. this is no different from the TE metric >> transition, the wide metric can not have the value over 63. this is why >> if we are going to move to this new scheme, better to do it long >> before when >> the >255 octect is really needed. >> >> thanks. >> >> ] >> ] -- >> ] Alex >> ] http://www.psg.com/~zinin >> ] >> ] >> ] _______________________________________________ >> ] Isis-wg mailing list >> ] Isis-wg@ietf.org >> ] https://www1.ietf.org/mailman/listinfo/isis-wg >> >> - Naiming >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg > > > _________________________________________________________________ > Discover the best of the best at MSN Luxury Living. http://lexus.msn.com/ > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > . > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Aug 7 03:37:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11036 for ; Sat, 7 Aug 2004 03:37:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtLjn-00063J-PK; Sat, 07 Aug 2004 03:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtLiX-0005ri-N1 for isis-wg@megatron.ietf.org; Sat, 07 Aug 2004 03:34:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10956 for ; Sat, 7 Aug 2004 03:34:12 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtLmO-0006Aw-KH for isis-wg@ietf.org; Sat, 07 Aug 2004 03:38:13 -0400 Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc11) with SMTP id <2004080707333701300ooqtte> (Authid: li.tony); Sat, 7 Aug 2004 07:33:41 +0000 In-Reply-To: <4114795E.9080204@psg.com> References: <4114795E.9080204@psg.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <154E3AD5-E844-11D8-98E8-000A95D1475E@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt Date: Sat, 7 Aug 2004 00:33:32 -0700 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: naiming@redback.com, Suresh Boddapati , isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit > the comment raised following the question whether there as ever been > any application where data was so large that it would not fit within > one TLV so that a dedicated TLV had to be defined; hence i pointed out > to the SRLG TLV (Type 138) definition because the corr. SRLG sub-TLV > would have not fit within the extended IS reachability TLV (Type 22) - > now i am not aware of a topology that currently requires more than a > single SRLG TLV > > > note that the maximum in the above was 255 octets minus 11 octets so > effectively 244 octets > Can I point out a grody coding trick? If you have a large amount of data (that still fits in an LSP fragment), and you have two TLV code points, then you can basically encode LOTS of bytes pretty easily. The first code point is an existing code point that you need to extend. The second is the code point for "More of the same". The semantics of this TLV is that the value of this TLV should be concatenated to the previous TLV before processing it. Recurse as necessary. Note that the "More of the same" TLV can be used with just about any other existing TLV type, so it's really only ONE additional code point above and beyond what we have today. Extending this across fragments is a complication that is left to the reader. ;-) If it will cease these discussions, I would be more than happy to write the draft.... But as we have many free code points, I don't think we're in a rush. Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Aug 8 03:00:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03810 for ; Sun, 8 Aug 2004 03:00:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bthcu-0001ER-An; Sun, 08 Aug 2004 02:57:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BthZw-0000sy-HG for isis-wg@megatron.ietf.org; Sun, 08 Aug 2004 02:54:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03585 for ; Sun, 8 Aug 2004 02:54:47 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bthdz-0001EW-Op for isis-wg@ietf.org; Sun, 08 Aug 2004 02:59:01 -0400 Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i786sFJ6008673 for ; Sat, 7 Aug 2004 23:54:15 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I2400A0183KJ2@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for isis-wg@ietf.org; Sun, 08 Aug 2004 02:54:15 -0400 (EDT) Received: from sun.com (vpn-129-147-153-140.Central.Sun.COM [129.147.153.140]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I2400COD8IE7L@bur-mail2.east.sun.com>; Sun, 08 Aug 2004 02:54:15 -0400 (EDT) Date: Sat, 07 Aug 2004 23:54:16 -0700 From: Radia Perlman Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt In-reply-to: <154E3AD5-E844-11D8-98E8-000A95D1475E@tony.li> To: Tony Li Message-id: <4115CE18.9000007@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 References: <4114795E.9080204@psg.com> <154E3AD5-E844-11D8-98E8-000A95D1475E@tony.li> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7BIT Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7BIT I guess you'd have to be careful if you extend an existing T this way that it wouldn't confuse existing routers that understand the existing T and ignore the rest of the data associated with it (since they wouldn't understand the "more of the same"). So as long as it would be OK for them to process only the initial part. Hard to know without an existing example, since it might be possible to just have multiple instances of the "T" that the old routers understand. Radia Tony Li wrote: >> > > > Can I point out a grody coding trick? > > If you have a large amount of data (that still fits in an LSP > fragment), and you have > two TLV code points, then you can basically encode LOTS of bytes > pretty easily. The > first code point is an existing code point that you need to extend. > The second > is the code point for "More of the same". The semantics of this TLV > is that the > value of this TLV should be concatenated to the previous TLV before > processing it. > Recurse as necessary. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Aug 8 09:32:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20570 for ; Sun, 8 Aug 2004 09:32:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Btnie-0006pX-OH; Sun, 08 Aug 2004 09:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Btngq-0006cr-Od for isis-wg@megatron.ietf.org; Sun, 08 Aug 2004 09:26:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20261 for ; Sun, 8 Aug 2004 09:26:19 -0400 (EDT) Received: from bay2-f4.bay2.hotmail.com ([65.54.247.4] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Btnky-0002ae-LS for isis-wg@ietf.org; Sun, 08 Aug 2004 09:30:37 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 8 Aug 2004 06:25:48 -0700 Received: from 64.160.52.221 by by2fd.bay2.hotmail.msn.com with HTTP; Sun, 08 Aug 2004 13:25:48 GMT X-Originating-IP: [64.160.52.221] X-Originating-Email: [sboddapa@hotmail.com] X-Sender: sboddapa@hotmail.com From: "Suresh Boddapati" To: tony.li@tony.li, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt Date: Sun, 08 Aug 2004 13:25:48 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2004 13:25:48.0914 (UTC) FILETIME=[3805CD20:01C47D4B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA20261 Cc: naiming@redback.com, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Tony, An existing TLV can already nicely fit within 255 bytes. I dont believe w= e=20 need a scheme to extend the length of existing TLVs. I thought the proble= m=20 that Naiming set out to solve was for new TLVs. Like Alex pointed out, = we=20 have enough TLV codepoints. If we solve the length problem for TLVs in=20 general, we can extend existing TLVs (even all of them, if necessary), by= =20 defining new ones which copy the whole information from older TLVs (or re= org=20 it intelligently like we did for wide metrics) and append the new=20 information using sub TLVs if necessary. Also, ordering of information across TLVs is not a good idea. The very id= ea=20 of TLVs is not to have a relation between one TLV and the other, each TLV= =20 being independent of the other, as far as encoding is concerned. It also=20 enables for optimum packing. If I can squeeze in 4 bytes of a different T= LV=20 in an LSP fragment because I cannot encode the "More of the same" TLV (du= e=20 to lack of space), I should be able to do that. Imposing an ordering=20 restriction between TLVs takes away this advantage. We do not say TLV X m= ust=20 follow TLV Y today in ISIS. Nor do we say the first instance of TLV X mus= t=20 precede the second instance of TLV X, which the "More of the same" TLV wi= ll=20 impose. We dont want a new scheme to impose such a restriction on=20 encoding/decoding rules. Plus, extending it to multiple LSPs will be a=20 "complication" as you point out. That will impose an ordering relation=20 between data in LSPs as well. Data that will not fit in LSP fragment 1 wi= ll=20 have to be encoded in LSP fragment 2. The essential drawback here is that= =20 the data in the TLV is not self identifying, it is saying "More of the sa= me"=20 which immediately requires a relation to "same", i.e. needs to be identif= ied=20 from information immediately preceding it (either in the TLV preceding it= or=20 LSP preceding it). If you read my scheme, it will achieve the desired without the above issu= e. =20 Nothing new, just applying the concept of fragmentation and reassembly to= =20 ISIS. It takes away the ordering restriction by explicitly using a fragme= nt=20 id associated with the data (which would, to be more precise, need its o= wn=20 data or context id of course, either as part of the fragment ID or=20 separately, in order to distinguish between two identical fragment numbe= rs=20 associated with two different contexts of data). Like I said earlier, I c= an=20 draft this up, but the bigger question remains. Do we really need to solv= e=20 this problem? Suresh >From: Tony Li >To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be >CC: Suresh Boddapati , naiming@redback.com,=20 >isis-wg@ietf.org >Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt >Date: Sat, 7 Aug 2004 00:33:32 -0700 > >>the comment raised following the question whether there as ever been an= y=20 >>application where data was so large that it would not fit within one TL= V=20 >>so that a dedicated TLV had to be defined; hence i pointed out to the S= RLG=20 >>TLV (Type 138) definition because the corr. SRLG sub-TLV would have not= =20 >>fit within the extended IS reachability TLV (Type 22) - now i am not aw= are=20 >>of a topology that currently requires more than a single SRLG TLV >> >> >>note that the maximum in the above was 255 octets minus 11 octets so=20 >>effectively 244 octets >> > > >Can I point out a grody coding trick? > >If you have a large amount of data (that still fits in an LSP fragment),= =20 >and you have >two TLV code points, then you can basically encode LOTS of bytes pretty=20 >easily. The >first code point is an existing code point that you need to extend. The= =20 >second >is the code point for "More of the same". The semantics of this TLV is=20 >that the >value of this TLV should be concatenated to the previous TLV before=20 >processing it. >Recurse as necessary. > >Note that the "More of the same" TLV can be used with just about any oth= er=20 >existing >TLV type, so it's really only ONE additional code point above and beyond= =20 >what we >have today. > >Extending this across fragments is a complication that is left to the=20 >reader. ;-) > >If it will cease these discussions, I would be more than happy to write = the=20 >draft.... >But as we have many free code points, I don't think we're in a rush. > >Tony > _________________________________________________________________ Don=92t just search. Find. Check out the new MSN Search!=20 http://search.msn.click-url.com/go/onm00200636ave/direct/01/ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Aug 9 14:38:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25383 for ; Mon, 9 Aug 2004 14:38:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEf0-0002gF-Sr; Mon, 09 Aug 2004 14:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuESm-0005Qe-MN for isis-wg@megatron.ietf.org; Mon, 09 Aug 2004 14:01:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20509 for ; Mon, 9 Aug 2004 14:01:35 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuEX9-0002G7-1N for isis-wg@ietf.org; Mon, 09 Aug 2004 14:06:08 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9B0EC640370; Mon, 9 Aug 2004 11:01:33 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06316-05; Mon, 9 Aug 2004 11:01:33 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 29E4F64036E; Mon, 9 Aug 2004 11:01:32 -0700 (PDT) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id LAA29617; Mon, 9 Aug 2004 11:01:31 -0700 (PDT) Message-Id: <200408091801.LAA29617@redback.com> To: isis-wg@ietf.org Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt In-reply-to: Mail from "Suresh Boddapati" dated Sun, 08 Aug 2004 13:25:48 -0000 Date: Mon, 09 Aug 2004 11:01:31 -0700 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: dimitri.papadimitriou@alcatel.be, Radia.Perlman@Sun.COM, tony.li@tony.li, naiming@redback.com, Suresh Boddapati X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org It seems we have two basic questions, (1) do we have a problem of the current isis TLV ? (2) if positive on (1), then how to do it nicely ? For (1), I stated the problem in my presentation, and also an email to this working group last week. I think we have already 'hit' this problem a couple of times, even though it's a 'soft' problem, not a 'hard' problem. so we have some ways to get around in some cases, while in other it much complicated the protocol scheme. But it's up to this working group to decide. For (2), we seems have a couple of ways to do it, - the draft on exteneded-tlv - Mike mentioned using a 'sub-tlv' to indicate a 'continue'; while we were designing the MT extension, Derek Yeung also mentioned this. - Tony's way to have a new TLV 'continuing' on the old TLV. - Suresh's way to have two TLVs with copying old TLV onto this new TLV, then do 'continue' among TLVs. >From the all above, none of them can be 'backwards compatible' without introduce transition mechanism. extended-tlv scheme gives advantage of without multiple TLVs within the same LSP fragment, which is a huge benefit. It can simplify lots of protocol logic. extended-tlv scheme is also the only one address the code-space issue. yes, there may not need to be concerned right now, but there is also no reason not to extend this code space if we are making changes the the isis TLVs. I don't think we should start to worry about the LSP fragment size, we have enough to go. We can extend the fragmantation capability later when we need this, but this fragmentation is orthogonal to the TLV extension, they don't have to be done at the same time. thanks. - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Aug 9 18:29:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27648 for ; Mon, 9 Aug 2004 18:29:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuIXl-0000j9-VW; Mon, 09 Aug 2004 18:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuIG2-000479-FW for isis-wg@megatron.ietf.org; Mon, 09 Aug 2004 18:04:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24265 for ; Mon, 9 Aug 2004 18:04:39 -0400 (EDT) Received: from bay2-f42.bay2.hotmail.com ([65.54.247.42] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuIKR-0003Oq-17 for isis-wg@ietf.org; Mon, 09 Aug 2004 18:09:16 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Aug 2004 15:04:09 -0700 Received: from 64.47.48.10 by by2fd.bay2.hotmail.msn.com with HTTP; Mon, 09 Aug 2004 22:04:09 GMT X-Originating-IP: [64.47.48.10] X-Originating-Email: [sboddapa@hotmail.com] X-Sender: sboddapa@hotmail.com From: "Suresh Boddapati" To: naiming@redback.com, isis-wg@ietf.org Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt Date: Mon, 09 Aug 2004 22:04:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Aug 2004 22:04:09.0753 (UTC) FILETIME=[CBFAF890:01C47E5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dimitri.papadimitriou@alcatel.be, Radia.Perlman@Sun.COM, tony.li@tony.li X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > >For (2), we seems have a couple of ways to do it, > > - the draft on exteneded-tlv > - Mike mentioned using a 'sub-tlv' to indicate a 'continue'; while > we were designing the MT extension, Derek Yeung also mentioned this. > - Tony's way to have a new TLV 'continuing' on the old TLV. > - Suresh's way to have two TLVs with copying old TLV onto this new TLV, > then do 'continue' among TLVs. > >From the all above, none of them can be 'backwards compatible' without >introduce transition mechanism. extended-tlv scheme gives advantage >of without multiple TLVs within the same LSP fragment, which is a >huge benefit. It can simplify lots of protocol logic. extended-tlv >scheme is also the only one address the code-space issue. yes, there >may not need to be concerned right now, but there is also no reason >not to extend this code space if we are making changes the the isis >TLVs. > Naiming, looks like you have not read my scheme in detail. My scheme does not have any backwards compatibility issue. Yours does and that's why you are proposing a transition mechanism by requiring that the high byte be zero before migrating the network to using larger than 255 byte TLVs. My scheme is very simple. You define a new TLV, call it the fragment ID TLV, it tells you what is being fragmented (the ID) and how many fragments are there. Another TLV is the fragment TLV, which can be repeated as many times as desired. It will contain the ID, the fragment number, how long the fragment is and the data. There is no explicit "continue" in here. You can encode any fragment anywhere in any LSP. From the fragment ID in the fragment and the fragment number, you can put the data together. I dont see what the backwards compatibilty issue here is. If an implementation does not understand these TLVs, it just ignores them. There is no transition mechanism required. >I don't think we should start to worry about the LSP fragment size, >we have enough to go. We can extend the fragmantation capability later >when we need this, but this fragmentation is orthogonal to the >TLV extension, they don't have to be done at the same time. > I have trouble understanding your argument. You are suggesting that "there is no hard problem with the TLV length today, but let us fix it anyway. But we dont want to fix this problem once and for all and extend this to multiple LSPs, because there is no problem today that requires this". You are trying to split this into two problems: 1) TLV length within one LSP problem and 2) TLV length spanning multiple LSPs problem. So tomorrow if there is a problem with multiple LSPs, then you want to add a new scheme, in addition to your scheme. Why do we want to use two different schemes to address these two problems when one will address both? Suresh _________________________________________________________________ Get ready for school! Find articles, homework help and more in the Back to School Guide! http://special.msn.com/network/04backtoschool.armx _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 10 01:28:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04763 for ; Tue, 10 Aug 2004 01:28:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuP3z-0004CH-Eu; Tue, 10 Aug 2004 01:20:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuOyM-0002vd-L3 for isis-wg@megatron.ietf.org; Tue, 10 Aug 2004 01:14:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03353 for ; Tue, 10 Aug 2004 01:14:53 -0400 (EDT) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuP2q-0003xJ-5N for isis-wg@ietf.org; Tue, 10 Aug 2004 01:19:32 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 97D9B3DCC8C; Mon, 9 Aug 2004 22:14:16 -0700 (PDT) In-Reply-To: <200408091801.LAA29617@redback.com> References: <200408091801.LAA29617@redback.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20B40F82-EA8C-11D8-AB2A-00039303E9E2@rawdofmt.org> Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt Date: Mon, 9 Aug 2004 22:14:17 -0700 To: Naiming Shen X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: "ISIS-WG \(E-mail\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Aug 9, 2004, at 11:01 AM, Naiming Shen wrote: > It seems we have two basic questions, > > (1) do we have a problem of the current isis TLV ? > (2) if positive on (1), then how to do it nicely ? I would prefer if we could please show some concrete examples of 1. I believe this was the consensus during the IETF WG slot. I counted at few people that came to the mic, and a few more that talked with me privately, who seemed to think there is no need for this draft. Conversely I didn't notice any one in support. We agreed in the meeting that concrete examples of a real problem should be provided on the mailing list. I think it is important that we not get mired down in discussing what the best solution to a non-problem is. Chris. > For (1), I stated the problem in my presentation, and also an email > to this working group last week. I think we have already 'hit' this > problem a couple of times, even though it's a 'soft' problem, not a > 'hard' problem. so we have some ways to get around in some cases, > while in other it much complicated the protocol scheme. But it's > up to this working group to decide. > > For (2), we seems have a couple of ways to do it, _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 10 13:43:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16487 for ; Tue, 10 Aug 2004 13:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buaaw-0000hS-3O; Tue, 10 Aug 2004 13:39:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuaJQ-0005Ex-Rj for isis-wg@megatron.ietf.org; Tue, 10 Aug 2004 13:21:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14190 for ; Tue, 10 Aug 2004 13:21:21 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuaNy-0000oV-LI for isis-wg@ietf.org; Tue, 10 Aug 2004 13:26:09 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 05F5168E115; Tue, 10 Aug 2004 10:21:19 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16997-10; Tue, 10 Aug 2004 10:21:18 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 8C7D968E114; Tue, 10 Aug 2004 10:21:18 -0700 (PDT) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id KAA16739; Tue, 10 Aug 2004 10:21:17 -0700 (PDT) Message-Id: <200408101721.KAA16739@redback.com> To: "Suresh Boddapati" Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt In-reply-to: Mail from "Suresh Boddapati" dated Mon, 09 Aug 2004 22:04:09 -0000 Date: Tue, 10 Aug 2004 10:21:16 -0700 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: naiming@redback.com, Radia.Perlman@Sun.COM, tony.li@tony.li, isis-wg@ietf.org, dimitri.papadimitriou@alcatel.be X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Suresh, ] > ] >For (2), we seems have a couple of ways to do it, ] > ] > - the draft on exteneded-tlv ] > - Mike mentioned using a 'sub-tlv' to indicate a 'continue'; while ] > we were designing the MT extension, Derek Yeung also mentioned this. ] > - Tony's way to have a new TLV 'continuing' on the old TLV. ] > - Suresh's way to have two TLVs with copying old TLV onto this new TLV, ] > then do 'continue' among TLVs. ] > ] >From the all above, none of them can be 'backwards compatible' without ] >introduce transition mechanism. extended-tlv scheme gives advantage ] >of without multiple TLVs within the same LSP fragment, which is a ] >huge benefit. It can simplify lots of protocol logic. extended-tlv ] >scheme is also the only one address the code-space issue. yes, there ] >may not need to be concerned right now, but there is also no reason ] >not to extend this code space if we are making changes the the isis ] >TLVs. ] > ] Naiming, looks like you have not read my scheme in detail. My scheme does ] not have any backwards compatibility issue. Yours does and that's why you ] are proposing a transition mechanism by requiring that the high byte be zero ] before migrating the network to using larger than 255 byte TLVs. ] ] My scheme is very simple. You define a new TLV, call it the fragment ID TLV ] it tells you what is being fragmented (the ID) and how many fragments are ] there. Another TLV is the fragment TLV, which can be repeated as many times ] as desired. It will contain the ID, the fragment number, how long the ] fragment is and the data. There is no explicit "continue" in here. You can ] encode any fragment anywhere in any LSP. From the fragment ID in the ] fragment and the fragment number, you can put the data together. I dont see ] what the backwards compatibilty issue here is. If an implementation does not ] understand these TLVs, it just ignores them. There is no transition ] mechanism required. ] I don't think it's 'simple'. First of all, you introduce some new items into isis TLV, fragment ID and fragment number as used in fragmented IP packets; Second, if you don't apply any rules on them, those fragments can be flooted anywhere, with flooding delay, purge of isis packets, it would not be easy to handle; Third, if there is a router restart/graceful-or-not, it needs to remember not to use the same fragment number, otherwise the new packets would have chance to mix with old packets which can generate some unexpected data(value field); Fourth, as Tony pointed out, "Extending this across fragments is a complication that is left to the reader. ;-) " and there is a reason for that;-) when the TLV fragments are long enough to push some of the fragment TLVs over to a different LSP, there is no reason to believe our flooding will deliver the older and newer LSPs in order, and there is no way to tell how to piece them together without corrupt the data inside the entire TLV. when there are two identical fragment-number in two different packets, you can tell by the sequence-numbers which one is the most recent one. you may also need to have checksum included for each TLV to ensure the integrity of the data. Fifth, it certainly has more overhead comparing to other suggested schemes interms of encoded octets and the protocol complication. ] >I don't think we should start to worry about the LSP fragment size, ] >we have enough to go. We can extend the fragmantation capability later ] >when we need this, but this fragmentation is orthogonal to the ] >TLV extension, they don't have to be done at the same time. ] > ] I have trouble understanding your argument. You are suggesting that "there ] is no hard problem with the TLV length today, but let us fix it anyway. But ] we dont want to fix this problem once and for all and extend this to ] multiple LSPs, because there is no problem today that requires this". You ] are trying to split this into two problems: 1) TLV length within one LSP ] problem and 2) TLV length spanning multiple LSPs problem. So tomorrow if ] there is a problem with multiple LSPs, then you want to add a new scheme, in ] addition to your scheme. Why do we want to use two different schemes to ] address these two problems when one will address both? My logic is simple, lets solve the problem in a reasonable way, as long as you are not encoding MP3 over isis packets, we will have a long way to go for 1493 bytes. On the other hand, if people are auguing we don't have problem for 254 bytes, why we are so concerned about over 1493 bytes? As i mentioned above, it's not trivial to handle the data across the packet boundary. We had the same dicussion in the isis capability draft regarding capability spread over TLV boundary and over packet boundary, it needs to have a lot of machanery to deal with them properly. we don't need to solve this problem right now. The fragmemtation I refer to is not the LSP fragments, I meant have the isis packets size grow over 1493 bytes and fragment/re-assemble the LSP fragments, then your scheme may be useful then ;-) thanks. - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 10 14:09:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18212 for ; Tue, 10 Aug 2004 14:09:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buaxj-0006L9-Lu; Tue, 10 Aug 2004 14:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuavN-0005Wo-91 for isis-wg@megatron.ietf.org; Tue, 10 Aug 2004 14:00:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17600 for ; Tue, 10 Aug 2004 14:00:35 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buazu-0001jR-OK for isis-wg@ietf.org; Tue, 10 Aug 2004 14:05:22 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id CFAB368E119; Tue, 10 Aug 2004 11:00:32 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24848-02; Tue, 10 Aug 2004 11:00:32 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id D617B68E11E; Tue, 10 Aug 2004 11:00:19 -0700 (PDT) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id LAA17256; Tue, 10 Aug 2004 11:00:18 -0700 (PDT) Message-Id: <200408101800.LAA17256@redback.com> To: Christian Hopps Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt In-reply-to: Mail from Christian Hopps dated Mon, 09 Aug 2004 22:14:17 PDT <20B40F82-EA8C-11D8-AB2A-00039303E9E2@rawdofmt.org> Date: Tue, 10 Aug 2004 11:00:18 -0700 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Naiming Shen , "ISIS-WG \(E-mail\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Chris, ] On Aug 9, 2004, at 11:01 AM, Naiming Shen wrote: ] > It seems we have two basic questions, ] > ] > (1) do we have a problem of the current isis TLV ? ] > (2) if positive on (1), then how to do it nicely ? ] ] I would prefer if we could please show some concrete examples of 1. I ] believe this was the consensus during the IETF WG slot. I counted at ] few people that came to the mic, and a few more that talked with me ] privately, who seemed to think there is no need for this draft. ] Conversely I didn't notice any one in support. We agreed in the meeting ] that concrete examples of a real problem should be provided on the ] mailing list. I personally don't have experience a system generating TLV over 253 bytes yet; the same experience i have is we have not running out IPv4 address space yet; and the same experience i have is i don't know any ISPs running out LSP fragment yet(besides someone leaked entire BGP routes into isis, but that would not be a good example); the same experience i have noticed RSVP still have enough class numbers and way enough c-types. But I do have experience that when some new service is defined, this 255 limit is a concern, and it usually ended up with picking a different TLV code. Not only this waste code space, but also complicate the protocol design. I gave some examples in my previous email under this thread(the 'concrete' examples i have), and most recent one is about the capability TLV handling over multiple TLVs, and we simply don't have a good solution for that(see the cap draft discussion thread). ] ] I think it is important that we not get mired down in discussing what ] the best solution to a non-problem is. ] agreed. thanks. ] Chris. ] ] > For (1), I stated the problem in my presentation, and also an email ] > to this working group last week. I think we have already 'hit' this ] > problem a couple of times, even though it's a 'soft' problem, not a ] > 'hard' problem. so we have some ways to get around in some cases, ] > while in other it much complicated the protocol scheme. But it's ] > up to this working group to decide. ] > ] > For (2), we seems have a couple of ways to do it, ] - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 10 14:33:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19628 for ; Tue, 10 Aug 2004 14:33:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BubH2-0001Wf-UM; Tue, 10 Aug 2004 14:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BubEa-0000vE-8S for isis-wg@megatron.ietf.org; Tue, 10 Aug 2004 14:20:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18820 for ; Tue, 10 Aug 2004 14:20:26 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BubJ9-00025F-QP for isis-wg@ietf.org; Tue, 10 Aug 2004 14:25:13 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i7AIJpBm090487; Tue, 10 Aug 2004 11:19:51 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i7AIJne55554; Tue, 10 Aug 2004 11:19:49 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <200408101721.KAA16739@redback.com> References: <200408101721.KAA16739@redback.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt Date: Tue, 10 Aug 2004 12:19:43 -0600 To: Naiming Shen X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: dimitri.papadimitriou@alcatel.be, Radia.Perlman@Sun.COM, tony.li@tony.li, isis-wg@ietf.org, Suresh Boddapati X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Once again, I haven't been paying a great deal of attention to the particular problem being addressed, but once again that doesn't stop me from weighing in (and forgive me if one of the other fossils already made the same points.) One of the architectural aspects of LSPs in IS-IS is that they are intended to be idempotent, with no interdependence between LSP "fragments" (an unfortunate choice of nomenclature, as this carries too much semantic baggage from IP.) The only exception is a dependence on the existence of LSP fragment zero. There is an expectation that the database is always internally consistent even while in flux; at worst there may be stale or missing routes for a brief period of time, and that updates to the database are effectively atomic. Each "fragment" is flooded, built, and rebuilt independently and without regard to ordering, and the flooding process is almost guaranteed to add a bunch of entropy as the flood moves across the network. Any scheme which depends on multiple fragments to be consistent in any database at any instant in time is arguably broken, because there will *always* be some period in which they are not consistent; this inconsistency can last for an arbitrarily long time. The consistency issue can of course be addressed with TLV-internal sequencing hacks, which would require implementations to play games when not all of the interdependent elements have arrived--the side effects of this could be pretty ugly, as information would effectively flap every time it is updated, and updates stop being anything resembling atomic. Any scheme which relies on LSP arrival ordering is, of course, so broken as to not be worth mentioning. If the issue at hand is that there is monolithic information that cannot fit in 253 bytes (but can fit within 1400mumble), having interdependent (and perhaps order-dependent) TLVs within a single LSP is unavoidable and a little gross, but not terrible (IMHO). If there is monolithic information that is too large to fit within a single LSP, perhaps IS-IS (which is now almost old enough to vote) is not the right vehicle. There is a balance between making things "future-proof" and in trying to solve problems that do not exist (yet or perhaps ever.) If it's the case that the problem trying to be solved can be done within the confines of a single LSP, my leaning would be to solve that problem and not try to solve the arbitrarily-large-data problem (which can always be addressed later if it turns out to be real) as it unnecessarily torques the protocol architecture. --Dave _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 10 14:58:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20866 for ; Tue, 10 Aug 2004 14:58:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bubl6-00077l-8Z; Tue, 10 Aug 2004 14:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buben-0005X6-27 for isis-wg@megatron.ietf.org; Tue, 10 Aug 2004 14:47:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20356 for ; Tue, 10 Aug 2004 14:47:31 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BubjL-0002Xx-Hd for isis-wg@ietf.org; Tue, 10 Aug 2004 14:52:18 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 10 Aug 2004 14:55:35 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7AIkpAU015340; Tue, 10 Aug 2004 14:46:51 -0400 (EDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-206-181.cisco.com [64.102.206.181]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BBE31580; Tue, 10 Aug 2004 11:46:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20040810140132.024d5678@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Aug 2004 14:46:29 -0400 To: Naiming Shen , "Suresh Boddapati" From: Jeff Learman Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt In-Reply-To: <200408101721.KAA16739@redback.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: naiming@redback.com, Radia.Perlman@Sun.COM, tony.li@tony.li, isis-wg@ietf.org, dimitri.papadimitriou@alcatel.be X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org If it ain't broke, don't fix it. One of the more successful aspects of ISIS has been the extensibility of the protocol due to the simple TLV scheme. Let's not break existing implementations by changing the length field for TLV tuples. Suresh's scheme works for items that fit in a single LSP. I wouldn't object to it if it is specifically limited to that case. Sure, it's not the best solution if we were starting fresh defining a new protocol, but it doesn't cause compatibility problems. For spanning multiple LSPs, we would need a sequence number or checksum scheme to validate the integrity of the whole sequence of segments. But since there's no need for it, I'm certainly not inclined to do the work. In any case, it could involve yet another TLV. If someone came up with a workable scheme and demonstrated it in a complex case, I wouldn't object to that either. I do object to any change that causes incompatibility between implementation versions, regardless of whether there's a transition solution. Such solutions should be reserved for very important problems, when there's no other way. Just my $0.02. I don't represent Cisco in these matters. Regards, Jeff At 01:21 PM 8/10/2004, Naiming Shen wrote: >Suresh, > > ] > > ] >For (2), we seems have a couple of ways to do it, > ] > > ] > - the draft on exteneded-tlv > ] > - Mike mentioned using a 'sub-tlv' to indicate a 'continue'; while > ] > we were designing the MT extension, Derek Yeung also mentioned this. > ] > - Tony's way to have a new TLV 'continuing' on the old TLV. > ] > - Suresh's way to have two TLVs with copying old TLV onto this new TLV, > ] > then do 'continue' among TLVs. > ] > > ] >From the all above, none of them can be 'backwards compatible' without > ] >introduce transition mechanism. extended-tlv scheme gives advantage > ] >of without multiple TLVs within the same LSP fragment, which is a > ] >huge benefit. It can simplify lots of protocol logic. extended-tlv > ] >scheme is also the only one address the code-space issue. yes, there > ] >may not need to be concerned right now, but there is also no reason > ] >not to extend this code space if we are making changes the the isis > ] >TLVs. > ] > > ] Naiming, looks like you have not read my scheme in detail. My scheme does > ] not have any backwards compatibility issue. Yours does and that's why you > ] are proposing a transition mechanism by requiring that the high byte be zero > ] before migrating the network to using larger than 255 byte TLVs. > ] > ] My scheme is very simple. You define a new TLV, call it the fragment ID TLV > ] it tells you what is being fragmented (the ID) and how many fragments are > ] there. Another TLV is the fragment TLV, which can be repeated as many times > ] as desired. It will contain the ID, the fragment number, how long the > ] fragment is and the data. There is no explicit "continue" in here. You can > ] encode any fragment anywhere in any LSP. From the fragment ID in the > ] fragment and the fragment number, you can put the data together. I dont see > ] what the backwards compatibilty issue here is. If an implementation does not > ] understand these TLVs, it just ignores them. There is no transition > ] mechanism required. > ] > >I don't think it's 'simple'. > > First of all, you introduce some new items into isis TLV, fragment ID > and fragment number as used in fragmented IP packets; > Second, if you don't apply any rules on them, those fragments can be > flooted anywhere, with flooding delay, purge of isis packets, it would > not be easy to handle; > Third, if there is a router restart/graceful-or-not, it needs to > remember not to use the same fragment number, otherwise the new > packets would have chance to mix with old packets which can generate > some unexpected data(value field); > Fourth, as Tony pointed out, "Extending this across fragments is a > complication that is left to the reader. ;-) " and there is a reason > for that;-) when the TLV fragments are long enough to push some > of the fragment TLVs over to a different LSP, there is no reason > to believe our flooding will deliver the older and newer LSPs in > order, and there is no way to tell how to piece them together > without corrupt the data inside the entire TLV. when there are two > identical fragment-number in two different packets, you can tell > by the sequence-numbers which one is the most recent one. you may > also need to have checksum included for each TLV to ensure the > integrity of the data. > Fifth, it certainly has more overhead comparing to other suggested > schemes interms of encoded octets and the protocol complication. > > ] >I don't think we should start to worry about the LSP fragment size, > ] >we have enough to go. We can extend the fragmantation capability later > ] >when we need this, but this fragmentation is orthogonal to the > ] >TLV extension, they don't have to be done at the same time. > ] > > ] I have trouble understanding your argument. You are suggesting that "there > ] is no hard problem with the TLV length today, but let us fix it anyway. But > ] we dont want to fix this problem once and for all and extend this to > ] multiple LSPs, because there is no problem today that requires this". You > ] are trying to split this into two problems: 1) TLV length within one LSP > ] problem and 2) TLV length spanning multiple LSPs problem. So tomorrow if > ] there is a problem with multiple LSPs, then you want to add a new scheme, in > ] addition to your scheme. Why do we want to use two different schemes to > ] address these two problems when one will address both? > >My logic is simple, lets solve the problem in a reasonable way, as long as >you are not encoding MP3 over isis packets, we will have a long way to >go for 1493 bytes. On the other hand, if people are auguing we don't >have problem for 254 bytes, why we are so concerned about over 1493 bytes? > >As i mentioned above, it's not trivial to handle the data across the >packet boundary. We had the same dicussion in the isis capability >draft regarding capability spread over TLV boundary and over packet >boundary, it needs to have a lot of machanery to deal with them >properly. we don't need to solve this problem right now. > >The fragmemtation I refer to is not the LSP fragments, I meant have >the isis packets size grow over 1493 bytes and fragment/re-assemble >the LSP fragments, then your scheme may be useful then ;-) > > >thanks. >- Naiming > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 10 15:31:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23840 for ; Tue, 10 Aug 2004 15:31:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BucIa-0006sK-47; Tue, 10 Aug 2004 15:28:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BucHc-0006jH-Pb for isis-wg@megatron.ietf.org; Tue, 10 Aug 2004 15:27:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23697 for ; Tue, 10 Aug 2004 15:27:38 -0400 (EDT) Received: from bay2-f12.bay2.hotmail.com ([65.54.247.12] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BucMC-00039z-OY for isis-wg@ietf.org; Tue, 10 Aug 2004 15:32:26 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Aug 2004 12:27:07 -0700 Received: from 64.47.48.10 by by2fd.bay2.hotmail.msn.com with HTTP; Tue, 10 Aug 2004 19:27:07 GMT X-Originating-IP: [64.47.48.10] X-Originating-Email: [sboddapa@hotmail.com] X-Sender: sboddapa@hotmail.com From: "Suresh Boddapati" To: dkatz@juniper.net, naiming@redback.com Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt Date: Tue, 10 Aug 2004 19:27:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Aug 2004 19:27:07.0321 (UTC) FILETIME=[062FB290:01C47F10] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA23697 Cc: dimitri.papadimitriou@alcatel.be, Radia.Perlman@Sun.COM, tony.li@tony.li, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >One of the architectural aspects of LSPs in IS-IS is that they are inten= ded=20 >to be idempotent, with no interdependence between LSP "fragments" (an=20 >unfortunate choice of nomenclature, as this carries too much semantic=20 >baggage from IP.) The only exception is a dependence on the existence o= f=20 >LSP fragment zero. There is an expectation that the database is always=20 >internally consistent even while in flux; at worst there may be stale o= r=20 >missing routes for a brief period of time, and that updates to the datab= ase=20 >are effectively atomic. Were the TLVs within the LSPs also not intended to be idempotent? AFAIK, they are idempotent today. > >Each "fragment" is flooded, built, and rebuilt independently and without= =20 >regard to ordering, and the flooding process is almost guaranteed to add= a=20 >bunch of entropy as the flood moves across the network. We are in agreement here. > >Any scheme which depends on multiple fragments to be consistent in any=20 >database at any instant in time is arguably broken, because there will=20 >*always* be some period in which they are not consistent; this=20 >inconsistency can last for an arbitrarily long time. The consistency is= sue=20 >can of course be addressed with TLV-internal sequencing hacks, which wou= ld=20 >require implementations to play games when not all of the interdependent= =20 >elements have arrived--the side effects of this could be pretty ugly, as= =20 >information would effectively flap every time it is updated, and updates= =20 >stop being anything resembling atomic. > >Any scheme which relies on LSP arrival ordering is, of course, so broken= as=20 >to not be worth mentioning. > Agreed. The fact is that if you ever have to solve a problem that spans=20 multiple LSPs, no matter which scheme you choose, you would have to wait = for=20 all the LSPs to arrive (irrespective of the order in which they arrive) t= o=20 put together the data. >If the issue at hand is that there is monolithic information that cannot= =20 >fit in 253 bytes (but can fit within 1400mumble), having interdependent=20 >(and perhaps order-dependent) TLVs within a single LSP is unavoidable an= d a=20 >little gross, but not terrible (IMHO). If there is monolithic informati= on=20 >that is too large to fit within a single LSP, perhaps IS-IS (which is no= w=20 >almost old enough to vote) is not the right vehicle. > Agreed here too. The point is simple. Why use a "little gross" scheme, wh= en =20 a cleaner one can be used. The original architecture did not foresee the=20 information being more than 255 bytes. Years later, we feel that is no=20 longer true. If we add a scheme that takes care of info that spills over=20 into multiple TLVs without violating the idempotence relation of TLVs=20 within an LSP, why not do it? An LSP can be viewed as space/memory where one can encode any TLV one wan= ts,=20 as long as the space is there. If an LSP X has 10 bytes free and one want= s=20 to encode a TLV that is 8 bytes, one can just use LSP X. An example of monolithic information that is just over 255 bytes: Consider the case where there are 10 bytes left in each of the 255 LSPs=20 originated by an IS. Now if there are 300 bytes of data to be encoded ,=20 short of rearranging the LSPs and creating space for 300 bytes, OR simply= =20 not advertising the data, we cannot use any of the other schemes. It can= be=20 argued that we could simply start generating new LSPs (using the extensio= n=20 of LSP fragments beyond 255, but then one can easily end up with lots of=20 LSPs very sparsely populated). Whereas if we use a scheme where we use th= e=20 space as and when we find it, it will just work fine and will allow for=20 optimum packing of LSPs. This may not be a very far fetched scenario beca= use=20 the LSPs are constantly changing. It can be upto the implementation wheth= er=20 it really wants to pack the LSPs optimally or not. But the scheme will al= low=20 for it. For the more basic case where you have enough space within the LSP, it wi= ll=20 also work just fine. In both cases, it will preserve the idempotence of T= LVs=20 also. My point is, please do not look at information spilling over into multipl= e=20 LSPs as a very remote case. It can happen even with less data depending = on=20 how the state of the database at any point is. Thanks. Suresh _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee=AE= =20 Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 10 17:02:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06301 for ; Tue, 10 Aug 2004 17:02:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bud9V-0005hN-E3; Tue, 10 Aug 2004 16:23:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bucds-0001ya-Lz for isis-wg@megatron.ietf.org; Tue, 10 Aug 2004 15:50:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25362 for ; Tue, 10 Aug 2004 15:50:38 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuciT-0003WE-7G for isis-wg@ietf.org; Tue, 10 Aug 2004 15:55:26 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 10 Aug 2004 15:58:42 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7AJo2AU007574; Tue, 10 Aug 2004 15:50:02 -0400 (EDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-206-181.cisco.com [64.102.206.181]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BBE37821; Tue, 10 Aug 2004 12:50:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20040810154933.0260e290@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Aug 2004 15:51:28 -0400 To: "Suresh Boddapati" , dkatz@juniper.net, naiming@redback.com From: Jeff Learman Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: dimitri.papadimitriou@alcatel.be, Radia.Perlman@Sun.COM, tony.li@tony.li, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 03:27 PM 8/10/2004, Suresh Boddapati wrote: >>One of the architectural aspects of LSPs in IS-IS is that they are intended to be idempotent, with no interdependence between LSP "fragments" (an unfortunate choice of nomenclature, as this carries too much semantic baggage from IP.) The only exception is a dependence on the existence of LSP fragment zero. There is an expectation that the database is always internally consistent even while in flux; at worst there may be stale or missing routes for a brief period of time, and that updates to the database are effectively atomic. > >Were the TLVs within the LSPs also not intended to be idempotent? >AFAIK, they are idempotent today. Of course -- they have to be, because you receive the same info any number of times with different LSP sequence numbers. There would be no reasonable way to provide non-idempotent semantics if you wanted to. Jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Aug 10 19:09:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15632 for ; Tue, 10 Aug 2004 19:09:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bufbb-0003EN-TU; Tue, 10 Aug 2004 19:00:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bufax-000330-AH for isis-wg@megatron.ietf.org; Tue, 10 Aug 2004 18:59:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15162 for ; Tue, 10 Aug 2004 18:59:47 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuffZ-00010a-CP for isis-wg@ietf.org; Tue, 10 Aug 2004 19:04:38 -0400 Received: from [10.0.1.4] (66-215-139-183.slt-cres.charterpipeline.net[66.215.139.183]) by comcast.net (rwcrmhc12) with SMTP id <2004081022591601400qa52se> (Authid: li.tony); Tue, 10 Aug 2004 22:59:18 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt Date: Tue, 10 Aug 2004 15:59:15 -0700 To: "Suresh Boddapati" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: naiming@redback.com, Radia.Perlman@Sun.COM, isis-wg@ietf.org, dkatz@juniper.net, dimitri.papadimitriou@alcatel.be X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit > An example of monolithic information that is just over 255 bytes: > Consider the case where there are 10 bytes left in each of the 255 > LSPs originated by an IS. Now if there are 300 bytes of data to be > encoded , short of rearranging the LSPs and creating space for 300 > bytes, OR simply not advertising the data, we cannot use any of the > other schemes. It can be argued that we could simply start generating > new LSPs (using the extension of LSP fragments beyond 255, but then > one can easily end up with lots of LSPs very sparsely populated). > Whereas if we use a scheme where we use the space as and when we find > it, it will just work fine and will allow for optimum packing of LSPs. > This may not be a very far fetched scenario because the LSPs are > constantly changing. It can be upto the implementation whether it > really wants to pack the LSPs optimally or not. But the scheme will > allow for it. > For the more basic case where you have enough space within the LSP, it > will also work just fine. In both cases, it will preserve the > idempotence of TLVs also. > And my point is this: the above problem is not worth solving. Our goal here is to provide _engineering_, not theoretical perfection. Solving this problem is far outside of the cost/complexity envelope that IS-IS is all about. I strongly suggest that we focus on agreeing on the problem to be solved. Solutions are easy, problem statements are the hard part. Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Aug 11 11:05:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11127 for ; Wed, 11 Aug 2004 11:05:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuXj-0005gZ-Hx; Wed, 11 Aug 2004 10:57:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuuOh-0003No-PY for isis-wg@megatron.ietf.org; Wed, 11 Aug 2004 10:48:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09756 for ; Wed, 11 Aug 2004 10:48:08 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuuTR-0000W8-JI for isis-wg@ietf.org; Wed, 11 Aug 2004 10:53:06 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Aug 2004 15:47:28 +0100 Message-ID: <37701240971DD31193970000F6CCB9F7060D8A5B@duke.datcon.co.uk> From: Jon Berger To: isis-wg@ietf.org Date: Wed, 11 Aug 2004 15:47:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Isis-wg] IPv6 Traffic Engineering in IS-IS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Folks, We propose that this draft be adopted by the IS-IS working group. This working group already owns IPv6 and TE support separately. IPv6 objects are defined for MPLS and GMPLS and so IGPs need to provide this service. The OSPF WG has already accepted a draft offering equivalent function as a work item. Could you please take a look at this and let us have any comments on either the technical solution or its suitability as a WG document. Thanks, Jon Title : IPv6 Traffic Engineering in IS-IS Author(s) : J. Harrison, et al. Filename : draft-harrison-isis-ipv6-te-00.txt Pages : 10 Date : 2004-7-6 This draft specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. The described method uses three new TLVs, together with 2 new sub-TLVs of the Extended IS Reachability TLV. The information distributed allows a CSPF algorithm to calculate traffic engineered routes using IPv6 addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-harrison-isis-ipv6-te-00.txt Jon Berger Network Protocols Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: mailto:jon.berger@dataconnection.com Web: http://www.dataconnection.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Aug 12 13:31:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17537 for ; Thu, 12 Aug 2004 13:31:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJ7I-000493-9q; Thu, 12 Aug 2004 13:11:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIs5-0008Ht-NO for isis-wg@megatron.ietf.org; Thu, 12 Aug 2004 12:56:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15027 for ; Thu, 12 Aug 2004 12:56:06 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIx4-0007rl-5B for isis-wg@ietf.org; Thu, 12 Aug 2004 13:01:19 -0400 X-BrightmailFiltered: true 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.10/8.12.6) with ESMTP id i7CGsMCL028576; Thu, 12 Aug 2004 09:54:24 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn5-739.cisco.com [10.21.90.227]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id ATA76002; Thu, 12 Aug 2004 09:55:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20040812094433.01c2ee18@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Aug 2004 09:54:34 -0700 To: Tony Li From: Les Ginsberg Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: dimitri.papadimitriou@alcatel.be, Radia.Perlman@Sun.COM, isis-wg@ietf.org, naiming@redback.com, Suresh Boddapati , dkatz@juniper.net X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Here is yet another approach to this issue. I believe it is possible to address the 255 byte limitation with no changes to the protocol whatsoever. The premise on which the alleged problem is based is that when and if we have more than 255 bytes of information to send about an object, that sending the information in two different TLVs is somehow fundamentally broken today i.e. that the recipients will fail to utilize the information in both TLVs - instead selecting one TLV over another. Each of the previously proposed solutions provides a way to overcome this alleged protocol deficiency. But if a clear statement is made that, in the case of at least certain objects, information in multiple TLVs should be considered additive, then the current protocol encoding requires no extension. If a system advertises multiple IS-neighbor TLVs to the same neighbor, the protocol currently processes all of these TLVs when performing SPF. Indeed, with the advent of TE sub-TLVs, we routinely send multiple IS-neighbor advertisements for the same neighbor - one for every link to that neighbor on which we have TE information to advertise. This does not break SPF calculations because the SPF algorithm correctly handles these multiple advertisements. Extending this notion, if a system has more than 255 bytes of TE information to send about a particular link to a neighbor, it could safely send multiple TLVs for that neighbor/link without adversely affecting the SPF calculation. What is needed to make this achieve the desired result regarding the TE information is for receiving systems to be implemented to consider the TE information in all TLVs associated with the same neighbor/link as valid and additive. This requires no protocol changes whatsoever - only a clear statement of the proper way to process the receipt of multiple TLVs for the same object. In looking at the various cases which might generate more than 255 bytes of data about an object (e.g. TE link information, SRLG, router capabilities) I see no usage which would be incompatible with this additive interpretation of advertisement. The additive proposal has a number of advantages as compared to some or all of the previously outlined solutions: a)It does not constrain the information about an object to a single LSP fragment b)It automatically provides the necessary object identifiers so that all the TLVs associated with the same object can be reliably identified c)No protocol changes of any kind are required. No new TLV code points, no new TLV attributes (e.g. fragment IDs), etc. All that is required in the way of specification is some text in the drafts associated with the applications which have the potential for more than 255 bytes defining the additive interpretation of the application information. Legitimate concern has been expressed about solutions which involve updates to multiple LSP fragments because of problems associated with the lack of atomicity in the update. These problems are not confined to solutions which allow TLVs about the same object to appear in different LSP fragments. Even when the solution requires all information about an object to be in a single LSP fragment it may require updates to multiple LSP fragments in order to advertise additional information about an object. This arises when the LSP fragment which contains the current information about an object does not have enough room to contain the additional information which needs to be advertised. So the TLV(s) must be deleted from the current fragment and added (with additional info) to another fragment. It can be argued that in cases where additional information needs to be advertised solutions which allow TLVs to appear in different fragments can avoid the multiple fragment issues by leaving the original advertisement unchanged and advertising the additional information in another LSP fragment. NOTE: The above should NOT be interpreted as an endorsement of a strategy which always favors single LSP fragment updates rather than minimizing the number of TLVs required to advertise the information about an object. I believe it is still preferable to use a single TLV whenever the information about an object is less than 255 bytes. However, when the information exceeds 255 bytes in length having the flexibility to place the additional TLV anywhere within the set of LSP fragments can minimize instances where multiple fragments must be updated. As updates to multiple LSP fragments are sometimes unavoidable no matter which solution might be used, the following guidelines are practices which minimize the disruption by maximizing the effective atomicity of multiple fragment updates: 1)Wherever possible, an implementation SHOULD advertise the update to TLV(s) in the same LSP fragment as the advertisement(s) which are being replaced. 2)Where #1 is not possible, the multiple affected LSP fragments should be flooded as an atomic action. 3)Systems which receive an update can minimize the potential disruption associated with the update by employing a modest delay time prior to processing the update so as to allow for the possible receipt of multiple LSP fragments associated with the same update prior to beginning processing. Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Aug 18 17:18:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19166 for ; Wed, 18 Aug 2004 17:18:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxXGR-0002kw-27; Wed, 18 Aug 2004 16:42:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxW9m-00068E-Ts for isis-wg@megatron.ietf.org; Wed, 18 Aug 2004 15:32:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01684 for ; Wed, 18 Aug 2004 15:30:52 -0400 (EDT) From: jcucchiara@mindspring.com Received: from smtp6.mindspring.com ([207.69.200.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxWFM-0004LV-IK for isis-wg@ietf.org; Wed, 18 Aug 2004 15:37:23 -0400 Received: from [192.168.167.40] (helo=wamui02.slb.atl.earthlink.net) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1BxW90-0004Ku-00; Wed, 18 Aug 2004 15:30:46 -0400 Message-ID: <1545021.1092857446395.JavaMail.root@wamui02.slb.atl.earthlink.net> Date: Wed, 18 Aug 2004 15:30:45 -0400 (GMT-04:00) To: jparker@axiowave.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org Subject: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jcucchiara@mindspring.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Jeff, A few more MIB questions... #1 The isisCircIndex has a SYNTAX Integer32 (1..2147483647) As we discussed in an earlier email a few weeks ago, this Index was to get its value from the isisNextCircIndex object. As in the DIFFSERV-MIB (rfc 3289), the actual index (i.e. the isisCircIndex) needs to have the type IndexInteger. #2 Can the isisManAreaAddrTable and the isisAreaAddrTable be combined? These seem to be the same info, except in one case the address is configured by an operator, and in the other case, an address is learned by ISIS. If an object were added to indicate if the object were manually configured, or learned, then these 2 tables could be combined. This would get rid of the a compile error with the read-only Index in the isisAreaAddrTable. The object which denotes if the entry was configured or learned would look something like: cnIetfAreaAddressType OBJECT-TYPE SYNTAX INTEGER { unknown(1), manuallyConfigured(2), learned(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to denote whether or not this entry was configured by an operator, or learned by ISIS. unknown(1) - this value indicates that it is not known if this entry has been configured or learned, manuallyConfigured(2) - this value indicates that this entry was configured by an operator learned(3) - this value indicates taht this entry was learned dynamically by ISIS." #3. One last question on the isisCircLevelTable. When a circuit is created in the isisCircTable, do 2 entries automatically appear in the isisCircLevelTable (one for Level1 and one for Level2)?? I think allowing operators to create rows in this table (by adding a RowStatus object) would be better. Under what circumstances would a circuit participate in both Level1 and Level2?? thanks, -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Aug 19 10:15:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04650 for ; Thu, 19 Aug 2004 10:15:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxnak-0003R6-RA; Thu, 19 Aug 2004 10:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxnVb-00019K-Lt for isis-wg@megatron.ietf.org; Thu, 19 Aug 2004 10:03:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03024 for ; Thu, 19 Aug 2004 10:03:14 -0400 (EDT) From: jcucchiara@mindspring.com Received: from blount.mail.mindspring.net ([207.69.200.226]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxnc1-0004uo-TY for isis-wg@ietf.org; Thu, 19 Aug 2004 10:09:55 -0400 Received: from [192.168.167.41] (helo=wamui03.slb.atl.earthlink.net) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BxnVQ-0006lx-00; Thu, 19 Aug 2004 10:03:04 -0400 Message-ID: <9081647.1092924184535.JavaMail.root@wamui03.slb.atl.earthlink.net> Date: Thu, 19 Aug 2004 10:03:03 -0400 (GMT-04:00) To: jparker@axiowave.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org Subject: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jcucchiara@mindspring.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Jeff, This is related to my question of yesterday on how to populate the isisCircLevelTable.... In the isisCircTable, the object's description below is unclear. Since this object is a read-create, it is set by an operator, what does the isisSysType scalar object have to do with this object? isisCircLevel OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), level1L2(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates which type of packets will be sent and accepted on this circuit. The values used will be modified by the settings of isisSysType. This object follows the replaceOnlyWhileDisabled behavior." DEFVAL { level1L2 } ::= { isisCircEntry 8 } Also, with regard to the isisCircLevelTable, is this object supposed to indicate which Level needs to be populated by the agent? In other words, does this object (above) denote what value the isisCircLevelIndex (below) takes on? If this is correct, then why are only leve1IS(1) and level2IS(2) the only options for the isisCircLevelIndex? isisCircLevelIndex OBJECT-TYPE SYNTAX INTEGER { level1IS (1), level2IS (2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level that this entry describes." ::= { isisCircLevelEntry 1 } Can these MIB descriptions be clarified? There appears to be some relationship between the isisSysType (scalar), the isisCircType object, and how an agent creates rows in the isisCircLevelTable (i.e. the value of the isisCircLevelIndex), but this is not documented anywhere in the MIB and is very confusing from a developer's point of view. Thanks, -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Aug 19 12:40:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15153 for ; Thu, 19 Aug 2004 12:40:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxpns-0000VY-4u; Thu, 19 Aug 2004 12:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxpYG-0006XQ-FR for isis-wg@megatron.ietf.org; Thu, 19 Aug 2004 12:14:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13026 for ; Thu, 19 Aug 2004 12:14:06 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxpei-0007ak-Ne for isis-wg@ietf.org; Thu, 19 Aug 2004 12:20:49 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 19 Aug 2004 17:13:25 +0100 Message-ID: <37701240971DD31193970000F6CCB9F705042510@duke.datcon.co.uk> From: Jonathan Harrison To: "'jcucchiara@mindspring.com'" , jparker@axiowave.com Subject: RE: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16 Date: Thu, 19 Aug 2004 17:13:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Joan, A few comments on your questions. Point #1 looks fine. On #2, I don't think there is any need to combine the tables. Each has a different purpose, and the tables are easier for the operator (and the implementer) as they are. - The isisAreaAddrTable reports information about area addresses learnt from other nodes (and must therefore be read-only). - The isisManAreaAddrTable is the set of area address configured on this node (and must therefore be read-create). Typically, there will be an overlap in these tables. However, it is much clearer to an operator of IS-IS to be able to view the configured and learnt addresses separately. In addition, I believe it is much simpler to implement separate read-create and read-only create tables than to implement a table where some entries are read-only and some are read-create. On #3, two entries in the isisCircLevelTable should be created automatically when the corresponding isisCircTable entry is created, as these are required for the operation of the circuit. Note that since the configured level of the circuit can change, the rows that are present should not depend on the isisCircLevel. For example, if an operator changes isisCircLevel from level1L2 to level1 and then back to level1L2, they would not want to lose the old level 2 configuration.) I also think that there is no benefit to be gained from allowing an operator to create or delete rows in this table. - It would give an operator additional (unnecessary) work to do. - It would add unnecessary complication to an implementation of IS-IS. For example, an implementation would need to cope with an operator attempting to delete MIB rows that may be essential to the correct operation of the circuit. Jon -----Original Message----- From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] Sent: 18 August 2004 20:31 To: jparker@axiowave.com Cc: isis-wg@ietf.org Subject: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16 Hi Jeff, A few more MIB questions... #1 The isisCircIndex has a SYNTAX Integer32 (1..2147483647) As we discussed in an earlier email a few weeks ago, this Index was to get its value from the isisNextCircIndex object. As in the DIFFSERV-MIB (rfc 3289), the actual index (i.e. the isisCircIndex) needs to have the type IndexInteger. #2 Can the isisManAreaAddrTable and the isisAreaAddrTable be combined? These seem to be the same info, except in one case the address is configured by an operator, and in the other case, an address is learned by ISIS. If an object were added to indicate if the object were manually configured, or learned, then these 2 tables could be combined. This would get rid of the a compile error with the read-only Index in the isisAreaAddrTable. The object which denotes if the entry was configured or learned would look something like: cnIetfAreaAddressType OBJECT-TYPE SYNTAX INTEGER { unknown(1), manuallyConfigured(2), learned(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to denote whether or not this entry was configured by an operator, or learned by ISIS. unknown(1) - this value indicates that it is not known if this entry has been configured or learned, manuallyConfigured(2) - this value indicates that this entry was configured by an operator learned(3) - this value indicates taht this entry was learned dynamically by ISIS." #3. One last question on the isisCircLevelTable. When a circuit is created in the isisCircTable, do 2 entries automatically appear in the isisCircLevelTable (one for Level1 and one for Level2)?? I think allowing operators to create rows in this table (by adding a RowStatus object) would be better. Under what circumstances would a circuit participate in both Level1 and Level2?? thanks, -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Aug 19 12:43:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15424 for ; Thu, 19 Aug 2004 12:43:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxpns-0000Vl-ID; Thu, 19 Aug 2004 12:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxpYg-0006ag-1S for isis-wg@megatron.ietf.org; Thu, 19 Aug 2004 12:14:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13055 for ; Thu, 19 Aug 2004 12:14:31 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxpf5-0007b7-8B for isis-wg@ietf.org; Thu, 19 Aug 2004 12:21:14 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Aug 2004 17:14:10 +0100 Message-ID: <37701240971DD31193970000F6CCB9F705042511@duke.datcon.co.uk> From: Jonathan Harrison To: "'jcucchiara@mindspring.com'" , jparker@axiowave.com Subject: RE: [Isis-wg] question on the relationship between isisSysType, i sisCircType and isisCircLevelIndex Date: Thu, 19 Aug 2004 17:13:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Joan, Jeff, I suggest we clarify the isisCircLevel description text to read as follows. "Indicates the configured level of the circuit. The actual level at which the circuit operates is taken from the overlap of the value of this object and the value of isisSysType, and this overlap decides which type of packets will be sent and accepted on this circuit. This object follows the replaceOnlyWhileDisabled behavior." To answer your other points: - As described in my previous mail, this object should not affect the existence of entries in the isisCircLevelTable. - Since the indexing of the isisCircLevelTable already allows the circuit to be configured separately at level 1 and level 2, there is no need to allow an isisCircLevelTable entry to have an index of level1L2. Jon -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of jcucchiara@mindspring.com Sent: 19 August 2004 15:03 To: jparker@axiowave.com Cc: isis-wg@ietf.org Subject: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex Hi Jeff, This is related to my question of yesterday on how to populate the isisCircLevelTable.... In the isisCircTable, the object's description below is unclear. Since this object is a read-create, it is set by an operator, what does the isisSysType scalar object have to do with this object? isisCircLevel OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), level1L2(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates which type of packets will be sent and accepted on this circuit. The values used will be modified by the settings of isisSysType. This object follows the replaceOnlyWhileDisabled behavior." DEFVAL { level1L2 } ::= { isisCircEntry 8 } Also, with regard to the isisCircLevelTable, is this object supposed to indicate which Level needs to be populated by the agent? In other words, does this object (above) denote what value the isisCircLevelIndex (below) takes on? If this is correct, then why are only leve1IS(1) and level2IS(2) the only options for the isisCircLevelIndex? isisCircLevelIndex OBJECT-TYPE SYNTAX INTEGER { level1IS (1), level2IS (2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level that this entry describes." ::= { isisCircLevelEntry 1 } Can these MIB descriptions be clarified? There appears to be some relationship between the isisSysType (scalar), the isisCircType object, and how an agent creates rows in the isisCircLevelTable (i.e. the value of the isisCircLevelIndex), but this is not documented anywhere in the MIB and is very confusing from a developer's point of view. Thanks, -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Aug 20 11:40:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22146 for ; Fri, 20 Aug 2004 11:40:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByB36-0000BO-6i; Fri, 20 Aug 2004 11:11:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByAqD-0003q5-8s for isis-wg@megatron.ietf.org; Fri, 20 Aug 2004 10:58:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18393 for ; Fri, 20 Aug 2004 10:57:27 -0400 (EDT) From: jcucchiara@mindspring.com Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByAwH-0000cv-SJ for isis-wg@ietf.org; Fri, 20 Aug 2004 11:04:23 -0400 Received: from wamui04.slb.atl.earthlink.net ([192.168.167.42]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1ByAop-0007mI-00; Fri, 20 Aug 2004 10:56:39 -0400 Message-ID: <24971620.1093013799409.JavaMail.root@wamui04.slb.atl.earthlink.net> Date: Fri, 20 Aug 2004 10:56:38 -0400 (GMT-04:00) To: Jeff Parker , jparker@axiowave.com Subject: Re: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jcucchiara@mindspring.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit -----Original Message----- > From: Jeff Parker > Sent: Aug 19, 2004 2:22 PM > To: jcucchiara@mindspring.com, jparker@axiowave.com > Cc: isis-wg@ietf.org > Subject: Re: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex > > >At 10:03 AM -0400 8/19/04, jcucchiara@mindspring.com wrote: > > > >Hi Jeff, > > > >This is related to my question of yesterday on > >how to populate the isisCircLevelTable.... > > > >In the isisCircTable, the object's description > >below is unclear. Since this object is a read-create, > >it is set by an operator, what does the isisSysType scalar > >object have to do with this object? > > > > > >isisCircLevel OBJECT-TYPE > > SYNTAX INTEGER > > { > > level1(1), > > level2(2), > > level1L2(3) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Indicates which type of packets will be sent and > > accepted on this circuit. The values used will be > > modified by the settings of isisSysType. This > > object follows the replaceOnlyWhileDisabled behavior." > > DEFVAL { level1L2 } > > ::= { isisCircEntry 8 } > If the router is running at Level 1, and the circuit is configured to > be L1 and L2, only L1 packets will appear. That is the imapct of > isisSysType on the effectiveness of the circuit. > > Different implementations could react differently: rejecting values > of CircLevel that don't match SysLevel, or silently accepting them. > But CircLevel cannot overrule SysLevel. I assume you mean CircType in the above paragraph (not CircLevel), right? I don't understand this answer. The agent is ALWAYS supposed to create 2 rows for every circuit in the CircLevelTable, one row which is circ + Level1 and the 2nd row which is circ + Level2, correct? Then the agent is supposed to look at SysLevel (scalar) object to figure out if one or both (i.e. Level1 or Level2 or both) are actually being used in ISIS routing. I think that a better design would be to add an operStatus type of object to the CircLevelEntry to specify that the row is or is not being used in routing. Could the DESCRIPTION clauses of the scalar object and the circLevelTable be clarified so that the relationship between the sysLevel scalar and how rows are created in this table is described? Additionally, the read-create objects in the circLevelTable need to be changed to read-write. The agent is responsible for creating these rows, thus, read-write should be fine. What is the purpose of the isisCircType object in the isisCircEntry? I don't see any purpose for this object, should it be removed? If a Circuit is referring to SysLevel to see what types of packets to send/receive on the circuit, then isisCircType is useless. > > > > > >Also, with regard to the isisCircLevelTable, is this object > >supposed to indicate which Level needs to be populated by the agent? > >In other words, does this object (above) denote what value the > >isisCircLevelIndex (below) takes on? > > > >If this is correct, then why are only leve1IS(1) and level2IS(2) > >the only options for the isisCircLevelIndex? > > > > > >isisCircLevelIndex OBJECT-TYPE > > SYNTAX INTEGER > > { > > level1IS (1), > > level2IS (2) > > } > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The level that this entry describes." > > ::= { isisCircLevelEntry 1 } > > > > > >Can these MIB descriptions be clarified? There appears to > >be some relationship between the isisSysType (scalar), the > >isisCircType object, and how an agent creates rows in the > >isisCircLevelTable (i.e. the value of the isisCircLevelIndex), > >but this is not documented anywhere in > >the MIB and is very confusing from a developer's point of view. > > > > Thanks, > > -Joan > The CircLevel is an index into a table for values that are specific > to a level. The MTU of a circuit is level independent, while the > Hello Timers can have different values for different levels. The use of read-create in the isisCircLevelTable is extremely confusing. As I stated above, read-write should be fine if the agent is always supposed to create 2 rows per circuit. Could this be changed? -Thanks, Joan > > - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Aug 20 11:42:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22308 for ; Fri, 20 Aug 2004 11:42:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByB62-00017l-91; Fri, 20 Aug 2004 11:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByAxZ-0006JZ-6R for isis-wg@megatron.ietf.org; Fri, 20 Aug 2004 11:05:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19155 for ; Fri, 20 Aug 2004 11:05:38 -0400 (EDT) From: jcucchiara@mindspring.com Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByB4D-0000qa-Pg for isis-wg@ietf.org; Fri, 20 Aug 2004 11:12:34 -0400 Received: from wamui04.slb.atl.earthlink.net ([192.168.167.42]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1ByAxV-0002hk-00; Fri, 20 Aug 2004 11:05:37 -0400 Message-ID: <6916954.1093014336858.JavaMail.root@wamui04.slb.atl.earthlink.net> Date: Fri, 20 Aug 2004 11:05:36 -0400 (GMT-04:00) To: Jonathan Harrison , jparker@axiowave.com Subject: RE: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jcucchiara@mindspring.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit -----Original Message----- > From: Jonathan Harrison > Sent: Aug 19, 2004 12:13 PM > To: "'jcucchiara@mindspring.com'" , jparker@axiowave.com > Cc: isis-wg@ietf.org > Subject: RE: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16 > > Joan, > > A few comments on your questions. > Hi Jon, > Point #1 looks fine. Thanks. > > On #2, I don't think there is any need to combine the tables. Each has a > different purpose, and the tables are easier for the operator (and the > implementer) as they are. > > - The isisAreaAddrTable reports information about area addresses learnt > from other nodes (and must therefore be read-only). > > - The isisManAreaAddrTable is the set of area address configured on this > node (and must therefore be read-create). > > Typically, there will be an overlap in these tables. However, it is much > clearer to an operator of IS-IS to be able to view the configured and learnt > addresses separately. In addition, I believe it is much simpler to > implement separate read-create and read-only create tables than to implement > a table where some entries are read-only and some are read-create. > This is the reason that I suggested the other object. CLI or NMS could display Manually configured or learned addresses separately, but the agent could combine this into one table. The only difference with these 2 tables is that one is configured by an operator and one is learned but both tables contain L1 area addresses. Keep in mind that the isisAreaAddressTable does not compile as the index is read-only which is not allowed in smiV2. So that would resolve that error. > On #3, two entries in the isisCircLevelTable should be created automatically > when the corresponding isisCircTable entry is created, as these are required > for the operation of the circuit. > > Note that since the configured level of the circuit can change, the rows > that are present should not depend on the isisCircLevel. For example, if an > operator changes isisCircLevel from level1L2 to level1 and then back to > level1L2, they would not want to lose the old level 2 configuration.) Okay, I understand this now, thank you. > I also think that there is no benefit to be gained from allowing an operator > to create or delete rows in this table. > - It would give an operator additional (unnecessary) work to do. > - It would add unnecessary complication to an implementation of IS-IS. For > example, an implementation would need to cope with an operator attempting to > delete MIB rows that may be essential to the correct operation of the > circuit. > Yes, I agree. thanks, -Joan > Jon -----Original Message----- From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] Sent: 18 August 2004 20:31 To: jparker@axiowave.com Cc: isis-wg@ietf.org Subject: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16 Hi Jeff, A few more MIB questions... #1 The isisCircIndex has a SYNTAX Integer32 (1..2147483647) As we discussed in an earlier email a few weeks ago, this Index was to get its value from the isisNextCircIndex object. As in the DIFFSERV-MIB (rfc 3289), the actual index (i.e. the isisCircIndex) needs to have the type IndexInteger. #2 Can the isisManAreaAddrTable and the isisAreaAddrTable be combined? These seem to be the same info, except in one case the address is configured by an operator, and in the other case, an address is learned by ISIS. If an object were added to indicate if the object were manually configured, or learned, then these 2 tables could be combined. This would get rid of the a compile error with the read-only Index in the isisAreaAddrTable. The object which denotes if the entry was configured or learned would look something like: cnIetfAreaAddressType OBJECT-TYPE SYNTAX INTEGER { unknown(1), manuallyConfigured(2), learned(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to denote whether or not this entry was configured by an operator, or learned by ISIS. unknown(1) - this value indicates that it is not known if this entry has been configured or learned, manuallyConfigured(2) - this value indicates that this entry was configured by an operator learned(3) - this value indicates taht this entry was learned dynamically by ISIS." #3. One last question on the isisCircLevelTable. When a circuit is created in the isisCircTable, do 2 entries automatically appear in the isisCircLevelTable (one for Level1 and one for Level2)?? I think allowing operators to create rows in this table (by adding a RowStatus object) would be better. Under what circumstances would a circuit participate in both Level1 and Level2?? thanks, -Joan _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Aug 20 15:15:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07570 for ; Fri, 20 Aug 2004 15:15:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByE3a-0005GS-Ji; Fri, 20 Aug 2004 14:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByD59-00060H-IS for isis-wg@megatron.ietf.org; Fri, 20 Aug 2004 13:21:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29195 for ; Fri, 20 Aug 2004 13:21:37 -0400 (EDT) From: jcucchiara@mindspring.com Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByDBo-0003yV-65 for isis-wg@ietf.org; Fri, 20 Aug 2004 13:28:33 -0400 Received: from wamui04.slb.atl.earthlink.net ([192.168.167.42]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1ByD0A-00022U-00; Fri, 20 Aug 2004 13:16:30 -0400 Message-ID: <24311601.1093022190327.JavaMail.root@wamui04.slb.atl.earthlink.net> Date: Fri, 20 Aug 2004 13:16:28 -0400 (GMT-04:00) To: jparker@world.std.com, jparker@axiowave.com Subject: Re: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org, jon.harrison@dataconnection.com X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jcucchiara@mindspring.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, My comments are prefaced with "jec>" -----Original Message----- From: Jeff Parker Sent: Aug 20, 2004 11:38 AM To: jcucchiara@mindspring.com Cc: on.harrison@dataconnection.com, <;isis-wg@ietf.org> Subject: Re: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex > > >I assume you mean CircType in the above paragraph (not CircLevel), right? > >I don't understand this answer. The agent is ALWAYS supposed to create >2 rows for every circuit in the CircLevelTable, one row which is circ + Level1 >and the 2nd row which is circ + Level2, correct? Then the agent is >supposed to look at SysLevel (scalar) object to figure out if one or both >(i.e. Level1 or Level2 or both) are actually being used in ISIS routing. > >I think that a better design would be to add an operStatus type of object >to the CircLevelEntry to specify that the row is or is not being >used in routing. > >Could the DESCRIPTION clauses of the scalar object and >the circLevelTable be clarified so that the relationship between the >sysLevel scalar and how rows are created in this table is described? > >Additionally, the read-create objects in the >circLevelTable need to be changed to read-write. The agent is responsible >for creating these rows, thus, read-write should be fine. > >What is the purpose of the isisCircType object in the isisCircEntry? I don't >see any purpose for this object, should it be removed? If a Circuit >is referring >to SysLevel to see what types of packets to send/receive on the circuit, >then isisCircType is useless. jec> Could you respond to the above concern? I don't see a need for jec> the isisCircType object since sysLevel overrides this, so could jec> this object be removed? Please comment. My mail is not appearing on the mail list, probably because my POP and SMTP servers are different. Jon has proposed language that I can accept. I trust this addresses your issue about how the fields interact. jec> The text does not mention how rows are to be created by the jec> agent in the isisCircLevelTable, so that needs to be called out. jec> A person that is reading this MIB for the first time is not likely to jec> understand. From an agent developer's point of view, this was jec> not at all clear. If the CircLevel table is read-only, I will fix. At present, I am between offices. jec> The objects in the CircLevelTable that are read-create need jec> to be made "read-write". (I didn't mention anything about read-only.) As to configuration, I can imagine configuring an interface/level that is not enabled yet. Since changing many attributes will force you to cycle adjacencies, you may want to configure them first, and then enable the Circuit for that level. Like selecting options on a car you don't own yet, it is less disruptive than trying to change them once the car is operational. jec> I think you have made my point for adding an OperStatus object jec> to this (CircLevelEntry) entry. It is all well and good if you expect that jec> you will always buy the perfect car that works as you expect jec> and as you pre-configured it, but you don't really know until jec> you actually get the car and turn it on and look at the gages/setting to jec> make sure that it really works. jec> Can you please comment on if you will be adding an OperStatus object? thanks, -Joan - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Aug 23 07:29:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29874 for ; Mon, 23 Aug 2004 07:29:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzCTd-0005kq-C1; Mon, 23 Aug 2004 06:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzC0b-0001yF-0Q for isis-wg@megatron.ietf.org; Mon, 23 Aug 2004 06:25:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26904 for ; Mon, 23 Aug 2004 06:24:53 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzC0n-0001Un-Tu for isis-wg@ietf.org; Mon, 23 Aug 2004 06:25:14 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Aug 2004 11:24:35 +0100 Message-ID: <37701240971DD31193970000F6CCB9F70504251E@duke.datcon.co.uk> From: Jonathan Harrison To: "'jcucchiara@mindspring.com'" , jparker@world.std.com, jparker@axiowave.com Subject: RE: [Isis-wg] question on the relationship between isisSysType, i sisCircType and isisCircLevelIndex Date: Mon, 23 Aug 2004 11:24:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Joan, Jeff, Some comments to hopefully clarify the use of the isisCircLevel and isisSysType objects, and to sum up the discussion so far. - The isisSysType object is required, as it defines the level(s) at which the IS-IS instance operates. - Even if isisSysType is level1L2IS, some circuits may be required to act at level 1 only or level 2 only. Hence the isisCircLevel object is required to define the level(s) at which a circuit operates. - Two entries in the isisCircLevelTable exist for every isisCircTable entry. One for level 1 and one for level 2. The comments for isisCircLevelEntry are pretty clear about this: "An isisCircLevelEntry exists for each level on each circuit used by Integrated IS-IS on this system." - A physical link failure could cause a circuit with isisCircAdminState 'on' to become unusable. This should probably be reflected in the MIB by an oper status object in the isisCircTable. For example, we could define an isisCircOperState object as follows. isisCircOperState OBJECT-TYPE SYNTAX INTEGER { operStatusUp(1), -- active operStatusDown(2), -- inactive operStatusGoingUp(3), -- activating operStatusGoingDown(4),-- deactivating operStatusActFailed(5) -- activation failed } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational state of this circuit." ::= { isisCircEntry 5 } With this change, I don't believe there is a need for an oper-status for the isisCircLevel table, as the status of each level could be deduced from the circuit oper-status, together with the isisSysType and isisCircLevel objects. - As Joan says, because there is no row status in the isisCircLevel table, the MAX-ACCESS for the modifiable objects must be "read-create" rather than "read-write". - With regards to the isisAreaAddr and isisManAreaAddr table, I still believe that they are correct as they are at present. The tables should be separate, because the two tables perform different functions. There should be no compiler problems with the isisAreaAddr table - a read-only index is allowed by SMIv2 if the object is the only one in the table (see for example, RFC2578, 7.7: "(2) a conceptual row must contain at least one columnar object which is not an auxiliary object. In the event that all of a conceptual row's columnar objects are also specified in its INDEX clause, then one of them must be accessible, i.e., have a MAX-ACCESS clause of "read-only". (Note that this situation does not arise for a conceptual row allowing create access, since such a row will have a status column which will not be an auxiliary object.)" Jon -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of jcucchiara@mindspring.com Sent: 20 August 2004 18:16 To: jparker@world.std.com; jparker@axiowave.com Cc: isis-wg@ietf.org; Jonathan Harrison Subject: Re: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex Hi, My comments are prefaced with "jec>" -----Original Message----- From: Jeff Parker Sent: Aug 20, 2004 11:38 AM To: jcucchiara@mindspring.com Cc: on.harrison@dataconnection.com, <;isis-wg@ietf.org> Subject: Re: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex > > >I assume you mean CircType in the above paragraph (not CircLevel), right? > >I don't understand this answer. The agent is ALWAYS supposed to create >2 rows for every circuit in the CircLevelTable, one row which is circ + Level1 >and the 2nd row which is circ + Level2, correct? Then the agent is >supposed to look at SysLevel (scalar) object to figure out if one or both >(i.e. Level1 or Level2 or both) are actually being used in ISIS routing. > >I think that a better design would be to add an operStatus type of object >to the CircLevelEntry to specify that the row is or is not being >used in routing. > >Could the DESCRIPTION clauses of the scalar object and >the circLevelTable be clarified so that the relationship between the >sysLevel scalar and how rows are created in this table is described? > >Additionally, the read-create objects in the >circLevelTable need to be changed to read-write. The agent is responsible >for creating these rows, thus, read-write should be fine. > >What is the purpose of the isisCircType object in the isisCircEntry? I don't >see any purpose for this object, should it be removed? If a Circuit >is referring >to SysLevel to see what types of packets to send/receive on the circuit, >then isisCircType is useless. jec> Could you respond to the above concern? I don't see a need for jec> the isisCircType object since sysLevel overrides this, so could jec> this object be removed? Please comment. My mail is not appearing on the mail list, probably because my POP and SMTP servers are different. Jon has proposed language that I can accept. I trust this addresses your issue about how the fields interact. jec> The text does not mention how rows are to be created by the jec> agent in the isisCircLevelTable, so that needs to be called out. jec> A person that is reading this MIB for the first time is not likely to jec> understand. From an agent developer's point of view, this was jec> not at all clear. If the CircLevel table is read-only, I will fix. At present, I am between offices. jec> The objects in the CircLevelTable that are read-create need jec> to be made "read-write". (I didn't mention anything about read-only.) As to configuration, I can imagine configuring an interface/level that is not enabled yet. Since changing many attributes will force you to cycle adjacencies, you may want to configure them first, and then enable the Circuit for that level. Like selecting options on a car you don't own yet, it is less disruptive than trying to change them once the car is operational. jec> I think you have made my point for adding an OperStatus object jec> to this (CircLevelEntry) entry. It is all well and good if you expect that jec> you will always buy the perfect car that works as you expect jec> and as you pre-configured it, but you don't really know until jec> you actually get the car and turn it on and look at the gages/setting to jec> make sure that it really works. jec> Can you please comment on if you will be adding an OperStatus object? thanks, -Joan - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Aug 25 10:59:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21262 for ; Wed, 25 Aug 2004 10:59:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzyop-0004Ev-Oa; Wed, 25 Aug 2004 10:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxrVV-0001ny-Mi for isis-wg@megatron.ietf.org; Thu, 19 Aug 2004 14:19:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21533 for ; Thu, 19 Aug 2004 14:19:24 -0400 (EDT) Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxrbw-0001hU-6y for isis-wg@ietf.org; Thu, 19 Aug 2004 14:26:07 -0400 Received: from 216-15-118-244.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com ([216.15.118.244] helo=[192.168.1.100]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #7) id 1BxrVM-0006E1-00; Thu, 19 Aug 2004 14:19:17 -0400 Mime-Version: 1.0 X-Sender: jparker@pop.theworld.com Message-Id: In-Reply-To: <9081647.1092924184535.JavaMail.root@wamui03.slb.atl.earthlink.net> References: <9081647.1092924184535.JavaMail.root@wamui03.slb.atl.earthlink.net> Date: Thu, 19 Aug 2004 14:22:56 -0400 To: jcucchiara@mindspring.com, jparker@axiowave.com From: Jeff Parker Subject: Re: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-Mailman-Approved-At: Wed, 25 Aug 2004 10:32:06 -0400 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 10:03 AM -0400 8/19/04, jcucchiara@mindspring.com wrote: > >Hi Jeff, > >This is related to my question of yesterday on >how to populate the isisCircLevelTable.... > >In the isisCircTable, the object's description >below is unclear. Since this object is a read-create, >it is set by an operator, what does the isisSysType scalar >object have to do with this object? > > >isisCircLevel OBJECT-TYPE > SYNTAX INTEGER > { > level1(1), > level2(2), > level1L2(3) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Indicates which type of packets will be sent and > accepted on this circuit. The values used will be > modified by the settings of isisSysType. This > object follows the replaceOnlyWhileDisabled behavior." > DEFVAL { level1L2 } > ::= { isisCircEntry 8 } If the router is running at Level 1, and the circuit is configured to be L1 and L2, only L1 packets will appear. That is the imapct of isisSysType on the effectiveness of the circuit. Different implementations could react differently: rejecting values of CircLevel that don't match SysLevel, or silently accepting them. But CircLevel cannot overrule SysLevel. > > >Also, with regard to the isisCircLevelTable, is this object >supposed to indicate which Level needs to be populated by the agent? >In other words, does this object (above) denote what value the >isisCircLevelIndex (below) takes on? > >If this is correct, then why are only leve1IS(1) and level2IS(2) >the only options for the isisCircLevelIndex? > > >isisCircLevelIndex OBJECT-TYPE > SYNTAX INTEGER > { > level1IS (1), > level2IS (2) > } > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The level that this entry describes." > ::= { isisCircLevelEntry 1 } > > >Can these MIB descriptions be clarified? There appears to >be some relationship between the isisSysType (scalar), the >isisCircType object, and how an agent creates rows in the >isisCircLevelTable (i.e. the value of the isisCircLevelIndex), >but this is not documented anywhere in >the MIB and is very confusing from a developer's point of view. > > Thanks, > -Joan The CircLevel is an index into a table for values that are specific to a level. The MTU of a circuit is level independent, while the Hello Timers can have different values for different levels. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Aug 25 10:59:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21366 for ; Wed, 25 Aug 2004 10:59:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzyoq-0004F0-38; Wed, 25 Aug 2004 10:32:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxrYm-0002C1-MK for isis-wg@megatron.ietf.org; Thu, 19 Aug 2004 14:22:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21891 for ; Thu, 19 Aug 2004 14:22:47 -0400 (EDT) Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxrfF-0001lY-Qd for isis-wg@ietf.org; Thu, 19 Aug 2004 14:29:30 -0400 Received: from 216-15-118-244.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com ([216.15.118.244] helo=[192.168.1.100]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #7) id 1BxrYf-0006rn-01; Thu, 19 Aug 2004 14:22:43 -0400 Mime-Version: 1.0 X-Sender: jparker@pop.theworld.com Message-Id: In-Reply-To: <37701240971DD31193970000F6CCB9F705042511@duke.datcon.co.uk> References: <37701240971DD31193970000F6CCB9F705042511@duke.datcon.co.uk> Date: Thu, 19 Aug 2004 14:25:54 -0400 To: Jonathan Harrison , "'jcucchiara@mindspring.com'" , jparker@axiowave.com From: Jeff Parker Subject: RE: [Isis-wg] question on the relationship between isisSysType, i sisCircType and isisCircLevelIndex Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Wed, 25 Aug 2004 10:32:06 -0400 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 5:13 PM +0100 8/19/04, Jonathan Harrison wrote: >Joan, Jeff, > >I suggest we clarify the isisCircLevel description text to read as follows. > >"Indicates the configured level of the circuit. The actual level at which >the circuit operates is taken from the overlap of the value of this object >and the value of isisSysType, and this overlap decides which type of packets >will be sent and accepted on this circuit. This object follows the >replaceOnlyWhileDisabled behavior." > > >To answer your other points: > > - As described in my previous mail, this object should not affect the >existence of entries in the isisCircLevelTable. > > - Since the indexing of the isisCircLevelTable already allows the circuit >to be configured separately at level 1 and level 2, there is no need to >allow an isisCircLevelTable entry to have an index of level1L2. > >Jon Jon - That text is clearer than what I have, and I will adopt it. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Aug 26 10:37:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05600 for ; Thu, 26 Aug 2004 10:37:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0L6E-0001WH-OA; Thu, 26 Aug 2004 10:19:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0KsE-0004RI-9C for isis-wg@megatron.ietf.org; Thu, 26 Aug 2004 10:05:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28358 for ; Thu, 26 Aug 2004 09:10:10 -0400 (EDT) From: jcucchiara@mindspring.com Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0K1z-0003iE-3g for isis-wg@ietf.org; Thu, 26 Aug 2004 09:11:10 -0400 Received: from h-67-100-203-184.cmbrmaor.dynamic.covad.net ([67.100.203.184] helo=jluciani-laptop) by hall.mail.mindspring.net with smtp (Exim 3.33 #1) id 1C0K0p-0000aB-00; Thu, 26 Aug 2004 09:09:55 -0400 Message-Id: <3.0.1.32.20040826091704.01330a24@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 26 Aug 2004 09:17:04 -0400 To: Jonathan Harrison , jparker@world.std.com, jparker@axiowave.com Subject: RE: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex In-Reply-To: <37701240971DD31193970000F6CCB9F70504251E@duke.datcon.co.uk > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.5 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 11:24 AM 8/23/04 +0100, Jonathan Harrison wrote: >Joan, Jeff, Hi Jon, > >Some comments to hopefully clarify the use of the isisCircLevel and >isisSysType objects, and to sum up the discussion so far. > > - The isisSysType object is required, as it defines the level(s) at which >the IS-IS instance operates. > > - Even if isisSysType is level1L2IS, some circuits may be required to act >at level 1 only or level 2 only. Hence the isisCircLevel object is required >to define the level(s) at which a circuit operates. > The text in the descriptions needs to be clarified to explain this relationship. Also, shouldn't there be some errors returned under certain circumstances? For example, if the sysType object is Level1, then an operator should receive an error if the circType is set to Level2 or Level1Level2 (would guess an Inconsistent Value error would be appropriate). This should all be specified in the MIB. As I said before, a person looking at this MIB for the first time (like myself) needs this information to develop an agent which is consistent with other vendors. > - Two entries in the isisCircLevelTable exist for every isisCircTable >entry. One for level 1 and one for level 2. The comments for >isisCircLevelEntry are pretty clear about this: "An isisCircLevelEntry >exists for each level on each circuit used by Integrated IS-IS on this >system." > This is not clear if the SysType and CircuitType are set to Level1, then that second level row is not being used. That is not how I interpret the phrase "used by Integrated IS-IS" as the second level row is not "used" in my humble opinion. So again, am just asking for better text here. I would think something like, "This table will contain 2 rows (one for level1 and one for level2) per circuit. Both of the rows per circuit will be "in use" if the SysType and CircuitType corresponding to this row is Level1Level2. If the value of SysType is Level1 or Level1Level2 and the value of CircuitType is Level1, then only the level1 row will be in use and the level2 row is not in use. If the value of SysType is Level1Level2 or Level2 and the value of CircuitType is Level2, then only the level2 row will be in use and the level1 row is not in use." The above description assumes that the operator receives an error if he/she sets the CircuitType to be a superset of SysType (as discussed above). > - A physical link failure could cause a circuit with isisCircAdminState >'on' to become unusable. This should probably be reflected in the MIB by an >oper status object in the isisCircTable. For example, we could define an >isisCircOperState object as follows. > > isisCircOperState OBJECT-TYPE > SYNTAX INTEGER { > operStatusUp(1), -- active > operStatusDown(2), -- inactive > operStatusGoingUp(3), -- activating > operStatusGoingDown(4),-- deactivating > operStatusActFailed(5) -- activation failed > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The operational state of this circuit." > ::= { isisCircEntry 5 } I do think this is a good idea, but a physical link failure would show up in ifOperStatus, but these do add some slightly different descriptions so this is fine. > >With this change, I don't believe there is a need for an oper-status for the >isisCircLevel table, as the status of each level could be deduced from the >circuit oper-status, together with the isisSysType and isisCircLevel >objects. > Isn't it possible that a circuit on a specific level could fail, without the circuit on the other level failing? Especially if an operator preconfigures a row, I would think that an operStatus object of some sort would be a good idea here. > - As Joan says, because there is no row status in the isisCircLevel table, >the MAX-ACCESS for the modifiable objects must be "read-create" rather than >"read-write". > > - With regards to the isisAreaAddr and isisManAreaAddr table, I still >believe that they are correct as they are at present. The tables should be >separate, because the two tables perform different functions. There should >be no compiler problems with the isisAreaAddr table - a read-only index is >allowed by SMIv2 if the object is the only one in the table (see for >example, RFC2578, 7.7: > > "(2) a conceptual row must contain at least one columnar object which is > not an auxiliary object. In the event that all of a conceptual > row's columnar objects are also specified in its INDEX clause, then > one of them must be accessible, i.e., have a MAX-ACCESS clause of > "read-only". (Note that this situation does not arise for a > conceptual row allowing create access, since such a row will have a > status column which will not be an auxiliary object.)" > I get a warning/error in my compiler so will ask on the mibs list about this, it could be the compiler. In any case, I prefer one table with an additional object to denote manual/learned, but can see that we don't agree on this point ;) so 2 tables are acceptable. -Joan >Jon > >-----Original Message----- >From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On >Behalf Of jcucchiara@mindspring.com >Sent: 20 August 2004 18:16 >To: jparker@world.std.com; jparker@axiowave.com >Cc: isis-wg@ietf.org; Jonathan Harrison >Subject: Re: [Isis-wg] question on the relationship between isisSysType, >isisCircType and isisCircLevelIndex > > > >Hi, > >My comments are prefaced with "jec>" > > >-----Original Message----- >From: Jeff Parker >Sent: Aug 20, 2004 11:38 AM >To: jcucchiara@mindspring.com >Cc: on.harrison@dataconnection.com, <;isis-wg@ietf.org> >Subject: Re: [Isis-wg] question on the relationship between isisSysType, >isisCircType and isisCircLevelIndex > >> >> >>I assume you mean CircType in the above paragraph (not CircLevel), right? >> >>I don't understand this answer. The agent is ALWAYS supposed to create >>2 rows for every circuit in the CircLevelTable, one row which is circ + >Level1 >>and the 2nd row which is circ + Level2, correct? Then the agent is >>supposed to look at SysLevel (scalar) object to figure out if one or both >>(i.e. Level1 or Level2 or both) are actually being used in ISIS routing. >> >>I think that a better design would be to add an operStatus type of object >>to the CircLevelEntry to specify that the row is or is not being >>used in routing. >> >>Could the DESCRIPTION clauses of the scalar object and >>the circLevelTable be clarified so that the relationship between the >>sysLevel scalar and how rows are created in this table is described? >> >>Additionally, the read-create objects in the >>circLevelTable need to be changed to read-write. The agent is responsible >>for creating these rows, thus, read-write should be fine. >> >>What is the purpose of the isisCircType object in the isisCircEntry? I >don't >>see any purpose for this object, should it be removed? If a Circuit >>is referring >>to SysLevel to see what types of packets to send/receive on the circuit, >>then isisCircType is useless. > >jec> Could you respond to the above concern? I don't see a need for >jec> the isisCircType object since sysLevel overrides this, so could >jec> this object be removed? Please comment. > > >My mail is not appearing on the mail list, probably because my POP >and SMTP servers are different. > >Jon has proposed language that I can accept. I trust this addresses >your issue about how the fields interact. > >jec> The text does not mention how rows are to be created by the >jec> agent in the isisCircLevelTable, so that needs to be called out. >jec> A person that is reading this MIB for the first time is not likely to >jec> understand. From an agent developer's point of view, this was >jec> not at all clear. > > >If the CircLevel table is read-only, I will fix. At present, I am >between offices. > >jec> The objects in the CircLevelTable that are read-create need >jec> to be made "read-write". (I didn't mention anything about >read-only.) > >As to configuration, I can imagine configuring an interface/level >that is not enabled yet. Since changing many attributes will force >you to cycle adjacencies, you may want to configure them first, and >then enable the Circuit for that level. Like selecting options on a >car you don't own yet, it is less disruptive than trying to change >them once the car is operational. > > >jec> I think you have made my point for adding an OperStatus object >jec> to this (CircLevelEntry) entry. It is all well and good if you expect >that >jec> you will always buy the perfect car that works as you expect >jec> and as you pre-configured it, but you don't really know until >jec> you actually get the car and turn it on and look at the gages/setting >to >jec> make sure that it really works. >jec> Can you please comment on if you will be adding an OperStatus object? > > >thanks, > -Joan > > > >- jeff parker > > > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Aug 27 12:26:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13695 for ; Fri, 27 Aug 2004 12:26:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jTl-0002AH-H8; Fri, 27 Aug 2004 12:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0jAZ-00048Z-Qp for isis-wg@megatron.ietf.org; Fri, 27 Aug 2004 12:01:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11870 for ; Fri, 27 Aug 2004 12:01:36 -0400 (EDT) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0jBj-0004y0-K0 for isis-wg@ietf.org; Fri, 27 Aug 2004 12:02:52 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 9F9DE3DCC8C for ; Fri, 27 Aug 2004 09:01:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <49BCAC90-F842-11D8-B6C8-00039303E9E2@rawdofmt.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ISIS-WG (E-mail) From: Christian Hopps Date: Fri, 27 Aug 2004 09:00:59 -0700 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] IETF60 WG meeting notes X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Folks, We had a snafu during the meeting and apparently our scribe didn't know that he was our scribe. Can anyone who took notes during the meeting please send them to me so that I can construct minutes? Thanks, Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg