From isis-wg-bounces@ietf.org Fri Oct 1 04:04:19 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 EAA04251 for ; Fri, 1 Oct 2004 04:04:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIGH-0002Oy-5E; Fri, 01 Oct 2004 03:55:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIDv-0001Kt-Qj for isis-wg@megatron.ietf.org; Fri, 01 Oct 2004 03:53:03 -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 DAA03361 for ; Fri, 1 Oct 2004 03:53:02 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.196] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIMK-0000NE-JE for isis-wg@ietf.org; Fri, 01 Oct 2004 04:01:45 -0400 Received: by mproxy.gmail.com with SMTP id 75so602510rnk for ; Fri, 01 Oct 2004 00:53:01 -0700 (PDT) Received: by 10.38.59.51 with SMTP id h51mr3359068rna; Fri, 01 Oct 2004 00:53:00 -0700 (PDT) Received: by 10.38.102.60 with HTTP; Fri, 1 Oct 2004 00:52:54 -0700 (PDT) Message-ID: Date: Fri, 1 Oct 2004 13:22:54 +0530 From: Abhishek Verma To: isis-wg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Voids in LSP? X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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, One thing which i noticed in OSPF was that each individual route can be advertised in a separate LSA. And multiple LSAs can be clubbed inside one LSUpdate message. If i understand correctly, then this for some reason seems to be missing in ISIS. Say, i receive a route. I try fitting this into one LSP. I find that it cant fit, so i create a new LSP and put this route there. I thus end up advertising two LSPs. Now, suppose some routing information that i had stored in the first LSP goes away, and makes enough space for me to fit the route that i have in the new LSP here in the first LSP. Will i remove the information from the 2nd LSP and try to fit this in the first one? If not, then cant it lead to a lot of waste spaces inside an LSP? I mean, routes can come and go and cant that create voids in an LSP? I think, now if i get some new routing information i will try to fit that into my original LSP. If it can fit there, then i will advertise this LSP. Only, if it cant fit, then i will use my next new LSP which i had created. Is this how it works? Thanks, Abhishek V. P.S. BTW is there a document/URL which can tell tell me of how and where the two protocols ISIS and OSPF differ? -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Oct 2 09:53:41 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 JAA17673 for ; Sat, 2 Oct 2004 09:53: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 1CDkHf-0003Mm-Pk; Sat, 02 Oct 2004 09:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDkGD-00021K-2C for isis-wg@megatron.ietf.org; Sat, 02 Oct 2004 09:49:17 -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 JAA17449 for ; Sat, 2 Oct 2004 09:49:15 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.199] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDkOr-00033e-Sk for isis-wg@ietf.org; Sat, 02 Oct 2004 09:58:15 -0400 Received: by mproxy.gmail.com with SMTP id 73so3270170rnk for ; Sat, 02 Oct 2004 06:49:08 -0700 (PDT) Received: by 10.38.92.61 with SMTP id p61mr2769944rnb; Sat, 02 Oct 2004 06:49:08 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Sat, 2 Oct 2004 06:49:08 -0700 (PDT) Message-ID: Date: Sat, 2 Oct 2004 19:19:08 +0530 From: Abhishek Verma To: isis-wg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] FW: Voids in LSP X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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 In case my previous mail got lost! > Hi, > > One thing which i noticed in OSPF was that each individual route can > be advertised in a separate LSA. And multiple LSAs can be clubbed > inside one LSUpdate message. If i understand correctly, then this for > some reason seems to be missing in ISIS. > > Say, i receive a route. I try fitting this into one LSP. I find that > it cant fit, so i create a new LSP and put this route there. I thus > end up advertising two LSPs. Now, suppose some routing information > that i had stored in the first LSP goes away, and makes enough space > for me to fit the route that i have in the new LSP here in the first > LSP. > > Will i remove the information from the 2nd LSP and try to fit this in > the first one? > > If not, then cant it lead to a lot of waste spaces inside an LSP? I > mean, routes can come and go and cant that create voids in an LSP? > > I think, now if i get some new routing information i will try to fit > that into my original LSP. If it can fit there, then i will advertise > this LSP. Only, if it cant fit, then i will use my next new LSP which > i had created. > > Is this how it works? > > Thanks, > Abhishek V. > > P.S. > > BTW is there a document/URL which can tell tell me of how and where > the two protocols ISIS and OSPF differ? > > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Oct 2 20:18:33 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 UAA18082 for ; Sat, 2 Oct 2004 20:18:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDu2c-0001q3-3I; Sat, 02 Oct 2004 20:15:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDu0k-0008Rx-Hm for isis-wg@megatron.ietf.org; Sat, 02 Oct 2004 20:14:03 -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 UAA17770 for ; Sat, 2 Oct 2004 20:13:56 -0400 (EDT) From: jcucchiara@mindspring.com Received: from tisch.mail.mindspring.net ([207.69.200.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDu9S-0007Om-7h for isis-wg@ietf.org; Sat, 02 Oct 2004 20:23:01 -0400 Received: from h-66-167-249-136.cmbrmaor.dynamic.covad.net ([66.167.249.136] helo=jluciani-laptop) by tisch.mail.mindspring.net with smtp (Exim 3.33 #1) id 1CDu0b-00083K-00; Sat, 02 Oct 2004 20:13:50 -0400 Message-Id: <3.0.1.32.20041002202245.01274bd0@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 02 Oct 2004 20:22:45 -0400 To: Christian Hopps , ISIS-WG (E-mail) Subject: Re: [Isis-wg] MIB again :) In-Reply-To: <547FDDCE-1308-11D9-BDBB-000D93C60674@rawdofmt.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: Jeff Parker , jeffp@middlebury.edu 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 Chris, The MIB does not compile cleanly with the smicng and smiLint MIB compilers which are recommended by the MIB Dr. review. I would prefer to see the MIB compile cleanly before making comments, but will re-interate comments I have made so far to the list. Some may have been discussed but am putting them in one email for completeness. (I sent output for smicng to the list already.) Comments: * MAJOR comment on the following Notifications: Having an agent keep track of ALL the source addresses so that a check is performed on every packet from every source to detect the following situations for these notifications and then send a single notification is extremely resource intensive for the device. - isisIDLenMismatch - isisMaxAreaAddressesMismatch - isisAuthenticationTypeFailure - isisAuthenticationFailure - isisVersionSkew - isisAreaMismatch - isisRejectedAdjacency - isisLSPTooLargeToPropagate - isisOrigLSPBuffSizeMismatch - isisProtocolsSupportedMismatch My suggestion would be to have an OPTIONAL table which kept track of sources and a counter for each of these situations, such that an operator could send notifications (or not) based on some threshold he/she determined The reason that I would make this table OPTIONAL is because it is not clear to me that anyone would want their device to check every single packet from every single source look for these errors. I also question wheter VersionSkew would happen for a protocol that only has one version. * 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. Please replace the above with isisCircIndex OBJECT-TYPE SYNTAX IndexInteger * could isisCircIfSubIndex be renamed to something else? (The description of this object shows that it is not an "ifIndex" but the name of the object leads one to believe that it is.) * could isisCircSmallHellos appear in the conformance statement as optional, it doesn't seem like this feature is part of ISIS * The isisManAreaAddrTable and the isisAreaAddrTable could be combined because they contain the same info. The only difference being that area addresses in the Manual Area Address Table are manually configured. An object could be added to denote how the address appeared in the table, e.g. 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." * The following indices seem to have somewhat random terminating values. If there is a reason for the choosen value, could this be described in the DESCRIPTION clause for that index? isisLSPTLVIndex OBJECT-TYPE SYNTAX Unsigned32 (1..1000000) isisCircIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) isisISAdjIndex OBJECT-TYPE SYNTAX Integer32 (1..2000000000) isisISAdjAreaAddrIndex OBJECT-TYPE SYNTAX Integer32 (1..2000000000) isisISAdjIPAddrIndex OBJECT-TYPE SYNTAX Integer32 (1..2000000000) isisRAIndex OBJECT-TYPE SYNTAX Integer32 (1..2000000000) isisIPRANextHopIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) The mib review guidelines state: " - Unsigned32 with a range that excludes zero is RECOMMENDED for most index objects. It is acceptable to include zero in the range when it is semantically significant or when it is used as the index value for a unique row with special properties. Such usage SHOULD be clearly documented in the DESCRIPTION clause." If there is no reasons for these specific terminating values, then could the above indices be changed to Unsigned32(1..4294967295)? * Could the isisISAdjProtSuppProtocol object be added to the IsisISAdjEntry? The isisISAdjProtSuppTable and isisISAdjTable have the same indices of (isisCircIndex, isisISAdjIndex) and so moving the isisISAdjProtSuppProtocol object into the isisISAdjTable would simplify the MIB and more importantly, group information that is the same in the same table. * The conformance statements should specify address types and lengths of addresses for example from rfc3289: OBJECT diffServMultiFieldClfrAddrType SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and IPv6 addresses." OBJECT diffServMultiFieldClfrDstAddr SYNTAX InetAddress (SIZE(0|4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." * Also, if you could add a conformance for the RowStatus objects such that createAndWait and notInService are not required that would be more flexible and especially appropriate for those tables that contain only a RowStatus object. For example from rfc3289: OBJECT diffServClfrStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." At 10:44 AM 9/30/04 -0700, Christian Hopps wrote: >Ok I made the bold claim that we would be done with the MIB by this >month. I think it's fair to say we won't be able to achieve that goal. > >Anyway, I'd like to come to an understanding about what we think the >open issues are and close them. > >A brief read through my mailbox highlighted at least a couple issues: > >1) Protocol supported > . Should we use a BITS scalar? > . Should we have 2 scalars, "Supported" and "Enabled"? > I believe that some consensus was reached to have 2 scalar objects to replace the table. Here is email which attempted to summarize this. 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. 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 } 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. >2) isisCircLevelEntry/isisSyslevelEntry Rows > . Should the values in the isisCircLevelEntrys be read-write or >read-create > I believe we agreed on read-write, and that the 2 rows per Circuit or System would always be there (and automatically created by the agent). There was ongoing (and inclusive) discussion on adding OperStatus objects. I would be in favor of adding OperStatus objects since sometimes the rows are "active" and sometimes they are just there. >For 1) Yes to both seems reasonable to me. I didn't see anyway comment >on this and the thread sort of died before this was answered. > I pasted in the email above which I hope summarizes the email discussion for 1. >For 2) my understanding with the isisCircLevelEntry (similar for >isisSysLevelEntry) is that currently the rows will be created *if they >don't exist already* according to what the user has set isisCircLevel >to in the isisCircEntry Row for the given circuit; however, the user >could create (read-create access) a value in a isisCircLevelEntry row >to configure a row that isn't supported by the isisCircLevel value in >the isisCircEntry. > >This seems somewhat useful, but complex. Are there examples of this in >other protocol MIBs? > I am not really in favor of preconfiguring using MIB objects, unless there are OperStatus objects to let me know what the status of the rows are when they go active. >From my experience with operators, they tend to not do much preconfiguration either. Nevertheless, it seemed there was more support having the 2 rows (level1 and level2) created by the agent. I do believe that more description for the relationships between some scalars and these tables is needed. I suggested some text in one of the emails to the list as an example: "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." Additionally, error return values need to be specified for certain situations that could occur in modify SysType/CircuitType under the wrong conditions. Thanks, -Joan >IANAME (I am not a MIB expert). > >Chris. > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 4 00:44:37 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 AAA05579 for ; Mon, 4 Oct 2004 00:44:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKPU-0006Iu-52; Mon, 04 Oct 2004 00:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKGc-0007rY-7S for isis-wg@megatron.ietf.org; Mon, 04 Oct 2004 00:16: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 AAA28402 for ; Mon, 4 Oct 2004 00:16:00 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDzl5-0000GF-L6 for isis-wg@ietf.org; Sun, 03 Oct 2004 02:22:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 02 Oct 2004 23:13:35 -0700 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 i936CDwp012468; Sat, 2 Oct 2004 23:12:13 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn4-99.cisco.com [10.21.80.99]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUK29328; Sat, 2 Oct 2004 23:09:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20041002225158.021a0ea0@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 02 Oct 2004 23:12:07 -0700 To: Abhishek Verma From: Les Ginsberg Subject: Re: [Isis-wg] Voids in LSP? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 01:22 PM 10/1/2004 +0530, Abhishek Verma wrote: >Hi, > >One thing which i noticed in OSPF was that each individual route can >be advertised in a separate LSA. And multiple LSAs can be clubbed >inside one LSUpdate message. If i understand correctly, then this for >some reason seems to be missing in ISIS. IS-IS uses a TLV based encoding scheme which has proven to be very efficient in terms of the number of bytes required to advertise multiple prefixes/neighbors etc. and has made it easy to extend the protocol. Multiple prefixes are routinely advertised in a single LSP PDU. >Say, i receive a route. I try fitting this into one LSP. I find that >it cant fit, so i create a new LSP and put this route there. I thus >end up advertising two LSPs. Now, suppose some routing information >that i had stored in the first LSP goes away, and makes enough space >for me to fit the route that i have in the new LSP here in the first >LSP. > >Will i remove the information from the 2nd LSP and try to fit this in >the first one? This would be undesirable as it unnecessarily causes increased flooding (2 LSPs updated instead of one) and possibly more SPFs run network-wide as a result. >If not, then cant it lead to a lot of waste spaces inside an LSP? I >mean, routes can come and go and cant that create voids in an LSP? It is certainly possible to have multiple LSP fragments none of which are full. Implementations can (and should) minimize this by always inserting new routing information into existing fragments whenever possible. Les >I think, now if i get some new routing information i will try to fit >that into my original LSP. If it can fit there, then i will advertise >this LSP. Only, if it cant fit, then i will use my next new LSP which >i had created. > >Is this how it works? > >Thanks, >Abhishek V. > >P.S. > >BTW is there a document/URL which can tell tell me of how and where >the two protocols ISIS and OSPF differ? > >-- >Class of 2004 >Institute of Technology, BHU >Varanasi, India > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 4 09:40: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 JAA05005 for ; Mon, 4 Oct 2004 09:40: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 1CET1w-0008BO-2R; Mon, 04 Oct 2004 09:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CET06-0007p5-Q4 for isis-wg@megatron.ietf.org; Mon, 04 Oct 2004 09:35: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 JAA04693 for ; Mon, 4 Oct 2004 09:35:36 -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 1CET9B-0001la-PX for isis-wg@ietf.org; Mon, 04 Oct 2004 09:45:02 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <4HNQ3DBS>; Mon, 4 Oct 2004 14:35:01 +0100 Message-ID: <37701240971DD31193970000F6CCB9F705042660@duke.datcon.co.uk> From: Jonathan Harrison To: Jeff Parker , jeffp@middlebury.edu Date: Mon, 4 Oct 2004 14:34:46 +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: 8b431ad66d60be2d47c7bfeb879db82c Cc: "'isis-wg@ietf.org'" Subject: [Isis-wg] IS-IS MIB bugs 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 Jeff, We've got a few more comments on draft 16 of the MIB. These are mainly very minor editorial points, so shouldn't be too controversial. - The objects with syntax TimeTicks should not have units "seconds". (The description of TimeTicks says "hundredths of seconds since an epoch".) - The isisSummAddress and isisRedistributeAddrAddress objects should be constrained to only include the relevant part of the prefix. For example, as currently defined, it would be possible to configure an entry in the table for each of 172.19.11.89/24 and 172.19.11.51/24 (since these both have a different index), even though they refer to a single summary prefix. It would be better for the MIB to mandate that the single entry 172.19.11.0/24 be configured instead. It should be sufficient to add text such as the following to the description of these objects: "The address must not contain any set host bits (bits set after the address prefix determined by isisSummAddrPrefixLen)." - There are a couple of typos in the comments for the Level 1 Manual Area Address Table: - "table for for which" should read "table for which" - "create more 3 rows" should read "create more than 3 rows" - Description for "Level 1 LSPs with segment number" should be "Level 1 LSPs with fragment number" - The description for isisLSPTLVTable should be something like "The table of TLVs in LSPs in the database." - The description for isisLSPTLVEntry should be something like "Each entry describes a TLV within an LSP currently stored in the system." - There is a missing . at the end of the following descriptions. isisSysStatPartChanges isisSysLevelSetOverload isisCircIfIndex isisCircIfSubIndex isisCircLevelHelloMultiplier isisPacketCounterTable isisPacketCounterEntry isisISAdjState - The spacing in the Unsigned16TC, and Unsigned8TC definitions (after 'SYNTAX' and 'STATUS') is inconsistent with other textual conventions. - There is an extra blank line after isisISAdj OBJECT IDENTIFIER ::= { isisObjects 6 }, and before isisISAdjUsage Thanks, Jon _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 4 09:47: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 JAA05517 for ; Mon, 4 Oct 2004 09:47: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 1CET9i-0000Gy-4A; Mon, 04 Oct 2004 09:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CET31-0008HB-Ad for isis-wg@megatron.ietf.org; Mon, 04 Oct 2004 09:38: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 JAA04861 for ; Mon, 4 Oct 2004 09:38:34 -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 1CETC1-0001op-NI for isis-wg@ietf.org; Mon, 04 Oct 2004 09:48:00 -0400 Received: from h-67-100-203-154.cmbrmaor.dynamic.covad.net ([67.100.203.154] helo=jluciani-laptop) by blount.mail.mindspring.net with smtp (Exim 3.33 #1) id 1CET2q-0005qF-00; Mon, 04 Oct 2004 09:38:28 -0400 Message-Id: <3.0.1.32.20041004094533.01278964@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 04 Oct 2004 09:45:33 -0400 To: "Parker, Jeff" , Christian Hopps , "ISIS-WG (E-mail)" Subject: Re: [Isis-wg] MIB again :) In-Reply-To: References: <3.0.1.32.20041002202245.01274bd0@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.4 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 Cc: Jeff Parker 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 02:08 PM 10/3/04 -0400, Parker, Jeff wrote: >Thanks for the comments > >> HI Chris, >> >> >> The MIB does not compile cleanly with the smicng and smiLint MIB compilers >> which are recommended by the MIB Dr. review. I would prefer to see >> the MIB compile cleanly before making comments, but will re-interate >> comments I have made so far to the list. Some may have been discussed >> but am putting them in one email for completeness. >> (I sent output for smicng to the list already.) >> >> Comments: >> >> * MAJOR comment on the following Notifications: >> >> Having an agent keep track of ALL the source addresses >> so that a check is performed on every packet from every source to detect >> the following situations for these notifications and then >> send a single notification is extremely resource intensive for the >> device. >> >> - isisIDLenMismatch >> - isisMaxAreaAddressesMismatch >> - isisAuthenticationTypeFailure >> - isisAuthenticationFailure >> - isisVersionSkew >> - isisAreaMismatch >> - isisRejectedAdjacency >> - isisLSPTooLargeToPropagate >> - isisOrigLSPBuffSizeMismatch >> - isisProtocolsSupportedMismatch > >These are packets that the protocol needs to verify. >My intent is not that we keep track of every instance of these errors: the >MIB specifies only that we keep track of the first such error per interface. According to what ISIS specification? Furthermore, I have not seen this ever requested by members of the working group except for you. Making these optional certainly gives more flexibility and that's all I'm asking for. I don't see that these are required by any specification, so seems like making them optional is a completely reasonable request. You say that you do NOT need to track every instance, and yes, the damping policy is such that AFTER the first error occurs for that particular source address, that particular error does not need to be detected again, but that is not flexible damping policy (and I don't know of any other standard MIB that doesn't allow such things to be configurable). Regardless, my point is that this is an incredible amount of overhead to check for these errors on every single packet. I would like to ask that an informal poll be taken to see who has this implemented, and if operators find it useful to receive a single notification about a single occurance. Most operators would be interested if a node was acting up by repeatedly sending bad packets, so one bad packet is NOT indicative of a node which is problematic. >> >> My suggestion would be to have an OPTIONAL table which kept track of >> sources and a counter for each of these situations, such that an operator >> could send notifications (or not) based on some threshold he/she >> determined >> >> The reason that I would make this table OPTIONAL is because it is not >> clear to me that anyone would want their device to check every single >> packet from every single source look for these errors. >> I also question wheter VersionSkew would >> happen for a protocol that only has one version. >> >> >> * 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. >> >> Please replace the above with >> >> isisCircIndex OBJECT-TYPE >> SYNTAX IndexInteger >> >> >> * could isisCircIfSubIndex be renamed to something else? >> (The description of this object shows that it is not an "ifIndex" >> but the name of the object leads one to believe that it is.) >> >> * could isisCircSmallHellos appear in the >> conformance statement as optional, it doesn't seem like >> this feature is part of ISIS > >Not providing the padding that 10589 requires is what is at stake here. I >would argue that 10589 defines what is and isn't a feature of ISIS Jeff, Sorry, yes, we agreed in prior email(s) that this was okay to add. My mistake. Like I said, I cut and pasted from a bunch of my original emails and most of resolved issues did not put in again. I mistakenly added this one and should NOT have. >> >> * The isisManAreaAddrTable and the isisAreaAddrTable >> could be combined because they contain the same info. >> The only difference being that area addresses in the >> Manual Area Address Table are manually configured. >> An object could be added to denote how the address >> appeared in the table, e.g. >> >> >> 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." >> >> >> >> * The following indices seem to have somewhat random >> terminating values. If there is a reason for the choosen >> value, could this be described in the DESCRIPTION clause for >> that index? > >Nope. I have added values to silence the MIB compiler. I would be much >happier not having any such limits. I don't understand your response. These terminating values where NOT causing any MIB compiler issues, this is a semantic issue (one which is specified in the MIB review guidelines, see below where I quote from the MIB review guidelines). >> >> >> isisLSPTLVIndex OBJECT-TYPE >> SYNTAX Unsigned32 (1..1000000) >> >> isisCircIndex OBJECT-TYPE >> SYNTAX Integer32 (1..2147483647) >> >> isisISAdjIndex OBJECT-TYPE >> SYNTAX Integer32 (1..2000000000) >> >> isisISAdjAreaAddrIndex OBJECT-TYPE >> SYNTAX Integer32 (1..2000000000) >> >> isisISAdjIPAddrIndex OBJECT-TYPE >> SYNTAX Integer32 (1..2000000000) >> >> isisRAIndex OBJECT-TYPE >> SYNTAX Integer32 (1..2000000000) >> >> isisIPRANextHopIndex OBJECT-TYPE >> SYNTAX Integer32 (1..65535) >> >> >> The mib review guidelines state: >> " - Unsigned32 with a range that excludes zero is RECOMMENDED for >> most index objects. It is acceptable to include zero in the >> range when it is semantically significant or when it is used as >> the index value for a unique row with special properties. Such >> usage SHOULD be clearly documented in the DESCRIPTION clause." >> >> If there is no reasons for these specific terminating values, then >> could the above indices be changed to Unsigned32(1..4294967295)? >> >> >> * Could the isisISAdjProtSuppProtocol object be added to >> the IsisISAdjEntry? The isisISAdjProtSuppTable and >> isisISAdjTable have the same >> indices of (isisCircIndex, isisISAdjIndex) and so >> moving the isisISAdjProtSuppProtocol object into the >> isisISAdjTable would simplify the MIB and more importantly, >> group information that is the same in the same table. > >The issue is that an adjacency might support multiple protocols. Yes, and why can't an additional object in the isisISAdjTable convey this information? >> >> >> * The conformance statements should specify address types and lengths of >> addresses >> for example from rfc3289: >> >> OBJECT diffServMultiFieldClfrAddrType >> SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } >> DESCRIPTION >> "An implementation is only required to support IPv4 and IPv6 >> addresses." >> >> >> OBJECT diffServMultiFieldClfrDstAddr >> SYNTAX InetAddress (SIZE(0|4|16)) >> DESCRIPTION >> "An implementation is only required to support IPv4 and globally >> unique IPv6 addresses." >> >> * Also, if you could add a conformance for the RowStatus objects >> such that createAndWait and notInService are not required that would >> be more flexible and especially >> appropriate for those tables that contain only a RowStatus object. >> >> For example from rfc3289: >> >> OBJECT diffServClfrStatus >> SYNTAX RowStatus { active(1) } >> WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } >> DESCRIPTION >> "Support for createAndWait and notInService is not required." >> >> >> At 10:44 AM 9/30/04 -0700, Christian Hopps wrote: >>> Ok I made the bold claim that we would be done with the MIB by this >>> month. I think it's fair to say we won't be able to achieve that goal. >>> >>> Anyway, I'd like to come to an understanding about what we think the >>> open issues are and close them. >>> >>> A brief read through my mailbox highlighted at least a couple issues: >>> >>> 1) Protocol supported >>> . Should we use a BITS scalar? >>> . Should we have 2 scalars, "Supported" and "Enabled"? >>> >> >> I believe that some consensus was reached to have 2 scalar objects to >> replace the >> table. Here is email which attempted to summarize this. >> 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. >> >> 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 } >> >> >> 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. >> >> >>> 2) isisCircLevelEntry/isisSyslevelEntry Rows >>> . Should the values in the isisCircLevelEntrys be read-write or >>> read-create >>> >> >> I believe we agreed on read-write, and that the 2 rows per Circuit or System >> would always be there (and automatically created by the agent). >> There was ongoing (and inclusive) discussion on adding >> OperStatus objects. I would be in favor of adding OperStatus objects since >> sometimes the rows are "active" and sometimes they are just there. >> >>> For 1) Yes to both seems reasonable to me. I didn't see anyway comment >>> on this and the thread sort of died before this was answered. >>> >> >> I pasted in the email above which I hope summarizes the email discussion >> for 1. >> >>> For 2) my understanding with the isisCircLevelEntry (similar for >>> isisSysLevelEntry) is that currently the rows will be created *if they >>> don't exist already* according to what the user has set isisCircLevel >>> to in the isisCircEntry Row for the given circuit; however, the user >>> could create (read-create access) a value in a isisCircLevelEntry row >>> to configure a row that isn't supported by the isisCircLevel value in >>> the isisCircEntry. >>> >>> This seems somewhat useful, but complex. Are there examples of this in >>> other protocol MIBs? >>> >> >> I am not really in favor of preconfiguring using MIB objects, unless there >> are OperStatus objects to let me know what the status of the rows are when >> they >> go active. >> >> From my experience with operators, they tend to not do much preconfiguration >> either. Nevertheless, it seemed there was more support having the 2 rows >> (level1 and level2) created by the agent. I do believe that more description >> for the relationships between some scalars and these tables is needed. I >> suggested >> some text in one of the emails to the list as an example: >> >> "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." >> >> Additionally, error return values need to be specified for certain situations >> that could occur in modify SysType/CircuitType under the wrong conditions. >> Since many of my comments/concerns were not addressed, does this mean that they will be incorporated in the next version of the MIB? I'd sort of like some clarification since I have made most/all of the comments to the list before and would like to understand if these are going to be incorporated into the next version of the MIB. thanks, -Joan >> Thanks, >> -Joan >> >> >>> IANAME (I am not a MIB expert). >>> >>> Chris. >>> >>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/isis-wg >>> >> > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 4 12:22:00 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 MAA19127 for ; Mon, 4 Oct 2004 12:22:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEVRq-0002Dn-1C; Mon, 04 Oct 2004 12:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJp6-0007R0-Tz for isis-wg@megatron.ietf.org; Sun, 03 Oct 2004 23:47: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 XAA17492 for ; Sun, 3 Oct 2004 23:47:36 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEBbO-00069v-8g for isis-wg@ietf.org; Sun, 03 Oct 2004 15:01:09 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Sun, 3 Oct 2004 14:09:20 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Sun, 3 Oct 2004 14:08:56 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.186 140.233.20.186 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Sun, 03 Oct 2004 14:08:30 -0400 Subject: Re: [Isis-wg] MIB again :) From: "Parker, Jeff" To: , Christian Hopps , "ISIS-WG (E-mail)" Message-ID: In-Reply-To: <3.0.1.32.20041002202245.01274bd0@pop.mindspring.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Oct 2004 18:08:56.0906 (UTC) FILETIME=[0CC9AAA0:01C4A974] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 04 Oct 2004 12:12:19 -0400 Cc: Jeff Parker 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 Thanks for the comments > HI Chris, > > > The MIB does not compile cleanly with the smicng and smiLint MIB compilers > which are recommended by the MIB Dr. review. I would prefer to see > the MIB compile cleanly before making comments, but will re-interate > comments I have made so far to the list. Some may have been discussed > but am putting them in one email for completeness. > (I sent output for smicng to the list already.) > > Comments: > > * MAJOR comment on the following Notifications: > > Having an agent keep track of ALL the source addresses > so that a check is performed on every packet from every source to detect > the following situations for these notifications and then > send a single notification is extremely resource intensive for the > device. > > - isisIDLenMismatch > - isisMaxAreaAddressesMismatch > - isisAuthenticationTypeFailure > - isisAuthenticationFailure > - isisVersionSkew > - isisAreaMismatch > - isisRejectedAdjacency > - isisLSPTooLargeToPropagate > - isisOrigLSPBuffSizeMismatch > - isisProtocolsSupportedMismatch These are packets that the protocol needs to verify. My intent is not that we keep track of every instance of these errors: the MIB specifies only that we keep track of the first such error per interface. > > My suggestion would be to have an OPTIONAL table which kept track of > sources and a counter for each of these situations, such that an operator > could send notifications (or not) based on some threshold he/she > determined > > The reason that I would make this table OPTIONAL is because it is not > clear to me that anyone would want their device to check every single > packet from every single source look for these errors. > I also question wheter VersionSkew would > happen for a protocol that only has one version. > > > * 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. > > Please replace the above with > > isisCircIndex OBJECT-TYPE > SYNTAX IndexInteger > > > * could isisCircIfSubIndex be renamed to something else? > (The description of this object shows that it is not an "ifIndex" > but the name of the object leads one to believe that it is.) > > * could isisCircSmallHellos appear in the > conformance statement as optional, it doesn't seem like > this feature is part of ISIS Not providing the padding that 10589 requires is what is at stake here. I would argue that 10589 defines what is and isn't a feature of ISIS > > * The isisManAreaAddrTable and the isisAreaAddrTable > could be combined because they contain the same info. > The only difference being that area addresses in the > Manual Area Address Table are manually configured. > An object could be added to denote how the address > appeared in the table, e.g. > > > 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." > > > > * The following indices seem to have somewhat random > terminating values. If there is a reason for the choosen > value, could this be described in the DESCRIPTION clause for > that index? Nope. I have added values to silence the MIB compiler. I would be much happier not having any such limits. > > > isisLSPTLVIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..1000000) > > isisCircIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > > isisISAdjIndex OBJECT-TYPE > SYNTAX Integer32 (1..2000000000) > > isisISAdjAreaAddrIndex OBJECT-TYPE > SYNTAX Integer32 (1..2000000000) > > isisISAdjIPAddrIndex OBJECT-TYPE > SYNTAX Integer32 (1..2000000000) > > isisRAIndex OBJECT-TYPE > SYNTAX Integer32 (1..2000000000) > > isisIPRANextHopIndex OBJECT-TYPE > SYNTAX Integer32 (1..65535) > > > The mib review guidelines state: > " - Unsigned32 with a range that excludes zero is RECOMMENDED for > most index objects. It is acceptable to include zero in the > range when it is semantically significant or when it is used as > the index value for a unique row with special properties. Such > usage SHOULD be clearly documented in the DESCRIPTION clause." > > If there is no reasons for these specific terminating values, then > could the above indices be changed to Unsigned32(1..4294967295)? > > > * Could the isisISAdjProtSuppProtocol object be added to > the IsisISAdjEntry? The isisISAdjProtSuppTable and > isisISAdjTable have the same > indices of (isisCircIndex, isisISAdjIndex) and so > moving the isisISAdjProtSuppProtocol object into the > isisISAdjTable would simplify the MIB and more importantly, > group information that is the same in the same table. The issue is that an adjacency might support multiple protocols. > > > * The conformance statements should specify address types and lengths of > addresses > for example from rfc3289: > > OBJECT diffServMultiFieldClfrAddrType > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > DESCRIPTION > "An implementation is only required to support IPv4 and IPv6 > addresses." > > > OBJECT diffServMultiFieldClfrDstAddr > SYNTAX InetAddress (SIZE(0|4|16)) > DESCRIPTION > "An implementation is only required to support IPv4 and globally > unique IPv6 addresses." > > * Also, if you could add a conformance for the RowStatus objects > such that createAndWait and notInService are not required that would > be more flexible and especially > appropriate for those tables that contain only a RowStatus object. > > For example from rfc3289: > > OBJECT diffServClfrStatus > SYNTAX RowStatus { active(1) } > WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } > DESCRIPTION > "Support for createAndWait and notInService is not required." > > > At 10:44 AM 9/30/04 -0700, Christian Hopps wrote: >> Ok I made the bold claim that we would be done with the MIB by this >> month. I think it's fair to say we won't be able to achieve that goal. >> >> Anyway, I'd like to come to an understanding about what we think the >> open issues are and close them. >> >> A brief read through my mailbox highlighted at least a couple issues: >> >> 1) Protocol supported >> . Should we use a BITS scalar? >> . Should we have 2 scalars, "Supported" and "Enabled"? >> > > I believe that some consensus was reached to have 2 scalar objects to > replace the > table. Here is email which attempted to summarize this. > 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. > > 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 } > > > 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. > > >> 2) isisCircLevelEntry/isisSyslevelEntry Rows >> . Should the values in the isisCircLevelEntrys be read-write or >> read-create >> > > I believe we agreed on read-write, and that the 2 rows per Circuit or System > would always be there (and automatically created by the agent). > There was ongoing (and inclusive) discussion on adding > OperStatus objects. I would be in favor of adding OperStatus objects since > sometimes the rows are "active" and sometimes they are just there. > >> For 1) Yes to both seems reasonable to me. I didn't see anyway comment >> on this and the thread sort of died before this was answered. >> > > I pasted in the email above which I hope summarizes the email discussion > for 1. > >> For 2) my understanding with the isisCircLevelEntry (similar for >> isisSysLevelEntry) is that currently the rows will be created *if they >> don't exist already* according to what the user has set isisCircLevel >> to in the isisCircEntry Row for the given circuit; however, the user >> could create (read-create access) a value in a isisCircLevelEntry row >> to configure a row that isn't supported by the isisCircLevel value in >> the isisCircEntry. >> >> This seems somewhat useful, but complex. Are there examples of this in >> other protocol MIBs? >> > > I am not really in favor of preconfiguring using MIB objects, unless there > are OperStatus objects to let me know what the status of the rows are when > they > go active. > > From my experience with operators, they tend to not do much preconfiguration > either. Nevertheless, it seemed there was more support having the 2 rows > (level1 and level2) created by the agent. I do believe that more description > for the relationships between some scalars and these tables is needed. I > suggested > some text in one of the emails to the list as an example: > > "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." > > Additionally, error return values need to be specified for certain situations > that could occur in modify SysType/CircuitType under the wrong conditions. > > Thanks, > -Joan > > >> IANAME (I am not a MIB expert). >> >> Chris. >> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg >> > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 4 12:23: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 MAA19290 for ; Mon, 4 Oct 2004 12:23: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 1CEVRq-0002Dw-Cl; Mon, 04 Oct 2004 12:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETGc-0001YJ-TQ for isis-wg@megatron.ietf.org; Mon, 04 Oct 2004 09:52: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 JAA05795 for ; Mon, 4 Oct 2004 09:52:40 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CETPh-0004WF-N9 for isis-wg@ietf.org; Mon, 04 Oct 2004 10:02:06 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Mon, 4 Oct 2004 09:52:09 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Oct 2004 09:52:09 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.186 140.233.20.186 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Mon, 04 Oct 2004 09:52:08 -0400 Subject: Re: [Isis-wg] MIB again :) From: "Parker, Jeff" To: , Christian Hopps , "ISIS-WG (E-mail)" Message-ID: In-Reply-To: <3.0.1.32.20041004094533.01278964@pop.mindspring.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Oct 2004 13:52:09.0265 (UTC) FILETIME=[5787FA10:01C4AA19] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 04 Oct 2004 12:12:19 -0400 Cc: Jeff Parker 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 >>> - isisIDLenMismatch >>> - isisMaxAreaAddressesMismatch >>> - isisAuthenticationTypeFailure >>> - isisAuthenticationFailure >>> - isisVersionSkew >>> - isisAreaMismatch >>> - isisRejectedAdjacency >>> - isisLSPTooLargeToPropagate >>> - isisOrigLSPBuffSizeMismatch >>> - isisProtocolsSupportedMismatch >> >> These are packets that the protocol needs to verify. >> My intent is not that we keep track of every instance of these errors: the >> MIB specifies only that we keep track of the first such error per interface. > > According to what ISIS specification? Joan - This is pretty standard error checking for all but one of these. I agree tha BufferSizeMismatch is not required, but everything else must be checked on every packet. So there is no extra processing required: just extra storage per circuit. What the MIB specifies is that you keep a bit mask of 10 bits per interface, and that you send an event when you get your first error. A number of vendors have debug options that let you see this kind of check in real time, and the operators I have talked to find it essential in brining up links between different versions of the protocol. > Furthermore, I have not seen this > ever requested > by members of the working group except for you. Making these optional > certainly > gives more flexibility and that's all I'm asking for. I don't see that > these are required by any specification, so seems like making them optional > is a completely reasonable request. > > You say that you do NOT need to track every instance, and yes, the > damping policy is such that AFTER the first error occurs for that particular > source address, that particular error does not need to be detected again, but > that is not flexible damping policy (and I don't know of any other standard > MIB that doesn't allow such things to be configurable). Regardless, my > point is that this is an incredible amount of overhead to check for these > errors on every single packet. I would like to ask that an informal poll > be taken to see who has this implemented, and if operators find it useful > to receive a single notification about a single occurance. > > Most operators would be interested if a node was acting up by repeatedly > sending bad packets, so one bad packet is NOT indicative of a node which > is problematic. >>> * The following indices seem to have somewhat random >>> terminating values. If there is a reason for the choosen >>> value, could this be described in the DESCRIPTION clause for >>> that index? >> >> Nope. I have added values to silence the MIB compiler. I would be much >> happier not having any such limits. > > I don't understand your response. These terminating values where NOT > causing any MIB compiler issues, this is a semantic issue (one which > is specified in the MIB review guidelines, see below where I quote from > the MIB review guidelines). > >>> isisLSPTLVIndex OBJECT-TYPE >>> SYNTAX Unsigned32 (1..1000000) >>> >>> isisCircIndex OBJECT-TYPE >>> SYNTAX Integer32 (1..2147483647) >>> >>> isisISAdjIndex OBJECT-TYPE >>> SYNTAX Integer32 (1..2000000000) >>> >>> isisISAdjAreaAddrIndex OBJECT-TYPE >>> SYNTAX Integer32 (1..2000000000) >>> >>> isisISAdjIPAddrIndex OBJECT-TYPE >>> SYNTAX Integer32 (1..2000000000) >>> >>> isisRAIndex OBJECT-TYPE >>> SYNTAX Integer32 (1..2000000000) >>> >>> isisIPRANextHopIndex OBJECT-TYPE >>> SYNTAX Integer32 (1..65535) >>> >>> >>> The mib review guidelines state: >>> " - Unsigned32 with a range that excludes zero is RECOMMENDED for >>> most index objects. It is acceptable to include zero in the >>> range when it is semantically significant or when it is used as >>> the index value for a unique row with special properties. Such >>> usage SHOULD be clearly documented in the DESCRIPTION clause." >>> >>> If there is no reasons for these specific terminating values, then >>> could the above indices be changed to Unsigned32(1..4294967295)? I can try that. >>> * Could the isisISAdjProtSuppProtocol object be added to >>> the IsisISAdjEntry? The isisISAdjProtSuppTable and >>> isisISAdjTable have the same >>> indices of (isisCircIndex, isisISAdjIndex) and so >>> moving the isisISAdjProtSuppProtocol object into the >>> isisISAdjTable would simplify the MIB and more importantly, >>> group information that is the same in the same table. >> >> The issue is that an adjacency might support multiple protocols. > > Yes, and why can't an additional object in the isisISAdjTable convey this > information? My point is simply that a scalar cannot capture this. What do you propose? > Since many of my comments/concerns were not addressed, does this > mean that they will be incorporated in the next version of the MIB? > I'd sort of like some clarification since I have made most/all of the > comments to the list before and would like to understand if these > are going to be incorporated into the next version of the MIB. > > thanks, > -Joan Joan - I will work on a new draft, and hope to get it out this week. I am reviewing your comments. - 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 Oct 4 14:34:51 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 OAA01445 for ; Mon, 4 Oct 2004 14:34:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEXcy-0002Uo-Az; Mon, 04 Oct 2004 14:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEXUu-0001ZK-1L for isis-wg@megatron.ietf.org; Mon, 04 Oct 2004 14:23: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 OAA00697 for ; Mon, 4 Oct 2004 14:23:42 -0400 (EDT) Received: from firestar.cisco.com ([171.68.227.75] helo=fire.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEXe1-0005Yi-Jo for isis-wg@ietf.org; Mon, 04 Oct 2004 14:33:10 -0400 Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.98.126]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i94IIAC11607; Mon, 4 Oct 2004 11:18:10 -0700 (PDT) Date: Mon, 4 Oct 2004 11:18:10 -0700 (PDT) From: Shankar Vemulapalli To: Abhishek Verma Subject: Re: [Isis-wg] FW: Voids in LSP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Hi Abhishek - At 7:19pm 10/02/04 +0530, Abhishek Verma wrote: > > > > P.S. > > > > BTW is there a document/URL which can tell tell me of how and where > > the two protocols ISIS and OSPF differ? Take a look at Henk's e-mail @: http://www.merit.edu/mail.archives/nanog/1999-01/msg00012.html This is from Dave Katz @: http://www.nanog.org/mtg-0006/katz.html Also, check the John Moy's & Radia Perlman's books too.. Hope it helps. Thanks, /Shankar _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 4 17:42: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 RAA28962 for ; Mon, 4 Oct 2004 17:42:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEaJT-000496-Cb; Mon, 04 Oct 2004 17:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZFu-0006L6-BW for isis-wg@megatron.ietf.org; Mon, 04 Oct 2004 16:16:22 -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 QAA12258 for ; Mon, 4 Oct 2004 16:16:19 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEZP2-0007LM-Gc for isis-wg@ietf.org; Mon, 04 Oct 2004 16:25:49 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2004 16:34:12 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i94KFkEF014156; Mon, 4 Oct 2004 16:15:48 -0400 (EDT) Received: from jlearman-w2k03.cisco.com (dhcp-64-102-83-236.cisco.com [64.102.83.236]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCL36488; Mon, 4 Oct 2004 13:15:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20041004160234.0226c5c0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Oct 2004 16:03:45 -0400 To: Abhishek Verma , diff-ospf-isis@yahoogroups.com From: Jeff Learman Subject: Re: [Isis-wg] FW: Voids in LSP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 09:49 AM 10/2/2004, Abhishek Verma wrote: >> BTW is there a document/URL which can tell tell me of how and where >> the two protocols ISIS and OSPF differ? diff-ospf-isis group: We wrote a document on this. Anybody know where it ended up? Jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 4 17:42: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 RAA29009 for ; Mon, 4 Oct 2004 17:42: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 1CEaJU-0004Ci-IE; Mon, 04 Oct 2004 17:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZFv-0006Lt-UT for isis-wg@megatron.ietf.org; Mon, 04 Oct 2004 16:16: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 QAA12261 for ; Mon, 4 Oct 2004 16:16:21 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEZP4-0007LP-11 for isis-wg@ietf.org; Mon, 04 Oct 2004 16:25:51 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 04 Oct 2004 16:15:52 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i94KFkEH014156; Mon, 4 Oct 2004 16:15:50 -0400 (EDT) Received: from jlearman-w2k03.cisco.com (dhcp-64-102-83-236.cisco.com [64.102.83.236]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCL36489; Mon, 4 Oct 2004 13:15:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20041004160425.0226cac8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Oct 2004 16:14:20 -0400 To: Abhishek Verma , isis-wg@ietf.org From: Jeff Learman Subject: Re: [Isis-wg] FW: Voids in LSP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 09:49 AM 10/2/2004, Abhishek Verma wrote: >In case my previous mail got lost! > >> Hi, >> >> One thing which i noticed in OSPF was that each individual route can >> be advertised in a separate LSA. And multiple LSAs can be clubbed >> inside one LSUpdate message. If i understand correctly, then this for >> some reason seems to be missing in ISIS. >> >> Say, i receive a route. I try fitting this into one LSP. I find that >> it cant fit, so i create a new LSP and put this route there. I thus >> end up advertising two LSPs. Now, suppose some routing information >> that i had stored in the first LSP goes away, and makes enough space >> for me to fit the route that i have in the new LSP here in the first >> LSP. >> >> Will i remove the information from the 2nd LSP and try to fit this in >> the first one? >> >> If not, then cant it lead to a lot of waste spaces inside an LSP? I >> mean, routes can come and go and cant that create voids in an LSP? Not really. You're sending two LSPs where you could send one, but LSPs aren't fixed size, so other than the overhead of the additional LSP fragment, you're not wasting space. If other info comes in, you can put it there in some circumstances. ISO 10589 has some language about how it's nice not to make info "jump" from fragment to fragment. As I recall, it's not easy advice to follow. I think the silence you've received might be due to the fact that the behavior here is very implementation-dependent, and that you can do a very simple thing and your routers will interoperate, but might be less efficient than other implementations. So it's up to you to work out the issues here since it's not an interoperability problem. You need to work out your own compromise between minimizing the movement of info from LSP to LSP versus sending the minimum number of LSPs. In general, ISIS's flooding mechanism is very efficient and scalable from a bandwidth perspective. I know this from studies I've done for low-bandwidth lines like SONET SDCC (192 kBit/sec). Regardless, you still want to strike a good tradeoff between the two extremes. Regards, Jeff Disclaimer: I haven't worked on ISIS at Cisco, and I don't speak for Cisco in this WG. >> I think, now if i get some new routing information i will try to fit >> that into my original LSP. If it can fit there, then i will advertise >> this LSP. Only, if it cant fit, then i will use my next new LSP which >> i had created. >> >> Is this how it works? >> >> Thanks, >> Abhishek V. >> >> P.S. >> >> BTW is there a document/URL which can tell tell me of how and where >> the two protocols ISIS and OSPF differ? >> >> -- >> Class of 2004 >> Institute of Technology, BHU >> Varanasi, India >> > >_______________________________________________ >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 Oct 5 14:08:46 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 OAA21367 for ; Tue, 5 Oct 2004 14:08:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtZW-0000pU-Lt; Tue, 05 Oct 2004 13:57:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtX5-0000FJ-2C for isis-wg@megatron.ietf.org; Tue, 05 Oct 2004 13:55:29 -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 NAA20216 for ; Tue, 5 Oct 2004 13:55:25 -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 1CEtgP-0000m3-Dt for isis-wg@ietf.org; Tue, 05 Oct 2004 14:05:05 -0400 Received: from h-66-167-249-54.cmbrmaor.dynamic.covad.net ([66.167.249.54] helo=jluciani-laptop) by smtp10.atl.mindspring.net with smtp (Exim 3.33 #1) id 1CEtWz-0005LT-00; Tue, 05 Oct 2004 13:55:22 -0400 Message-Id: <3.0.1.32.20041005135802.0131df50@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 05 Oct 2004 13:58:02 -0400 To: "Parker, Jeff" , Christian Hopps , "ISIS-WG (E-mail)" Subject: Re: [Isis-wg] MIB again :) In-Reply-To: References: <3.0.1.32.20041004094533.01278964@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Jeff Parker 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 01:52 PM 10/4/04 +0000, Parker, Jeff wrote: > >>>> - isisIDLenMismatch >>>> - isisMaxAreaAddressesMismatch >>>> - isisAuthenticationTypeFailure >>>> - isisAuthenticationFailure >>>> - isisVersionSkew >>>> - isisAreaMismatch >>>> - isisRejectedAdjacency >>>> - isisLSPTooLargeToPropagate >>>> - isisOrigLSPBuffSizeMismatch >>>> - isisProtocolsSupportedMismatch >>> >>> These are packets that the protocol needs to verify. >>> My intent is not that we keep track of every instance of these errors: the >>> MIB specifies only that we keep track of the first such error per interface. >> >> According to what ISIS specification? > >Joan - > This is pretty standard error checking for all but one of these. I >agree tha BufferSizeMismatch is not required, but everything else must be >checked on every packet. So there is no extra processing required: just >extra storage per circuit. > What the MIB specifies is that you keep a bit mask of 10 bits per >interface, and that you send an event when you get your first error. A >number of vendors have debug options that let you see this kind of check in >real time, and the operators I have talked to find it essential in brining >up links between different versions of the protocol. The description that you are giving here is far from what is in the current MIB. It sounds like you are suggesting that these notifications are going to be changed to a single notification which returns a BITs object to say what the problem might be if an adjacency can't be set up. Is this what you are saying? Also, if I understand you correctly, then operators can also disable this checking and turn it on if they see that an adjacency is not being set up, is this correct? I still don't completely understand your comment about "bringing up links between different versions of the protocol" Isn't there only 1 version? > >> Furthermore, I have not seen this >> ever requested >> by members of the working group except for you. Making these optional >> certainly >> gives more flexibility and that's all I'm asking for. I don't see that >> these are required by any specification, so seems like making them optional >> is a completely reasonable request. >> >> You say that you do NOT need to track every instance, and yes, the >> damping policy is such that AFTER the first error occurs for that particular >> source address, that particular error does not need to be detected again, but >> that is not flexible damping policy (and I don't know of any other standard >> MIB that doesn't allow such things to be configurable). Regardless, my >> point is that this is an incredible amount of overhead to check for these >> errors on every single packet. I would like to ask that an informal poll >> be taken to see who has this implemented, and if operators find it useful >> to receive a single notification about a single occurance. >> >> Most operators would be interested if a node was acting up by repeatedly >> sending bad packets, so one bad packet is NOT indicative of a node which >> is problematic. > >>>> * The following indices seem to have somewhat random >>>> terminating values. If there is a reason for the choosen >>>> value, could this be described in the DESCRIPTION clause for >>>> that index? >>> >>> Nope. I have added values to silence the MIB compiler. I would be much >>> happier not having any such limits. >> >> I don't understand your response. These terminating values where NOT >> causing any MIB compiler issues, this is a semantic issue (one which >> is specified in the MIB review guidelines, see below where I quote from >> the MIB review guidelines). >> >>>> isisLSPTLVIndex OBJECT-TYPE >>>> SYNTAX Unsigned32 (1..1000000) >>>> >>>> isisCircIndex OBJECT-TYPE >>>> SYNTAX Integer32 (1..2147483647) >>>> >>>> isisISAdjIndex OBJECT-TYPE >>>> SYNTAX Integer32 (1..2000000000) >>>> >>>> isisISAdjAreaAddrIndex OBJECT-TYPE >>>> SYNTAX Integer32 (1..2000000000) >>>> >>>> isisISAdjIPAddrIndex OBJECT-TYPE >>>> SYNTAX Integer32 (1..2000000000) >>>> >>>> isisRAIndex OBJECT-TYPE >>>> SYNTAX Integer32 (1..2000000000) >>>> >>>> isisIPRANextHopIndex OBJECT-TYPE >>>> SYNTAX Integer32 (1..65535) >>>> >>>> >>>> The mib review guidelines state: >>>> " - Unsigned32 with a range that excludes zero is RECOMMENDED for >>>> most index objects. It is acceptable to include zero in the >>>> range when it is semantically significant or when it is used as >>>> the index value for a unique row with special properties. Such >>>> usage SHOULD be clearly documented in the DESCRIPTION clause." >>>> >>>> If there is no reasons for these specific terminating values, then >>>> could the above indices be changed to Unsigned32(1..4294967295)? > >I can try that. Great! > >>>> * Could the isisISAdjProtSuppProtocol object be added to >>>> the IsisISAdjEntry? The isisISAdjProtSuppTable and >>>> isisISAdjTable have the same >>>> indices of (isisCircIndex, isisISAdjIndex) and so >>>> moving the isisISAdjProtSuppProtocol object into the >>>> isisISAdjTable would simplify the MIB and more importantly, >>>> group information that is the same in the same table. >>> >>> The issue is that an adjacency might support multiple protocols. >> >> Yes, and why can't an additional object in the isisISAdjTable convey this >> information? > >My point is simply that a scalar cannot capture this. What do you propose? > I'm suggesting adding another object to isisISAdjEntry, e.g. isisISAdjNeighborProtocol OBJECT-TYPE SYNTAX SupportedProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The protocol as reported in the IIH PDUs received from the neighbor." ::= { isisISAdjEntry x } The additional object alleviates the need for the isisISAdjProtSuppTable. -Joan >> Since many of my comments/concerns were not addressed, does this >> mean that they will be incorporated in the next version of the MIB? >> I'd sort of like some clarification since I have made most/all of the >> comments to the list before and would like to understand if these >> are going to be incorporated into the next version of the MIB. >> >> thanks, >> -Joan > >Joan - > I will work on a new draft, and hope to get it out this week. I am >reviewing your comments. > >- jeff parker > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 5 16:33:59 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 QAA08150 for ; Tue, 5 Oct 2004 16:33:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvjw-0007rC-DZ; Tue, 05 Oct 2004 16:16:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvV8-0006HG-9g for isis-wg@megatron.ietf.org; Tue, 05 Oct 2004 16:01: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 QAA03221 for ; Tue, 5 Oct 2004 16:01:32 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEveT-0003Vk-Vl for isis-wg@ietf.org; Tue, 05 Oct 2004 16:11:14 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Tue, 5 Oct 2004 16:00:55 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Oct 2004 16:00:55 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.186 140.233.20.186 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Tue, 05 Oct 2004 16:00:54 -0400 From: "Parker, Jeff" To: "ISIS-WG (E-mail)" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Oct 2004 20:00:55.0242 (UTC) FILETIME=[060DE2A0:01C4AB16] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] ISIS MIB - costs of notifications 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 Edited version of mail unintentionally sent privately to Joan On 10/5/04 1:58 PM, "jcucchiara@mindspring.com" wrote: > At 01:52 PM 10/4/04 +0000, Parker, Jeff wrote: >> >>>>> - isisIDLenMismatch >>>>> - isisMaxAreaAddressesMismatch >>>>> - isisAuthenticationTypeFailure >>>>> - isisAuthenticationFailure >>>>> - isisVersionSkew >>>>> - isisAreaMismatch >>>>> - isisRejectedAdjacency >>>>> - isisLSPTooLargeToPropagate >>>>> - isisOrigLSPBuffSizeMismatch >>>>> - isisProtocolsSupportedMismatch >>>> >>>> These are packets that the protocol needs to verify. >>>> My intent is not that we keep track of every instance of these errors: the >>>> MIB specifies only that we keep track of the first such error per > interface. >>> >>> According to what ISIS specification? >> >> Joan - >> This is pretty standard error checking for all but one of these. I >> agree tha BufferSizeMismatch is not required, but everything else must be >> checked on every packet. So there is no extra processing required: just >> extra storage per circuit. >> What the MIB specifies is that you keep a bit mask of 10 bits per >> interface, and that you send an event when you get your first error. A >> number of vendors have debug options that let you see this kind of check in >> real time, and the operators I have talked to find it essential in brining >> up links between different versions of the protocol. > > The description that you are giving here is far from what is in the current > MIB. It sounds like you are suggesting that these notifications are going to > be changed to a single notification which returns a BITs object to say > what the problem might be if an adjacency can't be set up. Is this what you > are saying? > > Also, if I understand you correctly, then operators can also disable this > checking and turn it on if they see that an adjacency is not being set up, > is this correct? > > I still don't completely understand your comment about "bringing up links > between different versions of the protocol" Isn't there only 1 version? Joan - In the most recent public version, from this June, I had changed a number of the notifications to be "once per circuit" in direct response to your comments. Here is a sample below. I am not suggesting sending BITS: I am suggesting sending one notification the first time you see each of these events on a circuit. The different events have different footprints. You keep a bit map per interface recording these events, and send a notification when the bit map changes. Since a dropped packet is going to be resent, we need someway to keep a system from banging out an en stream of these notifications. If this is useful, the vendor will find some way to clear the bits. I know of at least one implementation that does this when the packet counts for an interface are cleared. I'm not sure how much of this belongs in the MIB. I do not anticipate people turning off this kind of checking. When I get a packet, there is some basic validation that I perform. Does it think the ID length is 6? Does it think max area is 3? Is the version 1? If the answer to any of these is no, I really don't want to process this packet. I assume that you do the same. These notifications simply provide a way to notify an administrator that something is wrong. I do not expect to see a lot of ID Length problems: if they do arrive, it is probably due to an encapsulation problem. However, issues such as Auth failure might be very common when rolling out a change in that dimension. But I want to know about either error: they represent something that the operator needs to see. While there is only one version of IS-IS, there are different implementations, and sometimes they disagree about a feature. These notifications provide an alternative to silently dropping packets: noisely dropping (the first such) packet on an interface. Internet Engineering Task Force Jeff Parker, Editor INTERNET DRAFT Axiowave Networks Expiration Date: January 2005 July 6, 2004 Management Information Base for IS-IS .... isisAuthenticationTypeFailure NOTIFICATION-TYPE OBJECTS { isisSysLevelIndex, isisCircIfIndex, isisPduFragment } STATUS current DESCRIPTION "A notification sent when we receive a PDU with the wrong authentication type field. This notification includes the header of the packet, which may help a network manager identify the source of the confusion. This should be an edge-triggered notification. We should not send a second notification about PDUs received from the same circuit." ::= { isisTrapPrefix 9 } - 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 Oct 7 11:00: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 LAA24324 for ; Thu, 7 Oct 2004 11:00:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZcJ-0001kS-HD; Thu, 07 Oct 2004 10:51:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZSZ-00076W-2W for isis-wg@megatron.ietf.org; Thu, 07 Oct 2004 10:41:35 -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 KAA22783 for ; Thu, 7 Oct 2004 10:41:29 -0400 (EDT) Received: from mercury0.easily.co.uk ([213.161.76.90] helo=easily.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFZcC-000101-A8 for isis-wg@ietf.org; Thu, 07 Oct 2004 10:51:35 -0400 Received: from [149.254.200.215] (account ee7a30ha8ykg HELO [10.34.42.23]) by easily.co.uk (CommuniGate Pro SMTP 4.1.3) with ESMTP id 89696523; Thu, 07 Oct 2004 15:41:15 +0100 Message-ID: <416556F0.6030009@christiantena.co.uk> Date: Thu, 07 Oct 2004 15:47:12 +0100 From: Philip Christian User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Hopps Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt References: <20040614170235.H11354@kummer.juniper.net><200405121412.KAA06827@ietf.org> <200405121412.KAA06827@ietf.org><5.2.1.1.1.20040617100610.00a8e430@customermail.easily.co.uk> <20040617185155.T29575@kummer.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Jeff Learman , 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 Someone has just reminded me that I need to sort this out. As far as I can see the consensus was to change from OUI to SNMP ID and to not worry about any backward compatibility issues. Does anyone disagree before I spend the time hacking with notepad ? Philip Christian Hopps wrote: > > > On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: > >> A poll of how many have implemented the 250 TLV as currently defined >> may help sort out how to proceed .... >> >> Juniper hasn't (would you have guessed???) > > > Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) > and skip the compatibility octet, if at all possible. > > Rather than have everyone announce who hasn't implemented this draft, > I would prefer that anyone who has and is against changing the TLV > speak up. We can take a poll in San Diego as well. If no-one speaks up > we should change the draft, put it in LC and get it published. > > Chris. > > > > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.707 / Virus Database: 463 - Release Date: 15/06/2004 > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 7 12:31:08 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 MAA02351 for ; Thu, 7 Oct 2004 12:31:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFb8f-0002It-VR; Thu, 07 Oct 2004 12:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFauU-0005BL-CF for isis-wg@megatron.ietf.org; Thu, 07 Oct 2004 12:14:30 -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 MAA00922 for ; Thu, 7 Oct 2004 12:14:27 -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 1CFb4E-0006iO-23 for isis-wg@ietf.org; Thu, 07 Oct 2004 12:24:34 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Oct 2004 09:19:10 -0700 Received: from codc-mira-1.cisco.com (IDENT:mirapoint@codc-mira-1.cisco.com [192.122.173.20]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i97GDsEE024198 for ; Thu, 7 Oct 2004 09:13:55 -0700 (PDT) Received: from sunramac-w2k.cisco.com ([10.77.139.210]) by codc-mira-1.cisco.com (MOS 3.4.6-GR) with ESMTP id AFK95688; Thu, 7 Oct 2004 21:44:00 +0530 (IST) Message-Id: <4.3.2.7.2.20041006193715.02278558@codc-mira-1.cisco.com> X-Sender: sunramac@codc-mira-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Oct 2004 21:43:54 +0530 To: isis-wg@ietf.org From: Sundar Ramachandran Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Isis-wg] Additional comments on draft-ietf-isis-wg-mib-16 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 Greetings Jeff et al., I have some comments on draft-ietf-isis-wg-mib-16. Forgive me for proposing changes to the MIB at this time, but I'd like you to review the suggestions and hopefully consider incorporating changes if you find good use for them. The issues are as follows: 1. The ISIS MIB includes a few objects that have AF scope. i.e. in the context of using IS-IS in an IPv6 environment, there are at the least a couple MIB objects which can take on different values depending on whether we use IPv4 or IPv6. - isisSysMaxPathSplits - isisSysL2toL1Leaking The MIB does not provide this information. It will be useful to add more comments that describe what changes can be expected in the case of IPv4 or IPv6. 2. The OSPF MIB (RFC 1850) defines an initial period when trap notifications are suppressed. This is described in Section 4.3 of the RFC and helps to avoid a flood of traps during initial bootup activity when OSPF is enabled. It will be very useful to mimic this behavior in ISIS-MIB since there are traps which are not edge-triggered and can be generated after the bootup phase. One example is the isisSequenceNumberSkip notification. During initial activity, when there are no LSPs, new LSPs are re-issued with incremented sequence number. Multiple traps get generated since the sequence number is greater than 1. Do you think it's possible to make some provision in the MIB to handle this? 3. Upon running smilint on the ISIS-MIB module, there was one "minor" error and atleast one warning that seemed to pose a concern: - {notification-object-access} object `isisManAreaAddr' of notification `isisManualAddressDrops' must not be `not-accessible' - {index-element-accessible} warning: index element `isisSysLevelIndex' of row `isisSysLevelEntry' should be not-accessible in SMIv2 MIB isisManAreaAddr must be not-accessible since it's an INDEX as well as a part of the conceptual table. But there seems to be a problem with this being a part of the isisManualAddressDrops NOTIFICATION-TYPE. Should this be changed to "read-only"? I've seen one such example in ifIndex (IF-MIB) which is an INDEX to ifTable, present in the table and also part of a NOTIFICATION-TYPE. Does MAX-ACCESS for these two objects need to be fixed? Hope you can comment on these. Thanks for your time. - Sundar. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 7 12:59:37 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 MAA04794 for ; Thu, 7 Oct 2004 12:59:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbZu-0000ar-2S; Thu, 07 Oct 2004 12:57:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbXT-0008CO-9O for isis-wg@megatron.ietf.org; Thu, 07 Oct 2004 12:54:47 -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 MAA04215 for ; Thu, 7 Oct 2004 12:54:44 -0400 (EDT) Received: from c-230.static.at.kpnqwest.net ([193.154.188.230] helo=ghostrider.gredler.at) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbhB-00011X-VE for isis-wg@ietf.org; Thu, 07 Oct 2004 13:04:51 -0400 Received: from [193.83.223.231] (pc-caroline.gredler.at [193.83.223.231]) by ghostrider.gredler.at (8.12.11/8.12.9) with ESMTP id i97GrXlw002334; Thu, 7 Oct 2004 18:53:33 +0200 Message-ID: <4165748D.8000803@juniper.net> Date: Thu, 07 Oct 2004 18:53:33 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sundar Ramachandran Subject: Re: [Isis-wg] Additional comments on draft-ietf-isis-wg-mib-16 References: <4.3.2.7.2.20041006193715.02278558@codc-mira-1.cisco.com> In-Reply-To: <4.3.2.7.2.20041006193715.02278558@codc-mira-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Sundar Ramachandran wrote: > Greetings Jeff et al., > > I have some comments on draft-ietf-isis-wg-mib-16. Forgive me for proposing > changes to the MIB at this time, but I'd like you to review the > suggestions and > hopefully consider incorporating changes if you find good use for them. > The issues > are as follows: > > 1. The ISIS MIB includes a few objects that have AF scope. i.e. in the > context > of using IS-IS in an IPv6 environment, there are at the least a couple > MIB objects > which can take on different values depending on whether we use IPv4 or > IPv6. > > - isisSysMaxPathSplits > - isisSysL2toL1Leaking i slightly disagree: ad isisSysMaxPathSplits: load sharing / next-hop selection is typical a route-resolver (=system) function and not a per-AF function; ad isisSysL2toL1Leaking: assume the most likely case that you have a policy that leaks based on admin-tags - i.e. every prefix (irrespective of AF) that carries a certain tag will get leaked: carrying redundant L2toL1Leaking is IMHO not necessary; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Oct 8 11:00:31 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 LAA02027 for ; Fri, 8 Oct 2004 11:00:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFw6b-0000jK-La; Fri, 08 Oct 2004 10:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvu8-0005Mp-4c for isis-wg@megatron.ietf.org; Fri, 08 Oct 2004 10:39: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 KAA00142 for ; Fri, 8 Oct 2004 10:39:31 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.195] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFw43-0008DX-QT for isis-wg@ietf.org; Fri, 08 Oct 2004 10:49:49 -0400 Received: by mproxy.gmail.com with SMTP id 73so65988rnl for ; Fri, 08 Oct 2004 07:39:23 -0700 (PDT) Received: by 10.39.1.30 with SMTP id d30mr133651rni; Fri, 08 Oct 2004 07:39:23 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Fri, 8 Oct 2004 07:39:23 -0700 (PDT) Message-ID: Date: Fri, 8 Oct 2004 20:09:23 +0530 From: Abhishek Verma To: isis-wg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Overload Bit X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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, A -- B -- C [1] A, B and C are 3 L1/L2 ISIS routers. B has its overload bit set. This as per what i have read "ensures that no other router uses this local router for transit traffic". Now, here goes my problem(s): ISIS adjacencies are up between these 3 routers. A is aware of C's loopback and C is aware of A's loopback IP address. That could be say, because we have added loopback interfaces to our areas. Now if I try to ping A from C, should my ping go? IMO it shouldnt. Only the traffic destined to B's directly connected interfaces should be allowed. Also does this technically mean that when A receives an LSP from B with this bit set, it should not install it? If that is the case then why would B advertise its LSP in the first place? When it knows that A and C are not going to use that? Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Oct 8 11:27:37 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 LAA04199 for ; Fri, 8 Oct 2004 11:27:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwTK-0005lY-Si; Fri, 08 Oct 2004 11:15:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwNY-0004bP-M4 for isis-wg@megatron.ietf.org; Fri, 08 Oct 2004 11:09:56 -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 LAA02728 for ; Fri, 8 Oct 2004 11:09:55 -0400 (EDT) Received: from bay2-f7.bay2.hotmail.com ([65.54.247.7] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwXU-0000bN-KA for isis-wg@ietf.org; Fri, 08 Oct 2004 11:20:14 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 8 Oct 2004 08:09:04 -0700 Received: from 64.172.59.106 by by2fd.bay2.hotmail.msn.com with HTTP; Fri, 08 Oct 2004 15:08:52 GMT X-Originating-IP: [64.172.59.106] X-Originating-Email: [sboddapa@hotmail.com] X-Sender: sboddapa@hotmail.com From: "Suresh Boddapati" To: abhishekv.verma@gmail.com, isis-wg@ietf.org Subject: RE: [Isis-wg] Overload Bit Date: Fri, 08 Oct 2004 15:08:52 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Oct 2004 15:09:04.0793 (UTC) FILETIME=[C040A890:01C4AD48] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 > >A -- B -- C > >[1] A, B and C are 3 L1/L2 ISIS routers. B has its overload bit set. >This as per what i have read "ensures that no other router uses this >local router for transit traffic". > >Now, here goes my problem(s): > >ISIS adjacencies are up between these 3 routers. A is aware of C's >loopback and C is aware of A's loopback IP address. That could be say, >because we have added loopback interfaces to our areas. > >Now if I try to ping A from C, should my ping go? > Assuming B set the overload bit, no, your ping should not succeed because A should ignore B's nbrs in its SPF calculation. >IMO it shouldnt. Only the traffic destined to B's directly connected >interfaces should be allowed. Also does this technically mean that >when A receives an LSP from B with this bit set, it should not install >it? No. A should install the LSP from B, precisely to be able to reach B's subnets (see below). > >If that is the case then why would B advertise its LSP in the first >place? When it knows that A and C are not going to use that? > Because you still want to be able to reach B's directly connected subnets. B is saying "Dont use me as a transit, because I may not have the complete topology information. But you can use me to reach any of the networks that I have advertised". Implementations also allow a node to declare itself overloaded for a certain amount of time to avoid transient blackholes ( check out the relevant draft on this). Suresh >Thanks, >Abhishek > >-- >Class of 2004 >Institute of Technology, BHU >Varanasi, India > >_______________________________________________ >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 Oct 8 11:35:28 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 LAA05056 for ; Fri, 8 Oct 2004 11:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwgY-0000A8-CB; Fri, 08 Oct 2004 11:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwZt-00078K-FJ for isis-wg@megatron.ietf.org; Fri, 08 Oct 2004 11:22: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 LAA03688 for ; Fri, 8 Oct 2004 11:22:40 -0400 (EDT) Received: from westford-nat.juniper.net ([65.194.140.2] helo=pi-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwjp-0000to-N3 for isis-wg@ietf.org; Fri, 08 Oct 2004 11:32:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Overload Bit Date: Fri, 8 Oct 2004 11:21:46 -0400 Message-ID: <98F04BA831360C4FB5F7FC0118D91828034A2ADF@pi.jnpr.net> Thread-Topic: [Isis-wg] Overload Bit Thread-Index: AcStR4lPEifIEkVRSG+1zOYi82FiBwAAgq8A From: "Jeelani Syed" To: "Abhishek Verma" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable 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 First of all overload state is assumed to be a temporary state and it is undesirable to purge all LSPs beloging to a router from network and reflood them instead of just sending a LSP=20 with overload bit set/reset. -jeelani.sm -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Abhishek Verma Sent: Friday, October 08, 2004 10:39 AM To: isis-wg@ietf.org Subject: [Isis-wg] Overload Bit Hi, A -- B -- C [1] A, B and C are 3 L1/L2 ISIS routers. B has its overload bit set. This as per what i have read "ensures that no other router uses this local router for transit traffic". Now, here goes my problem(s): ISIS adjacencies are up between these 3 routers. A is aware of C's loopback and C is aware of A's loopback IP address. That could be say, because we have added loopback interfaces to our areas. Now if I try to ping A from C, should my ping go?=20 IMO it shouldnt. Only the traffic destined to B's directly connected interfaces should be allowed. Also does this technically mean that when A receives an LSP from B with this bit set, it should not install it? If that is the case then why would B advertise its LSP in the first place? When it knows that A and C are not going to use that? Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ 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 Oct 8 19:11:31 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 TAA27477 for ; Fri, 8 Oct 2004 19:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3qL-0006Sw-SZ; Fri, 08 Oct 2004 19:08:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3jC-00041B-RO for isis-wg@megatron.ietf.org; Fri, 08 Oct 2004 19:00:46 -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 TAA27068 for ; Fri, 8 Oct 2004 19:00:43 -0400 (EDT) Received: from knint.xs4all.nl ([80.126.131.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG3tC-0007Df-61 for isis-wg@ietf.org; Fri, 08 Oct 2004 19:11:06 -0400 Received: from knint.xs4all.nl (localhost.localdomain [127.0.0.1]) by knint.xs4all.nl (8.12.8/8.12.8) with ESMTP id i98N0ZMQ001193; Sat, 9 Oct 2004 01:00:35 +0200 Received: (from henk@localhost) by knint.xs4all.nl (8.12.8/8.12.8/Submit) id i98N0YVx001190; Sat, 9 Oct 2004 01:00:34 +0200 From: Henk Smit Message-Id: <200410082300.i98N0YVx001190@knint.xs4all.nl> Subject: Re: [Isis-wg] Overload Bit To: jsyed@juniper.net (Jeelani Syed) Date: Sat, 9 Oct 2004 01:00:34 +0200 (CEST) In-Reply-To: <98F04BA831360C4FB5F7FC0118D91828034A2ADF@pi.jnpr.net> from "Jeelani Syed" at Oct 08, 2004 11:21:46 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 > First of all overload state is assumed to be a temporary state Says who ? If a router wants to set the overload bit for ever, it is allowed to do so. There are cases where a constant setting of the overload bit is useful. > and it is undesirable to purge > all LSPs beloging to a router from network and reflood them instead of > just sending a LSP > with overload bit set/reset. 1) Purging an LSP or 2) setting the overload bit are two totally different things, and should not be compared with each other. Also, purging one LSP or setting the overload bit on one LSP requires roughly the same amount of work to be done by all routers (both actions require one router to create a new LSP, flood it to all routers, all routers do some LSPDB housekeeping, all routers run an SPF computation). Hope this helps, Henk. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Oct 8 19:16: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 TAA27757 for ; Fri, 8 Oct 2004 19:16: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 1CG3x1-000089-Dr; Fri, 08 Oct 2004 19:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG3r6-0006qm-8q for isis-wg@megatron.ietf.org; Fri, 08 Oct 2004 19:08:56 -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 TAA27360 for ; Fri, 8 Oct 2004 19:08:53 -0400 (EDT) Received: from knint.xs4all.nl ([80.126.131.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG415-0007LT-0b for isis-wg@ietf.org; Fri, 08 Oct 2004 19:19:16 -0400 Received: from knint.xs4all.nl (localhost.localdomain [127.0.0.1]) by knint.xs4all.nl (8.12.8/8.12.8) with ESMTP id i98N8mMQ001214; Sat, 9 Oct 2004 01:08:48 +0200 Received: (from henk@localhost) by knint.xs4all.nl (8.12.8/8.12.8/Submit) id i98N8m78001211; Sat, 9 Oct 2004 01:08:48 +0200 From: Henk Smit Message-Id: <200410082308.i98N8m78001211@knint.xs4all.nl> Subject: Re: [Isis-wg] Overload Bit To: sboddapa@hotmail.com (Suresh Boddapati) Date: Sat, 9 Oct 2004 01:08:48 +0200 (CEST) In-Reply-To: from "Suresh Boddapati" at Oct 08, 2004 03:08:52 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 > >Now if I try to ping A from C, should my ping go? > > Assuming B set the overload bit, no, your ping should not succeed because A > should ignore B's nbrs in its SPF calculation. It depends. If A tries to ping the IP address of the loopback interface of C, it should not succeed. If A tries to ping the IP address of the p2p interface of C that is connected to B, then the ping *will* succeed. > >IMO it shouldnt. Only the traffic destined to B's directly connected > >interfaces should be allowed. Agreed. But you should realize that the IP address of C's p2p interface is in fact in an IP range that is advertised by B, because B has an IP address in that same range configured on its p2p interface to C. Suresh already answered the other questions. Hope this helps. Henk. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Oct 9 08:14:50 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 IAA07304 for ; Sat, 9 Oct 2004 08:14:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGG43-00084t-FX; Sat, 09 Oct 2004 08:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGG3W-0007tN-HP for isis-wg@megatron.ietf.org; Sat, 09 Oct 2004 08:10: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 IAA07188 for ; Sat, 9 Oct 2004 08:10:33 -0400 (EDT) Received: from jaffa.juniper.net ([207.17.137.105] helo=juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGGDc-0004q3-VJ for isis-wg@ietf.org; Sat, 09 Oct 2004 08:21:02 -0400 Received: from ([172.24.245.25]) by jaffa.juniper.net with ESMTP ; Sat, 09 Oct 2004 05:09:36 -0700 Received: from MESON.jnpr.net ([172.27.50.11]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Sat, 9 Oct 2004 05:09:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Overload Bit Date: Sat, 9 Oct 2004 17:39:25 +0530 Message-ID: <34C303A46945174CA17EEFA6A2FE39E3F2C115@MESON.jnpr.net> Thread-Topic: [Isis-wg] Overload Bit thread-index: AcStjNJ9PTX4FD9oQPG1D31Eg4FSTwAasgBg From: "Minto Jeyananth" To: "Henk Smit" , "Suresh Boddapati" X-OriginalArrivalTime: 09 Oct 2004 12:09:36.0634 (UTC) FILETIME=[D857BDA0:01C4ADF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable 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: quoted-printable >=20 > > >Now if I try to ping A from C, should my ping go? > > > > Assuming B set the overload bit, no, your ping should not succeed > because A > > should ignore B's nbrs in its SPF calculation. >=20 > It depends. > If A tries to ping the IP address of the loopback interface of C, it > should > not succeed. =20 Need not to be. It's based on SPF implementation.=20 --Minto =20 > If A tries to ping the IP address of the p2p interface of C that is > connected to B, then the ping *will* succeed. >=20 > > >IMO it shouldnt. Only the traffic destined to B's directly connected > > >interfaces should be allowed. >=20 > Agreed. But you should realize that the IP address of C's p2p interface > is in fact in an IP range that is advertised by B, because B has an IP > address in that same range configured on its p2p interface to C. >=20 > Suresh already answered the other questions. > Hope this helps. >=20 > Henk. >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Oct 9 11:32:32 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 LAA20734 for ; Sat, 9 Oct 2004 11:32:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGJAy-0005UI-Ag; Sat, 09 Oct 2004 11:30:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGJ8e-0004xf-Cc for isis-wg@megatron.ietf.org; Sat, 09 Oct 2004 11:28: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 LAA20491 for ; Sat, 9 Oct 2004 11:28:02 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGJIm-0008MS-I7 for isis-wg@ietf.org; Sat, 09 Oct 2004 11:38:33 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 09 Oct 2004 11:46:45 -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 i99FRTYX000822; Sat, 9 Oct 2004 11:27:30 -0400 (EDT) Received: from jlearman-w2k03.cisco.com (rtp-vpn2-378.cisco.com [10.82.241.122]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCO70217; Sat, 9 Oct 2004 08:27:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20041009112408.023fef18@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 09 Oct 2004 11:26:42 -0400 To: "Minto Jeyananth" , "Henk Smit" , "Suresh Boddapati" From: Jeff Learman Subject: RE: [Isis-wg] Overload Bit In-Reply-To: <34C303A46945174CA17EEFA6A2FE39E3F2C115@MESON.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 08:09 AM 10/9/2004, Minto Jeyananth wrote: > > Need not to be. It's based on SPF implementation. I disagree -- I agree with Henk. Pinging C's loopback address should fail because it is advertised only by C, and is therefore transit routing. Pinging any address that's directly connected to B (including an interface on C) should succeed. Jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Oct 9 15:20: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 PAA04129 for ; Sat, 9 Oct 2004 15:20: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 1CGMj7-0003TQ-RV; Sat, 09 Oct 2004 15:17:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGMiL-000390-TB for isis-wg@megatron.ietf.org; Sat, 09 Oct 2004 15:17:09 -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 PAA03717 for ; Sat, 9 Oct 2004 15:17:08 -0400 (EDT) Received: from door.sniff.de ([82.212.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGMsM-0003uQ-Fj for isis-wg@ietf.org; Sat, 09 Oct 2004 15:27:40 -0400 Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 0030B2AA0F; Sat, 9 Oct 2004 19:09:27 +0000 (GMT) In-Reply-To: <34C303A46945174CA17EEFA6A2FE39E3F2C115@MESON.jnpr.net> References: <34C303A46945174CA17EEFA6A2FE39E3F2C115@MESON.jnpr.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marc Binderberger Subject: Re: [Isis-wg] Overload Bit Date: Sat, 9 Oct 2004 21:17:32 +0200 To: "Minto Jeyananth" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Minto, >>> Assuming B set the overload bit, no, your ping should not succeed >>> because A should ignore B's nbrs in its SPF calculation. >> >> It depends. >> If A tries to ping the IP address of the loopback interface of C, it >> should >> not succeed. > > Need not to be. It's based on SPF implementation. do you mean a ping to C's loopback may happen, depending on the SPF implementation? from the ISO 10589 document: "7.2.8.1 Computing routes through overloaded Intermediate systems The Decision Process shall not utilise a link to an Intermediate system neighbour from an IS whose LSPs have the LSP Database Overload indication set. Such paths may introduce loops since the overloaded IS does not have a complete routeing information base. The Decision Process shall, however utilise the link to reach End system neighbours since these paths are guaranteed to be non-looping." Based on this C's loopback should not be routed via B. Regards, Marc -- Marc Binderberger Powered by *BSD ;-) _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Oct 10 23:21:57 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 XAA08320 for ; Sun, 10 Oct 2004 23:21:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGqj4-0005IN-Dp; Sun, 10 Oct 2004 23:19:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGqfl-0004yM-3D for isis-wg@megatron.ietf.org; Sun, 10 Oct 2004 23:16:29 -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 XAA07819 for ; Sun, 10 Oct 2004 23:16:26 -0400 (EDT) Received: from westford-nat.juniper.net ([65.194.140.2] helo=pi-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGqqC-0005CA-JE for isis-wg@ietf.org; Sun, 10 Oct 2004 23:27:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Overload Bit Date: Sun, 10 Oct 2004 23:15:50 -0400 Message-ID: <98F04BA831360C4FB5F7FC0118D91828034A2AE2@pi.jnpr.net> Thread-Topic: [Isis-wg] Overload Bit Thread-Index: AcStisgbMntNHZifQPGAoeWcTAacSgBs9oUA From: "Jeelani Syed" To: "Henk Smit" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable 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: quoted-printable Agreed, I thought the question was why to advertise LSPs(disabling ISIS on overload state) at all instead of using overload bit. So I was pointing out one of the advantages using overload bit=20 in flooding perspective especially when router has lot of LSP fragments. -jeelani.sm -----Original Message----- From: Henk Smit [mailto:hhwsmit@xs4all.nl] Sent: Friday, October 08, 2004 7:01 PM To: Jeelani Syed Cc: Abhishek Verma; isis-wg@ietf.org Subject: Re: [Isis-wg] Overload Bit > First of all overload state is assumed to be a temporary state Says who ? If a router wants to set the overload bit for ever, it is allowed to do so. There are cases where a constant setting of the overload bit is useful. > and it is undesirable to purge > all LSPs beloging to a router from network and reflood them instead of > just sending a LSP=20 > with overload bit set/reset. 1) Purging an LSP or 2) setting the overload bit are two totally different things, and should not be compared with each other. Also, purging one LSP or setting the overload bit on one LSP=20 requires roughly the same amount of work to be done by all routers (both actions require one router to create a new LSP, flood it to all routers, all routers do some LSPDB housekeeping, all routers run an SPF computation). Hope this helps, Henk. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Oct 10 23:44:58 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 XAA09784 for ; Sun, 10 Oct 2004 23:44:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGr5Z-00089D-Pu; Sun, 10 Oct 2004 23:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGr5G-00082x-RL for isis-wg@megatron.ietf.org; Sun, 10 Oct 2004 23:42: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 XAA09707 for ; Sun, 10 Oct 2004 23:42:47 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGrFi-0005cU-UI for isis-wg@ietf.org; Sun, 10 Oct 2004 23:53:39 -0400 Received: from [192.168.1.3] (c-67-164-0-92.client.comcast.net[67.164.0.92]) by comcast.net (rwcrmhc11) with SMTP id <2004101103421401300cbgpbe> (Authid: li.tony); Mon, 11 Oct 2004 03:42:14 +0000 In-Reply-To: <98F04BA831360C4FB5F7FC0118D91828034A2AE2@pi.jnpr.net> References: <98F04BA831360C4FB5F7FC0118D91828034A2AE2@pi.jnpr.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <89C94476-1B37-11D9-A663-000A95D1475E@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Isis-wg] Overload Bit Date: Sun, 10 Oct 2004 20:42:13 -0700 To: "Jeelani Syed" X-Mailer: Apple Mail (2.619) X-Spam-Score: 1.2 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Henk Smit , 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 One situation that came up that was of interest was an ISP that had their NOC adjacent to their production links. On the router leading to the NOC, they set overload. This prevented transit traffic through that router even tho it was very well connected. The NOC still had connectivity as ES's (connected prefixes) were still reachable. Tony On Oct 10, 2004, at 8:15 PM, Jeelani Syed wrote: > Agreed, I thought the question was why to advertise LSPs(disabling ISIS > on overload state) at all instead of using overload bit. So I was > pointing out one of the advantages using overload bit > in flooding perspective especially when router has lot of LSP > fragments. > > -jeelani.sm > > -----Original Message----- > From: Henk Smit [mailto:hhwsmit@xs4all.nl] > Sent: Friday, October 08, 2004 7:01 PM > To: Jeelani Syed > Cc: Abhishek Verma; isis-wg@ietf.org > Subject: Re: [Isis-wg] Overload Bit > > > >> First of all overload state is assumed to be a temporary state > > Says who ? > If a router wants to set the overload bit for ever, it is allowed to > do so. There are cases where a constant setting of the overload bit > is useful. > >> and it is undesirable to purge >> all LSPs beloging to a router from network and reflood them instead of >> just sending a LSP >> with overload bit set/reset. > > 1) Purging an LSP or 2) setting the overload bit > are two totally different things, and should not be compared with > each other. > > Also, purging one LSP or setting the overload bit on one LSP > requires roughly the same amount of work to be done by all > routers (both actions require one router to create a new LSP, > flood it to all routers, all routers do some LSPDB housekeeping, > all routers run an SPF computation). > > Hope this helps, > > Henk. > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 11 00:40:57 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 AAA13463 for ; Mon, 11 Oct 2004 00:40:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGrxh-0001pu-3c; Mon, 11 Oct 2004 00:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGrvi-0001YJ-ID for isis-wg@megatron.ietf.org; Mon, 11 Oct 2004 00:37: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 AAA13313 for ; Mon, 11 Oct 2004 00:36:59 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGs6A-0006gF-P6 for isis-wg@ietf.org; Mon, 11 Oct 2004 00:47:52 -0400 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 10 Oct 2004 21:36:31 -0700 X-BrightmailFiltered: true X-Ironport-AV: i="3.85,131,1094454000"; d="scan'208"; a="10533888:sNHT22357830" Received: from MESON.jnpr.net ([172.27.50.11]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 10 Oct 2004 21:36:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Overload Bit Date: Mon, 11 Oct 2004 10:06:24 +0530 Message-ID: <34C303A46945174CA17EEFA6A2FE39E3F2C15B@MESON.jnpr.net> Thread-Topic: [Isis-wg] Overload Bit thread-index: AcSuFILBozvppAOSSXmnOqWu6RqfLwBNzGQw From: "Minto Jeyananth" To: "Jeff Learman" , "Henk Smit" , "Suresh Boddapati" X-OriginalArrivalTime: 11 Oct 2004 04:36:29.0931 (UTC) FILETIME=[E0A193B0:01C4AF4B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Yes, I was wrong. its not based on implementation.=20 Minto=20 =20 > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Saturday, October 09, 2004 8:57 PM > To: Minto Jeyananth; Henk Smit; Suresh Boddapati > Cc: isis-wg@ietf.org > Subject: RE: [Isis-wg] Overload Bit >=20 > At 08:09 AM 10/9/2004, Minto Jeyananth wrote: > > > > Need not to be. It's based on SPF implementation. >=20 > I disagree -- I agree with Henk. Pinging C's loopback address should > fail because it is advertised only by C, and is therefore transit > routing. Pinging any address that's directly connected to B > (including an interface on C) should succeed. >=20 > Jeff >=20 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 13 06:04:37 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 GAA08278 for ; Wed, 13 Oct 2004 06:04:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHfxP-00044o-1c; Wed, 13 Oct 2004 06:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHfsa-0003QU-NA for isis-wg@megatron.ietf.org; Wed, 13 Oct 2004 05:57: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 FAA07774 for ; Wed, 13 Oct 2004 05:57:04 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.192] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHg3R-0000iB-3W for isis-wg@ietf.org; Wed, 13 Oct 2004 06:08:22 -0400 Received: by mproxy.gmail.com with SMTP id 73so897956rnl for ; Wed, 13 Oct 2004 02:56:58 -0700 (PDT) Received: by 10.38.71.35 with SMTP id t35mr2315485rna; Wed, 13 Oct 2004 02:56:56 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Wed, 13 Oct 2004 02:56:30 -0700 (PDT) Message-ID: Date: Wed, 13 Oct 2004 15:26:30 +0530 From: Abhishek Verma To: Jeff Learman Subject: Re: [Isis-wg] FW: Voids in LSP In-Reply-To: <4.3.2.7.2.20041004160234.0226c5c0@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4.3.2.7.2.20041004160234.0226c5c0@dingdong.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: Abhishek Verma 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, > diff-ospf-isis group: I tried searching for this group but was unable to find one! Is there a way to join this? > > We wrote a document on this. Anybody know where it ended up? I believe you are talking of draft-bhatia-manral-diff-isis-ospf-00.txt. Right? I see that it has expired. Are you guys planning for the next version? This draft is an excellent resource for beginners like us, who often get confused with the different link state routing protocols that we have! And this helped straighten out a lot of things for me! Thanks, Abhishek. > > Jeff > > -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 13 08:24: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 IAA21196 for ; Wed, 13 Oct 2004 08:24: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 1CHi8u-0007tw-Pc; Wed, 13 Oct 2004 08:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHi7L-0007bB-5R for isis-wg@megatron.ietf.org; Wed, 13 Oct 2004 08:20:31 -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 IAA20914 for ; Wed, 13 Oct 2004 08:20:26 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.206] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHiIA-0003nO-OA for isis-wg@ietf.org; Wed, 13 Oct 2004 08:31:45 -0400 Received: by mproxy.gmail.com with SMTP id 75so781267rnl for ; Wed, 13 Oct 2004 05:20:22 -0700 (PDT) Received: by 10.38.165.75 with SMTP id n75mr2358835rne; Wed, 13 Oct 2004 05:20:22 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Wed, 13 Oct 2004 05:20:22 -0700 (PDT) Message-ID: Date: Wed, 13 Oct 2004 17:50:22 +0530 From: Abhishek Verma To: isis-wg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] TLV 132 doubt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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, I have the following setup and am seeing a queer problem. R1 (x.1/24) ------------------ R2 (x.2/24) where x = 2.2.2.0/24 R1 and R2 are both configured to be L1 routers. Initially I have added only one interface on R2 in my ISIS. Thus i see only 2.2.2.2/24 being advertised in IP Interface TLV (Type 132).This works fine. I also see 2.2.2.0/24 being advertised in IP Internal Reachability TLV (128). Now, I add another interface, say 3.3.3.1/24 to ISIS. What i see now is that when R2 advertises its L1 LSP, it replaces 2.2.2.2/24 in TLV 132 with 3.3.3.1. Shouldnt we be advertising both the IP addresses in the TLV 132? What exactly is then the significance of TLV 132? Thoug I see two addresses 2.2.2/24 and 3.3.3/24 in TLV 128. Another doubt: On a broadcast LAN, why dont we send PSNPs to acknowledge the Pseudonode LSPs that have been originated by the DIS? Regards, Abhishek. -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 13 19:23:08 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 TAA24656 for ; Wed, 13 Oct 2004 19:23:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHsJz-00024m-Si; Wed, 13 Oct 2004 19:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHsA9-00082m-P5 for isis-wg@megatron.ietf.org; Wed, 13 Oct 2004 19:04:07 -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 TAA23111 for ; Wed, 13 Oct 2004 19:04:05 -0400 (EDT) Received: from firestar.cisco.com ([171.68.227.75] helo=fire.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHsLB-0002dx-Hr for isis-wg@ietf.org; Wed, 13 Oct 2004 19:15:30 -0400 Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.98.126]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i9DN3Ui08075; Wed, 13 Oct 2004 16:03:30 -0700 (PDT) Date: Wed, 13 Oct 2004 16:03:30 -0700 (PDT) From: Shankar Vemulapalli To: Abhishek Verma Subject: Re: [Isis-wg] TLV 132 doubt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Hi Abhishek - See below - At 5:50pm 10/13/04 +0530, Abhishek Verma wrote: > Hi, > > I have the following setup and am seeing a queer problem. > > R1 (x.1/24) ------------------ R2 (x.2/24) > > where x = 2.2.2.0/24 > > R1 and R2 are both configured to be L1 routers. Initially I have added > only one interface on R2 in my ISIS. Thus i see only 2.2.2.2/24 being > advertised in IP Interface TLV (Type 132).This works fine. > > I also see 2.2.2.0/24 being advertised in IP Internal Reachability TLV (128). > > Now, I add another interface, say 3.3.3.1/24 to ISIS. What i see now > is that when R2 advertises its L1 LSP, it replaces 2.2.2.2/24 in TLV > 132 with 3.3.3.1. Shouldnt we be advertising both the IP addresses in > the TLV 132? Take a look at the RFC 1195 for information on the the TLV 132. Also, look into RFC 3359 and RFC 3787 (section 10) > What exactly is then the significance of TLV 132? See above - > Thoug I see two addresses 2.2.2/24 and 3.3.3/24 in TLV 128. > > Another doubt: On a broadcast LAN, why dont we send PSNPs to > acknowledge the Pseudonode LSPs that have been originated by the DIS? Because IS-IS doesnt' require explicit acknowledgments on a LAN. Actually, DIS summarizes the database by sending a CSNP (complete sequence numbers packet) and not a PSNP. The way it works on the LAN is: if a router detects that in the received CSNP, that there is a missed LSP, it transmits that LSP on the LAN. This is because, it either not listed in the CSNP or listed with a lower seq. #. On the contrary, if the a router detects that if the DIS more recent info. in the CSNP, it explicitly requests that LSP via PSNP. Hope it helps. /Shankar > Regards, > Abhishek. > > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India > > _______________________________________________ > 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 Oct 13 22:02:13 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 WAA04502 for ; Wed, 13 Oct 2004 22:02:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHumc-0005OT-Ni; Wed, 13 Oct 2004 21:51:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHucw-0003Ma-W8 for isis-wg@megatron.ietf.org; Wed, 13 Oct 2004 21:41:59 -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 VAA03318 for ; Wed, 13 Oct 2004 21:41:59 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHuny-0005Oy-85 for isis-wg@ietf.org; Wed, 13 Oct 2004 21:53:25 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i9E1fJ991453; Wed, 13 Oct 2004 18:41:19 -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 i9E1fDe54872; Wed, 13 Oct 2004 18:41:14 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1F2A67DE-1D82-11D9-A274-000D93298656@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [Isis-wg] TLV 132 doubt Date: Wed, 13 Oct 2004 19:41:08 -0600 To: Shankar Vemulapalli X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 On Oct 13, 2004, at 5:03 PM, Shankar Vemulapalli wrote: > Because IS-IS doesnt' require explicit acknowledgments on a LAN. > Actually, DIS summarizes the database by sending a CSNP (complete > sequence numbers packet) and not a PSNP. > > The way it works on the LAN is: if a router detects that in the > received > CSNP, that there is a missed LSP, it transmits that LSP on the LAN. > This > is because, it either not listed in the CSNP or listed with a lower > seq. #. > > On the contrary, if the a router detects that if the DIS more recent > info. > in the CSNP, it explicitly requests that LSP via PSNP. Yep, and the nice part about this scheme is that under normal conditions the LSP traffic is constant, regardless of the number of systems on the LAN. As such, it is the only truly useful application of LAN multicast among control protocols. The unicast ack scheme that OSPF and others use will at best cut the packet count in half, so the packet count still grows proportionately with the number of systems, making the optimization effectively useless from a scaling perspective. Then there's EIGRP, which in some cases actually generates *more* packets (well, one more anyhow) because of its attempt to use multicast than it would have had it just unicast everything. But I digress. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 14 10:43: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 KAA25449 for ; Thu, 14 Oct 2004 10:43: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 1CI6hF-0007ka-7n; Thu, 14 Oct 2004 10:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI6ds-0006Gj-MN for isis-wg@megatron.ietf.org; Thu, 14 Oct 2004 10:31: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 KAA24241 for ; Thu, 14 Oct 2004 10:31:42 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.197] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI6p2-0003WY-Lg for isis-wg@ietf.org; Thu, 14 Oct 2004 10:43:17 -0400 Received: by mproxy.gmail.com with SMTP id 73so59149rnl for ; Thu, 14 Oct 2004 07:31:42 -0700 (PDT) Received: by 10.38.13.47 with SMTP id 47mr3055531rnm; Thu, 14 Oct 2004 07:31:42 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Thu, 14 Oct 2004 07:31:42 -0700 (PDT) Message-ID: Date: Thu, 14 Oct 2004 20:01:42 +0530 From: Abhishek Verma To: isis-wg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Listing some other pseudonode in CSNP X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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, I have a doubt. R1 --- R2 |----- R3 R1-R2 and R2-R3 are on different LANs. R2 happens to be the DIS on both of them. I see that when R2 sends its CSNPs to R1, it includes the pseudonode LSP that it has generated for the LAN2 also in it. Will this not confuse R1? Say the sys ID of R2 is 0000.1010.1010 It will create a pseudonode LSP for both LANs, say 0000.1010.1010.01-00 and 0000.1010.1010.02-00 respectively. I see 0000.1010.1010.02-00 listed in the CSNP that R2 sends to R1. Now R1 doesnt have this LSP, as it holds relevance only in the other LAN. What will R1 now do? Will it send a PSNP back to R2 requesting it? If it does, then it will make no sense. Am i missing something? Regards, Abhishek. -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 14 11:56: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 LAA02113 for ; Thu, 14 Oct 2004 11:56: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 1CI7ox-0003PU-FB; Thu, 14 Oct 2004 11:47:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7n5-0002oJ-46 for isis-wg@megatron.ietf.org; Thu, 14 Oct 2004 11:45:19 -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 LAA01359 for ; Thu, 14 Oct 2004 11:45:17 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI7yH-00050g-7L for isis-wg@ietf.org; Thu, 14 Oct 2004 11:56:53 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2004 17:58:13 +0200 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9EFijSf003846; Thu, 14 Oct 2004 17:44:45 +0200 (MEST) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4449.cisco.com [10.61.81.96]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA07037; Thu, 14 Oct 2004 16:44:44 +0100 (BST) Message-Id: <4.3.2.7.2.20041014164052.02b293e0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Oct 2004 16:44:35 +0100 To: Abhishek Verma From: mike shand Subject: Re: [Isis-wg] Listing some other pseudonode in CSNP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 All LSPs (including pseudonode LSPs) are flooded everywhere. So R1 SHOULD have a copy, and if it finds it hasn't the normal operation of the update process will ensure that it gets one. R1, actually needs the "other LAN's" pseudonode LSP in order to compute a path R1 P1 R2 P2 R3...., as do any routers which are upstream of R1. Mike At 20:01 14/10/2004 +0530, Abhishek Verma wrote: >Hi, > >I have a doubt. > >R1 --- R2 > |----- R3 > >R1-R2 and R2-R3 are on different LANs. > >R2 happens to be the DIS on both of them. > >I see that when R2 sends its CSNPs to R1, it includes the pseudonode >LSP that it has generated for the LAN2 also in it. Will this not >confuse R1? > >Say the sys ID of R2 is 0000.1010.1010 > >It will create a pseudonode LSP for both LANs, say >0000.1010.1010.01-00 and 0000.1010.1010.02-00 respectively. > >I see 0000.1010.1010.02-00 listed in the CSNP that R2 sends to R1. Now >R1 doesnt have this LSP, as it holds relevance only in the other LAN. >What will R1 now do? Will it send a PSNP back to R2 requesting it? > >If it does, then it will make no sense. > >Am i missing something? > >Regards, >Abhishek. > >-- >Class of 2004 >Institute of Technology, BHU >Varanasi, India > >_______________________________________________ >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 Oct 14 12:36:32 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 MAA05549 for ; Thu, 14 Oct 2004 12:36:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8Qk-0007nw-By; Thu, 14 Oct 2004 12:26:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8Fa-00033G-7o for isis-wg@megatron.ietf.org; Thu, 14 Oct 2004 12:14:46 -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 MAA03872 for ; Thu, 14 Oct 2004 12:14:42 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI8Qi-0005kO-I3 for isis-wg@ietf.org; Thu, 14 Oct 2004 12:26:19 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Oct 2004 12:34:18 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9EGE8cD001405; Thu, 14 Oct 2004 12:14:09 -0400 (EDT) Received: from jlearman-w2k03.cisco.com (dhcp-64-102-206-106.cisco.com [64.102.206.106]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCR42087; Thu, 14 Oct 2004 09:14:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20041014121131.023e3f00@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Oct 2004 12:14:04 -0400 To: mike shand , Abhishek Verma From: Jeff Learman Subject: Re: [Isis-wg] Listing some other pseudonode in CSNP In-Reply-To: <4.3.2.7.2.20041014164052.02b293e0@jaws.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Right, Mike. Abhishek, the incorrect statement you made was: >>R1 doesnt have this LSP, as it holds relevance only in the other LAN. All LSPs have relevance on all ISs in the subdomain (L1 area or L2 backbone). That's how the connectivity graph is created on which you run SPF. Jeff At 11:44 AM 10/14/2004, mike shand wrote: >All LSPs (including pseudonode LSPs) are flooded everywhere. So R1 SHOULD have a copy, and if it finds it hasn't the normal operation of the update process will ensure that it gets one. > >R1, actually needs the "other LAN's" pseudonode LSP in order to compute a path R1 P1 R2 P2 R3...., as do any routers which are upstream of R1. > > Mike > >At 20:01 14/10/2004 +0530, Abhishek Verma wrote: >>Hi, >> >>I have a doubt. >> >>R1 --- R2 >> |----- R3 >> >>R1-R2 and R2-R3 are on different LANs. >> >>R2 happens to be the DIS on both of them. >> >>I see that when R2 sends its CSNPs to R1, it includes the pseudonode >>LSP that it has generated for the LAN2 also in it. Will this not >>confuse R1? >> >>Say the sys ID of R2 is 0000.1010.1010 >> >>It will create a pseudonode LSP for both LANs, say >>0000.1010.1010.01-00 and 0000.1010.1010.02-00 respectively. >> >>I see 0000.1010.1010.02-00 listed in the CSNP that R2 sends to R1. Now >>R1 doesnt have this LSP, as it holds relevance only in the other LAN. >>What will R1 now do? Will it send a PSNP back to R2 requesting it? >> >>If it does, then it will make no sense. >> >>Am i missing something? >> >>Regards, >>Abhishek. >> >>-- >>Class of 2004 >>Institute of Technology, BHU >>Varanasi, India >> >>_______________________________________________ >>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 Thu Oct 14 13:14: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 NAA08717 for ; Thu, 14 Oct 2004 13:14: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 1CI98X-0001lC-M5; Thu, 14 Oct 2004 13:11:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI92C-0000Bp-Gt for isis-wg@megatron.ietf.org; Thu, 14 Oct 2004 13:05:00 -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 NAA07884 for ; Thu, 14 Oct 2004 13:04:57 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.196] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI9DM-0006u2-SL for isis-wg@ietf.org; Thu, 14 Oct 2004 13:16:35 -0400 Received: by mproxy.gmail.com with SMTP id 73so24871rnl for ; Thu, 14 Oct 2004 10:04:48 -0700 (PDT) Received: by 10.38.152.68 with SMTP id z68mr3120044rnd; Thu, 14 Oct 2004 10:04:48 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Thu, 14 Oct 2004 10:04:47 -0700 (PDT) Message-ID: Date: Thu, 14 Oct 2004 22:34:47 +0530 From: Abhishek Verma To: isis-wg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Zero Metrics in TLV 128? X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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 All, I notice this. R1 (x.1/24) ----------- R2 (x.2/24) |__ 192.168.1/24 R2 is also connected to another interface 192.168.1/24 and this interface has been added to ISIS. R1 and R2 are L1L2 routers. R1 in its L2 LSP advertises 192.168.1/24 network in its TLV 128 (IP Internal Reachability) with Zero metric. It does not include this interface in its L1 LSP though. Thus would an ISIS router advertise the IP reachability information that it has learnt from other ISIS routers with metric Zero to other ISes? Is this normal? When i connect R3 to R2 on another LAN, I see it advertising the network x/24 (the one over which R1 and R2 are connected) with metric 20 back to R2 in its L2 LSP. This is again, included in TLV 128. I thought, since it learnt this information from other ISes it should have advertised this with metric Zero. I think i got lost somewhere! Any clues, anybody? Regards, Abhishek. -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 14 15:54: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 PAA22550 for ; Thu, 14 Oct 2004 15:54: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 1CIBdB-0002UQ-MA; Thu, 14 Oct 2004 15:51:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBZ6-0000Y8-Lb for isis-wg@megatron.ietf.org; Thu, 14 Oct 2004 15:47: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 PAA21730 for ; Thu, 14 Oct 2004 15:47:06 -0400 (EDT) Received: from door.sniff.de ([82.212.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIBkK-0001jW-8m for isis-wg@ietf.org; Thu, 14 Oct 2004 15:58:44 -0400 Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 2F62B2AA0F; Thu, 14 Oct 2004 19:39:20 +0000 (GMT) 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: Marc Binderberger Subject: Re: [Isis-wg] TLV 132 doubt Date: Thu, 14 Oct 2004 21:47:35 +0200 To: Shankar Vemulapalli X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Hi Shankar, > Take a look at the RFC 1195 for information on the the TLV 132. > Also, look into RFC 3359 and RFC 3787 (section 10) > >> What exactly is then the significance of TLV 132? > > See above - Are these RFCs really explaining the significance of TLV132 in _LSP_? RFC1195 just tells us what to do, RFC3787 talks about the IIH. While I understand it for IIH - ensuring a consistency between both sides (p2p) or LAN members - I wonder why this TLV in LSPs? Playing with a test router (by accident a box from your company ;-) it looks like the first loopback address is used. Kind of a "router ID"? Even then the question: why? Regards, Marc -- Marc Binderberger _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 14 16:13:47 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 QAA24835 for ; Thu, 14 Oct 2004 16:13: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 1CIBxC-0003Zj-J1; Thu, 14 Oct 2004 16:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBpG-0007yx-Po for isis-wg@megatron.ietf.org; Thu, 14 Oct 2004 16:03: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 QAA23489 for ; Thu, 14 Oct 2004 16:03:48 -0400 (EDT) Received: from door.sniff.de ([82.212.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIC0T-0002GE-NJ for isis-wg@ietf.org; Thu, 14 Oct 2004 16:15:27 -0400 Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id DC12F2AA0F; Thu, 14 Oct 2004 19:56:08 +0000 (GMT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3ED6D1AC-1E1C-11D9-9A0A-0003934A79C2@sniff.de> Content-Transfer-Encoding: 7bit From: Marc Binderberger Subject: Re: [Isis-wg] Listing some other pseudonode in CSNP Date: Thu, 14 Oct 2004 22:04:24 +0200 To: Abhishek Verma X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Hello Abhishek, > R1 --- R2 > |----- R3 > > R1-R2 and R2-R3 are on different LANs. > R2 happens to be the DIS on both of them. > I see that when R2 sends its CSNPs to R1, it includes the pseudonode > LSP that it has generated for the LAN2 also in it. The CSNP lists all LSPs in the database of R2. That include the R2--R3 LAN pseudonode as well. > Will this not confuse R1? I hope it won't :-) The DIS pseudonode ID is part of the LAN IIH packets (the LAN ID field). So all members of a particular LAN know the DIS from that. No way to get confused. > I see 0000.1010.1010.02-00 listed in the CSNP that R2 sends to R1. Now > R1 doesnt have this LSP, as it holds relevance only in the other LAN. No relevance? For sure, it is needed to get connectivity to R3. With the pseudonodes the topology looks like: R1 -- (R2.01) -- R2.00 -- (R2.02) -- R3 Without the R2.02 (your 0000.1010.1010.02-00) it wouldn't be possible to built the connected graph R1 -> R2 -> R3. > What will R1 now do? Will it send a PSNP back to R2 requesting it? Yes (assuming it hasn't received the first flooding of R2.02). Regards, Marc -- Marc Binderberger _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 14 17:18: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 RAA06970 for ; Thu, 14 Oct 2004 17:18: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 1CICSv-0000G7-2x; Thu, 14 Oct 2004 16:44:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICHS-0004gg-6O for isis-wg@megatron.ietf.org; Thu, 14 Oct 2004 16:32:58 -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 QAA27143 for ; Thu, 14 Oct 2004 16:32:55 -0400 (EDT) Received: from door.sniff.de ([82.212.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICSf-00034U-A0 for isis-wg@ietf.org; Thu, 14 Oct 2004 16:44:34 -0400 Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 2BDC12AA0F; Thu, 14 Oct 2004 20:25:20 +0000 (GMT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <52C8605E-1E20-11D9-9A0A-0003934A79C2@sniff.de> Content-Transfer-Encoding: 7bit From: Marc Binderberger Subject: Re: [Isis-wg] Zero Metrics in TLV 128? Date: Thu, 14 Oct 2004 22:33:36 +0200 To: Abhishek Verma X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Hello Abhishek, maybe I can answer parts of your question. Based on my experience with Cisco equipment (haven't checked if all details are a MUST per specs of if Juniper and other may behave differently. Comments about this are welcome :-) R2 put the 192.168.1/24 into the L1 database by default (unless you configure "isis circuit-type level-2-only" in the interface context). It also redistributes all L1 information into L2 (modulo up/down bit - another story). So R2 is advertising the 182.168.1/24 in L1 and L2 LSP. Other L1L2 routers being connected to R2 via L1L2 links will again redistribute the L1 information into L2. This L2 information is newly generated on R1 and R3 and thus both routers advertise it. The metric should be the calculated metric on R1 and R3, i.e. 10 for standard link distance R1--R2 / R3--R2 and 10 again for the default interface distance of the 192.168.1/24 interface. So I'm not surprised by your finding of R3. But I can't explain the zero metrics on R1 (?). Regards, Marc On Oct 14, 2004, at 19:04 Uhr, Abhishek Verma wrote: > Hi All, > > I notice this. > > R1 (x.1/24) ----------- R2 (x.2/24) > |__ 192.168.1/24 > > R2 is also connected to another interface 192.168.1/24 and this > interface has been added to ISIS. R1 and R2 are L1L2 routers. R1 in > its L2 LSP advertises 192.168.1/24 network in its TLV 128 (IP Internal > Reachability) with Zero metric. It does not include this interface in > its L1 LSP though. > > Thus would an ISIS router advertise the IP reachability information > that it has learnt from other ISIS routers with metric Zero to other > ISes? > > Is this normal? > > When i connect R3 to R2 on another LAN, I see it advertising the > network x/24 (the one over which R1 and R2 are connected) with metric > 20 back to R2 in its L2 LSP. This is again, included in TLV 128. > > I thought, since it learnt this information from other ISes it should > have advertised this with metric Zero. > > I think i got lost somewhere! > > Any clues, anybody? > > Regards, > Abhishek. > > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > -- Marc Binderberger _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Oct 22 09:25:37 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 JAA02150 for ; Fri, 22 Oct 2004 09:25:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzJS-00056Q-FV; Fri, 22 Oct 2004 09:18:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh3w-00087U-WF for isis-wg@megatron.ietf.org; Thu, 21 Oct 2004 13:49: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 NAA28651 for ; Thu, 21 Oct 2004 13:49:19 -0400 (EDT) Received: from web53404.mail.yahoo.com ([206.190.37.51]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKhGQ-0001KI-Rq for isis-wg@ietf.org; Thu, 21 Oct 2004 14:02:26 -0400 Message-ID: <20041021174838.33342.qmail@web53404.mail.yahoo.com> Received: from [47.234.0.51] by web53404.mail.yahoo.com via HTTP; Thu, 21 Oct 2004 10:48:38 PDT Date: Thu, 21 Oct 2004 10:48:38 -0700 (PDT) From: maya cook To: isis-wg@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Fri, 22 Oct 2004 09:18:32 -0400 Subject: [Isis-wg] RFC 11142.ps vs RFC1142.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: , Content-Type: multipart/mixed; boundary="===============1729765612==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============1729765612== Content-Type: multipart/alternative; boundary="0-1628309311-1098380918=:32941" --0-1628309311-1098380918=:32941 Content-Type: text/plain; charset=us-ascii Can anyone tell me where I can get an update postscript version of rfc 1142. The .txt and .ps versions on the IETF site are different. They both have the same date February 1990. But the .txt version has some updates (authentication, overload bit etc). The .ps version is old. It is hard to read the .txt version and I would like to print a hard copy. I found a few sites that had the old .ps version. Where can I get an updated postscript version? Thanks maya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1628309311-1098380918=:32941 Content-Type: text/html; charset=us-ascii
Can anyone tell me where I can get an update postscript version of rfc 1142.
The .txt and .ps versions on the IETF site are different. They both have the same date February 1990. But the .txt version has some updates (authentication, overload bit etc). The .ps version is old. It is hard to read the .txt version and I would like to print a hard copy. I found a few sites that had the old .ps version.  Where can I get an updated postscript version?
 
Thanks
maya
 

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-1628309311-1098380918=:32941-- --===============1729765612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1729765612==-- From isis-wg-bounces@ietf.org Fri Oct 22 12:32: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 MAA18541 for ; Fri, 22 Oct 2004 12:32: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 1CL2J1-0003Mo-Ka; Fri, 22 Oct 2004 12:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2Aq-0001Uw-7E for isis-wg@megatron.ietf.org; Fri, 22 Oct 2004 12:21:52 -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 MAA17819 for ; Fri, 22 Oct 2004 12:21:48 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2NT-0001Y7-Pq for isis-wg@ietf.org; Fri, 22 Oct 2004 12:35:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 22 Oct 2004 09:31:39 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9MGL56s029113; Fri, 22 Oct 2004 09:21:05 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-1186.cisco.com [10.21.100.162]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUZ15577; Fri, 22 Oct 2004 09:18:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20041022091528.01e9dd48@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Oct 2004 09:21:04 -0700 To: maya cook From: Les Ginsberg Subject: Re: [Isis-wg] RFC 11142.ps vs RFC1142.txt In-Reply-To: <20041021174838.33342.qmail@web53404.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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:48 AM 10/21/2004 -0700, maya cook wrote: >Can anyone tell me where I can get an update postscript version of rfc 1142. >The .txt and .ps versions on the IETF site are different. They both have >the same date February 1990. But the .txt version has some updates >(authentication, overload bit etc). The .ps version is old. It is hard to >read the .txt version and I would like to print a hard copy. I found a few >sites that had the old .ps version. Where can I get an updated postscript >version? > Maya - RFC 1142 is obsolete - and has been ever since ISO 10589 was published back in 1992. Please use ISO 10589:2002 - freely available at http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c030932_ISO_IEC_10589_2002(E).zip Les (Chris/Dave/Alex - could we do something about getting the status of this document changed from "Informational" to "Obsolete" as this question seems to come up every 6 months or so??) >Thanks >maya > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.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 Mon Oct 25 09:05:31 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 JAA23197 for ; Mon, 25 Oct 2004 09:05:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM4S2-0002KX-Ie; Mon, 25 Oct 2004 08:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzpk-0000jE-1F for isis-wg@megatron.ietf.org; Fri, 22 Oct 2004 09:51:56 -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 JAA04446 for ; Fri, 22 Oct 2004 09:51:53 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL02N-0006gM-2v for isis-wg@ietf.org; Fri, 22 Oct 2004 10:05:09 -0400 Received: from 140.233.20.186 [140.233.20.186] by anthrax.middlebury.edu with XWall v3.30 ; Fri, 22 Oct 2004 09:51:03 -0400 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 22 Oct 2004 09:50:51 -0400 Subject: Re: [Isis-wg] RFC 11142.ps vs RFC1142.txt From: Jeff Parker To: maya cook , Message-ID: In-Reply-To: <20041021174838.33342.qmail@web53404.mail.yahoo.com> Mime-version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-Mailman-Approved-At: Mon, 25 Oct 2004 08:59:53 -0400 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: , Content-Type: multipart/mixed; boundary="===============0429894685==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0429894685== Content-type: multipart/alternative; boundary="B_3181283462_177847" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3181283462_177847 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Maya - RFC 1142 is an imperfect copy of ISO 10589. Accept no substitutes: get the original. - jeff parker On 10/21/04 1:48 PM, "maya cook" wrote: > Can anyone tell me where I can get an update postscript version of rfc 1142. > The .txt and .ps versions on the IETF site are different. They both have the > same date February 1990. But the .txt version has some updates > (authentication, overload bit etc). The .ps version is old. It is hard to read > the .txt version and I would like to print a hard copy. I found a few sites > that had the old .ps version. Where can I get an updated postscript version? > > Thanks > maya > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg --B_3181283462_177847 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] RFC 11142.ps vs RFC1142.txt Maya = -
    RFC 1142 is an imperfect copy of ISO 10589.  A= ccept no substitutes: get the original.  

- jeff parker


On 10/21/04 1:48 PM, "maya cook" <maya01_cook@yahoo.com> wr= ote:

Can anyone tell me where I can get an update postscript= version of rfc 1142.
The .txt and .ps versions on the IETF site are different. They both have th= e same date February 1990. But the .txt version has some updates (authentica= tion, overload bit etc). The .ps version is old. It is hard to read the .txt= version and I would like to print a hard copy. I found a few sites that had= the old .ps version.  Where can I get an updated postscript version?  
Thanks
maya
 
__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
____________________= ___________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

 --B_3181283462_177847-- --===============0429894685== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0429894685==-- From isis-wg-bounces@ietf.org Mon Oct 25 13:58:32 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 NAA18836 for ; Mon, 25 Oct 2004 13:58:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM93O-0003DM-Cn; Mon, 25 Oct 2004 13:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8zA-0002R5-AC for isis-wg@megatron.ietf.org; Mon, 25 Oct 2004 13:50:24 -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 NAA18022 for ; Mon, 25 Oct 2004 13:50:22 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM9Cc-00041O-6U for isis-wg@ietf.org; Mon, 25 Oct 2004 14:04:21 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Mon, 25 Oct 2004 13:49:49 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 13:49:49 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.186 140.233.20.186 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 25 Oct 2004 13:49:47 -0400 From: "Parker, Jeff" To: "ISIS-WG (E-mail)" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Oct 2004 17:49:49.0390 (UTC) FILETIME=[05E71EE0:01C4BABB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Submission of new version of the MIB 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 have submitted version 17 of the MIB, in hopes of making the cutoff before the meeting. The changes are listed below. Comments and concerns are welcome - jeff parker -- Changes in version 17 -- -- Limited the types of address supported to IPv4 or IPv6 -- Added InterfaceIndex for CircIndex -- Changed names to match MIB guidelines -- Added display hints for Textual Conventions -- Cleaned up formating -- Combined isisManAreaAddrTable with AreaAddressTable -- Replaced isisSysProtSuppTable with BITS -- Limit states required to support RowStatus -- Removed arbitrary limits, replaces with non-zero unsigned -- Added SysLevel to IPRA table -- Changed access type on a number of fields -- Replace "out System ID" with "our System ID" -- Change access for Indicies -- Add new objects for notifications -- New MIB Boilerplate _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 04:31:55 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 EAA10357 for ; Tue, 26 Oct 2004 04:31:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMcq-0007zh-Oo; Tue, 26 Oct 2004 04:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMX1-0006N8-Pb for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 04:18: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 EAA09107 for ; Tue, 26 Oct 2004 04:18:10 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMkY-0005L6-6H for isis-wg@ietf.org; Tue, 26 Oct 2004 04:32:17 -0400 Received: by wproxy.gmail.com with SMTP id 55so153505wri for ; Tue, 26 Oct 2004 01:17:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=Jwk8Vn453fjQOGPBCTwdpXdvysAZkSaoQC16RD94jxr0X+Fj0RMaoN+B+vO4fMUAPdNxuW5G73j/x9aor72skgxoneW8Kq7OHJTWvO4Tu0zoXVNTEfI960/Q+MMwHUzdgqQWxaz0EQSLD6Ivm8wxXC0rV57Cv5aHJglUTLZjnQw= Received: by 10.38.76.80 with SMTP id y80mr215597rna; Tue, 26 Oct 2004 01:17:37 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Tue, 26 Oct 2004 01:17:37 -0700 (PDT) Message-ID: Date: Tue, 26 Oct 2004 13:47:37 +0530 From: Abhishek Verma To: isis-wg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Isis-wg] No MAC Address .. X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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, I have an ISIS adjacency (L1/L2/L1L2) up with a router. What if i dont recieve my MAC address in his HELLOs. What should i do? Should i break off the adjacency that i have with the other router? What should i do? Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 05:01: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 FAA13615 for ; Tue, 26 Oct 2004 05:01:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMN85-0007oG-ID; Tue, 26 Oct 2004 04:56:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMzu-00057Z-Dp for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 04:48: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 EAA12376 for ; Tue, 26 Oct 2004 04:48:03 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNDW-00068S-Q4 for isis-wg@ietf.org; Tue, 26 Oct 2004 05:02:11 -0400 Received: from [192.168.1.3] (c-67-164-0-92.client.comcast.net[67.164.0.92]) by comcast.net (rwcrmhc13) with SMTP id <2004102608472601500mvkdde> (Authid: li.tony); Tue, 26 Oct 2004 08:47:26 +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] No MAC Address .. Date: Tue, 26 Oct 2004 01:47:24 -0700 To: Abhishek Verma X-Mailer: Apple Mail (2.619) X-Spam-Score: 1.2 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 If you don't receive a MAC address (presumably you're on a LAN ;-), then the other system has broken its adjacency with you, probably because it can't hear you, or it rebooted, and you need to restart the adjacency. Tony On Oct 26, 2004, at 1:17 AM, Abhishek Verma wrote: > Hi, > > I have an ISIS adjacency (L1/L2/L1L2) up with a router. What if i dont > recieve my MAC address in his HELLOs. What should i do? Should i break > off the adjacency that i have with the other router? What should i do? > > Thanks, > Abhishek > > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India > > _______________________________________________ > 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 Oct 26 10:30:32 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 KAA09617 for ; Tue, 26 Oct 2004 10:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSEj-0007Yq-4p; Tue, 26 Oct 2004 10:23:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSAq-0005r5-92 for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 10:19: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 KAA08671 for ; Tue, 26 Oct 2004 10:19:42 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSOL-0003x1-NK for isis-wg@ietf.org; Tue, 26 Oct 2004 10:33:52 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Tue, 26 Oct 2004 10:19:01 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Oct 2004 10:19:00 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.186 140.233.20.186 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 26 Oct 2004 10:19:00 -0400 Subject: Re: [Isis-wg] No MAC Address .. From: "Parker, Jeff" To: Abhishek Verma , "ISIS-WG (E-mail)" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Oct 2004 14:19:00.0867 (UTC) FILETIME=[BD356D30:01C4BB66] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit 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 It isn't clear if o He had your MAC address in the past, but no longer does o He has never had your MAC address. If he has never acknowledged you, you could use whatever diagnostic tools that the peer supports to check for dropped hellos: they may be due to a number of causes: mismatch of IP address, mismatch of Area Address, mismatch of security, etc. You might, for example, be reporting the wrong MAC yourself. There may be some diagnostic capability on the peer that will give you some visibility here. You are presumably on a LAN, and may have the ability to perform a packet dump on the hellos. I would compare the fields above and look for differences. We have tried to address this kind of issue with SNMP Notifications and counters, but that work is recent enough that I would be surprised if it were implemented on your peer. - jeff parker On 10/26/04 4:17 AM, "Abhishek Verma" wrote: > Hi, > > I have an ISIS adjacency (L1/L2/L1L2) up with a router. What if i dont > recieve my MAC address in his HELLOs. What should i do? Should i break > off the adjacency that i have with the other router? What should i do? > > Thanks, > Abhishek > > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India > > _______________________________________________ > 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 Oct 26 11:34: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 LAA15637 for ; Tue, 26 Oct 2004 11:34: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 1CMTB6-0000ez-4i; Tue, 26 Oct 2004 11:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMT9t-0000SH-VE for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 11:22: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 LAA13822 for ; Tue, 26 Oct 2004 11:22:47 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTNZ-0005DI-E1 for isis-wg@ietf.org; Tue, 26 Oct 2004 11:36:58 -0400 Received: by wproxy.gmail.com with SMTP id 55so196680wri for ; Tue, 26 Oct 2004 08:22:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=E+7SmuPts2exKl8f3VlcfOrCl/gTHS0FiPDcY0CdYy3DRK86WQaSpZ8a8OlUvmupLW2Pzd3FWe9hgoBmHSiTJhDISDxfwqNwOkGrIgluLaNfed0i1q+e0ueh7zSsHHhCaeYmO6jfvol/xuT/KxVMYJk6crFt0kTwFNJNROC9uPk= Received: by 10.38.151.24 with SMTP id y24mr350804rnd; Tue, 26 Oct 2004 08:22:14 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Tue, 26 Oct 2004 08:22:14 -0700 (PDT) Message-ID: Date: Tue, 26 Oct 2004 20:52:14 +0530 From: Abhishek Verma To: "Parker, Jeff" Subject: Re: [Isis-wg] No MAC Address .. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: "ISIS-WG \(E-mail\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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, > o He had your MAC address in the past, but no longer does He had the MAC and my adjacency was up. But then I receive a HELLO from him in which he doesnt list my HELLO! And Yes, i am on a LAN. I believe in such cases, i should change my adjacency from the "UP" state to the "Init" state. Dont think its mentioned anywhere in the ISIS docs. Regards, Abhishek _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 11:50:00 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 LAA17353 for ; Tue, 26 Oct 2004 11:50:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTTl-0005Fl-JT; Tue, 26 Oct 2004 11:43:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTPD-00046q-PV for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 11:38: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 LAA16160 for ; Tue, 26 Oct 2004 11:38:37 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTct-0005mW-0y for isis-wg@ietf.org; Tue, 26 Oct 2004 11:52:48 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Tue, 26 Oct 2004 11:38:04 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Oct 2004 11:38:04 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.186 140.233.20.186 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 26 Oct 2004 11:38:04 -0400 Subject: Re: [Isis-wg] No MAC Address .. From: "Parker, Jeff" To: Abhishek Verma Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Oct 2004 15:38:04.0476 (UTC) FILETIME=[C89EB7C0:01C4BB71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 10/26/04 11:22 AM, "Abhishek Verma" wrote: > Hi Jeff, > >> o He had your MAC address in the past, but no longer does > > He had the MAC and my adjacency was up. But then I receive a HELLO > from him in which he doesnt list my HELLO! > > And Yes, i am on a LAN. I believe in such cases, i should change my > adjacency from the "UP" state to the "Init" state. > > Dont think its mentioned anywhere in the ISIS docs. > > Regards, > Abhishek Abhishek - A serious charge indeed. I take it that you are implementing your own version of the protocol. Does this happen time after time, or rarely? Does his adjacency move from state init to full? Who is the designated router on the LAN? If it is you, are you doing the right things? What happens when you alter the priority so that the remote end is (or isn't) the DIS? I would take a look at what the two of you are sending, as suggested before. You might wish to compare your exchange with what two other peers are doing. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 11:53:10 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 LAA17683 for ; Tue, 26 Oct 2004 11:53:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTbi-0006yC-KB; Tue, 26 Oct 2004 11:51:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTUE-0005Ri-LB for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 11:43: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 LAA16730 for ; Tue, 26 Oct 2004 11:43:48 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMThv-0005t7-7S for isis-wg@ietf.org; Tue, 26 Oct 2004 11:57:59 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Tue, 26 Oct 2004 11:43:18 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Oct 2004 11:43:18 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.186 140.233.20.186 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 26 Oct 2004 11:38:04 -0400 Subject: Re: [Isis-wg] No MAC Address .. From: "Parker, Jeff" To: Abhishek Verma Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Oct 2004 15:43:18.0382 (UTC) FILETIME=[83B8F8E0:01C4BB72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 10/26/04 11:22 AM, "Abhishek Verma" wrote: > Hi Jeff, > >> o He had your MAC address in the past, but no longer does > > He had the MAC and my adjacency was up. But then I receive a HELLO > from him in which he doesnt list my HELLO! > > And Yes, i am on a LAN. I believe in such cases, i should change my > adjacency from the "UP" state to the "Init" state. > > Dont think its mentioned anywhere in the ISIS docs. > > Regards, > Abhishek Abhishek - A serious charge indeed. I take it that you are implementing your own version of the protocol. Does this happen time after time, or rarely? Does his adjacency move from state init to full? Who is the designated router on the LAN? If it is you, are you doing the right things? What happens when you alter the priority so that the remote end is (or isn't) the DIS? I would take a look at what the two of you are sending, as suggested before. You might wish to compare your exchange with what two other peers are doing. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 12:33: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 MAA20846 for ; Tue, 26 Oct 2004 12:33: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 1CMU9z-00085N-6u; Tue, 26 Oct 2004 12:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMU6B-000719-Vv for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 12:23: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 MAA20124 for ; Tue, 26 Oct 2004 12:23:01 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.192]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUJr-0006mi-UL for isis-wg@ietf.org; Tue, 26 Oct 2004 12:37:13 -0400 Received: by wproxy.gmail.com with SMTP id 55so205918wri for ; Tue, 26 Oct 2004 09:22:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=MgKWaayMtFJjEkgsGnTZw8RAZcJayZcNgJjb5F8rcTZ0qtDQc8EImFR9C0OsosIAQgJVqSIMgrtc+lczWtYeZunds6iV2PeDS9uZit/BygCWaRBEEkcKwyU5bYXA6jxGHjvXVAkriTtsJMLa4YQy+JFKqElESDHPDBTZHpd5dbw= Received: by 10.38.151.24 with SMTP id y24mr378248rnd; Tue, 26 Oct 2004 09:22:28 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Tue, 26 Oct 2004 09:22:28 -0700 (PDT) Message-ID: Date: Tue, 26 Oct 2004 21:52:28 +0530 From: Abhishek Verma To: "Parker, Jeff" , isis-wg@ietf.org Subject: Re: [Isis-wg] No MAC Address .. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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 serious charge indeed. :) > > I take it that you are implementing your own version of the protocol. Exactly. > Does this happen time after time, or rarely? Does his adjacency move from > state init to full? Who is the designated router on the LAN? If it is you, > are you doing the right things? What happens when you alter the priority so > that the remote end is (or isn't) the DIS? It happens only when the router at the other end because of some reason isnt able to process my HELLO messages and times out. I am btw the DIS, so i have a smaller HOLD Timer than him. This router at the other end is busy and times out. He then sends me a HELLO message in which i am not listed. SO the question is, should i upon recieving this HELLO message bring down my adjacency with this guy from Up to Init? The doubt came because its not clearly spelled out in the specs! Regards, Abhishek > > I would take a look at what the two of you are sending, as suggested > before. You might wish to compare your exchange with what two other peers > are doing. > > - jeff parker > > -- -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 12:40:28 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 MAA21301 for ; Tue, 26 Oct 2004 12:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMULU-0001nE-Sm; Tue, 26 Oct 2004 12:38:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUKu-0001dF-HF for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 12:38:16 -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 MAA21119 for ; Tue, 26 Oct 2004 12:38:13 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUYa-00071f-NZ for isis-wg@ietf.org; Tue, 26 Oct 2004 12:52:26 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2004 12:34:40 -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 i9QGYZWV020366; Tue, 26 Oct 2004 12:34:37 -0400 (EDT) Received: from jlearman-w2k03.cisco.com (dhcp-64-102-83-124.cisco.com [64.102.83.124]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCY04584; Tue, 26 Oct 2004 09:34:34 -0700 (PDT) Message-Id: <4.3.2.7.2.20041026122754.023ddc40@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Oct 2004 12:34:29 -0400 To: "Parker, Jeff" , Abhishek Verma From: Jeff Learman Subject: Re: [Isis-wg] No MAC Address .. In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 By George, I think he's right. While it might be mentioned somewhere, it should be mentioned in Section 8.4.2.4, "Existing Adjacencies". Jeff At 11:38 AM 10/26/2004, Parker, Jeff wrote: >On 10/26/04 11:22 AM, "Abhishek Verma" wrote: > >> Hi Jeff, >> >>> o He had your MAC address in the past, but no longer does >> >> He had the MAC and my adjacency was up. But then I receive a HELLO >> from him in which he doesnt list my HELLO! >> >> And Yes, i am on a LAN. I believe in such cases, i should change my >> adjacency from the "UP" state to the "Init" state. >> >> Dont think its mentioned anywhere in the ISIS docs. >> >> Regards, >> Abhishek > >Abhishek - > A serious charge indeed. > > I take it that you are implementing your own version of the protocol. >Does this happen time after time, or rarely? Does his adjacency move from >state init to full? Who is the designated router on the LAN? If it is you, >are you doing the right things? What happens when you alter the priority so >that the remote end is (or isn't) the DIS? > > I would take a look at what the two of you are sending, as suggested >before. You might wish to compare your exchange with what two other peers >are doing. > >- 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 Tue Oct 26 12:42:13 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 MAA21495 for ; Tue, 26 Oct 2004 12:42: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 1CMULV-0001nJ-6S; Tue, 26 Oct 2004 12:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMULC-0001dL-QU for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 12:38: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 MAA21136 for ; Tue, 26 Oct 2004 12:38:31 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUYs-00071s-Mo for isis-wg@ietf.org; Tue, 26 Oct 2004 12:52:44 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Tue, 26 Oct 2004 12:38:01 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Oct 2004 12:38:01 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.186 140.233.20.186 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 26 Oct 2004 12:38:01 -0400 Subject: Re: [Isis-wg] No MAC Address .. From: "Parker, Jeff" To: Abhishek Verma , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Oct 2004 16:38:01.0601 (UTC) FILETIME=[28AC6F10:01C4BB7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit 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 haven't seen chapter and verse in the two trips to 10589 this morning, but I wouldn't claim that it isn't covered. I would suggest that you not use a hello without your MAC to update your adjacency. As a result, you will time out soon enough. "The router is busy and times out. He then sends a hello..." If the router cannot keep up with your hello packets, his adjacency will time out. At this point, he tears down the adjacency, so he shouldn't send your mac address. Would the router at the far end by your implementation? What provisions have you made to expedite the sending and receiving of hellos? Your body will shortchange your hands and feet to keep your brain alive. - jeff parker On 10/26/04 12:22 PM, "Abhishek Verma" wrote: > Hi Jeff, > >> A serious charge indeed. > > :) > >> >> I take it that you are implementing your own version of the protocol. > > Exactly. > >> Does this happen time after time, or rarely? Does his adjacency move from >> state init to full? Who is the designated router on the LAN? If it is you, >> are you doing the right things? What happens when you alter the priority so >> that the remote end is (or isn't) the DIS? > > It happens only when the router at the other end because of some > reason isnt able to process my HELLO messages and times out. I am btw > the DIS, so i have a smaller HOLD Timer than him. This router at the > other end is busy and times out. He then sends me a HELLO message in > which i am not listed. > > SO the question is, should i upon recieving this HELLO message bring > down my adjacency with this guy from Up to Init? The doubt came > because its not clearly spelled out in the specs! > > Regards, > Abhishek > >> >> I would take a look at what the two of you are sending, as suggested >> before. You might wish to compare your exchange with what two other peers >> are doing. >> >> - jeff parker >> >> > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 13:09: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 NAA24232 for ; Tue, 26 Oct 2004 13:09: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 1CMUad-00076j-5P; Tue, 26 Oct 2004 12:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUWN-0006Sr-5q for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 12:50:07 -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 MAA22037 for ; Tue, 26 Oct 2004 12:50:04 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUk3-0007Hl-DB for isis-wg@ietf.org; Tue, 26 Oct 2004 13:04:16 -0400 Received: by wproxy.gmail.com with SMTP id 55so209881wri for ; Tue, 26 Oct 2004 09:49:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=O4K0g5GW9skHIAlA1vADPPm5uUGqd+VH9/+OGnnAcequHOIhihdTGOreO1LvyE9zFLCWjaFF1KSLCLiRNdKUqAyQhxhb5p+8wOkap0r4O03fvp0Jzf4JE0pHgPxeyIQeVRPRPhED6MSIS6giOfvCVZQXmAcNEDUAGf4pzdyjo8k= Received: by 10.38.67.25 with SMTP id p25mr397391rna; Tue, 26 Oct 2004 09:49:35 -0700 (PDT) Received: by 10.38.102.30 with HTTP; Tue, 26 Oct 2004 09:49:35 -0700 (PDT) Message-ID: Date: Tue, 26 Oct 2004 22:19:35 +0530 From: Abhishek Verma To: "Parker, Jeff" Subject: Re: [Isis-wg] No MAC Address .. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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: Abhishek Verma 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 would suggest that you not use a hello without your MAC to update your > adjacency. As a result, you will time out soon enough. why waste time? Why not bring down the adjacency immediately and declare the remote router to be in the down state. > > "The router is busy and times out. He then sends a hello..." > > If the router cannot keep up with your hello packets, his adjacency will > time out. At this point, he tears down the adjacency, so he shouldn't send > your mac address. Which is exactly what is happening. Say R1 and R2 are two routers where R1 is the DIS. R2 waits for some 10 secs and if he doesnt hear from R1 then he declares him dead, tears down its adjacency and omits his MAC from its HELLOs. R1, otoh, needs to wait for 30 secs or so, as per your suggestion to declare R2 to be down. I say, why wait for that much time. The first time you hear from R1 without your MAC, bring down the adjacency and go, sing out a song in the rain! Regards, Abhishek. > Would the router at the far end by your implementation? > What provisions have you made to expedite the sending and receiving of > hellos? Your body will shortchange your hands and feet to keep your brain > alive. > > > > - jeff parker > > On 10/26/04 12:22 PM, "Abhishek Verma" wrote: > > > Hi Jeff, > > > >> A serious charge indeed. > > > > :) > > > >> > >> I take it that you are implementing your own version of the protocol. > > > > Exactly. > > > >> Does this happen time after time, or rarely? Does his adjacency move from > >> state init to full? Who is the designated router on the LAN? If it is you, > >> are you doing the right things? What happens when you alter the priority so > >> that the remote end is (or isn't) the DIS? > > > > It happens only when the router at the other end because of some > > reason isnt able to process my HELLO messages and times out. I am btw > > the DIS, so i have a smaller HOLD Timer than him. This router at the > > other end is busy and times out. He then sends me a HELLO message in > > which i am not listed. > > > > SO the question is, should i upon recieving this HELLO message bring > > down my adjacency with this guy from Up to Init? The doubt came > > because its not clearly spelled out in the specs! > > > > Regards, > > Abhishek > > > >> > >> I would take a look at what the two of you are sending, as suggested > >> before. You might wish to compare your exchange with what two other peers > >> are doing. > >> > >> - jeff parker > >> > >> > > > > -- -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 13:11: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 NAA24414 for ; Tue, 26 Oct 2004 13:11: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 1CMUeJ-0007v8-Jp; Tue, 26 Oct 2004 12:58:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUYk-0006mV-Hx for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 12:52: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 MAA22131 for ; Tue, 26 Oct 2004 12:52:31 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUmQ-0007KE-Ur for isis-wg@ietf.org; Tue, 26 Oct 2004 13:06:44 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9QGqS8M011037 for ; Tue, 26 Oct 2004 11:52:30 -0500 (CDT) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 26 Oct 2004 22:22:27 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D210306BDE@ii0015exch002u.iprc.lucent.com> From: "Ramalingam, Swaminathan (Swaminathan)" To: Jeff Learman , "Parker, Jeff" , Abhishek Verma Subject: RE: [Isis-wg] No MAC Address .. Date: Tue, 26 Oct 2004 22:22:27 +0530 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: b280b4db656c3ca28dd62e5e0b03daa8 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 It is mentioned in 8.4.2.5.3 8.4.2.5.3 If a Level n LAN IIH PDU is received from neighbour N, and this system's lANAddress is no longer in N's IIH PDU, the IS shall a) set the adjacency's adjacencyState to "initialising", and b) generate an adjacencyStateChange (Down) event. - Swami >-----Original Message----- >From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On >Behalf Of Jeff Learman >Sent: Tuesday, October 26, 2004 10:04 PM >To: Parker, Jeff; Abhishek Verma >Cc: ISIS-WG (E-mail) >Subject: Re: [Isis-wg] No MAC Address .. > > > >By George, I think he's right. While it might be mentioned >somewhere, it should be mentioned in Section 8.4.2.4, "Existing >Adjacencies". > >Jeff > >At 11:38 AM 10/26/2004, Parker, Jeff wrote: >>On 10/26/04 11:22 AM, "Abhishek Verma" > wrote: >> >>> Hi Jeff, >>> >>>> o He had your MAC address in the past, but no longer does >>> >>> He had the MAC and my adjacency was up. But then I receive a HELLO >>> from him in which he doesnt list my HELLO! >>> >>> And Yes, i am on a LAN. I believe in such cases, i should change my >>> adjacency from the "UP" state to the "Init" state. >>> >>> Dont think its mentioned anywhere in the ISIS docs. >>> >>> Regards, >>> Abhishek >> >>Abhishek - >> A serious charge indeed. >> >> I take it that you are implementing your own version of >the protocol. >>Does this happen time after time, or rarely? Does his >adjacency move from >>state init to full? Who is the designated router on the LAN? > If it is you, >>are you doing the right things? What happens when you alter >the priority so >>that the remote end is (or isn't) the DIS? >> >> I would take a look at what the two of you are sending, >as suggested >>before. You might wish to compare your exchange with what >two other peers >>are doing. >> >>- 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 > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 13:31: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 NAA26838 for ; Tue, 26 Oct 2004 13:31: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 1CMUug-00056h-CD; Tue, 26 Oct 2004 13:15:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUoa-00038r-J9 for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 13:08:56 -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 NAA24193 for ; Tue, 26 Oct 2004 13:08:53 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMV2I-0007xn-1s for isis-wg@ietf.org; Tue, 26 Oct 2004 13:23:06 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2004 13:08:27 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9QH8NUD002673; Tue, 26 Oct 2004 13:08:24 -0400 (EDT) Received: from jlearman-w2k03.cisco.com (dhcp-64-102-83-124.cisco.com [64.102.83.124]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCY07650; Tue, 26 Oct 2004 10:08:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20041026130406.023e9028@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Oct 2004 13:08:17 -0400 To: "Ramalingam, Swaminathan (Swaminathan)" , "Parker, Jeff" , Abhishek Verma From: Jeff Learman Subject: RE: [Isis-wg] No MAC Address .. In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D210306BDE@ii0015exch002u.ip rc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 At 12:52 PM 10/26/2004, Ramalingam, Swaminathan (Swaminathan) wrote: >It is mentioned in 8.4.2.5.3 > >8.4.2.5.3 If a Level n LAN IIH PDU is received from neighbour N, and this >system's lANAddress is no longer in N's IIH >PDU, the IS shall >a) set the adjacency's adjacencyState to "initialising", and >b) generate an adjacencyStateChange (Down) event. Ah, yes. There it is. Thanks :) Jeff >- Swami > > >>-----Original Message----- >>From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On >>Behalf Of Jeff Learman >>Sent: Tuesday, October 26, 2004 10:04 PM >>To: Parker, Jeff; Abhishek Verma >>Cc: ISIS-WG (E-mail) >>Subject: Re: [Isis-wg] No MAC Address .. >> >> >> >>By George, I think he's right. While it might be mentioned >>somewhere, it should be mentioned in Section 8.4.2.4, "Existing >>Adjacencies". >> >>Jeff >> >>At 11:38 AM 10/26/2004, Parker, Jeff wrote: >>>On 10/26/04 11:22 AM, "Abhishek Verma" >> wrote: >>> >>>> Hi Jeff, >>>> >>>>> o He had your MAC address in the past, but no longer does >>>> >>>> He had the MAC and my adjacency was up. But then I receive a HELLO >>>> from him in which he doesnt list my HELLO! >>>> >>>> And Yes, i am on a LAN. I believe in such cases, i should change my >>>> adjacency from the "UP" state to the "Init" state. >>>> >>>> Dont think its mentioned anywhere in the ISIS docs. >>>> >>>> Regards, >>>> Abhishek >>> >>>Abhishek - >>> A serious charge indeed. >>> >>> I take it that you are implementing your own version of >>the protocol. >>>Does this happen time after time, or rarely? Does his >>adjacency move from >>>state init to full? Who is the designated router on the LAN? >> If it is you, >>>are you doing the right things? What happens when you alter >>the priority so >>>that the remote end is (or isn't) the DIS? >>> >>> I would take a look at what the two of you are sending, >>as suggested >>>before. You might wish to compare your exchange with what >>two other peers >>>are doing. >>> >>>- 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 >> _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 26 14:09:32 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 OAA00192 for ; Tue, 26 Oct 2004 14:09:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVbu-000300-3a; Tue, 26 Oct 2004 13:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVY2-0000vV-45 for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 13:55: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 NAA28878 for ; Tue, 26 Oct 2004 13:55:52 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVlj-0000tF-Ky for isis-wg@ietf.org; Tue, 26 Oct 2004 14:10:04 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2004 11:06:45 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9QHng7E000845; Tue, 26 Oct 2004 10:55:27 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn5-416.cisco.com [10.21.89.160]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVC05696; Tue, 26 Oct 2004 10:21:01 -0700 (PDT) Message-Id: <4.3.2.7.2.20041026101001.01d7c0b0@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Oct 2004 10:23:57 -0700 To: Abhishek Verma From: Les Ginsberg Subject: Re: [Isis-wg] No MAC Address .. In-Reply-To: References: Mime-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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: , Content-Type: multipart/mixed; boundary="===============0956506720==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============0956506720== Content-Type: multipart/alternative; boundary="=====================_9419294==_.ALT" --=====================_9419294==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:52 PM 10/26/2004 +0530, Abhishek Verma wrote: >Hi Jeff, > > > A serious charge indeed. > >:) > > > > > I take it that you are implementing your own version of the protocol. > >Exactly. > > > Does this happen time after time, or rarely? Does his adjacency move from > > state init to full? Who is the designated router on the LAN? If it is > you, > > are you doing the right things? What happens when you alter the > priority so > > that the remote end is (or isn't) the DIS? > >It happens only when the router at the other end because of some >reason isnt able to process my HELLO messages and times out. I am btw >the DIS, so i have a smaller HOLD Timer than him. This router at the >other end is busy and times out. He then sends me a HELLO message in >which i am not listed. > >SO the question is, should i upon recieving this HELLO message bring >down my adjacency with this guy from Up to Init? The doubt came >because its not clearly spelled out in the specs! Abhishek - The relevant section in ISO 10589:2002 is: 8.4.2.5.3 If a Level n LAN IIH PDU is received from neighbour N, and this system's lANAddress is no longer in N's IIH PDU, the IS shall a) set the adjacency's adjacencyState to "initialising", and b) generate an adjacencyStateChange (Down) event. It probably would have been clearer if this text was part of Section 8.4.2.4 (Existing adjacencies). Nevertheless, it applies in this case. Les >Regards, >Abhishek > > > > > I would take a look at what the two of you are sending, as suggested > > before. You might wish to compare your exchange with what two other peers > > are doing. > > > > - jeff parker > > > > > > >-- > >-- >Class of 2004 >Institute of Technology, BHU >Varanasi, India > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg --=====================_9419294==_.ALT Content-Type: text/html; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA28878 Content-Transfer-Encoding: quoted-printable At 09:52 PM 10/26/2004 +0530, Abhishek Verma wrote:
Hi Jeff,

>    A serious charge indeed.

:)

>
>    I take it that you are implementing your own version of the protocol.

Exactly.

> Does this happen time after time, or rarely?  Does his adjacency move from
> state init to full?  Who is the designated router on the LAN?  If it is you,
> are you doing the right things?  What happens when you alter the priority so
> that the remote end is (or isn't) the DIS?

It happens only when the router at the other end because of some
reason isnt able to process my HELLO messages and times out. I am btw
the DIS, so i have a smaller HOLD Timer than him. This router at=20 the
other end is busy and times out. He then sends me a HELLO message=20 in
which i am not listed.

SO the question is, should i upon recieving this HELLO message=20 bring
down my adjacency with this guy from Up to Init? The doubt came
because its not clearly spelled out in the specs!

Abhishek -

The relevant section in ISO 10589:2002 is:

8.4.2.5.3 If a Level n L= AN IIH PDU is received from neighbour N, and this system=92s lANAddre= ss is no longer in N=92s IIH PDU, t= he IS shall

a) &nbs= p;    set the adjacency=92s adjacencyState to =93initialising=94, and
b) &nbs= p;    generate an adjacencyStateChange (Down) event.


It probably would have been clearer if this text was part of Section 8.4.2.4 (Existing adjacencies). Nevertheless, it applies in this case.

   Les

Regards,
Abhishek

>
>    I would take a look at what the two of you are sending, as suggested
> before.  You might wish to compare your exchange with what two other peers
> are doing.
>
> - jeff parker
>
>


--

--
Class of 2004
Institute of Technology, BHU
Varanasi, India

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
--=====================_9419294==_.ALT-- --===============0956506720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0956506720==-- From isis-wg-bounces@ietf.org Thu Oct 28 02: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 CAA08323 for ; Thu, 28 Oct 2004 02: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 1CN3Xj-0003aA-BT; Thu, 28 Oct 2004 02:13:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN3X6-0003Ga-Na for isis-wg@megatron.ietf.org; Thu, 28 Oct 2004 02:13:12 -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 CAA07042 for ; Thu, 28 Oct 2004 02:13:12 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN3l2-0000mG-E7 for isis-wg@ietf.org; Thu, 28 Oct 2004 02:27:42 -0400 Received: from s19745 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I6A00DFW3V0JC@mta0.huawei.com> for isis-wg@ietf.org; Thu, 28 Oct 2004 13:13:49 +0800 (CST) Date: Thu, 28 Oct 2004 13:14:08 +0800 From: shengcheng To: isis-wg@ietf.org Message-id: <001001c4bcac$f4902260$1c336e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 2.2 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Isis-wg] "back to back" in ISO 10589 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: , Content-Type: multipart/mixed; boundary="===============1565386594==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1565386594== Content-type: multipart/alternative; boundary="Boundary_(ID_j0IMCvAN8gu6QAh2HfCe+g)" This is a multi-part message in MIME format. --Boundary_(ID_j0IMCvAN8gu6QAh2HfCe+g) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 SGksDQpJbiBJU08gMTA1ODksIDcuMy4xOSgxOTk4IHZlcnNpb24pDQoNCiINCk5PVEUgQW4gSW50 ZXJtZWRpYXRlIFN5c3RlbSBpcyBwZXJtaXR0ZWQgdG8gdHJhbnNtaXQgYSBzbWFsbA0KbnVtYmVy IG9mIExTUHMgKG5vIG1vcmUgdGhhbiAxMCkgd2l0aCBhIHNob3J0ZXIgc2VwYXJhdGlvbiBpbnRl cnZhbCwNCihvciBldmVuIKGwYmFjayB0byBiYWNrobEpLCBwcm92aWRlZCB0aGF0IG5vIG1vcmUg dGhhbg0KMTAwMC9taW5pbXVtQnJvYWRjYXN0TFNQdHJhbnNtaXNzaW9uSW50ZXJ2YWwgTFNQcyBh cmUNCnRyYW5zbWl0dGVkIGluIGFueSBvbmUgc2Vjb25kIHBlcmlvZC4NCiINCg0KV2hhdCBkb2Vz ICJiYWNrIHRvIGJhY2siIHJlZmVyIHRvID8gSSBoYXZlIG15IG93biB1bmRlcnN0YW5kaW5nIGJ1 dCBjYW4ndA0KbWFrZSBzdXJlIGl0IGlzIHJpZ2h0LiANCg0KQW55Ym9keSBjYW4gY2xhcmlmeT8N Cg0KVGhhbmtzDQpTaGVuZw0KDQo= --Boundary_(ID_j0IMCvAN8gu6QAh2HfCe+g) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTE5LjYzMDciIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSw8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5JbiBJU08gMTA1ODksIDcuMy4xOSgxOTk4IHZlcnNpb24pPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+IjxCUj5OT1RFIEFuIEludGVybWVkaWF0ZSBTeXN0ZW0gaXMgcGVybWl0dGVk IHRvIHRyYW5zbWl0IGEgDQpzbWFsbDxCUj5udW1iZXIgb2YgTFNQcyAobm8gbW9yZSB0aGFuIDEw KSB3aXRoIGEgc2hvcnRlciBzZXBhcmF0aW9uIA0KaW50ZXJ2YWwsPEJSPihvciBldmVuIKGwYmFj ayB0byBiYWNrobEpLCBwcm92aWRlZCB0aGF0IG5vIG1vcmUgDQp0aGFuPEJSPjEwMDAvbWluaW11 bUJyb2FkY2FzdExTUHRyYW5zbWlzc2lvbkludGVydmFsIExTUHMgYXJlPEJSPnRyYW5zbWl0dGVk IGluIA0KYW55IG9uZSBzZWNvbmQgcGVyaW9kLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPiI8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ V2hhdCBkb2VzICJiYWNrIHRvIGJhY2siIHJlZmVyIHRvID8mbmJzcDtJIGhhdmUgbXkgb3duIA0K dW5kZXJzdGFuZGluZyBidXQgY2FuJ3Q8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5t YWtlIHN1cmUgaXQgaXMgcmlnaHQuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkFueWJvZHkgY2FuIGNsYXJpZnk/ PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoYW5r czwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlNoZW5nPC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_j0IMCvAN8gu6QAh2HfCe+g)-- --===============1565386594== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1565386594==-- From isis-wg-bounces@ietf.org Thu Oct 28 02:36: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 CAA10193 for ; Thu, 28 Oct 2004 02:36: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 1CN3qL-0002ap-T0; Thu, 28 Oct 2004 02:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN3ot-0002EG-DW for isis-wg@megatron.ietf.org; Thu, 28 Oct 2004 02:31:35 -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 CAA09851 for ; Thu, 28 Oct 2004 02:31:34 -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 1CN42u-000155-Kd for isis-wg@ietf.org; Thu, 28 Oct 2004 02:46:04 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2004 23:40:16 -0700 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 i9S6UhYJ019702; Wed, 27 Oct 2004 23:30:44 -0700 (PDT) Received: from ginsberg-w2k01.cisco.com (sjc-vpn4-500.cisco.com [10.21.81.244]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AVD79232; Wed, 27 Oct 2004 23:27:41 -0700 (PDT) Message-Id: <4.3.2.7.2.20041027232407.02169e58@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Oct 2004 23:31:29 -0700 To: shengcheng From: Les Ginsberg Subject: Re: [Isis-wg] "back to back" in ISO 10589 In-Reply-To: <001001c4bcac$f4902260$1c336e0a@HUAWEI.COM> Mime-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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: , Content-Type: multipart/mixed; boundary="===============1594073672==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============1594073672== Content-Type: multipart/alternative; boundary="=====================_1936484==_.ALT" --=====================_1936484==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sheng - At 01:14 PM 10/28/2004 +0800, shengcheng wrote: >Hi, >In ISO 10589, 7.3.19(1998 version) NEVER EVER UNDER ANY CIRCUMSTANCES USE THE 1998 VERSION AS A REFERENCE!!!! The 1998 version is an unapproved version with numerous inaccuracies, some= =20 of major significance. Please discard it. (Where did you get this anyway?) Use the 2002 version, freely available at: http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c030932_ISO_IEC_10= 589_2002(E).zip > >" >NOTE An Intermediate System is permitted to transmit a small >number of LSPs (no more than 10) with a shorter separation interval, >(or even =A1=B0back to back=A1=B1), provided that no more than >1000/minimumBroadcastLSPtransmissionInterval LSPs are >transmitted in any one second period. >" > >What does "back to back" refer to ? I have my own understanding but can't >make sure it is right. "Back to back" means with no delay between the LSPs. Les > >Anybody can clarify? > >Thanks >Sheng > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg --=====================_1936484==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sheng -

At 01:14 PM 10/28/2004 +0800, shengcheng wrote:
Hi,
In ISO 10589, 7.3.19(1998 version)

NEVER EVER UNDER ANY CIRCUMSTANCES USE THE 1998 VERSION AS A REFERENCE!!!!

The 1998 version is an unapproved version with numerous inaccuracies, some of major significance. Please discard it.
(Where did you get this anyway?)

Use the 2002 version, freely available at:

http://www.iso.org/iso/en/ittf/PubliclyAvailableStandard= s/c030932_ISO_IEC_10589_2002(E).zip



 
"
NOTE An Intermediate System is permitted to transmit a small
number of LSPs (no more than 10) with a shorter separation=20 interval,
(or even =A1=B0back to back=A1=B1), provided that no more than
1000/minimumBroadcastLSPtransmissionInterval LSPs are
transmitted in any one second period.
"
 
What does "back to back" refer to ? I have my own understanding but can't
make sure it is right.

"Back to back" means with no delay between the LSPs.

   Les


 
Anybody can clarify?
 
Thanks
Sheng
 
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
--=====================_1936484==_.ALT-- --===============1594073672== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1594073672==-- From isis-wg-bounces@ietf.org Thu Oct 28 06:18:32 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 GAA27403 for ; Thu, 28 Oct 2004 06:18:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN7Ku-0003wi-Ez; Thu, 28 Oct 2004 06:16:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN7KV-0003jL-Hm for isis-wg@megatron.ietf.org; Thu, 28 Oct 2004 06:16:27 -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 GAA27089 for ; Thu, 28 Oct 2004 06:16:25 -0400 (EDT) Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN7YT-0005a1-RU for isis-wg@ietf.org; Thu, 28 Oct 2004 06:30:59 -0400 Received: from s19745 (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I6A00L46GU4FN@mta1.huawei.com> for isis-wg@ietf.org; Thu, 28 Oct 2004 17:54:05 +0800 (CST) Date: Thu, 28 Oct 2004 18:06:25 +0800 From: shengcheng Subject: Re: [Isis-wg] "back to back" in ISO 10589 To: Les Ginsberg Message-id: <002d01c4bcd5$c8f87ac0$1c336e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com References: <4.3.2.7.2.20041027232407.02169e58@mira-sjc5-3.cisco.com> X-Spam-Score: 3.3 (+++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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: , Content-Type: multipart/mixed; boundary="===============1258125483==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1258125483== Content-type: multipart/alternative; boundary="Boundary_(ID_nUnpN898MQQbq60QHnqdEw)" This is a multi-part message in MIME format. --Boundary_(ID_nUnpN898MQQbq60QHnqdEw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 TGVzOiANCiAgICBUaGFuayB5b3UgZm9yIHlvdXIgdGltZWx5IGhlbHAuIEluIGZhY3QsIGkgZm9y Z2V0IHdoZXJlIHRvIGdldCB0aGF0IDE5OTggdmVyc2lvbi4gOikNCiAgICBUbyBteSBrbm93bGVk Z2UsIDIwMDIgdmVyc2lvbiBpcyBub3QgZnJlZSBhdCB0aGUgYmVnaW5pbmcuIEkgYW0gYWxzbyBp bnRlcmVzdGVkIGhvdyBtdWNoIGhhcyB0aGUNCjIwMDIgdmVyc2lvbiBiZWVuIGltcHJvdmVkIGZy b20gMTk5MiB2ZXJzaW9uIGJ5IElTTyBvcmcuIFdvdWxkIHlvdSBwbGVhc2UgZ2l2ZSBzb21lIGRp cmVjdGlvbj8NCg0KVGhhbmtzLiANClNoZW5nDQoNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCiAgRnJvbTogTGVzIEdpbnNiZXJnIA0KICBUbzogc2hlbmdjaGVuZyANCiAgQ2M6IGlz aXMtd2dAaWV0Zi5vcmcgDQogIFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI4LCAyMDA0IDI6MzEg UE0NCiAgU3ViamVjdDogUmU6IFtJc2lzLXdnXSAiYmFjayB0byBiYWNrIiBpbiBJU08gMTA1ODkN Cg0KDQogIFNoZW5nIC0NCg0KICBBdCAwMToxNCBQTSAxMC8yOC8yMDA0ICswODAwLCBzaGVuZ2No ZW5nIHdyb3RlOg0KDQogICAgSGksDQogICAgSW4gSVNPIDEwNTg5LCA3LjMuMTkoMTk5OCB2ZXJz aW9uKQ0KDQoNCiAgTkVWRVIgRVZFUiBVTkRFUiBBTlkgQ0lSQ1VNU1RBTkNFUyBVU0UgVEhFIDE5 OTggVkVSU0lPTiBBUyBBIFJFRkVSRU5DRSEhISENCg0KICBUaGUgMTk5OCB2ZXJzaW9uIGlzIGFu IHVuYXBwcm92ZWQgdmVyc2lvbiB3aXRoIG51bWVyb3VzIGluYWNjdXJhY2llcywgc29tZSBvZiBt YWpvciBzaWduaWZpY2FuY2UuIFBsZWFzZSBkaXNjYXJkIGl0Lg0KICAoV2hlcmUgZGlkIHlvdSBn ZXQgdGhpcyBhbnl3YXk/KQ0KDQogIFVzZSB0aGUgMjAwMiB2ZXJzaW9uLCBmcmVlbHkgYXZhaWxh YmxlIGF0Og0KDQogIGh0dHA6Ly93d3cuaXNvLm9yZy9pc28vZW4vaXR0Zi9QdWJsaWNseUF2YWls YWJsZVN0YW5kYXJkcy9jMDMwOTMyX0lTT19JRUNfMTA1ODlfMjAwMihFKS56aXANCg0KDQoNCg0K DQogICAgIg0KICAgIE5PVEUgQW4gSW50ZXJtZWRpYXRlIFN5c3RlbSBpcyBwZXJtaXR0ZWQgdG8g dHJhbnNtaXQgYSBzbWFsbA0KICAgIG51bWJlciBvZiBMU1BzIChubyBtb3JlIHRoYW4gMTApIHdp dGggYSBzaG9ydGVyIHNlcGFyYXRpb24gaW50ZXJ2YWwsDQogICAgKG9yIGV2ZW4gobBiYWNrIHRv IGJhY2uhsSksIHByb3ZpZGVkIHRoYXQgbm8gbW9yZSB0aGFuDQogICAgMTAwMC9taW5pbXVtQnJv YWRjYXN0TFNQdHJhbnNtaXNzaW9uSW50ZXJ2YWwgTFNQcyBhcmUNCiAgICB0cmFuc21pdHRlZCBp biBhbnkgb25lIHNlY29uZCBwZXJpb2QuDQogICAgIg0KICAgICANCiAgICBXaGF0IGRvZXMgImJh Y2sgdG8gYmFjayIgcmVmZXIgdG8gPyBJIGhhdmUgbXkgb3duIHVuZGVyc3RhbmRpbmcgYnV0IGNh bid0DQogICAgbWFrZSBzdXJlIGl0IGlzIHJpZ2h0LiANCg0KDQogICJCYWNrIHRvIGJhY2siIG1l YW5zIHdpdGggbm8gZGVsYXkgYmV0d2VlbiB0aGUgTFNQcy4NCg0KICAgICBMZXMNCg0KDQoNCg0K ICAgIEFueWJvZHkgY2FuIGNsYXJpZnk/DQogICAgIA0KICAgIFRoYW5rcw0KICAgIFNoZW5nDQog ICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgSXNpcy13ZyBtYWlsaW5nIGxpc3QNCiAgICBJc2lzLXdnQGlldGYub3JnDQogICAgaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXNpcy13Zw0K --Boundary_(ID_nUnpN898MQQbq60QHnqdEw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjkxOS42MzA3IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPkxlczogPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGFuayB5b3UgZm9yIHlvdXIgdGltZWx5 IGhlbHAuIEluIA0KZmFjdCwgaSBmb3JnZXQgd2hlcmUgdG8gZ2V0IHRoYXQgMTk5OCB2ZXJzaW9u LiA6KTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsgVG8gbXkga25vd2xlZGdlLCAyMDAyIHZlcnNpb24gaXMgDQpu b3QgZnJlZSBhdCB0aGUgYmVnaW5pbmcuJm5ic3A7SSBhbSBhbHNvIGludGVyZXN0ZWQgaG93IG11 Y2ggaGFzIA0KdGhlPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPjIwMDIgdmVyc2lvbiBiZWVuIGltcHJvdmVkIGZyb20gMTk5MiB2ZXJzaW9uIGJ5 IElTTyANCm9yZy4gV291bGQgeW91IHBsZWFzZSBnaXZlIHNvbWUgZGlyZWN0aW9uPzwvRk9OVD48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 OyBzaXplPTI+VGhhbmtzLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+U2hlbmc8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPEJM T0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4t TEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkct UklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4t LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JP VU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxh Y2siPjxCPkZyb206PC9CPiANCiAgPEEgaHJlZj0ibWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbSIg dGl0bGU9Z2luc2JlcmdAY2lzY28uY29tPkxlcyBHaW5zYmVyZzwvQT4gDQogIDwvRElWPg0KICA8 RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSBocmVm PSJtYWlsdG86c2hlbmdjQGh1YXdlaS5jb20iIA0KICB0aXRsZT1zaGVuZ2NAaHVhd2VpLmNvbT5z aGVuZ2NoZW5nPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMy MDMwNzsiPjxCPkNjOjwvQj4gPEEgaHJlZj0ibWFpbHRvOmlzaXMtd2dAaWV0Zi5vcmciIA0KICB0 aXRsZT1pc2lzLXdnQGlldGYub3JnPmlzaXMtd2dAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElW IHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IFRodXJzZGF5 LCBPY3RvYmVyIDI4LCAyMDA0IDI6MzEgDQpQTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJlOiBbSXNpcy13Z10gImJhY2sg dG8gYmFjayIgaW4gSVNPIA0KICAxMDU4OTwvRElWPg0KICA8RElWPjxCUj48L0RJVj5TaGVuZyAt PEJSPjxCUj5BdCAwMToxNCBQTSAxMC8yOC8yMDA0ICswODAwLCBzaGVuZ2NoZW5nIA0KICB3cm90 ZTo8QlI+DQogIDxCTE9DS1FVT1RFIGNpdGUgdHlwZT0iY2l0ZSI+PEZPTlQgc2l6ZT0yPkhpLDwv Rk9OVD48QlI+PEZPTlQgc2l6ZT0yPkluIElTTyANCiAgICAxMDU4OSwgNy4zLjE5KDE5OTggdmVy c2lvbik8L0ZPTlQ+PEJSPjwvQkxPQ0tRVU9URT48QlI+PEZPTlQgDQogIHNpemU9ND48Qj48ST5O RVZFUiBFVkVSIFVOREVSIEFOWSBDSVJDVU1TVEFOQ0VTIFVTRSBUSEUgMTk5OCBWRVJTSU9OIEFT IEEgDQogIFJFRkVSRU5DRSEhISE8QlI+PEJSPjwvST48L0I+PC9GT05UPlRoZSAxOTk4IHZlcnNp b24gaXMgYW4gdW5hcHByb3ZlZCB2ZXJzaW9uIA0KICB3aXRoIG51bWVyb3VzIGluYWNjdXJhY2ll cywgc29tZSBvZiBtYWpvciBzaWduaWZpY2FuY2UuIFBsZWFzZSBkaXNjYXJkIA0KICBpdC48QlI+ KFdoZXJlIGRpZCB5b3UgZ2V0IHRoaXMgYW55d2F5Pyk8QlI+PEJSPlVzZSB0aGUgMjAwMiB2ZXJz aW9uLCBmcmVlbHkgDQogIGF2YWlsYWJsZSBhdDo8QlI+PEJSPjxBIA0KICBocmVmPSJodHRwOi8v d3d3Lmlzby5vcmcvaXNvL2VuL2l0dGYvUHVibGljbHlBdmFpbGFibGVTdGFuZGFyZHMvYzAzMDkz Ml9JU09fSUVDXzEwNTg5XzIwMDIoRSkuemlwIiANCiAgZXVkb3JhPSJhdXRvdXJsIj5odHRwOi8v d3d3Lmlzby5vcmcvaXNvL2VuL2l0dGYvUHVibGljbHlBdmFpbGFibGVTdGFuZGFyZHMvYzAzMDkz Ml9JU09fSUVDXzEwNTg5XzIwMDIoRSkuemlwPC9BPjxCUj48QlI+PEJSPjxCUj4NCiAgPEJMT0NL UVVPVEUgY2l0ZSB0eXBlPSJjaXRlIj48QlI+PEZPTlQgc2l6ZT0yPiI8QlI+Tk9URSBBbiBJbnRl cm1lZGlhdGUgDQogICAgU3lzdGVtIGlzIHBlcm1pdHRlZCB0byB0cmFuc21pdCBhIHNtYWxsPEJS Pm51bWJlciBvZiBMU1BzIChubyBtb3JlIHRoYW4gMTApIA0KICAgIHdpdGggYSBzaG9ydGVyIHNl cGFyYXRpb24gaW50ZXJ2YWwsPEJSPihvciBldmVuIKGwYmFjayB0byBiYWNrobEpLCBwcm92aWRl ZCANCiAgICB0aGF0IG5vIG1vcmUgdGhhbjxCUj4xMDAwL21pbmltdW1Ccm9hZGNhc3RMU1B0cmFu c21pc3Npb25JbnRlcnZhbCBMU1BzIA0KICAgIGFyZTxCUj50cmFuc21pdHRlZCBpbiBhbnkgb25l IHNlY29uZCBwZXJpb2QuPC9GT05UPjxCUj48Rk9OVCANCiAgICBzaXplPTI+IjwvRk9OVD48QlI+ Jm5ic3A7PEJSPjxGT05UIHNpemU9Mj5XaGF0IGRvZXMgImJhY2sgdG8gYmFjayIgcmVmZXIgdG8g DQogICAgPyBJIGhhdmUgbXkgb3duIHVuZGVyc3RhbmRpbmcgYnV0IGNhbid0PC9GT05UPjxCUj48 Rk9OVCBzaXplPTI+bWFrZSBzdXJlIGl0IA0KICAgIGlzIHJpZ2h0LiA8L0ZPTlQ+PEJSPjwvQkxP Q0tRVU9URT48QlI+IkJhY2sgdG8gYmFjayIgbWVhbnMgd2l0aCBubyBkZWxheSANCiAgYmV0d2Vl biB0aGUgTFNQcy48QlI+PEJSPiZuYnNwOyZuYnNwOyBMZXM8QlI+PEJSPjxCUj4NCiAgPEJMT0NL UVVPVEUgY2l0ZSB0eXBlPSJjaXRlIj48QlI+PEZPTlQgc2l6ZT0yPkFueWJvZHkgY2FuIA0KICAg IGNsYXJpZnk/PC9GT05UPjxCUj4mbmJzcDs8QlI+PEZPTlQgc2l6ZT0yPlRoYW5rczwvRk9OVD48 QlI+PEZPTlQgDQogICAgc2l6ZT0yPlNoZW5nPC9GT05UPjxCUj4mbmJzcDs8QlI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+SXNpcy13ZyANCiAgICBt YWlsaW5nIGxpc3Q8QlI+SXNpcy13Z0BpZXRmLm9yZzxCUj48QSANCiAgICBocmVmPSJodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pc2lzLXdnIiANCiAgICBldWRvcmE9ImF1 dG91cmwiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lzaXMtd2c8L0E+ PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_nUnpN898MQQbq60QHnqdEw)-- --===============1258125483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1258125483==-- From isis-wg-bounces@ietf.org Thu Oct 28 06:48:32 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 GAA29236 for ; Thu, 28 Oct 2004 06:48:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN7np-0000pp-SS; Thu, 28 Oct 2004 06:46:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN7n4-0000fo-2B for isis-wg@megatron.ietf.org; Thu, 28 Oct 2004 06:45:58 -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 GAA29139 for ; Thu, 28 Oct 2004 06:45:55 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN814-00067O-D6 for isis-wg@ietf.org; Thu, 28 Oct 2004 07:00:29 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2004 13:03:04 +0200 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9SAjHSf018608; Thu, 28 Oct 2004 12:45:18 +0200 (MEST) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4356.cisco.com [10.61.81.3]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA07822; Thu, 28 Oct 2004 11:45:16 +0100 (BST) Message-Id: <4.3.2.7.2.20041028113545.0237e840@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Oct 2004 11:40:35 +0100 To: shengcheng From: mike shand Subject: Re: [Isis-wg] "back to back" in ISO 10589 In-Reply-To: <002d01c4bcd5$c8f87ac0$1c336e0a@HUAWEI.COM> References: <4.3.2.7.2.20041027232407.02169e58@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: Les Ginsberg , 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 At 18:06 28/10/2004 +0800, shengcheng wrote: >Les: > Thank you for your timely help. In fact, i forget where to get that=20 > 1998 version. :) > To my knowledge, 2002 version is not free at the begining. I am also= =20 > interested how much has the >2002 version been improved from 1992 version by ISO org. Would you please= =20 >give some direction? It is certainly free now. The 2002 version includes all the defect reports on ISO/IEC 10589 published= =20 by ISO since 1992, some of which are minor editorial corrections, but=20 others are critical for correct operation. Mike > >Thanks. >Sheng > >>----- Original Message ----- >>From: Les Ginsberg >>To: shengcheng >>Cc: isis-wg@ietf.org >>Sent: Thursday, October 28, 2004 2:31 PM >>Subject: Re: [Isis-wg] "back to back" in ISO 10589 >> >>Sheng - >> >>At 01:14 PM 10/28/2004 +0800, shengcheng wrote: >>>Hi, >>>In ISO 10589, 7.3.19(1998 version) >> >>NEVER EVER UNDER ANY CIRCUMSTANCES USE THE 1998 VERSION AS A REFERENCE!!!! >> >>The 1998 version is an unapproved version with numerous inaccuracies,=20 >>some of major significance. Please discard it. >>(Where did you get this anyway?) >> >>Use the 2002 version, freely available at: >> >>http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c030932_ISO_IEC_= 10589_2002(E).zip >> >> >> >>> >>>" >>>NOTE An Intermediate System is permitted to transmit a small >>>number of LSPs (no more than 10) with a shorter separation interval, >>>(or even =A1=B0back to back=A1=B1), provided that no more than >>>1000/minimumBroadcastLSPtransmissionInterval LSPs are >>>transmitted in any one second period. >>>" >>> >>>What does "back to back" refer to ? I have my own understanding but can't >>>make sure it is right. >> >>"Back to back" means with no delay between the LSPs. >> >> Les >> >> >>> >>>Anybody can clarify? >>> >>>Thanks >>>Sheng >>> >>>_______________________________________________ >>>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 Thu Oct 28 12:10: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 MAA07910 for ; Thu, 28 Oct 2004 12:10: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 1CNCBz-0000XB-0F; Thu, 28 Oct 2004 11:27:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUyv-0006lJ-Up for isis-wg@megatron.ietf.org; Tue, 26 Oct 2004 13:19:38 -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 NAA25471 for ; Tue, 26 Oct 2004 13:19:34 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVCO-0008KI-NZ for isis-wg@ietf.org; Tue, 26 Oct 2004 13:33:47 -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 i9QHHVBm082259; Tue, 26 Oct 2004 10:17:31 -0700 (PDT) (envelope-from dkatz@dkatz.org) 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 i9QHHVe25603; Tue, 26 Oct 2004 10:17:31 -0700 (PDT) (envelope-from dkatz@dkatz.org) In-Reply-To: <4.3.2.7.2.20041026122754.023ddc40@dingdong.cisco.com> References: <4.3.2.7.2.20041026122754.023ddc40@dingdong.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [Isis-wg] No MAC Address .. Date: Tue, 26 Oct 2004 11:17:26 -0600 To: Jeff Learman X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Oct 2004 11:27:58 -0400 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 See 8.4.2.5.3 in the 1992 spec (the One True Spec.) Not exactly in the right place, but it's there. On Oct 26, 2004, at 10:34 AM, Jeff Learman wrote: > > By George, I think he's right. While it might be mentioned > somewhere, it should be mentioned in Section 8.4.2.4, "Existing > Adjacencies". > > Jeff > > At 11:38 AM 10/26/2004, Parker, Jeff wrote: >> On 10/26/04 11:22 AM, "Abhishek Verma" >> wrote: >> >>> Hi Jeff, >>> >>>> o He had your MAC address in the past, but no longer does >>> >>> He had the MAC and my adjacency was up. But then I receive a HELLO >>> from him in which he doesnt list my HELLO! >>> >>> And Yes, i am on a LAN. I believe in such cases, i should change my >>> adjacency from the "UP" state to the "Init" state. >>> >>> Dont think its mentioned anywhere in the ISIS docs. >>> >>> Regards, >>> Abhishek >> >> Abhishek - >> A serious charge indeed. >> >> I take it that you are implementing your own version of the >> protocol. >> Does this happen time after time, or rarely? Does his adjacency move >> from >> state init to full? Who is the designated router on the LAN? If it >> is you, >> are you doing the right things? What happens when you alter the >> priority so >> that the remote end is (or isn't) the DIS? >> >> I would take a look at what the two of you are sending, as >> suggested >> before. You might wish to compare your exchange with what two other >> peers >> are doing. >> >> - 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 > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 28 19:28: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 TAA10736 for ; Thu, 28 Oct 2004 19:28: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 1CNGxz-0007e6-W7; Thu, 28 Oct 2004 16:33:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNFZG-0007mD-OQ for isis-wg@megatron.ietf.org; Thu, 28 Oct 2004 15:04:14 -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 PAA17733 for ; Thu, 28 Oct 2004 15:04:13 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNFnN-0004sx-16 for isis-wg@ietf.org; Thu, 28 Oct 2004 15:18:50 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2004 15:03:41 -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 i9SJ3ZWV028627; Thu, 28 Oct 2004 15:03:37 -0400 (EDT) Received: from jlearman-w2k03.cisco.com (dhcp-64-102-83-124.cisco.com [64.102.83.124]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCZ86919; Thu, 28 Oct 2004 12:03:34 -0700 (PDT) Message-Id: <4.3.2.7.2.20041028122130.0241cf00@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Oct 2004 12:22:55 -0400 To: shengcheng , isis-wg@ietf.org From: Jeff Learman Subject: Re: [Isis-wg] "back to back" in ISO 10589 In-Reply-To: <001001c4bcac$f4902260$1c336e0a@HUAWEI.COM> Mime-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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: , Content-Type: multipart/mixed; boundary="===============1456448861==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============1456448861== Content-Type: multipart/alternative; boundary="=====================_14369031==_.ALT" --=====================_14369031==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think I recognize this text from 1992, and no doubt it's in 2002 as well. By "back to back", it simply means transmitted one after the other as fast as possible. Jeff At 01:14 AM 10/28/2004, shengcheng wrote: >Hi, >In ISO 10589, 7.3.19(1998 version) >=20 >" >NOTE An Intermediate System is permitted to transmit a small >number of LSPs (no more than 10) with a shorter separation interval, >(or even =A1=B0back to back=A1=B1), provided that no more than >1000/minimumBroadcastLSPtransmissionInterval LSPs are >transmitted in any one second period. >" >=20 >What does "back to back" refer to ? I have my own understanding but can't >make sure it is right.=20 >=20 >Anybody can clarify? >=20 >Thanks >Sheng >=20 >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg --=====================_14369031==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think I recognize this text from 1992, and no doubt it's in 2002
as well.  By "back to back", it simply means transmitted one after
the other as fast as possible.

Jeff

At 01:14 AM 10/28/2004, shengcheng wrote:
Hi,
In ISO 10589, 7.3.19(1998 version)
 
"
NOTE An Intermediate System is permitted to transmit a small
number of LSPs (no more than 10) with a shorter separation=20 interval,
(or even =A1=B0back to back=A1=B1), provided that no more than
1000/minimumBroadcastLSPtransmissionInterval LSPs are
transmitted in any one second period.
"
 
What does "back to back" refer to ? I have my own understanding but can't
make sure it is right.
 
Anybody can clarify?
 
Thanks
Sheng
 
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg
--=====================_14369031==_.ALT-- --===============1456448861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1456448861==-- From isis-wg-bounces@ietf.org Fri Oct 29 10:17:32 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 KAA03293 for ; Fri, 29 Oct 2004 10:17:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNXEs-0000xb-JN; Fri, 29 Oct 2004 09:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNX3h-0001B1-8B for isis-wg@megatron.ietf.org; Fri, 29 Oct 2004 09:44: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 JAA29475 for ; Fri, 29 Oct 2004 09:44:47 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNXHy-0007Ll-MG for isis-wg@ietf.org; Fri, 29 Oct 2004 09:59:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2004 06:56:02 -0700 X-BrightmailFiltered: true Received: from codc-mira-1.cisco.com (IDENT:mirapoint@codc-mira-1.cisco.com [192.122.173.20]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9TDiBQ0005083 for ; Fri, 29 Oct 2004 06:44:12 -0700 (PDT) Received: from sunramac-w2k.cisco.com ([10.77.139.210]) by codc-mira-1.cisco.com (MOS 3.4.6-GR) with ESMTP id AFV38602; Fri, 29 Oct 2004 19:14:31 +0530 (IST) Message-Id: <4.3.2.7.2.20041027153610.022f5998@codc-mira-1.cisco.com> X-Sender: sunramac@codc-mira-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Oct 2004 19:14:12 +0530 To: isis-wg@ietf.org From: Sundar Ramachandran Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Isis-wg] On draft version 17 of the IS-IS MIB 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 Hello Jeff, Some concerns on the latest yet-to-be-approved draft revision of the MIB: 1. There were some comments earlier in the month from Jonathan Harrison about minor bugs in draft version 16 of the MIB. One of them related to the inconsistent textual definition of "seconds" for objects using the syntax TimeTicks. As he pointed out, TimeTicks represents the time (4294967296) in hundredths of a second since an epoch. I see from the latest draft revision 17 that some of the objects previously using TimeTicks have been modified as follows: e.g., isisSysLevelSetOverloadUntil OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "If isisSysLevelSetOverload is true, the overload bit should be set at startup, and cleared after sysUpTime exceeds this value." ::= { isisSysLevelEntry 6 } But the description indicates that the determination of it's value depends on sysUpTime, which is encoded based on TimeTicks. So do we have an inconsistency here? I mean, do we maintain the SYNTAX as TimeTicks and change the UNITS, or should it remain as you've modified it? Moreover, I find that not all similar definitions have been corrected. For instance, you still have: isisCircLastUpTime OBJECT-TYPE SYNTAX TimeTicks UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "If the circuit is enabled, the value of sysUpTime when isisCircAdminState most recently entered the state on. If the circuit is not on, the value of sysUpTime when the circuit last entered state on, 0 if the circuit has never been on." ::= { isisCircEntry 13 } and isisISAdjLastUpTime OBJECT-TYPE SYNTAX TimeTicks UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "If the isisISAdjState is in state 'up', the value of sysUpTime when the adjacency most recently entered the state 'up', or 0 if it has never been in state 'up'." ::= { isisISAdjEntry 11 } So I believe the inconsistency still remains. Correct me if I'm wrong. 2. The isisOrigLSPBuffSizeMismatch notification is generated for two conditions: a) When the received L1 or L2 LSP is larger than the local value of isisOriginatingBufferSize, b) When there's a mismatch between the value in the PDU of the received LSP (with the isisOriginatingBufferSize field present) and the local isisOriginatingBufferSize value. In the description of this notification, it is mentioned that: " We pass up the size from the option field or the size of the LSP that exceeds our configuration." So is it possible to tell whether the trap was generated as a result of condition "a" or "b" above? ISO/IEC 10589:2002 uses the notificationLSPHeader parameter to report the contents of the LSP header and this is part of the equivalent OSI notification, thus helping to identify the cause of the trap event. I don't think PduLspId, SysLevelIndex and CircIfIndex will be sufficient to determine which condition caused the trap generation. It's useful to indicate which condition resulted in a buff. size mismatch. I'd like to know what you think. 3. I also need clarification on something not very specific to the current MIB revision. This has to do with the SIZE 0 for OSINSAddress: SYNTAX OCTET STRING (SIZE(0..20)) I'd like to know when a string object with zero-length value will be applicable considering that this TC is used to encode isisAreaAddr, isisISAdjNeighSNPAAddress, isisISAdjAreaAddress, isisRASNPAAddress, isisRASNPAMask and isisRASNPAPrefix? My guess is that it applies in situations when no address is configured. For example, when we have no area address configured, or we have no neighbor SNPA addresses? Or is there a different reason? The DEFVAL of ' 'H (the empty string) is provided only for isisRASNPAAddress and isisIPRASNPAAddress, so it's not very clear. I just want to make sure that it's valid to use OSINSAddress as SYNTAX with the prescribed size restriction for all the respective MIB objects. 4. Finally, based on my earlier post with queries on draft 16, I'd like to know if it's useful enough to define or make provisions in the MIB for an initial activity period where traps are suppressed, much along the lines of the RFC1850 OSPF-MIB definition. Hope to hear suggestions and corrections where necessary! Thanks for your time. - Sundar. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Oct 30 18:30:32 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 SAA24035 for ; Sat, 30 Oct 2004 18:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO1cW-0005En-6b; Sat, 30 Oct 2004 18:22:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO1PB-00079Q-QN for isis-wg@megatron.ietf.org; Sat, 30 Oct 2004 18:09: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 SAA22535 for ; Sat, 30 Oct 2004 18:08:58 -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 1CO1db-0002v5-6e for isis-wg@ietf.org; Sat, 30 Oct 2004 18:24:05 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 8ECB73DCC8C for ; Sat, 30 Oct 2004 15:08:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <366F0F28-2AC0-11D9-B18E-000D93C60674@rawdofmt.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ISIS-WG (E-mail) From: Christian Hopps Date: Sat, 30 Oct 2004 18:08:21 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Agenda IETF 61 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 agenda for isis-wg at IETF 61 is open. Can people who wish to present please send me mail. Thanks, Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg