From isis-wg-admin@spider.juniper.net Tue Jan 1 12:34:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13846 for ; Tue, 1 Jan 2002 12:34:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g01HUU199898; Tue, 1 Jan 2002 09:30:30 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id fBVAWc191231 for ; Mon, 31 Dec 2001 02:32:38 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id fBVAY1287100 for ; Mon, 31 Dec 2001 02:34:01 -0800 (PST) X-JNPR-Received-From: outside Received: from web11204.mail.yahoo.com ([216.136.131.186]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 31 Dec 2001 02:28:08 -0800 Message-ID: <20011231102811.98773.qmail@web11204.mail.yahoo.com> Received: from [203.196.145.150] by web11204.mail.yahoo.com via HTTP; Mon, 31 Dec 2001 02:28:11 PST From: Aravind Ravikumar To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-992764757-1009794491=:97979" X-OriginalArrivalTime: 31 Dec 2001 10:28:08.0952 (UTC) FILETIME=[D7586F80:01C191E5] Subject: [Isis-wg] ISIS Adjacency IP Address Table Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 31 Dec 2001 02:28:11 -0800 (PST) --0-992764757-1009794491=:97979 Content-Type: text/plain; charset=us-ascii Hi, Currently, the entry in the Adjacency IP Address Table is indexed as follows: 1. Instance 2. Circuit Index 3. isisIsAdjIpAddrAdjIndex If a neighbor IS advertises more than One IP Interface Address in its HELLO Packets, then we may need some mapping mechanism to know that these IP Addresses were advertised by this specific IS. In order to avoid such mechanisms, can't we have the Adjacency IP Address Table as part of the Adjacency Table. ( This will help in properly identifying each and all the Interfaces advertised by each IS). Therefore is'nt it better to have the following Index: 1. Instance 2. Circuit Index 3. Adjacency Index 4. Adjacency IP Address Index Or can we have the following index: 1. Instance 2. Circuit Index 3. isisIsAdjIpAddrAdjIndex 4. Ip Address Is the above understanding correct ? Please clear my doubt. Thanking in advance. --------------------------------- Do You Yahoo!? Send your FREE holiday greetings online at Yahoo! Greetings. --0-992764757-1009794491=:97979 Content-Type: text/html; charset=us-ascii

Hi,

Currently, the entry in the Adjacency IP Address Table is indexed as follows:

1. Instance    2. Circuit Index         3. isisIsAdjIpAddrAdjIndex

If a neighbor IS advertises more than One IP Interface Address in its HELLO Packets, then we may need some mapping mechanism

to know that these IP Addresses were advertised by this specific IS. 

In order to avoid such mechanisms, can't we have the Adjacency IP Address Table  as part of the Adjacency Table.

( This will help in properly identifying each and all the Interfaces advertised by each IS).

Therefore is'nt it better to have the following Index:

1. Instance     2. Circuit Index      3. Adjacency Index       4. Adjacency IP Address Index  

Or can we have the following index:

1. Instance   2. Circuit Index       3. isisIsAdjIpAddrAdjIndex   4. Ip Address

Is the above understanding correct ?

Please clear my doubt.

Thanking in advance.

 

 


Do You Yahoo!?
Send your FREE holiday greetings online at Yahoo! Greetings. --0-992764757-1009794491=:97979-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 2 04:23:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01289 for ; Wed, 2 Jan 2002 04:23:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g029JP104368; Wed, 2 Jan 2002 01:19:25 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0291D104277 for ; Wed, 2 Jan 2002 01:01:13 -0800 (PST) (envelope-from rameshrr@future.futsoft.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0292m205886 for ; Wed, 2 Jan 2002 01:02:48 -0800 (PST) X-JNPR-Received-From: outside Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Jan 2002 00:56:54 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 02 Jan 2002 14:41:49 +0530 Received: from rameshrr (rameshrr.future.futsoft.com [192.168.5.19]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g028u4o06665; Wed, 2 Jan 2002 14:26:04 +0530 Reply-To: From: "Rayapureddi Ramesh" To: "ISIS (E-mail)" Cc: "ISISWG (E-mail)" Message-Id: <007101c1936d$02d582f0$1305a8c0@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01C1939B.1C8F4590" X-OriginalArrivalTime: 02 Jan 2002 08:56:54.0718 (UTC) FILETIME=[6D461DE0:01C1936B] Subject: [Isis-wg] Echo packet Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 2 Jan 2002 14:38:12 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0072_01C1939B.1C8F4590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have one doubt regarding CLNS echo packet. When we sent multiple echo (CLNP) requests and received multiple echo responses, how to correlate them. Is there any standard/RFC talking about the co-relation. If any body knows, please help me out. Regards, Ramesh ------=_NextPart_000_0072_01C1939B.1C8F4590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have = one doubt=20 regarding CLNS echo packet.
 
When = we sent=20 multiple echo (CLNP) requests and received multiple echo responses, =
how to correlate them. Is there any = standard/RFC=20 talking about the co-relation.
 
If any = body knows,=20 please help me out.
 
 
Regards,
Ramesh
------=_NextPart_000_0072_01C1939B.1C8F4590-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 2 05:54:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02094 for ; Wed, 2 Jan 2002 05:54:29 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g02Aon104807; Wed, 2 Jan 2002 02:50:49 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g029pc104539 for ; Wed, 2 Jan 2002 01:51:38 -0800 (PST) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 24E1D1DCC77; Wed, 2 Jan 2002 01:53:13 -0800 (PST) To: Nagasta Bagamba Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] IGP shortcuts In-reply-to: Mail from Nagasta Bagamba dated Sat, 29 Dec 2001 13:24:54 PST <20011229212454.55644.qmail@web21109.mail.yahoo.com> From: Naiming Shen Message-Id: <20020102095313.24E1D1DCC77@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 02 Jan 2002 01:53:13 -0800 A couple of points need to be emphasized on this "shortcut" draft, it was authors fault not including those in the original draft. I hope this will clear some of the confusions: (a) the igp shortcut is not a neighbor adjacency, it affects only how the routes being installed in the local routing table. (b) the decision to use the mpls tunnel is AFTER the node being put on the PATH list during the spf calculation, assume the node is the mpls tunnel tail-end. (c) the downstream nodes will inherit the mpls tunnel metric properties, so all the routes announced by the downstream nodes will inherit the mpls tunnel metric property, it varies depends on relative or absolute. the downstream nodes can be thought of as all the adjacent neighbors of the tail-end node, except for the nodes already on the PATH list; and their downstreams. (d) if there are multiple mpls tunnels to the same node, only the best(lowest) metric ones are being used, and only the ones better than or equal to the native metric are being used. (e) if a downstream node has multiple upstream paths, then the best metric paths win. this is no different from the "normal" spf. looking at your examples, according to this draft, my answer is just opposite to your picks: topology A, case 1, it will be the second graph, routes advertised by "D" will have metric of 15 plus whatever the cost from D to those networks. topology B, case 2, yes, A will install X with metric of 15 using the tunnel towards B. topology B, case 3, no, A will not install this X with metric of 19. pls read (a) through (e) carefully, and see if you still think they can create routing-loops. If still do, please give examples on how the routing loops will exist. thanks. ]Hi, ] ]I'm sorry, my second question wasn't clear enough. ]I'll try to explain my question through examples. ]There are 3 ways to use TE-tunnels as shortcuts. I'll ]explain each one of them through examples. ]Topology A will be used for introducing case 1. This ]case refers just to the nodes (ISs) in the topology, ]not to the leafs (IPs). ]Topology B will be used for introducing cases 2 and 3. ]Those cases refers especially to the leafs (IPs) of ]the tree. ] ]Topology A: ] ] 10 ] A----B ] 9 | | 10 ] C----D ] 10 ] ] TE-tunnel from A to B, relative -5. ] Source node - A. ] SPT (without TE-tunnels): ] A ] 10 / \ 9 ] B C ] | 10 ] D ] ] ]Case 1: Using TE-tunnels as IGP links ]If we use TE-tunnels after building the SPF tree, we ]will get: ] A ] 5 / \ 9 ] B C ] | 10 ] D ] ]But, if we look at the TE-tunnel as a link with cost 5 ](10-5), and use it through the build of the SPT, we'll ]get: ] ] A ] 5 / \ 9 ] B C ] 10 | ] D ] ] ]Topology B: ] ] A ] 10 / \ 9 ] / \ ] B----C ] 10 ] ] TE-tunnel from A to B, relative -5. ] Source node - A. ] There is network X between B and C. ] SPT (without TE-tunnels): ] A ] 10 / \ 9 ] B C ] | 10 ] X ] ]Case 2: Use TE-tunnels after building the nodes (ISs) ]of the SPF tree, but before adding the leafs (IP ]reachability). ]The result: ] ] A ] 5 / \ 9 ] B C ] 10 | ] X ] ]Case 3: Use TE-tunnels after building the whole SPF ]tree (nodes and leafs). ]The result: ] ] A ] 5 / \ 9 ] B C ] | 10 ] X ] ] ]Case 3 is routing-loop-free. ]Cases 1 and 2 can create routing-loops. To avoid it, ]we must not allow negative links in the graph (it ]seems impossible with the absolute metric type). ] ]My question is - which of the above cases is the one ]the draft refers to? ] ]Nagi ] ]--- Naiming Shen wrote: ]> ]Hi, ]> ] ]> ]I have some wonders about several issues in the ]> draft ]> ]"draft-hsmit-mpls-igp-spf-00.txt". ]> ] ]> ]1. In secrion 6.1: "The relative metric is bounded ]> by ]> ]minimum and maximum allowed metric values" ]> ]Is there any use for maximum value higher than 1? ]> ]As I see it, any positive relative metric causes ]> the ]> ]TE-tunnel not to be used by the IGP, so there is ]> no ]> ]need for more than one positive value. ]> ]> yes, it is not useful for relative metric > +1 if ]> the igp ]> load sharing scheme is equal-cost. ]> ]> but there is no need to restrict it as long as you ]> know it will not ]> be used. if a paricular native path has metric of ]> 10, and you set ]> absolute metric to 15, assume the native path does ]> not change, ]> it's equivalent to setting the relative metric to +5 ]> here. ]> ]> ] ]> ]2. In section 4: "Traffic to nodes that are ]> downstream ]> ]of the tail-end nodes will also flow over those ]> ]TE-tunnels" ]> ]I find the word "downstream" a little bit ]> problematic. ]> ]It can be downstream to the node on the SPF tree ]> OR ]> ]downstream to the node on the IGP topology graph. ]> ]I think it refers to the SPF tree, but is there ]> any ]> ]prevention from using TE-tunnels, as shortcuts, on ]> the ]> ] ]> ]IGP topology graph instead of on the SPF tree? It ]> ]looks like it will give more functionality and ]> meaning ]> ]to the word "shortcuts". Of course we have to be ]> ]careful form routing loops, but with some basic ]> rules ]> ]it is possible... :) ]> ]> i can't parse your sentence here, what is ]> "downstream to SPF" ]> vs "downstream to IGP topology graph"? ]> how can you "form routing loops"? can you give an ]> example ]> which actually causes routing loops? ]> ]> ]> - Naiming ]> _______________________________________________ ]> Isis-wg mailing list - ]> Isis-wg@external.juniper.net ]> http://external.juniper.net/mailman/listinfo/isis-wg ] ] ] ] ] ] ]__________________________________________________ ]Do You Yahoo!? ]Send your FREE holiday greetings online! ]http://greetings.yahoo.com - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 2 10:19:48 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05497 for ; Wed, 2 Jan 2002 10:19:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g02FF0106469; Wed, 2 Jan 2002 07:15:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g02FBw106439 for ; Wed, 2 Jan 2002 07:11:58 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g02FDYG00339 for ; Wed, 2 Jan 2002 07:13:34 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Jan 2002 07:13:29 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g02FDaZ25294; Wed, 2 Jan 2002 10:13:37 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAJ11280; Wed, 2 Jan 2002 10:13:24 -0500 (EST) Message-Id: <4.3.2.7.2.20020102100954.01d26d40@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Jeff Learman Subject: Re: [Isis-wg] Echo packet Cc: "ISIS (E-mail)" , "ISISWG (E-mail)" In-Reply-To: <007101c1936d$02d582f0$1305a8c0@future.futsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_719714==_.ALT" X-OriginalArrivalTime: 02 Jan 2002 15:13:29.0437 (UTC) FILETIME=[08C6A0D0:01C193A0] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 02 Jan 2002 10:13:19 -0500 --=====================_719714==_.ALT Content-Type: text/plain; charset="us-ascii" A CLNP echo request packet may contain user data. The echo reply will normally contain the entire echo request packet, and the user data may be used to correlate the request with the response. Alternatively, depending on your CLNP echo implementation, you could correlate the reply with the request by inspecting the Data Unit ID in the CLNP echo request header copied in the echo reply. Jeff At 04:08 AM 1/2/2002, Rayapureddi Ramesh wrote: >Hi, > >I have one doubt regarding CLNS echo packet. > >When we sent multiple echo (CLNP) requests and received multiple echo responses, >how to correlate them. Is there any standard/RFC talking about the co-relation. > >If any body knows, please help me out. > > >Regards, >Ramesh --=====================_719714==_.ALT Content-Type: text/html; charset="us-ascii"
A CLNP echo request packet may contain user data.  The echo reply will
normally contain the entire echo request packet, and the user data may
be used to correlate the request with the response.

Alternatively, depending on your CLNP echo implementation, you could
correlate the reply with the request by inspecting the Data Unit ID
in the CLNP echo request header copied in the echo reply.

Jeff

At 04:08 AM 1/2/2002, Rayapureddi Ramesh wrote:
Hi,
 
I have one doubt regarding CLNS echo packet.
 
When we sent multiple echo (CLNP) requests and received multiple echo responses,
how to correlate them. Is there any standard/RFC talking about the co-relation.
 
If any body knows, please help me out.
 
 
Regards,
Ramesh
--=====================_719714==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 2 10:47:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05808 for ; Wed, 2 Jan 2002 10:47:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g02FhT106623; Wed, 2 Jan 2002 07:43:29 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g02FWn106557 for ; Wed, 2 Jan 2002 07:32:49 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 10:34:25 -0500 Message-ID: From: "Manral, Vishwas" To: "'Dave Katz'" Cc: ginsberg@pluris.com, isis-wg@spider.juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Isis-wg] Regarding document for best current practices Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 2 Jan 2002 10:34:30 -0500 Dave, Changed the subject line to actually reflect the contents of the discussion. No matter how small the difference, don't you think it would be good to document it somewhere(may be, "not all that sticky" issues, could be documented too)? To think of it, wouldn't it be nice, if we could actually have an informational document(all ISIS work in IETF is informational anyway, I guess) which could talk about ISIS for IP specifically. This could talk about the entire protocol(instead of a delta with the ISO spec as in RFC1195) and could incorporate the best current practices. Would there be any interest in the group for this kind of a document? I personally feel it would be a good idea, and would help in easier understanding and better implementation of ISIS(atleast for those who are not all that well versed). I have no idea of the IETF/ISO laison though.(I tried to check if this thing had been raised before in the mailing list couldn't find it) Thanks, Vishwas --------------------------------------------------------------------- I think the number of things that are done in practical conflict with the spec is vanishingly small, where "practical conflict" is interpreted as "a reasonable implementation would notice." Excessively pedantic boxes have a way of fixing themselves one way or another. Most of these things are pretty obvious to anyone reasonably versed in the art, though the potentially sticky ones (like not bothering with ISHs) should probably be documented. --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 2 15:45:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10482 for ; Wed, 2 Jan 2002 15:45:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g02KeW107927; Wed, 2 Jan 2002 12:40:32 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web21101.mail.yahoo.com (web21101.mail.yahoo.com [216.136.227.103]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g02KOx107854 for ; Wed, 2 Jan 2002 12:24:59 -0800 (PST) (envelope-from nagastabagamba@yahoo.com) Message-ID: <20020102202636.87813.qmail@web21101.mail.yahoo.com> Received: from [212.179.34.114] by web21101.mail.yahoo.com via HTTP; Wed, 02 Jan 2002 12:26:36 PST From: Nagasta Bagamba Subject: Re: [Isis-wg] IGP shortcuts To: Naiming Shen Cc: isis-wg@spider.juniper.net In-Reply-To: <20020102095313.24E1D1DCC77@prattle.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 2 Jan 2002 12:26:36 -0800 (PST) Hi, I understood from your answer that case 2 is the one the draft refers to. I'll give an example, which in my opinion causes routing-loops. The topology: 10 5 30 60 A---B---C---D---E | | +---------------+ 10 Description in words: A through E are connected in a line. E is also connected to A (creating kind of a circle). The metrics: A-B is 10, B-C is 5, C-D is 30, D-E is 60, E-A is 10. There is TE-tunnel from A to C. A is the source node. X is the network between D and E. SPT (without TE-tunnels): A 10 / \ 10 B E 5 | | 60 C X 30 | D You wrote in (c): "the downstream nodes will inherit the mpls tunnel metric properties, so all the routes announced by the downstream nodes will inherit the mpls tunnel metric property, it varies depends on relative or absolute." Section 6.1 in the draft: "When using an absolute metric on a TE-tunnel, the cost of the IP routes in the routing table does not depend on the topology of the network. Note that this fixed metric is not only used to compute the cost of IP routes advertised by the router that is the tail-end of the TE-tunnel, but also for all the routes that are downstream of this tail-end router." The following example is based on the above. Example: TE-tunnel with absolute metric 1. If we'll use the TE-tunnel in the SPF, node C will use the TE-tunnel because it is the tail-end node. Node D will use it as well, because it is downstream to C and though inherits its TE-tunnel metric property. Therefore, the cost to C and D are both 1. So, A will install route to X with metric 1 and the TE-tunnel as its next-hop. Let's take a look at B and C. B and C know nothing about TE-tunnels. They compute normal SPF. B will install route to X with metric 80 (10+10+60) and with next-hop A. C will install route to X with metric 85 (5+10+10+60) and with next-hop B. Now, suppose a packet reach A, and its destination is network X. A will forward the packet to C, through the TE-tunnel. C will forward it to B. B will farward it back to A, and we have a routing-loop... Similar scenario can happen with relative metrics. Regards, Nagi --- Naiming Shen wrote: > > > A couple of points need to be emphasized on this > "shortcut" draft, > it was authors fault not including those in the > original draft. > I hope this will clear some of the confusions: > > (a) the igp shortcut is not a neighbor adjacency, > it affects only > how the routes being installed in the local > routing table. > (b) the decision to use the mpls tunnel is AFTER > the node being put > on the PATH list during the spf calculation, > assume the node is > the mpls tunnel tail-end. > (c) the downstream nodes will inherit the mpls > tunnel metric > properties, so all the routes announced by the > downstream nodes > will inherit the mpls tunnel metric property, > it varies depends > on relative or absolute. the downstream nodes > can be thought of > as all the adjacent neighbors of the tail-end > node, except for > the nodes already on the PATH list; and their > downstreams. > (d) if there are multiple mpls tunnels to the same > node, only the > best(lowest) metric ones are being used, and > only the ones > better than or equal to the native metric are > being used. > (e) if a downstream node has multiple upstream > paths, then the best > metric paths win. this is no different from the > "normal" spf. > > looking at your examples, according to this draft, > my answer is > just opposite to your picks: > > topology A, case 1, it will be the second graph, > routes advertised > by "D" will have metric of 15 plus whatever the cost > from D to those > networks. > > topology B, case 2, yes, A will install X with > metric of 15 using > the tunnel towards B. > > topology B, case 3, no, A will not install this X > with metric of 19. > > > pls read (a) through (e) carefully, and see if you > still think they > can create routing-loops. If still do, please give > examples on > how the routing loops will exist. > > thanks. > > ]Hi, > ] > ]I'm sorry, my second question wasn't clear enough. > ]I'll try to explain my question through examples. > ]There are 3 ways to use TE-tunnels as shortcuts. > I'll > ]explain each one of them through examples. > ]Topology A will be used for introducing case 1. > This > ]case refers just to the nodes (ISs) in the > topology, > ]not to the leafs (IPs). > ]Topology B will be used for introducing cases 2 > and 3. > ]Those cases refers especially to the leafs (IPs) > of > ]the tree. > ] > ]Topology A: > ] > ] 10 > ] A----B > ] 9 | | 10 > ] C----D > ] 10 > ] > ] TE-tunnel from A to B, relative -5. > ] Source node - A. > ] SPT (without TE-tunnels): > ] A > ] 10 / \ 9 > ] B C > ] | 10 > ] D > ] > ] > ]Case 1: Using TE-tunnels as IGP links > ]If we use TE-tunnels after building the SPF tree, > we > ]will get: > ] A > ] 5 / \ 9 > ] B C > ] | 10 > ] D > ] > ]But, if we look at the TE-tunnel as a link with > cost 5 > ](10-5), and use it through the build of the SPT, > we'll > ]get: > ] > ] A > ] 5 / \ 9 > ] B C > ] 10 | > ] D > ] > ] > ]Topology B: > ] > ] A > ] 10 / \ 9 > ] / \ > ] B----C > ] 10 > ] > ] TE-tunnel from A to B, relative -5. > ] Source node - A. > ] There is network X between B and C. > ] SPT (without TE-tunnels): > ] A > ] 10 / \ 9 > ] B C > ] | 10 > ] X > ] > ]Case 2: Use TE-tunnels after building the nodes > (ISs) > ]of the SPF tree, but before adding the leafs (IP > ]reachability). > ]The result: > ] > ] A > ] 5 / \ 9 > ] B C > ] 10 | > ] X > ] > ]Case 3: Use TE-tunnels after building the whole > SPF > ]tree (nodes and leafs). > ]The result: > ] > ] A > ] 5 / \ 9 > ] B C > ] | 10 > ] X > ] > ] > ]Case 3 is routing-loop-free. > ]Cases 1 and 2 can create routing-loops. To avoid > it, > ]we must not allow negative links in the graph (it > ]seems impossible with the absolute metric type). > ] > ]My question is - which of the above cases is the > one > ]the draft refers to? > ] > ]Nagi > ] > ]--- Naiming Shen wrote: > ]> ]Hi, > ]> ] > ]> ]I have some wonders about several issues in > the > ]> draft > ]> ]"draft-hsmit-mpls-igp-spf-00.txt". > ]> ] > ]> ]1. In secrion 6.1: "The relative metric is > bounded > ]> by > ]> ]minimum and maximum allowed metric values" > ]> ]Is there any use for maximum value higher than > 1? > ]> ]As I see it, any positive relative metric > causes > ]> the > ]> ]TE-tunnel not to be used by the IGP, so there > is > ]> no > ]> ]need for more than one positive value. > ]> > === message truncated === __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 3 01:26:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18434 for ; Thu, 3 Jan 2002 01:26:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g036Lt110408; Wed, 2 Jan 2002 22:21:55 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id fBTEQD179671 for ; Sat, 29 Dec 2001 06:26:13 -0800 (PST) (envelope-from sivaa@indiatimes.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id fBTERN267206 for ; Sat, 29 Dec 2001 06:27:24 -0800 (PST) X-JNPR-Received-From: outside Received: from WS0005.indiatimes.com ([203.199.93.15]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 29 Dec 2001 06:23:27 -0800 Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id TAA12657 for "workgroup"; Sat, 29 Dec 2001 19:28:46 +0530 From: "Sivakumar A" Message-Id: <200112291358.TAA12657@WS0005.indiatimes.com> To: "workgroup" Reply-To: "Sivakumar A" X-URL: http://indiatimes.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_MAILER_ATTACH_BOUNDARY_200112296193658659639006" X-OriginalArrivalTime: 29 Dec 2001 14:23:28.0249 (UTC) FILETIME=[6246AE90:01C19074] Subject: [Isis-wg] External IPRA Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 29 Dec 2001 19:36:58 +0530 --=_MAILER_ATTACH_BOUNDARY_200112296193658659639006 Content-Type: text/plain; charset=us-ascii Message from "" forwarded as attachment: Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY_200112296193658659639006 Content-Type: message/rfc822 From: "" Full-Name: "" To: "workgroup" CC: "Jeff Parker" ,"Radia Perlman - Boston Center for Networking" Reply-To: Subject: External IPRA Date: Mon, 24 Dec 2001 11:55:22 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868" MIME-Version: 1.0 --=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868 Content-type: text/plain; charset="us-ascii" Hi, Kindly clarify the following Whether External IPRA needs to be summarized? If yes, then consider the following. External IPRA with Internal Metric matches Summary Address Table Entry S1. We announce S1 with what ever metric that is configured in the Summary Address Table Note: SA table does not have a field indicating the type of metric whether internal or external. External IPRA with External Metric matches Summary Address Table Entry S2. What should be done now, since the metric configured in the summary Address Table does not specify whether it is internal or external can S2 now be announced for the External IPRA. Will this not violate the specification which says, that external metrics are not camparable to internal metrics? Any help on this is greatly appreciated Thanks & Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868 Content-type: text/html; charset="us-ascii"

Hi,

Kindly clarify the following

Whether External IPRA needs to be summarized? If yes, then consider the following.

External IPRA with Internal Metric matches  Summary Address Table Entry S1. We announce S1 with what ever metric that is configured in the Summary Address Table

Note: SA table does not have a field indicating the type of metric whether internal or external.

External IPRA with External Metric matches Summary Address Table Entry S2. What should be done now, since the metric configured in the summary Address Table does not specify whether it is internal or external can S2 now be announced for the External IPRA. Will this not violate the specification which says, that external metrics are not camparable to internal metrics?

Any help on this is greatly appreciated 

Thanks & Regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868-- --=_MAILER_ATTACH_BOUNDARY_200112296193658659639006-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 3 04:52:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28512 for ; Thu, 3 Jan 2002 04:51:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g039mD111382; Thu, 3 Jan 2002 01:48:13 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g02Mfb108444 for ; Wed, 2 Jan 2002 14:41:37 -0800 (PST) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 2A0901DCC6A; Wed, 2 Jan 2002 14:43:15 -0800 (PST) To: Nagasta Bagamba Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] IGP shortcuts In-reply-to: Mail from Nagasta Bagamba dated Wed, 02 Jan 2002 12:26:36 PST <20020102202636.87813.qmail@web21101.mail.yahoo.com> From: Naiming Shen Message-Id: <20020102224315.2A0901DCC6A@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 02 Jan 2002 14:43:15 -0800 ]Hi, ] ]I understood from your answer that case 2 is the one ]the draft refers to. ] ]I'll give an example, which in my opinion causes ]routing-loops. ] ]The topology: ] ] 10 5 30 60 ] A---B---C---D---E ] | | ] +---------------+ ] 10 ] ]Description in words: A through E are connected in a ]line. E is also connected to A (creating kind of a ]circle). The metrics: A-B is 10, B-C is 5, C-D is 30, ]D-E is 60, E-A is 10. There is TE-tunnel from A to C. ]A is the source node. X is the network between D and ]E. ] ]SPT (without TE-tunnels): ] A ]10 / \ 10 ] B E ] 5 | | 60 ] C X ]30 | ] D ] ]You wrote in (c): "the downstream nodes will inherit ]the mpls tunnel metric properties, so all the routes ]announced by the downstream nodes will inherit the ]mpls tunnel metric property, it varies depends on ]relative or absolute." ] ]Section 6.1 in the draft: "When using an absolute ]metric on a TE-tunnel, the cost of the IP routes in ]the routing table does not depend on the topology of ]the network. Note that this fixed metric is not only ]used to compute the cost of IP routes advertised by ]the router that is the tail-end of the TE-tunnel, but ]also for all the routes that are downstream of this ]tail-end router." i think i should add that the routes using the tunnel will inherit the tunnel metric properties. in your case, A first put B and E on path with cost of 10. when C is on the PATH, it finds the C has a tunnel with metric of 1. its like A to C has the metric of 1. D is C's down stream, D will be on the PAH of metric of 31. Since both D and E have the network X with metric of 60, A->E path will set it to 70, and A->C->D will "set" it to 91. So A will not use the tunnel as nexthop, so that the X can't be set to 1. there was lots of discussion on the absolute metric, should it "float" after the tail-end node, or just set all the routes using this tunnel to the fixed value. at that time, we decided to set it fixed. but that does not affect the "normal" spf procedure putting the nodes on the path. thanks. ] ]The following example is based on the above. ] ]Example: TE-tunnel with absolute metric 1. ] ]If we'll use the TE-tunnel in the SPF, node C will use ]the TE-tunnel because it is the tail-end node. Node D ]will use it as well, because it is downstream to C and ]though inherits its TE-tunnel metric property. ]Therefore, the cost to C and D are both 1. So, A will ]install route to X with metric 1 and the TE-tunnel as ]its next-hop. ]Let's take a look at B and C. B and C know nothing ]about TE-tunnels. They compute normal SPF. B will ]install route to X with metric 80 (10+10+60) and with ]next-hop A. C will install route to X with metric 85 ](5+10+10+60) and with next-hop B. ]Now, suppose a packet reach A, and its destination is ]network X. A will forward the packet to C, through the ]TE-tunnel. C will forward it to B. B will farward it ]back to A, and we have a routing-loop... ] ]Similar scenario can happen with relative metrics. ] ]Regards, ]Nagi ] ]--- Naiming Shen wrote: ]> ]> ]> A couple of points need to be emphasized on this ]> "shortcut" draft, ]> it was authors fault not including those in the ]> original draft. ]> I hope this will clear some of the confusions: ]> ]> (a) the igp shortcut is not a neighbor adjacency, ]> it affects only ]> how the routes being installed in the local ]> routing table. ]> (b) the decision to use the mpls tunnel is AFTER ]> the node being put ]> on the PATH list during the spf calculation, ]> assume the node is ]> the mpls tunnel tail-end. ]> (c) the downstream nodes will inherit the mpls ]> tunnel metric ]> properties, so all the routes announced by the ]> downstream nodes ]> will inherit the mpls tunnel metric property, ]> it varies depends ]> on relative or absolute. the downstream nodes ]> can be thought of ]> as all the adjacent neighbors of the tail-end ]> node, except for ]> the nodes already on the PATH list; and their ]> downstreams. ]> (d) if there are multiple mpls tunnels to the same ]> node, only the ]> best(lowest) metric ones are being used, and ]> only the ones ]> better than or equal to the native metric are ]> being used. ]> (e) if a downstream node has multiple upstream ]> paths, then the best ]> metric paths win. this is no different from the ]> "normal" spf. ]> ]> looking at your examples, according to this draft, ]> my answer is ]> just opposite to your picks: ]> ]> topology A, case 1, it will be the second graph, ]> routes advertised ]> by "D" will have metric of 15 plus whatever the cost ]> from D to those ]> networks. ]> ]> topology B, case 2, yes, A will install X with ]> metric of 15 using ]> the tunnel towards B. ]> ]> topology B, case 3, no, A will not install this X ]> with metric of 19. ]> ]> ]> pls read (a) through (e) carefully, and see if you ]> still think they ]> can create routing-loops. If still do, please give ]> examples on ]> how the routing loops will exist. ]> ]> thanks. ]> ]> ]Hi, ]> ] ]> ]I'm sorry, my second question wasn't clear enough. ]> ]I'll try to explain my question through examples. ]> ]There are 3 ways to use TE-tunnels as shortcuts. ]> I'll ]> ]explain each one of them through examples. ]> ]Topology A will be used for introducing case 1. ]> This ]> ]case refers just to the nodes (ISs) in the ]> topology, ]> ]not to the leafs (IPs). ]> ]Topology B will be used for introducing cases 2 ]> and 3. ]> ]Those cases refers especially to the leafs (IPs) ]> of ]> ]the tree. ]> ] ]> ]Topology A: ]> ] ]> ] 10 ]> ] A----B ]> ] 9 | | 10 ]> ] C----D ]> ] 10 ]> ] ]> ] TE-tunnel from A to B, relative -5. ]> ] Source node - A. ]> ] SPT (without TE-tunnels): ]> ] A ]> ] 10 / \ 9 ]> ] B C ]> ] | 10 ]> ] D ]> ] ]> ] ]> ]Case 1: Using TE-tunnels as IGP links ]> ]If we use TE-tunnels after building the SPF tree, ]> we ]> ]will get: ]> ] A ]> ] 5 / \ 9 ]> ] B C ]> ] | 10 ]> ] D ]> ] ]> ]But, if we look at the TE-tunnel as a link with ]> cost 5 ]> ](10-5), and use it through the build of the SPT, ]> we'll ]> ]get: ]> ] ]> ] A ]> ] 5 / \ 9 ]> ] B C ]> ] 10 | ]> ] D ]> ] ]> ] ]> ]Topology B: ]> ] ]> ] A ]> ] 10 / \ 9 ]> ] / \ ]> ] B----C ]> ] 10 ]> ] ]> ] TE-tunnel from A to B, relative -5. ]> ] Source node - A. ]> ] There is network X between B and C. ]> ] SPT (without TE-tunnels): ]> ] A ]> ] 10 / \ 9 ]> ] B C ]> ] | 10 ]> ] X ]> ] ]> ]Case 2: Use TE-tunnels after building the nodes ]> (ISs) ]> ]of the SPF tree, but before adding the leafs (IP ]> ]reachability). ]> ]The result: ]> ] ]> ] A ]> ] 5 / \ 9 ]> ] B C ]> ] 10 | ]> ] X ]> ] ]> ]Case 3: Use TE-tunnels after building the whole ]> SPF ]> ]tree (nodes and leafs). ]> ]The result: ]> ] ]> ] A ]> ] 5 / \ 9 ]> ] B C ]> ] | 10 ]> ] X ]> ] ]> ] ]> ]Case 3 is routing-loop-free. ]> ]Cases 1 and 2 can create routing-loops. To avoid ]> it, ]> ]we must not allow negative links in the graph (it ]> ]seems impossible with the absolute metric type). ]> ] ]> ]My question is - which of the above cases is the ]> one ]> ]the draft refers to? ]> ] ]> ]Nagi ]> ] ]> ]--- Naiming Shen wrote: ]> ]> ]Hi, ]> ]> ] ]> ]> ]I have some wonders about several issues in ]> the ]> ]> draft ]> ]> ]"draft-hsmit-mpls-igp-spf-00.txt". ]> ]> ] ]> ]> ]1. In secrion 6.1: "The relative metric is ]> bounded ]> ]> by ]> ]> ]minimum and maximum allowed metric values" ]> ]> ]Is there any use for maximum value higher than ]> 1? ]> ]> ]As I see it, any positive relative metric ]> causes ]> ]> the ]> ]> ]TE-tunnel not to be used by the IGP, so there ]> is ]> ]> no ]> ]> ]need for more than one positive value. ]> ]> ]> ]=== message truncated === ] ] ] ]__________________________________________________ ]Do You Yahoo!? ]Send your FREE holiday greetings online! ]http://greetings.yahoo.com - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 3 06:32:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29223 for ; Thu, 3 Jan 2002 06:32:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g03BTH112325; Thu, 3 Jan 2002 03:29:17 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g02Mua108510 for ; Wed, 2 Jan 2002 14:56:36 -0800 (PST) (envelope-from jparker@axiowave.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g02MwEG11347 for ; Wed, 2 Jan 2002 14:58:14 -0800 (PST) X-JNPR-Received-From: outside Received: from bridge.axiowave.com ([216.49.69.50]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Jan 2002 14:58:08 -0800 Message-ID: From: Jeff Parker To: "'Aravind Ravikumar'" , isis-wg@juniper.net Subject: RE: [Isis-wg] ISIS Adjacency IP Address Table MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Jan 2002 22:58:08.0734 (UTC) FILETIME=[F221BFE0:01C193E0] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 2 Jan 2002 17:58:08 -0500 Aravind - Good point. I will add a new index, isisISAdjIndex, to identify the adjacency, and change the description of the remaining unique index. The changes are included below. I will send you a current version of the mib by private mail. - jeff parker - axiowave networks - Cogito, ergo spud: I think, therefore I yam. isisISAdjIPAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of IP Addresses of neighboring Intermediate Systems as reported in received IIH PDUs." ::= { isisISAdj 3 } isisISAdjIPAddrEntry OBJECT-TYPE SYNTAX IsisISAdjIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IP Address reported by a neighboring Intermediate System in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjIndex, -- Added isisISAdjIPAddrAdjIndex } ::= { isisISAdjIPAddrTable 1 } IsisISAdjIPAddrEntry ::= SEQUENCE { isisISAdjIPAddrAdjIndex Integer32, isisISAdjIPAddressType InetAddressType, isisISAdjIPAddress InetAddress } isisISAdjIPAddrAdjIndex OBJECT-TYPE SYNTAX Integer32 (1..2000000000) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index to this table which identifies the IP addresss to which this entry belongs." ::= { isisISAdjIPAddrEntry 1 } -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, December 31, 2001 5:28 AM To: isis-wg@juniper.net Subject: [Isis-wg] ISIS Adjacency IP Address Table Hi, Currently, the entry in the Adjacency IP Address Table is indexed as follows: 1. Instance 2. Circuit Index 3. isisIsAdjIpAddrAdjIndex If a neighbor IS advertises more than One IP Interface Address in its HELLO Packets, then we may need some mapping mechanism to know that these IP Addresses were advertised by this specific IS. In order to avoid such mechanisms, can't we have the Adjacency IP Address Table as part of the Adjacency Table. ( This will help in properly identifying each and all the Interfaces advertised by each IS). Therefore is'nt it better to have the following Index: 1. Instance 2. Circuit Index 3. Adjacency Index 4. Adjacency IP Address Index Or can we have the following index: 1. Instance 2. Circuit Index 3. isisIsAdjIpAddrAdjIndex 4. Ip Address Is the above understanding correct ? Please clear my doubt. Thanking in advance. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 3 15:25:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10401 for ; Thu, 3 Jan 2002 15:25:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g03KM1114773; Thu, 3 Jan 2002 12:22:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web14907.mail.yahoo.com (web14907.mail.yahoo.com [216.136.225.59]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g03KDW114727 for ; Thu, 3 Jan 2002 12:13:32 -0800 (PST) (envelope-from donkiha@yahoo.com) Message-ID: <20020103201516.1447.qmail@web14907.mail.yahoo.com> Received: from [12.104.224.46] by web14907.mail.yahoo.com via HTTP; Thu, 03 Jan 2002 12:15:16 PST From: Dong Ha To: isis-wg@spider.juniper.net In-Reply-To: <20020102224315.2A0901DCC6A@prattle.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] bgp mailing list Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 3 Jan 2002 12:15:16 -0800 (PST) Hello everyone, Sorry for this off topic but could anyone tell me some mailing lists for BGP-4? Thanks. Dong __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 4 07:30:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01123 for ; Fri, 4 Jan 2002 07:30:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g04CPh119584; Fri, 4 Jan 2002 04:25:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g04CMR119561 for ; Fri, 4 Jan 2002 04:22:27 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp15.cisco.com [144.254.108.82]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA26997; Fri, 4 Jan 2002 12:23:31 GMT Message-Id: <4.3.2.7.2.20020104120549.0339cea0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Dave Katz From: mike shand Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Cc: VishwasM@netplane.com, ginsberg@pluris.com, isis-wg@spider.juniper.net In-Reply-To: <200112301844.fBUIipb50547@cirrus.juniper.net> References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 04 Jan 2002 12:23:53 +0000 Let me just reinforce what Dave is saying here (as if that were needed :-) The ONLY thing that matters is that the LSP gen interval for any particular LSP is less than the value which the originating router sets in the remaining lifetime field when it is generated. i.e. we need to ensure that the originator will refresh the LSP before its remaining lifetime value has been exhausted. Provided that constraint is met (with a reasonable amount of slop to take care of timing differences etc.) not only can different routers use different values for "MaxAge", but a router could (if it was bloody minded enough) use different values for different LSPs (provided it could remember when to refresh them)! There is ABSOLUTELY no need for any other router to police the value of MaxAge, and as has been pointed out, to do so would be wrong. Just as a historical note here, the original DECnet PhaseV specification (where maxAGE was truely an architectural constant) did require that an LSP with a remaining lifetime greater than Maxage (20 minutes) be treated as being corrupt. This was propagated into 10589 (see 7.3.16.3), where it says that "If the value of Remaining Lifetime is greater than MaxAge the LSP shall be processed as if there were a checksum error." This is reasonable if MaxAge really is fixed. But I think most implementations (and certainly those which allow MaxAge to be varied) quitely ignore this requirement (as indeed they must). If anything needs documenting, it should simply be the deletion of this sentence. Mike At 10:44 30/12/2001 -0800, Dave Katz wrote: >I haven't been paying a lot of attention to this conversation, but that >never stopped me from commenting before. > >One of the nice things about ISIS (as compared to OSPF) is that there >are very few things that are truly architectural constants (as in, if >you don't use this value, the protocol won't work.) Further, there >are less settable parameters that must be coordinated between systems >in order for the network to function. > >The LSP lifetime (along with the adjacency holding time) has the very >nice property that everybody can pick different values and the network >Just Works. This has operationally saved people more times than I can >count. > >Any system that makes judgement on the choice of values of these parameters >set by another system is just plain broken. > >--Dave > > From: "Manral, Vishwas" > Cc: "'isis-wg@spider.juniper.net'" > Content-Type: text/plain; > charset="iso-8859-1" > Sender: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Fri, 28 Dec 2001 00:37:40 -0500 > > Les, > > I get the point you are trying to make. The problem you say would happen > whenever there is a diff in MaxAge in IS's in the domain(and the LSP's for > some reason is not refreshed). > > This is what I am trying to say. The MaxAge would be the value which would > be put in a self LSP, as remaining lifetime when we are originating a new > LSP. If the remaining life time is greater than MaxAge for some other > IS, it > should treat the stuff as if MaxAge(in the sense it should not drop > the LSP, > MIB ops on remaining lifetime shld give age as MaxAge(if any), SPF(age > value) etc), however it should start the purge(MaxAge) timer for that LSP > with the value of "remaining lifetime" field(So remaining lifetime > would be > zero after remaining life time period). However this would cause the > MaxAge > field to be used as in the remaining lifetime and not as configured in the > IS itself.(some problems/loopholes/against existing approach with this > approach??) > > This way all people would purge the LSP at nearly the same time(so the > problem described would not arise). > > Thanks, > Vishwas > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: Friday, December 28, 2001 10:29 AM > To: 'Manral, Vishwas'; Les Ginsberg; 'Jeff Parker' > Cc: IS-IS-WG (E-mail) > Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > Vishwas - > > Makes no difference. From the point of view of the receiver of an LSP, it > has no way of knowing what the value of LSP lifetime may be on the > originating IS since the remaining lifetime field gets modified, based on > elapsed time, prior to flooding. All the receiver can say is that the > originating IS has a value for LSP lifetime which is >= the original > received remaining lifetime. > > If an IS arbitrarily decreases the remaining lifetime of an LSP it has > received, then it is quite possible that the LSP will age out of the local > database before the originating router regenerates that LSP. The protocol > will eventually recover, but in order to do so the LSP will first be > purged, > causing an SPF to be run on all routers (or many of them anyway) with this > LSP absent, and then the originating router will, on seeing the purged > version, regenerate that LSP, flood it, and a second SPF will be run on > every router. Reachability advertised in this LSP will temporarily > disappear > from the forwarding databases throughout the area/domain and then be > restored. This is highly undesirable. > > Les > > > > > > > > Les, > > > > I meant "remaining lifetime" field in the LSP and not age(wrong use of > > terminology on my part). > > > > So this is what I meant:- > > > > 1. If the remaining Lifetime is > MaxAge value in the router, > > treat the > > remaining lifetime as if it was MaxAge. > > 2. MaxLSPGenInt should be less than min value of MaxAge for > > all routers in > > the domain. > > 3. The difference(as pointed out) should be at least enough > > so that the LSP > > is propagated thruout the domain(so that no one purges the > > LSP before the > > new version reaches it). > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Les Ginsberg [mailto:ginsberg@pluris.com] > > Sent: Friday, December 28, 2001 2:31 AM > > To: 'Manral, Vishwas'; 'Jeff Parker' > > Cc: IS-IS-WG (E-mail) > > Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > > > > > > > > Treating any LSP with age above Maxage could be done as if > > > age was MaxAge. > > > May be we need to recommend that all routers in a domain > > have the same > > > Maxage(and the value of MaxLSPGenInt should be less than the > > > value of the > > > smallest value of MaxAge in any router in the domain)value > > > for things to > > > work ok(and then we can treat all LSP's with age greater than > > > MaxAge as > > > MaxAge), we could raise a trap on getting an LSP with age > > greater than > > > MaxAge. > > > > > > > The change from an architectural constant to a configurable value was > > presumably made based on customer demand. To require, or even > > suggest, that > > an implementation treat an LSP received with a lifetime > the > > architectural > > constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do. > > Routers which did this could end up purging an LSP from their database > > before the originating router's MaxLSPGenInt timer fired, > > which would cause > > unnecessary flapping. If you want to argue that the current "de facto > > standard" of making LSP lifetime configurable should be made > > invalid you > > will at least be addressing the issue directly - though I > > suspect you will > > get little support. Circumventing the issue by pretending the > > value is not > > configurable is unwise. > > > > It is also worth noting that, as you suggest, there is a necessary > > relationship between LSP lifetime and MaxLSPGenInt, namely: > > > > 1)MaxLSPGenInt must be less than LSPlifetime > > 2)(LSPlifetime - MaxLSPGenInt) should be large enough to > > allow propagation > > of the LSP throughout the area/domain before the old LSP ages out > > > > If LSP lifetime is modified from the "default" value of 1200 > > seconds, it > > makes sense to change MaxLSPGenInt in a like manner. > > > > Les > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 4 08:22:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01502 for ; Fri, 4 Jan 2002 08:22:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g04DJB119859; Fri, 4 Jan 2002 05:19:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g04CtJ119740 for ; Fri, 4 Jan 2002 04:55:19 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 07:56:42 -0500 Message-ID: From: "Manral, Vishwas" To: "'mike shand'" , Dave Katz Cc: ginsberg@pluris.com, isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 4 Jan 2002 07:57:15 -0500 Mike, Agreed as long as another IS does not impose its MaxAge value on anybody else, we need not have the condition that I had earlier specified i.e. Min(MaxAge) >= Max(MinLSPGEnInterval) + Max(proagation Delay)(this however would cause the MaxAge value used to be the minimum of the MaxAge in the domain), where Min and Max are functions over all routers. So only condition now would be MaxAge >= MaxLSPGenInterval + propagation delay for any router. Apart from the scentence that you rightly suggested needs to be removed, I guess maybe table 2 page 35, which talks about Routing Architechtural Constant and has MaxAge as one of them can have MaxAge removed(it sends a wrong signal). Thanks, Vishwas -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Friday, January 04, 2002 5:54 PM To: Dave Katz Cc: VishwasM@netplane.com; ginsberg@pluris.com; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Let me just reinforce what Dave is saying here (as if that were needed :-) The ONLY thing that matters is that the LSP gen interval for any particular LSP is less than the value which the originating router sets in the remaining lifetime field when it is generated. i.e. we need to ensure that the originator will refresh the LSP before its remaining lifetime value has been exhausted. Provided that constraint is met (with a reasonable amount of slop to take care of timing differences etc.) not only can different routers use different values for "MaxAge", but a router could (if it was bloody minded enough) use different values for different LSPs (provided it could remember when to refresh them)! There is ABSOLUTELY no need for any other router to police the value of MaxAge, and as has been pointed out, to do so would be wrong. Just as a historical note here, the original DECnet PhaseV specification (where maxAGE was truely an architectural constant) did require that an LSP with a remaining lifetime greater than Maxage (20 minutes) be treated as being corrupt. This was propagated into 10589 (see 7.3.16.3), where it says that "If the value of Remaining Lifetime is greater than MaxAge the LSP shall be processed as if there were a checksum error." This is reasonable if MaxAge really is fixed. But I think most implementations (and certainly those which allow MaxAge to be varied) quitely ignore this requirement (as indeed they must). If anything needs documenting, it should simply be the deletion of this sentence. Mike At 10:44 30/12/2001 -0800, Dave Katz wrote: >I haven't been paying a lot of attention to this conversation, but that >never stopped me from commenting before. > >One of the nice things about ISIS (as compared to OSPF) is that there >are very few things that are truly architectural constants (as in, if >you don't use this value, the protocol won't work.) Further, there >are less settable parameters that must be coordinated between systems >in order for the network to function. > >The LSP lifetime (along with the adjacency holding time) has the very >nice property that everybody can pick different values and the network >Just Works. This has operationally saved people more times than I can >count. > >Any system that makes judgement on the choice of values of these parameters >set by another system is just plain broken. > >--Dave > > From: "Manral, Vishwas" > Cc: "'isis-wg@spider.juniper.net'" > Content-Type: text/plain; > charset="iso-8859-1" > Sender: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Fri, 28 Dec 2001 00:37:40 -0500 > > Les, > > I get the point you are trying to make. The problem you say would happen > whenever there is a diff in MaxAge in IS's in the domain(and the LSP's for > some reason is not refreshed). > > This is what I am trying to say. The MaxAge would be the value which would > be put in a self LSP, as remaining lifetime when we are originating a new > LSP. If the remaining life time is greater than MaxAge for some other > IS, it > should treat the stuff as if MaxAge(in the sense it should not drop > the LSP, > MIB ops on remaining lifetime shld give age as MaxAge(if any), SPF(age > value) etc), however it should start the purge(MaxAge) timer for that LSP > with the value of "remaining lifetime" field(So remaining lifetime > would be > zero after remaining life time period). However this would cause the > MaxAge > field to be used as in the remaining lifetime and not as configured in the > IS itself.(some problems/loopholes/against existing approach with this > approach??) > > This way all people would purge the LSP at nearly the same time(so the > problem described would not arise). > > Thanks, > Vishwas > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: Friday, December 28, 2001 10:29 AM > To: 'Manral, Vishwas'; Les Ginsberg; 'Jeff Parker' > Cc: IS-IS-WG (E-mail) > Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > Vishwas - > > Makes no difference. From the point of view of the receiver of an LSP, it > has no way of knowing what the value of LSP lifetime may be on the > originating IS since the remaining lifetime field gets modified, based on > elapsed time, prior to flooding. All the receiver can say is that the > originating IS has a value for LSP lifetime which is >= the original > received remaining lifetime. > > If an IS arbitrarily decreases the remaining lifetime of an LSP it has > received, then it is quite possible that the LSP will age out of the local > database before the originating router regenerates that LSP. The protocol > will eventually recover, but in order to do so the LSP will first be > purged, > causing an SPF to be run on all routers (or many of them anyway) with this > LSP absent, and then the originating router will, on seeing the purged > version, regenerate that LSP, flood it, and a second SPF will be run on > every router. Reachability advertised in this LSP will temporarily > disappear > from the forwarding databases throughout the area/domain and then be > restored. This is highly undesirable. > > Les > > > > > > > > Les, > > > > I meant "remaining lifetime" field in the LSP and not age(wrong use of > > terminology on my part). > > > > So this is what I meant:- > > > > 1. If the remaining Lifetime is > MaxAge value in the router, > > treat the > > remaining lifetime as if it was MaxAge. > > 2. MaxLSPGenInt should be less than min value of MaxAge for > > all routers in > > the domain. > > 3. The difference(as pointed out) should be at least enough > > so that the LSP > > is propagated thruout the domain(so that no one purges the > > LSP before the > > new version reaches it). > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Les Ginsberg [mailto:ginsberg@pluris.com] > > Sent: Friday, December 28, 2001 2:31 AM > > To: 'Manral, Vishwas'; 'Jeff Parker' > > Cc: IS-IS-WG (E-mail) > > Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > > > > > > > > Treating any LSP with age above Maxage could be done as if > > > age was MaxAge. > > > May be we need to recommend that all routers in a domain > > have the same > > > Maxage(and the value of MaxLSPGenInt should be less than the > > > value of the > > > smallest value of MaxAge in any router in the domain)value > > > for things to > > > work ok(and then we can treat all LSP's with age greater than > > > MaxAge as > > > MaxAge), we could raise a trap on getting an LSP with age > > greater than > > > MaxAge. > > > > > > > The change from an architectural constant to a configurable value was > > presumably made based on customer demand. To require, or even > > suggest, that > > an implementation treat an LSP received with a lifetime > the > > architectural > > constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do. > > Routers which did this could end up purging an LSP from their database > > before the originating router's MaxLSPGenInt timer fired, > > which would cause > > unnecessary flapping. If you want to argue that the current "de facto > > standard" of making LSP lifetime configurable should be made > > invalid you > > will at least be addressing the issue directly - though I > > suspect you will > > get little support. Circumventing the issue by pretending the > > value is not > > configurable is unwise. > > > > It is also worth noting that, as you suggest, there is a necessary > > relationship between LSP lifetime and MaxLSPGenInt, namely: > > > > 1)MaxLSPGenInt must be less than LSPlifetime > > 2)(LSPlifetime - MaxLSPGenInt) should be large enough to > > allow propagation > > of the LSP throughout the area/domain before the old LSP ages out > > > > If LSP lifetime is modified from the "default" value of 1200 > > seconds, it > > makes sense to change MaxLSPGenInt in a like manner. > > > > Les _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 4 12:54:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09620 for ; Fri, 4 Jan 2002 12:54:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g04Ho1121001; Fri, 4 Jan 2002 09:50:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g04HnD120986 for ; Fri, 4 Jan 2002 09:49:13 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g04HoQ642640; Fri, 4 Jan 2002 09:50:26 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g04Hndm64880; Fri, 4 Jan 2002 09:49:39 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201041749.g04Hndm64880@cirrus.juniper.net> From: Dave Katz To: mshand@cisco.com CC: VishwasM@netplane.com, ginsberg@pluris.com, isis-wg@spider.juniper.net In-reply-to: <4.3.2.7.2.20020104120549.0339cea0@jaws.cisco.com> (message from mike shand on Fri, 04 Jan 2002 12:23:53 +0000) Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt References: < <4.3.2.7.2.20020104120549.0339cea0@jaws.cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 4 Jan 2002 09:49:39 -0800 (PST) Cool, another sentence in the spec that I missed. ;-) X-JNPR-Received-From: outside X-Sender: mshand@jaws.cisco.com Date: Fri, 04 Jan 2002 12:23:53 +0000 From: mike shand Cc: VishwasM@netplane.com, ginsberg@pluris.com, isis-wg@spider.juniper.net Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Jan 2002 12:23:27.0640 (UTC) FILETIME=[9CDB7180:01C1951A] Let me just reinforce what Dave is saying here (as if that were needed :-) The ONLY thing that matters is that the LSP gen interval for any particular LSP is less than the value which the originating router sets in the remaining lifetime field when it is generated. i.e. we need to ensure that the originator will refresh the LSP before its remaining lifetime value has been exhausted. Provided that constraint is met (with a reasonable amount of slop to take care of timing differences etc.) not only can different routers use different values for "MaxAge", but a router could (if it was bloody minded enough) use different values for different LSPs (provided it could remember when to refresh them)! There is ABSOLUTELY no need for any other router to police the value of MaxAge, and as has been pointed out, to do so would be wrong. Just as a historical note here, the original DECnet PhaseV specification (where maxAGE was truely an architectural constant) did require that an LSP with a remaining lifetime greater than Maxage (20 minutes) be treated as being corrupt. This was propagated into 10589 (see 7.3.16.3), where it says that "If the value of Remaining Lifetime is greater than MaxAge the LSP shall be processed as if there were a checksum error." This is reasonable if MaxAge really is fixed. But I think most implementations (and certainly those which allow MaxAge to be varied) quitely ignore this requirement (as indeed they must). If anything needs documenting, it should simply be the deletion of this sentence. Mike At 10:44 30/12/2001 -0800, Dave Katz wrote: >I haven't been paying a lot of attention to this conversation, but that >never stopped me from commenting before. > >One of the nice things about ISIS (as compared to OSPF) is that there >are very few things that are truly architectural constants (as in, if >you don't use this value, the protocol won't work.) Further, there >are less settable parameters that must be coordinated between systems >in order for the network to function. > >The LSP lifetime (along with the adjacency holding time) has the very >nice property that everybody can pick different values and the network >Just Works. This has operationally saved people more times than I can >count. > >Any system that makes judgement on the choice of values of these parameters >set by another system is just plain broken. > >--Dave > > From: "Manral, Vishwas" > Cc: "'isis-wg@spider.juniper.net'" > Content-Type: text/plain; > charset="iso-8859-1" > Sender: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Fri, 28 Dec 2001 00:37:40 -0500 > > Les, > > I get the point you are trying to make. The problem you say would happen > whenever there is a diff in MaxAge in IS's in the domain(and the LSP's for > some reason is not refreshed). > > This is what I am trying to say. The MaxAge would be the value which would > be put in a self LSP, as remaining lifetime when we are originating a new > LSP. If the remaining life time is greater than MaxAge for some other > IS, it > should treat the stuff as if MaxAge(in the sense it should not drop > the LSP, > MIB ops on remaining lifetime shld give age as MaxAge(if any), SPF(age > value) etc), however it should start the purge(MaxAge) timer for that LSP > with the value of "remaining lifetime" field(So remaining lifetime > would be > zero after remaining life time period). However this would cause the > MaxAge > field to be used as in the remaining lifetime and not as configured in the > IS itself.(some problems/loopholes/against existing approach with this > approach??) > > This way all people would purge the LSP at nearly the same time(so the > problem described would not arise). > > Thanks, > Vishwas > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: Friday, December 28, 2001 10:29 AM > To: 'Manral, Vishwas'; Les Ginsberg; 'Jeff Parker' > Cc: IS-IS-WG (E-mail) > Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > Vishwas - > > Makes no difference. From the point of view of the receiver of an LSP, it > has no way of knowing what the value of LSP lifetime may be on the > originating IS since the remaining lifetime field gets modified, based on > elapsed time, prior to flooding. All the receiver can say is that the > originating IS has a value for LSP lifetime which is >= the original > received remaining lifetime. > > If an IS arbitrarily decreases the remaining lifetime of an LSP it has > received, then it is quite possible that the LSP will age out of the local > database before the originating router regenerates that LSP. The protocol > will eventually recover, but in order to do so the LSP will first be > purged, > causing an SPF to be run on all routers (or many of them anyway) with this > LSP absent, and then the originating router will, on seeing the purged > version, regenerate that LSP, flood it, and a second SPF will be run on > every router. Reachability advertised in this LSP will temporarily > disappear > from the forwarding databases throughout the area/domain and then be > restored. This is highly undesirable. > > Les > > > > > > > > Les, > > > > I meant "remaining lifetime" field in the LSP and not age(wrong use of > > terminology on my part). > > > > So this is what I meant:- > > > > 1. If the remaining Lifetime is > MaxAge value in the router, > > treat the > > remaining lifetime as if it was MaxAge. > > 2. MaxLSPGenInt should be less than min value of MaxAge for > > all routers in > > the domain. > > 3. The difference(as pointed out) should be at least enough > > so that the LSP > > is propagated thruout the domain(so that no one purges the > > LSP before the > > new version reaches it). > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Les Ginsberg [mailto:ginsberg@pluris.com] > > Sent: Friday, December 28, 2001 2:31 AM > > To: 'Manral, Vishwas'; 'Jeff Parker' > > Cc: IS-IS-WG (E-mail) > > Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > > > > > > > > Treating any LSP with age above Maxage could be done as if > > > age was MaxAge. > > > May be we need to recommend that all routers in a domain > > have the same > > > Maxage(and the value of MaxLSPGenInt should be less than the > > > value of the > > > smallest value of MaxAge in any router in the domain)value > > > for things to > > > work ok(and then we can treat all LSP's with age greater than > > > MaxAge as > > > MaxAge), we could raise a trap on getting an LSP with age > > greater than > > > MaxAge. > > > > > > > The change from an architectural constant to a configurable value was > > presumably made based on customer demand. To require, or even > > suggest, that > > an implementation treat an LSP received with a lifetime > the > > architectural > > constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do. > > Routers which did this could end up purging an LSP from their database > > before the originating router's MaxLSPGenInt timer fired, > > which would cause > > unnecessary flapping. If you want to argue that the current "de facto > > standard" of making LSP lifetime configurable should be made > > invalid you > > will at least be addressing the issue directly - though I > > suspect you will > > get little support. Circumventing the issue by pretending the > > value is not > > configurable is unwise. > > > > It is also worth noting that, as you suggest, there is a necessary > > relationship between LSP lifetime and MaxLSPGenInt, namely: > > > > 1)MaxLSPGenInt must be less than LSPlifetime > > 2)(LSPlifetime - MaxLSPGenInt) should be large enough to > > allow propagation > > of the LSP throughout the area/domain before the old LSP ages out > > > > If LSP lifetime is modified from the "default" value of 1200 > > seconds, it > > makes sense to change MaxLSPGenInt in a like manner. > > > > Les > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 7 09:58:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16250 for ; Mon, 7 Jan 2002 09:58:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g07Er0140950; Mon, 7 Jan 2002 06:53:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g07Eq3140938 for ; Mon, 7 Jan 2002 06:52:03 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Manral, Vishwas'" Cc: "IS-IS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 7 Jan 2002 09:53:11 -0500 > Jeff, > > The object > isisCircSmallHellos OBJECT-TYPE > SYNTAX AdminState > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Can we send unpadded hellos on LAN circuits? Off means > LAN Hellos must be padded." > DEFVAL { off } > ::= { isisCircEntry 26 } > > says the DEFVAL should be such that we must send LAN Hellos > padded. However > from the discussion > http://people.juniper.net/pipermail/isis-wg/2000/000300.html > http://people.juniper.net/pipermail/isis-wg/2000/000305.html > it seems padding isn't of much help. Wouldn't it be better to > change the > DEFVAL to not off(on)? > ... > Vishwas Vishwas - The standard requires padded hellos. The introduction of this variable is an admission that some people like to run without padded hellos, but I don't see any reason to make unpadded (small hellos) the default behavior. Strong feelings from the list? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 00:00:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07151 for ; Tue, 8 Jan 2002 00:00:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g084u4144509; Mon, 7 Jan 2002 20:56:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g084lt144465 for ; Mon, 7 Jan 2002 20:47:55 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 23:50:05 -0500 Message-ID: From: "Manral, Vishwas" To: "'Jeff Parker'" Cc: "IS-IS-WG (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 7 Jan 2002 23:27:39 -0500 Jeff, My idea was that if the padded hellos aren't really of much use, and as Dave put it "essentially useless and creates lots of unnecessary customer service" wouldn't it be wise not to make it the default value. We aren't strictly following the specs anyway. -Vishwas -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Monday, January 07, 2002 8:23 PM To: 'Manral, Vishwas' Cc: IS-IS-WG (E-mail) Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt > Jeff, > > The object > isisCircSmallHellos OBJECT-TYPE > SYNTAX AdminState > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Can we send unpadded hellos on LAN circuits? Off means > LAN Hellos must be padded." > DEFVAL { off } > ::= { isisCircEntry 26 } > > says the DEFVAL should be such that we must send LAN Hellos > padded. However > from the discussion > http://people.juniper.net/pipermail/isis-wg/2000/000300.html > http://people.juniper.net/pipermail/isis-wg/2000/000305.html > it seems padding isn't of much help. Wouldn't it be better to > change the > DEFVAL to not off(on)? > ... > Vishwas Vishwas - The standard requires padded hellos. The introduction of this variable is an admission that some people like to run without padded hellos, but I don't see any reason to make unpadded (small hellos) the default behavior. Strong feelings from the list? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 00:15:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07296 for ; Tue, 8 Jan 2002 00:15:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g085C7144597; Mon, 7 Jan 2002 21:12:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0850t144534 for ; Mon, 7 Jan 2002 21:00:55 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0852X651483; Mon, 7 Jan 2002 21:02:33 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0851cW77660; Mon, 7 Jan 2002 21:01:38 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201080501.g0851cW77660@cirrus.juniper.net> From: Dave Katz To: VishwasM@netplane.com CC: jparker@axiowave.com, isis-wg@spider.juniper.net In-reply-to: (VishwasM@netplane.com) Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 7 Jan 2002 21:01:38 -0800 (PST) To put on my rude pragmatist's hat again, it doesn't really matter a whole lot in practice what the MIB says the default is, since the default is whatever the implementation already does (and defaults in general are notoriously difficult to change in practice.) Jeff, My idea was that if the padded hellos aren't really of much use, and as Dave put it "essentially useless and creates lots of unnecessary customer service" wouldn't it be wise not to make it the default value. We aren't strictly following the specs anyway. -Vishwas -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Monday, January 07, 2002 8:23 PM To: 'Manral, Vishwas' Cc: IS-IS-WG (E-mail) Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt > Jeff, > > The object > isisCircSmallHellos OBJECT-TYPE > SYNTAX AdminState > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Can we send unpadded hellos on LAN circuits? Off means > LAN Hellos must be padded." > DEFVAL { off } > ::= { isisCircEntry 26 } > > says the DEFVAL should be such that we must send LAN Hellos > padded. However > from the discussion > http://people.juniper.net/pipermail/isis-wg/2000/000300.html > http://people.juniper.net/pipermail/isis-wg/2000/000305.html > it seems padding isn't of much help. Wouldn't it be better to > change the > DEFVAL to not off(on)? > ... > Vishwas Vishwas - The standard requires padded hellos. The introduction of this variable is an admission that some people like to run without padded hellos, but I don't see any reason to make unpadded (small hellos) the default behavior. Strong feelings from the list? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 00:47:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08079 for ; Tue, 8 Jan 2002 00:47:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g085hB144755; Mon, 7 Jan 2002 21:43:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g085KM144647 for ; Mon, 7 Jan 2002 21:20:22 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 00:22:33 -0500 Message-ID: From: "Manral, Vishwas" To: "'Dave Katz'" Cc: jparker@axiowave.com, isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 8 Jan 2002 00:22:40 -0500 Dave, Right, but wouldn't it help new implementations if the default was the value desired from implementations? I although agree that not all implementations would follow the default as given in the MIB, and its a not a big issue what the default in this case should be. Thanks, Vishwas -----Original Message----- From: Dave Katz [mailto:dkatz@juniper.net] Sent: Tuesday, January 08, 2002 10:32 AM To: VishwasM@netplane.com Cc: jparker@axiowave.com; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt To put on my rude pragmatist's hat again, it doesn't really matter a whole lot in practice what the MIB says the default is, since the default is whatever the implementation already does (and defaults in general are notoriously difficult to change in practice.) Jeff, My idea was that if the padded hellos aren't really of much use, and as Dave put it "essentially useless and creates lots of unnecessary customer service" wouldn't it be wise not to make it the default value. We aren't strictly following the specs anyway. -Vishwas -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Monday, January 07, 2002 8:23 PM To: 'Manral, Vishwas' Cc: IS-IS-WG (E-mail) Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt > Jeff, > > The object > isisCircSmallHellos OBJECT-TYPE > SYNTAX AdminState > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Can we send unpadded hellos on LAN circuits? Off means > LAN Hellos must be padded." > DEFVAL { off } > ::= { isisCircEntry 26 } > > says the DEFVAL should be such that we must send LAN Hellos > padded. However > from the discussion > http://people.juniper.net/pipermail/isis-wg/2000/000300.html > http://people.juniper.net/pipermail/isis-wg/2000/000305.html > it seems padding isn't of much help. Wouldn't it be better to > change the > DEFVAL to not off(on)? > ... > Vishwas Vishwas - The standard requires padded hellos. The introduction of this variable is an admission that some people like to run without padded hellos, but I don't see any reason to make unpadded (small hellos) the default behavior. Strong feelings from the list? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 01:56:34 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08632 for ; Tue, 8 Jan 2002 01:56:34 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g086qB145067; Mon, 7 Jan 2002 22:52:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g086Ol144943 for ; Mon, 7 Jan 2002 22:24:47 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g086QR653047; Mon, 7 Jan 2002 22:26:27 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g086PWL77994; Mon, 7 Jan 2002 22:25:32 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201080625.g086PWL77994@cirrus.juniper.net> From: Dave Katz To: VishwasM@netplane.com CC: jparker@axiowave.com, isis-wg@spider.juniper.net In-reply-to: (VishwasM@netplane.com) Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 7 Jan 2002 22:25:32 -0800 (PST) Ruder pragmatist--I won't be writing another one. ;-) I guess it makes sense to try to mirror best practice (whatever that may be) for these things. When all else fails, default to the spec or flip a coin. --Dave X-JNPR-Received-From: outside From: "Manral, Vishwas" Cc: jparker@axiowave.com, isis-wg@spider.juniper.net Date: Tue, 8 Jan 2002 00:22:40 -0500 Content-Type: text/plain X-OriginalArrivalTime: 08 Jan 2002 05:22:23.0671 (UTC) FILETIME=[7402B470:01C19804] Dave, Right, but wouldn't it help new implementations if the default was the value desired from implementations? I although agree that not all implementations would follow the default as given in the MIB, and its a not a big issue what the default in this case should be. Thanks, Vishwas -----Original Message----- From: Dave Katz [mailto:dkatz@juniper.net] Sent: Tuesday, January 08, 2002 10:32 AM To: VishwasM@netplane.com Cc: jparker@axiowave.com; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt To put on my rude pragmatist's hat again, it doesn't really matter a whole lot in practice what the MIB says the default is, since the default is whatever the implementation already does (and defaults in general are notoriously difficult to change in practice.) Jeff, My idea was that if the padded hellos aren't really of much use, and as Dave put it "essentially useless and creates lots of unnecessary customer service" wouldn't it be wise not to make it the default value. We aren't strictly following the specs anyway. -Vishwas -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Monday, January 07, 2002 8:23 PM To: 'Manral, Vishwas' Cc: IS-IS-WG (E-mail) Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt > Jeff, > > The object > isisCircSmallHellos OBJECT-TYPE > SYNTAX AdminState > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Can we send unpadded hellos on LAN circuits? Off means > LAN Hellos must be padded." > DEFVAL { off } > ::= { isisCircEntry 26 } > > says the DEFVAL should be such that we must send LAN Hellos > padded. However > from the discussion > http://people.juniper.net/pipermail/isis-wg/2000/000300.html > http://people.juniper.net/pipermail/isis-wg/2000/000305.html > it seems padding isn't of much help. Wouldn't it be better to > change the > DEFVAL to not off(on)? > ... > Vishwas Vishwas - The standard requires padded hellos. The introduction of this variable is an admission that some people like to run without padded hellos, but I don't see any reason to make unpadded (small hellos) the default behavior. Strong feelings from the list? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 03:24:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17560 for ; Tue, 8 Jan 2002 03:24:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g088J6145471; Tue, 8 Jan 2002 00:19:06 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g087aR145273 for ; Mon, 7 Jan 2002 23:36:27 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id XAA04779; Mon, 7 Jan 2002 23:37:34 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 23:37:34 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F6E4@avalon.pluris.com> From: Les Ginsberg To: "'Dave Katz'" , VishwasM@netplane.com Cc: jparker@axiowave.com, isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 7 Jan 2002 23:37:33 -0800 (Sigh...somewhat against my better judgement...) There are some folks who think the benefits of padding outweigh the drawbacks - others feel the scale is tipped in the other direction. Whatever your individual opinion on the matter, the fact is that the spec calls for padding. If there is a strong consensus that the spec needs to be changed, then a change to the spec should be formally written, whether as a modification to the ISO spec or an IETF draft. (NO!! I am NOT proposing or advocating this!!) In the meantime, trying to use the MIB to override the spec is inappropriate. Jeff had the right idea(scroll to the bottom and see) - I'm on his side. Les > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Monday, January 07, 2002 10:26 PM > To: VishwasM@netplane.com > Cc: jparker@axiowave.com; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > Ruder pragmatist--I won't be writing another one. ;-) > > I guess it makes sense to try to mirror best practice > (whatever that may > be) for these things. When all else fails, default to the > spec or flip > a coin. > > --Dave > > X-JNPR-Received-From: outside > From: "Manral, Vishwas" > Cc: jparker@axiowave.com, isis-wg@spider.juniper.net > Date: Tue, 8 Jan 2002 00:22:40 -0500 > Content-Type: text/plain > X-OriginalArrivalTime: 08 Jan 2002 05:22:23.0671 (UTC) > FILETIME=[7402B470:01C19804] > > Dave, > > Right, but wouldn't it help new implementations if the > default was the value > desired from implementations? I although agree that not > all implementations > would follow the default as given in the MIB, and its a > not a big issue what > the default in this case should be. > > Thanks, > Vishwas > > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Tuesday, January 08, 2002 10:32 AM > To: VishwasM@netplane.com > Cc: jparker@axiowave.com; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > To put on my rude pragmatist's hat again, it doesn't > really matter a > whole lot in practice what the MIB says the default is, since the > default is whatever the implementation already does (and defaults > in general are notoriously difficult to change in practice.) > > Jeff, > > My idea was that if the padded hellos aren't really of > much use, and as > Dave > put it "essentially useless and creates lots of > unnecessary customer > service" wouldn't it be wise not to make it the default > value. We aren't > strictly following the specs anyway. > > -Vishwas > > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Monday, January 07, 2002 8:23 PM > To: 'Manral, Vishwas' > Cc: IS-IS-WG (E-mail) > Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > > Jeff, > > > > The object > > isisCircSmallHellos OBJECT-TYPE > > SYNTAX AdminState > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Can we send unpadded hellos on LAN > circuits? Off means > > LAN Hellos must be padded." > > DEFVAL { off } > > ::= { isisCircEntry 26 } > > > > says the DEFVAL should be such that we must send LAN Hellos > > padded. However > > from the discussion > > http://people.juniper.net/pipermail/isis-wg/2000/000300.html > > http://people.juniper.net/pipermail/isis-wg/2000/000305.html > > it seems padding isn't of much help. Wouldn't it be better to > > change the > > DEFVAL to not off(on)? > > ... > > Vishwas > > Vishwas - > The standard requires padded hellos. The introduction > of this variable is an admission that some people like to > run without padded hellos, but I don't see any reason to make > unpadded (small hellos) the default behavior. > > Strong feelings from the list? > > - jeff parker > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 04:07:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17842 for ; Tue, 8 Jan 2002 04:07:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08910145683; Tue, 8 Jan 2002 01:01:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0890r145668 for ; Tue, 8 Jan 2002 01:00:53 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 04:03:05 -0500 Message-ID: From: "Manral, Vishwas" To: "'Les Ginsberg'" , "'Dave Katz'" Cc: jparker@axiowave.com, isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 8 Jan 2002 04:02:57 -0500 Les, But thats already happenning(MIB overriding the spec I mean). ISIS Hello multiplier(one example I came across) is a "routing architectural constant" according to the spec. The object isisCircLevelHelloMultiplier OBJECT-TYPE SYNTAX Integer32 (2..100) MAX-ACCESS read-create STATUS current DESCRIPTION "This value is multiplied by the corresponding HelloTimer and the result in seconds (rounded up) is used as the holding time in transmitted hellos, to be used by receivers of hello packets from this IS" REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" DEFVAL { 10 } ::= { isisCircLevelEntry 7 } tells its configureable. And with the way the MaxAge is used, we may require MaxAge to be configureable too, that would again be a violation of the spec. I guess this is a bigger issue than changing the value of DEFVAL. What are ur views on a draft on ISIS for IP(I sent a mail regarding this earlier, but no responses)? Thanks, Vishwas -----Original Message----- From: Les Ginsberg [mailto:ginsberg@pluris.com] Sent: Tuesday, January 08, 2002 1:08 PM To: 'Dave Katz'; VishwasM@netplane.com Cc: jparker@axiowave.com; isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt (Sigh...somewhat against my better judgement...) There are some folks who think the benefits of padding outweigh the drawbacks - others feel the scale is tipped in the other direction. Whatever your individual opinion on the matter, the fact is that the spec calls for padding. If there is a strong consensus that the spec needs to be changed, then a change to the spec should be formally written, whether as a modification to the ISO spec or an IETF draft. (NO!! I am NOT proposing or advocating this!!) In the meantime, trying to use the MIB to override the spec is inappropriate. Jeff had the right idea(scroll to the bottom and see) - I'm on his side. Les > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Monday, January 07, 2002 10:26 PM > To: VishwasM@netplane.com > Cc: jparker@axiowave.com; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > Ruder pragmatist--I won't be writing another one. ;-) > > I guess it makes sense to try to mirror best practice > (whatever that may > be) for these things. When all else fails, default to the > spec or flip > a coin. > > --Dave > > X-JNPR-Received-From: outside > From: "Manral, Vishwas" > Cc: jparker@axiowave.com, isis-wg@spider.juniper.net > Date: Tue, 8 Jan 2002 00:22:40 -0500 > Content-Type: text/plain > X-OriginalArrivalTime: 08 Jan 2002 05:22:23.0671 (UTC) > FILETIME=[7402B470:01C19804] > > Dave, > > Right, but wouldn't it help new implementations if the > default was the value > desired from implementations? I although agree that not > all implementations > would follow the default as given in the MIB, and its a > not a big issue what > the default in this case should be. > > Thanks, > Vishwas > > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Tuesday, January 08, 2002 10:32 AM > To: VishwasM@netplane.com > Cc: jparker@axiowave.com; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > To put on my rude pragmatist's hat again, it doesn't > really matter a > whole lot in practice what the MIB says the default is, since the > default is whatever the implementation already does (and defaults > in general are notoriously difficult to change in practice.) > > Jeff, > > My idea was that if the padded hellos aren't really of > much use, and as > Dave > put it "essentially useless and creates lots of > unnecessary customer > service" wouldn't it be wise not to make it the default > value. We aren't > strictly following the specs anyway. > > -Vishwas > > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Monday, January 07, 2002 8:23 PM > To: 'Manral, Vishwas' > Cc: IS-IS-WG (E-mail) > Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > > Jeff, > > > > The object > > isisCircSmallHellos OBJECT-TYPE > > SYNTAX AdminState > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Can we send unpadded hellos on LAN > circuits? Off means > > LAN Hellos must be padded." > > DEFVAL { off } > > ::= { isisCircEntry 26 } > > > > says the DEFVAL should be such that we must send LAN Hellos > > padded. However > > from the discussion > > http://people.juniper.net/pipermail/isis-wg/2000/000300.html > > http://people.juniper.net/pipermail/isis-wg/2000/000305.html > > it seems padding isn't of much help. Wouldn't it be better to > > change the > > DEFVAL to not off(on)? > > ... > > Vishwas > > Vishwas - > The standard requires padded hellos. The introduction > of this variable is an admission that some people like to > run without padded hellos, but I don't see any reason to make > unpadded (small hellos) the default behavior. > > Strong feelings from the list? > > - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 08:51:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21046 for ; Tue, 8 Jan 2002 08:51:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08Dj1147280; Tue, 8 Jan 2002 05:45:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08DiZ147265 for ; Tue, 8 Jan 2002 05:44:35 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g08Dkh232930 for ; Tue, 8 Jan 2002 05:46:49 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 05:45:28 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20563; Tue, 8 Jan 2002 08:45:36 -0500 (EST) Message-Id: <200201081345.IAA20563@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 08 Jan 2002 13:45:28.0484 (UTC) FILETIME=[BB8FA640:01C1984A] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 08 Jan 2002 08:45:36 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Three-Way Handshake for IS-IS Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-3way-04.txt Pages : 8 Date : 07-Jan-02 The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-3way-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-3way-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020107135102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-3way-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-3way-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020107135102.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 11:42:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29027 for ; Tue, 8 Jan 2002 11:42:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08GX4148043; Tue, 8 Jan 2002 08:33:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08GPM148005 for ; Tue, 8 Jan 2002 08:25:22 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g08GRa237647 for ; Tue, 8 Jan 2002 08:27:36 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 08:24:44 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g08GP4a04483; Tue, 8 Jan 2002 11:25:04 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK07824; Tue, 8 Jan 2002 11:24:51 -0500 (EST) Message-Id: <4.3.2.7.2.20020108112118.01ceded8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manral, Vishwas" From: Jeff Learman Subject: Fwd: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Cc: isis-wg@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 08 Jan 2002 16:24:44.0703 (UTC) FILETIME=[FB82F2F0:01C19860] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 08 Jan 2002 11:24:38 -0500 Vishwas, I strongly recommend against changing the default for whether to pad IIHs. This will create interoperability problems between implementations. It's fine that some implementations allow the IIHs to not be padded and to not check IIH padding. However, the default should minimize the number of things that must be configured to permit interoperability, and implementations exist that check the padding as required by the spec. If we were starting from scratch, we might choose a different default, but we're not. Does the MIB allow independent control of whether IIHs are padded and whether or not to check IIH padding? If so, it might be reasonable to have the default to "not check" (although, as Les says, this is debatable). This is would not cause the interoperability problem that would be caused by changing the way IIHs are transmitted. Regards, Jeff >At 04:02 AM 1/8/2002, you wrote: >>Les, >> >>But thats already happenning(MIB overriding the spec I mean). ISIS Hello >>multiplier(one example I came across) is a "routing architectural constant" >>according to the spec. The object >> >> isisCircLevelHelloMultiplier OBJECT-TYPE >> SYNTAX Integer32 (2..100) >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "This value is multiplied by the corresponding HelloTimer >> and the result in seconds (rounded up) is used as the >> holding time in transmitted hellos, to be used by receivers >> of hello packets from this IS" >> REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" >> DEFVAL { 10 } >> ::= { isisCircLevelEntry 7 } >> >>tells its configureable. And with the way the MaxAge is used, we may require >>MaxAge to be configureable too, that would again be a violation of the spec. >>I guess this is a bigger issue than changing the value of DEFVAL. >> >>What are ur views on a draft on ISIS for IP(I sent a mail regarding this >>earlier, but no responses)? >> >>Thanks, >>Vishwas >> >> >>-----Original Message----- >>From: Les Ginsberg [mailto:ginsberg@pluris.com] >>Sent: Tuesday, January 08, 2002 1:08 PM >>To: 'Dave Katz'; VishwasM@netplane.com >>Cc: jparker@axiowave.com; isis-wg@spider.juniper.net >>Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt >> >> >>(Sigh...somewhat against my better judgement...) >> >>There are some folks who think the benefits of padding outweigh the >>drawbacks - others feel the scale is tipped in the other direction. Whatever >>your individual opinion on the matter, the fact is that the spec calls for >>padding. If there is a strong consensus that the spec needs to be changed, >>then a change to the spec should be formally written, whether as a >>modification to the ISO spec or an IETF draft. (NO!! I am NOT proposing or >>advocating this!!) >> >>In the meantime, trying to use the MIB to override the spec is >>inappropriate. Jeff had the right idea(scroll to the bottom and see) - I'm >>on his side. >> >> Les >> >> >>> -----Original Message----- >>> From: Dave Katz [mailto:dkatz@juniper.net] >>> Sent: Monday, January 07, 2002 10:26 PM >>> To: VishwasM@netplane.com >>> Cc: jparker@axiowave.com; isis-wg@spider.juniper.net >>> Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt >>> >>> >>> Ruder pragmatist--I won't be writing another one. ;-) >>> >>> I guess it makes sense to try to mirror best practice >>> (whatever that may >>> be) for these things. When all else fails, default to the >>> spec or flip >>> a coin. >>> >>> --Dave >>> >>> X-JNPR-Received-From: outside >>> From: "Manral, Vishwas" >>> Cc: jparker@axiowave.com, isis-wg@spider.juniper.net >>> Date: Tue, 8 Jan 2002 00:22:40 -0500 >>> Content-Type: text/plain >>> X-OriginalArrivalTime: 08 Jan 2002 05:22:23.0671 (UTC) >>> FILETIME=[7402B470:01C19804] >>> >>> Dave, >>> >>> Right, but wouldn't it help new implementations if the >>> default was the value >>> desired from implementations? I although agree that not >>> all implementations >>> would follow the default as given in the MIB, and its a >>> not a big issue what >>> the default in this case should be. >>> >>> Thanks, >>> Vishwas >>> >>> -----Original Message----- >>> From: Dave Katz [mailto:dkatz@juniper.net] >>> Sent: Tuesday, January 08, 2002 10:32 AM >>> To: VishwasM@netplane.com >>> Cc: jparker@axiowave.com; isis-wg@spider.juniper.net >>> Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt >>> >>> >>> To put on my rude pragmatist's hat again, it doesn't >>> really matter a >>> whole lot in practice what the MIB says the default is, since the >>> default is whatever the implementation already does (and defaults >>> in general are notoriously difficult to change in practice.) >>> >>> Jeff, >>> >>> My idea was that if the padded hellos aren't really of >>> much use, and as >>> Dave >>> put it "essentially useless and creates lots of >>> unnecessary customer >>> service" wouldn't it be wise not to make it the default >>> value. We aren't >>> strictly following the specs anyway. >>> >>> -Vishwas >>> >>> -----Original Message----- >>> From: Jeff Parker [mailto:jparker@axiowave.com] >>> Sent: Monday, January 07, 2002 8:23 PM >>> To: 'Manral, Vishwas' >>> Cc: IS-IS-WG (E-mail) >>> Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt >>> >>> >>> > Jeff, >>> > >>> > The object >>> > isisCircSmallHellos OBJECT-TYPE >>> > SYNTAX AdminState >>> > MAX-ACCESS read-create >>> > STATUS current >>> > DESCRIPTION >>> > "Can we send unpadded hellos on LAN >>> circuits? Off means >>> > LAN Hellos must be padded." >>> > DEFVAL { off } >>> > ::= { isisCircEntry 26 } >>> > >>> > says the DEFVAL should be such that we must send LAN Hellos >>> > padded. However >>> > from the discussion >>> > http://people.juniper.net/pipermail/isis-wg/2000/000300.html >>> > http://people.juniper.net/pipermail/isis-wg/2000/000305.html >>> > it seems padding isn't of much help. Wouldn't it be better to >>> > change the >>> > DEFVAL to not off(on)? >>> > ... >>> > Vishwas >>> >>> Vishwas - >>> The standard requires padded hellos. The introduction >>> of this variable is an admission that some people like to >>> run without padded hellos, but I don't see any reason to make >>> unpadded (small hellos) the default behavior. >>> >>> Strong feelings from the list? >>> >>> - jeff parker >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@external.juniper.net >>http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 12:01:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29835 for ; Tue, 8 Jan 2002 12:01:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08Gw7148173; Tue, 8 Jan 2002 08:58:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08Gln148111 for ; Tue, 8 Jan 2002 08:47:49 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g08GoCR06263; Tue, 8 Jan 2002 11:50:12 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK08510; Tue, 8 Jan 2002 11:50:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020108112515.01cb0ec0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manral, Vishwas" From: Jeff Learman Subject: Re: [Isis-wg] Regarding document for best current practices Cc: "'Dave Katz'" , ginsberg@pluris.com, isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 08 Jan 2002 11:49:21 -0500 Vishwas, You repeated your request for a new document on IS-IS, either a compendium of best practices or a new spec that describes Integrated IS-IS. One response I saw was that there weren't many discrepancies between spec and practice, and that most "best practices" were matters of implementation, not specification. I suspect that there are things that would be good to document, and perhaps padding of IIHs is one. If you were to go over the list of potential issues and present it, it might generate some interest. I doubt that this is work that anyone is eager to take on out of public interest, but if you are willing to drive the work, I'm sure you would get lots of feedback ;-) Concerning creating a new spec that combines ISO 10589 and RFC-1195, this sure would be nice for those trying to learn integrated IS-IS and newcomers to the field. However, there are significant issues: 1. It would be a lot of hard work. 2. Any new wording of these specs would create new ambiguity problems. Which spec would be the definitive one? Would the new document be definitive or just descriptive? 3. There would be a temptation to "fix" things, which would be a disaster. If there is any new text, it should start out with the intention of being identical in meaning to the previous specs. Unfortunately, this would make it less helpful and clear for the IP-only crowd. But at least, it could be used as a starting point, so that any changes could be written against it, and therefore anyone could tell what changed between two subsequent versions. All of these issues could be worked through, if there is enough commitment among all players. But I doubt that we will find this kind of commitment, and I question whether the result would justify the amount of work and haggling that would be required. Alternatively, someone could write a good book on implementing IS-IS. They'd probably sell upwards of 50 copies ;-) Regards, Jeff Disclaimer: This is my opinion. I do not represent Cisco in this forum and I have never worked on IS-IS at Cisco. At 10:34 AM 1/2/2002, Manral, Vishwas wrote: >Dave, > >Changed the subject line to actually reflect the contents of the discussion. > >No matter how small the difference, don't you think it would be good to >document it somewhere(may be, "not all that sticky" issues, could be >documented too)? > >To think of it, wouldn't it be nice, if we could actually have an >informational document(all ISIS work in IETF is informational anyway, I >guess) which could talk about ISIS for IP specifically. This could talk >about the entire protocol(instead of a delta with the ISO spec as in >RFC1195) and could incorporate the best current practices. > >Would there be any interest in the group for this kind of a document? I >personally feel it would be a good idea, and would help in easier >understanding and better implementation of ISIS(atleast for those who are >not all that well versed). I have no idea of the IETF/ISO laison though.(I >tried to check if this thing had been raised before in the mailing list >couldn't find it) > >Thanks, >Vishwas > > >--------------------------------------------------------------------- >I think the number of things that are done in practical conflict with >the spec is vanishingly small, where "practical conflict" is >interpreted as "a reasonable implementation would notice." >Excessively pedantic boxes have a way of fixing themselves one way or >another. > >Most of these things are pretty obvious to anyone reasonably versed in >the art, though the potentially sticky ones (like not bothering with >ISHs) should probably be documented. > >--Dave >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 12:33:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01340 for ; Tue, 8 Jan 2002 12:33:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08HTB148338; Tue, 8 Jan 2002 09:29:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08HDJ148261 for ; Tue, 8 Jan 2002 09:13:19 -0800 (PST) (envelope-from jparker@axiowave.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g08HFU239521 for ; Tue, 8 Jan 2002 09:15:34 -0800 (PST) X-JNPR-Received-From: outside Received: from bridge.axiowave.com ([216.49.69.50]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 09:11:27 -0800 Message-ID: From: Jeff Parker To: "'Jeff Learman'" Cc: isis-wg@juniper.net Subject: RE: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 08 Jan 2002 17:11:27.0999 (UTC) FILETIME=[8267F8F0:01C19867] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 8 Jan 2002 12:11:28 -0500 > Does the MIB allow independent control of whether IIHs are > padded and whether or not to check IIH padding? Jeff L. There is no knob to control checking paddding, as there is no counter, no Notification (Trap) defined to track that a peer is not padding, so no behavior to modify. My take is that interoperation is possible, if not required, between those who pad and those who do not, so there is no need for a standard notification when the twain shall meet. I have added this knob to control padding to allow an administrator to set the behavior when an implementation supports both. While I think it is important to show the right value for the padding setting (that is, the MIB variable should be present and readable) I don't think it is required that an implementation support the unpadded version. I've tried to capture that in a revised Description clause, below. This does give preference to the padded behavior, which should be supported for the reasons you laid out in the comments I edited out. - jeff parker isisCircSmallHellos OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "Can we send unpadded hellos on LAN circuits? Off means LAN Hellos must be padded. Implementations should allow the administrator to read this value. An implementation need not be able to support unpadded hellos to be conformant." DEFVAL { off } ::= { isisCircEntry 21 } _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 13:25:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03681 for ; Tue, 8 Jan 2002 13:25:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08ILB148582; Tue, 8 Jan 2002 10:21:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08Hxd148478 for ; Tue, 8 Jan 2002 09:59:39 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g08I1s241252 for ; Tue, 8 Jan 2002 10:01:54 -0800 (PST) X-JNPR-Received-From: outside Received: from xover.mindspeed.com ([198.62.10.2]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 09:57:57 -0800 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 12:58:07 -0500 Message-ID: From: "Manral, Vishwas" To: "'Jeff Learman'" Cc: isis-wg@juniper.net Subject: RE: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-OriginalArrivalTime: 08 Jan 2002 17:57:57.0750 (UTC) FILETIME=[013A3160:01C1986E] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 8 Jan 2002 12:58:02 -0500 Jeff L., It is exactly this reason I think a document of "Best Current Practices" is required(and am unable to see why anyone would be against one). The Spec says that MaxAge is an architectural constant, however implementations making assumptions based on that would be broken. Padded IIH Hello's(it seems to me - as well as from archives) don't exactly serve their purpose, yet not implementing could lead to interoperability problems as some implementations check the padding. This itself sounds reason enough(to me) to document the best current practices, if not the the "ISIS for IP" document. I am ready to raise the issues/put forward a document for the purpose(if the list thinks its worth the effort) and am sure there will be more people interested in helping with the issues/document. So wouldn't the BCP for sending IIH Hello's be that we send padded Hello's till the adjacency comes UP(in case padding needs to be done). Also shouldn't the behaviour for new implementations be not to check padding, or would we still want padding to be checked in some cases? Thanks a lot for the information, Vishwas -----Original Message----- From: Jeff Learman [mailto:jlearman@cisco.com] Sent: Tuesday, January 08, 2002 9:55 PM To: Manral, Vishwas Cc: isis-wg@juniper.net Subject: Fwd: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Vishwas, I strongly recommend against changing the default for whether to pad IIHs. This will create interoperability problems between implementations. It's fine that some implementations allow the IIHs to not be padded and to not check IIH padding. However, the default should minimize the number of things that must be configured to permit interoperability, and implementations exist that check the padding as required by the spec. If we were starting from scratch, we might choose a different default, but we're not. Does the MIB allow independent control of whether IIHs are padded and whether or not to check IIH padding? If so, it might be reasonable to have the default to "not check" (although, as Les says, this is debatable). This is would not cause the interoperability problem that would be caused by changing the way IIHs are transmitted. Regards, Jeff >At 04:02 AM 1/8/2002, you wrote: >>Les, >> >>But thats already happenning(MIB overriding the spec I mean). ISIS Hello >>multiplier(one example I came across) is a "routing architectural constant" >>according to the spec. The object >> >> isisCircLevelHelloMultiplier OBJECT-TYPE >> SYNTAX Integer32 (2..100) >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "This value is multiplied by the corresponding HelloTimer >> and the result in seconds (rounded up) is used as the >> holding time in transmitted hellos, to be used by receivers >> of hello packets from this IS" >> REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" >> DEFVAL { 10 } >> ::= { isisCircLevelEntry 7 } >> >>tells its configureable. And with the way the MaxAge is used, we may require >>MaxAge to be configureable too, that would again be a violation of the spec. >>I guess this is a bigger issue than changing the value of DEFVAL. >> >>What are ur views on a draft on ISIS for IP(I sent a mail regarding this >>earlier, but no responses)? >> >>Thanks, >>Vishwas >> >> >>-----Original Message----- >>From: Les Ginsberg [mailto:ginsberg@pluris.com] >>Sent: Tuesday, January 08, 2002 1:08 PM >>To: 'Dave Katz'; VishwasM@netplane.com >>Cc: jparker@axiowave.com; isis-wg@spider.juniper.net >>Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt >> >> >>(Sigh...somewhat against my better judgement...) >> >>There are some folks who think the benefits of padding outweigh the >>drawbacks - others feel the scale is tipped in the other direction. Whatever >>your individual opinion on the matter, the fact is that the spec calls for >>padding. If there is a strong consensus that the spec needs to be changed, >>then a change to the spec should be formally written, whether as a >>modification to the ISO spec or an IETF draft. (NO!! I am NOT proposing or >>advocating this!!) >> >>In the meantime, trying to use the MIB to override the spec is >>inappropriate. Jeff had the right idea(scroll to the bottom and see) - I'm >>on his side. >> >> Les >> >> >>> -----Original Message----- >>> From: Dave Katz [mailto:dkatz@juniper.net] >>> Sent: Monday, January 07, 2002 10:26 PM >>> To: VishwasM@netplane.com >>> Cc: jparker@axiowave.com; isis-wg@spider.juniper.net >>> Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt >>> >>> >>> Ruder pragmatist--I won't be writing another one. ;-) >>> >>> I guess it makes sense to try to mirror best practice >>> (whatever that may >>> be) for these things. When all else fails, default to the >>> spec or flip >>> a coin. >>> >>> --Dave >>> >>> X-JNPR-Received-From: outside >>> From: "Manral, Vishwas" >>> Cc: jparker@axiowave.com, isis-wg@spider.juniper.net >>> Date: Tue, 8 Jan 2002 00:22:40 -0500 >>> Content-Type: text/plain >>> X-OriginalArrivalTime: 08 Jan 2002 05:22:23.0671 (UTC) >>> FILETIME=[7402B470:01C19804] >>> >>> Dave, >>> >>> Right, but wouldn't it help new implementations if the >>> default was the value >>> desired from implementations? I although agree that not >>> all implementations >>> would follow the default as given in the MIB, and its a >>> not a big issue what >>> the default in this case should be. >>> >>> Thanks, >>> Vishwas >>> >>> -----Original Message----- >>> From: Dave Katz [mailto:dkatz@juniper.net] >>> Sent: Tuesday, January 08, 2002 10:32 AM >>> To: VishwasM@netplane.com >>> Cc: jparker@axiowave.com; isis-wg@spider.juniper.net >>> Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt >>> >>> >>> To put on my rude pragmatist's hat again, it doesn't >>> really matter a >>> whole lot in practice what the MIB says the default is, since the >>> default is whatever the implementation already does (and defaults >>> in general are notoriously difficult to change in practice.) >>> >>> Jeff, >>> >>> My idea was that if the padded hellos aren't really of >>> much use, and as >>> Dave >>> put it "essentially useless and creates lots of >>> unnecessary customer >>> service" wouldn't it be wise not to make it the default >>> value. We aren't >>> strictly following the specs anyway. >>> >>> -Vishwas >>> >>> -----Original Message----- >>> From: Jeff Parker [mailto:jparker@axiowave.com] >>> Sent: Monday, January 07, 2002 8:23 PM >>> To: 'Manral, Vishwas' >>> Cc: IS-IS-WG (E-mail) >>> Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt >>> >>> >>> > Jeff, >>> > >>> > The object >>> > isisCircSmallHellos OBJECT-TYPE >>> > SYNTAX AdminState >>> > MAX-ACCESS read-create >>> > STATUS current >>> > DESCRIPTION >>> > "Can we send unpadded hellos on LAN >>> circuits? Off means >>> > LAN Hellos must be padded." >>> > DEFVAL { off } >>> > ::= { isisCircEntry 26 } >>> > >>> > says the DEFVAL should be such that we must send LAN Hellos >>> > padded. However >>> > from the discussion >>> > http://people.juniper.net/pipermail/isis-wg/2000/000300.html >>> > http://people.juniper.net/pipermail/isis-wg/2000/000305.html >>> > it seems padding isn't of much help. Wouldn't it be better to >>> > change the >>> > DEFVAL to not off(on)? >>> > ... >>> > Vishwas >>> >>> Vishwas - >>> The standard requires padded hellos. The introduction >>> of this variable is an admission that some people like to >>> run without padded hellos, but I don't see any reason to make >>> unpadded (small hellos) the default behavior. >>> >>> Strong feelings from the list? >>> >>> - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 8 14:00:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05164 for ; Tue, 8 Jan 2002 14:00:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08IuB148753; Tue, 8 Jan 2002 10:56:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08Ig3148681 for ; Tue, 8 Jan 2002 10:42:03 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g08IiI243544 for ; Tue, 8 Jan 2002 10:44:18 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 10:43:03 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g08IhMG15332; Tue, 8 Jan 2002 13:43:23 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK12528; Tue, 8 Jan 2002 13:43:07 -0500 (EST) Message-Id: <4.3.2.7.2.20020108132338.01d13008@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manral, Vishwas" From: Jeff Learman Subject: RE: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Cc: isis-wg@juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 08 Jan 2002 18:43:04.0093 (UTC) FILETIME=[4E555CD0:01C19874] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 08 Jan 2002 13:41:56 -0500 I personally found padding to be extremely useful, but for reasons that apply to developers rather than customers. At my previous job at ONE, we ported our ISIS to a variety of platforms. It was always very helpful that no special test was required to verify that the LAN drivers & interfaces supported full 1500 byte frames (and surprising how often, even in big brand name equipment), they didn't. Of course, this doesn't apply to consumers, as this kind of thing shouldn't vary for a given platform/product. On a simple LAN, big IIHs don't help much but shouldn't hurt much either. In complex cases where MTU sizes aren't consistent (e.g., using ATM or certain bridging cases), I would think it is helpful to know that a link isn't what you think it is. But some people with more experience than I have think that it's better to let the routing protocol work, and if big packets don't work, customers will naturally focus on that problem rather than the routing protocol. They have a good point. I'm sure I oversimplified the cases; I don't have a strong opinion on whether checking should happen by default or not. In any case, it's an issue that might merit being included in an informational RFC, as well as a warning that MaxAge is not implemented as an architectural constant in some implementations. (Need we say more about that?) It would certainly be interesting to see a list of potential issues. Regards, Jeff At 12:58 PM 1/8/2002, Manral, Vishwas wrote: >Jeff L., > >It is exactly this reason I think a document of "Best Current Practices" is >required(and am unable to see why anyone would be against one). > >The Spec says that MaxAge is an architectural constant, however >implementations making assumptions based on that would be broken. Padded IIH >Hello's(it seems to me - as well as from archives) don't exactly serve their >purpose, yet not implementing could lead to interoperability problems as >some implementations check the padding. > >This itself sounds reason enough(to me) to document the best current >practices, if not the the "ISIS for IP" document. I am ready to raise the >issues/put forward a document for the purpose(if the list thinks its worth >the effort) and am sure there will be more people interested in helping with >the issues/document. > >So wouldn't the BCP for sending IIH Hello's be that we send padded Hello's >till the adjacency comes UP(in case padding needs to be done). Also >shouldn't the behaviour for new implementations be not to check padding, or >would we still want padding to be checked in some cases? > >Thanks a lot for the information, >Vishwas > >-----Original Message----- >From: Jeff Learman [mailto:jlearman@cisco.com] >Sent: Tuesday, January 08, 2002 9:55 PM >To: Manral, Vishwas >Cc: isis-wg@juniper.net >Subject: Fwd: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt > > > >Vishwas, > >I strongly recommend against changing the default for whether to >pad IIHs. This will create interoperability problems between >implementations. > >It's fine that some implementations allow the IIHs to not be padded >and to not check IIH padding. However, the default should minimize >the number of things that must be configured to permit interoperability, >and implementations exist that check the padding as required by the >spec. > >If we were starting from scratch, we might choose a different default, >but we're not. > >Does the MIB allow independent control of whether IIHs are padded and >whether or not to check IIH padding? If so, it might be reasonable to >have the default to "not check" (although, as Les says, this is debatable). >This is would not cause the interoperability problem that would be caused >by changing the way IIHs are transmitted. > >Regards, >Jeff > >>At 04:02 AM 1/8/2002, you wrote: >>>Les, >>> >>>But thats already happenning(MIB overriding the spec I mean). ISIS Hello >>>multiplier(one example I came across) is a "routing architectural >constant" >>>according to the spec. The object >>> >>> isisCircLevelHelloMultiplier OBJECT-TYPE >>> SYNTAX Integer32 (2..100) >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "This value is multiplied by the corresponding HelloTimer >>> and the result in seconds (rounded up) is used as the >>> holding time in transmitted hellos, to be used by receivers >>> of hello packets from this IS" >>> REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" >>> DEFVAL { 10 } >>> ::= { isisCircLevelEntry 7 } >>> >>>tells its configureable. And with the way the MaxAge is used, we may >require >>>MaxAge to be configureable too, that would again be a violation of the >spec. >>>I guess this is a bigger issue than changing the value of DEFVAL. >>> >>>What are ur views on a draft on ISIS for IP(I sent a mail regarding this >>>earlier, but no responses)? >>> >>>Thanks, >>>Vishwas >>> >>> >>>-----Original Message----- >>>From: Les Ginsberg [mailto:ginsberg@pluris.com] >>>Sent: Tuesday, January 08, 2002 1:08 PM >>>To: 'Dave Katz'; VishwasM@netplane.com >>>Cc: jparker@axiowave.com; isis-wg@spider.juniper.net >>>Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt >>> >>> >>>(Sigh...somewhat against my better judgement...) >>> >>>There are some folks who think the benefits of padding outweigh the >>>drawbacks - others feel the scale is tipped in the other direction. >Whatever >>>your individual opinion on the matter, the fact is that the spec calls for >>>padding. If there is a strong consensus that the spec needs to be changed, >>>then a change to the spec should be formally written, whether as a >>>modification to the ISO spec or an IETF draft. (NO!! I am NOT proposing or >>>advocating this!!) >>> >>>In the meantime, trying to use the MIB to override the spec is >>>inappropriate. Jeff had the right idea(scroll to the bottom and see) - I'm >>>on his side. >>> >>> Les >>> >>> >>>> -----Original Message----- >>>> From: Dave Katz [mailto:dkatz@juniper.net] >>>> Sent: Monday, January 07, 2002 10:26 PM >>>> To: VishwasM@netplane.com >>>> Cc: jparker@axiowave.com; isis-wg@spider.juniper.net >>>> Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt >>>> >>>> >>>> Ruder pragmatist--I won't be writing another one. ;-) >>>> >>>> I guess it makes sense to try to mirror best practice >>>> (whatever that may >>>> be) for these things. When all else fails, default to the >>>> spec or flip >>>> a coin. >>>> >>>> --Dave >>>> >>>> X-JNPR-Received-From: outside >>>> From: "Manral, Vishwas" >>>> Cc: jparker@axiowave.com, isis-wg@spider.juniper.net >>>> Date: Tue, 8 Jan 2002 00:22:40 -0500 >>>> Content-Type: text/plain >>>> X-OriginalArrivalTime: 08 Jan 2002 05:22:23.0671 (UTC) >>>> FILETIME=[7402B470:01C19804] >>>> >>>> Dave, >>>> >>>> Right, but wouldn't it help new implementations if the >>>> default was the value >>>> desired from implementations? I although agree that not >>>> all implementations >>>> would follow the default as given in the MIB, and its a >>>> not a big issue what >>>> the default in this case should be. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> -----Original Message----- >>>> From: Dave Katz [mailto:dkatz@juniper.net] >>>> Sent: Tuesday, January 08, 2002 10:32 AM >>>> To: VishwasM@netplane.com >>>> Cc: jparker@axiowave.com; isis-wg@spider.juniper.net >>>> Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt >>>> >>>> >>>> To put on my rude pragmatist's hat again, it doesn't >>>> really matter a >>>> whole lot in practice what the MIB says the default is, since the >>>> default is whatever the implementation already does (and defaults >>>> in general are notoriously difficult to change in practice.) >>>> >>>> Jeff, >>>> >>>> My idea was that if the padded hellos aren't really of >>>> much use, and as >>>> Dave >>>> put it "essentially useless and creates lots of >>>> unnecessary customer >>>> service" wouldn't it be wise not to make it the default >>>> value. We aren't >>>> strictly following the specs anyway. >>>> >>>> -Vishwas >>>> >>>> -----Original Message----- >>>> From: Jeff Parker [mailto:jparker@axiowave.com] >>>> Sent: Monday, January 07, 2002 8:23 PM >>>> To: 'Manral, Vishwas' >>>> Cc: IS-IS-WG (E-mail) >>>> Subject: RE: Regarding draft-ietf-isis-wg-mib-06.txt >>>> >>>> >>>> > Jeff, >>>> > >>>> > The object >>>> > isisCircSmallHellos OBJECT-TYPE >>>> > SYNTAX AdminState >>>> > MAX-ACCESS read-create >>>> > STATUS current >>>> > DESCRIPTION >>>> > "Can we send unpadded hellos on LAN >>>> circuits? Off means >>>> > LAN Hellos must be padded." >>>> > DEFVAL { off } >>>> > ::= { isisCircEntry 26 } >>>> > >>>> > says the DEFVAL should be such that we must send LAN Hellos >>>> > padded. However >>>> > from the discussion >>>> > http://people.juniper.net/pipermail/isis-wg/2000/000300.html >>>> > http://people.juniper.net/pipermail/isis-wg/2000/000305.html >>>> > it seems padding isn't of much help. Wouldn't it be better to >>>> > change the >>>> > DEFVAL to not off(on)? >>>> > ... >>>> > Vishwas >>>> >>>> Vishwas - >>>> The standard requires padded hellos. The introduction >>>> of this variable is an admission that some people like to >>>> run without padded hellos, but I don't see any reason to make >>>> unpadded (small hellos) the default behavior. >>>> >>>> Strong feelings from the list? >>>> >>>> - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 02:27:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00514 for ; Wed, 9 Jan 2002 02:27:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g097N5151988; Tue, 8 Jan 2002 23:23:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08J6O148813 for ; Tue, 8 Jan 2002 11:06:24 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g08J8d244413 for ; Tue, 8 Jan 2002 11:08:39 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 11:04:50 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g08J5B317201; Tue, 8 Jan 2002 14:05:11 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK13342; Tue, 8 Jan 2002 14:04:59 -0500 (EST) Message-Id: <4.3.2.7.2.20020108134317.04335b28@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Jeff Learman Subject: RE: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Cc: isis-wg@juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 08 Jan 2002 19:04:50.0843 (UTC) FILETIME=[593796B0:01C19877] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 08 Jan 2002 13:45:17 -0500 Sounds good to me, Jeff. Jeff L At 12:11 PM 1/8/2002, Jeff Parker wrote: >> Does the MIB allow independent control of whether IIHs are >> padded and whether or not to check IIH padding? > >Jeff L. > There is no knob to control checking paddding, >as there is no counter, no Notification (Trap) >defined to track that a peer is not padding, so >no behavior to modify. > My take is that interoperation is possible, >if not required, between those who pad and those >who do not, so there is no need for a standard >notification when the twain shall meet. > > I have added this knob to control padding >to allow an administrator to set the behavior >when an implementation supports both. > While I think it is important to show the >right value for the padding setting (that is, >the MIB variable should be present and readable) >I don't think it is required that an implementation >support the unpadded version. I've tried to capture >that in a revised Description clause, below. This >does give preference to the padded behavior, which >should be supported for the reasons you laid out in >the comments I edited out. > >- jeff parker > > isisCircSmallHellos OBJECT-TYPE > SYNTAX AdminState > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Can we send unpadded hellos on LAN circuits? Off means > LAN Hellos must be padded. > Implementations should allow the administrator to read > this value. An implementation need not be able to > support unpadded hellos to be conformant." > DEFVAL { off } > ::= { isisCircEntry 21 } _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 02:31:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00609 for ; Wed, 9 Jan 2002 02:31:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g097RB152019; Tue, 8 Jan 2002 23:27:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08JEB148855 for ; Tue, 8 Jan 2002 11:14:11 -0800 (PST) (envelope-from prz@redback.com) Received: from redback.com (dhcp-35-94.redback.com [155.53.35.94]) by prattle.redback.com (Postfix) with ESMTP id 15BDBCAB7A; Tue, 8 Jan 2002 11:16:26 -0800 (PST) Message-ID: <3C3B320B.7F736B4B@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Learman Cc: "Manral, Vishwas" , "'Dave Katz'" , ginsberg@pluris.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Regarding document for best current practices References: <4.3.2.7.2.20020108112515.01cb0ec0@dingdong.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 08 Jan 2002 09:53:15 -0800 Content-Transfer-Encoding: 7bit Jeff Learman wrote: > Vishwas, > > Concerning creating a new spec that combines ISO 10589 and RFC-1195, > this sure would be nice for those trying to learn integrated IS-IS > and newcomers to the field. However, there are significant issues: > > 1. It would be a lot of hard work. > > 2. Any new wording of these specs would create new ambiguity problems. > Which spec would be the definitive one? Would the new document be > definitive or just descriptive? We do not have really a framework for normative or definitive documents in this group since a) we publish informationals b) it's not in the charter really c) ISO is the normative side for anything but IP features > Alternatively, someone could write a good book on implementing IS-IS. > They'd probably sell upwards of 50 copies ;-) there is at least one very good book (IMHO and if the author followed my comments ;-) in the immediate pipe by a well-known serious publisher. To stay unbiased, I'm not giving any further information ... thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 02:34:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00662 for ; Wed, 9 Jan 2002 02:34:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g097U1152047; Tue, 8 Jan 2002 23:30:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com ([208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08Jgw148985 for ; Tue, 8 Jan 2002 11:43:24 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA15845; Tue, 8 Jan 2002 11:44:24 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 11:44:24 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com> From: Les Ginsberg To: "'Jeff Learman'" , "Manral, Vishwas" Cc: "'Dave Katz'" , Les Ginsberg , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 8 Jan 2002 11:44:24 -0800 In the work plan in ISO SC6/WG7 which produced the revised 10589:2001 spec, there was a Phase 2 specified which was aimed at producing a document which covered changes to the protocol introduced in the IP world. The exact form this was to take was never agreed upon, the idea was floated on this list (by me) with a rather tepid response. As the 10589 revision work progressed, it became clear to me that ISO was the wrong place for this Phase 2 work to take place - if it was going to take place at all it needed to be driven by the community which was driving the evolution of the protocol. In my view, what is needed is not a BCP document, but rather a new version of RFC 1195. This would not need to supplant existing RFCs describing protocol extensions, but it should at a minimum correct inaccuracies and obsolete items in 1195, and hopefully go on to define extensions to the protocol which have become common practice but have never been documented - and have interoperability issues. The MAXAGE issue is a minor example - as Mike Shand's keen eye has demonstrated - a strictly conformant implementation based on 10589 would reject LSPs with a lifetime > 1200. The fact that no one seems to do this does not diminish the need for having a document that clearly states this. It is a good thing that the way this group works tries to be responsive to real world (AKA customer) requirements. It is not a good thing when protocol extensions are made and left purely to word-of-mouth/reverse engineering style documentation. Given the extension of ISIS for IP into the formerly OSI only world of SONET, the need for formalizing protocol extensions becomes even greater - else we will end up with multiple/non-interoperable solutions. I would love to believe that a meaningful liason between IETF/ISO/ITU regarding IS-IS could be achieved, since that would allow all the interested communities to participate in the evolution of the protocol - but having spent a fair amount of effort trying to make that happen, I am not optimistic. (No disrespect to a number of interested parties who were supportive along the way). Jeff Learman's comments below are pretty much on the mark - but if there is sufficient interest in addressing things, I will be a willing participant. Les > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Tuesday, January 08, 2002 8:49 AM > To: Manral, Vishwas > Cc: 'Dave Katz'; ginsberg@pluris.com; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Regarding document for best current practices > > > > Vishwas, > > You repeated your request for a new document on IS-IS, either a > compendium of best practices or a new spec that describes Integrated > IS-IS. One response I saw was that there weren't many discrepancies > between spec and practice, and that most "best practices" were matters > of implementation, not specification. > > I suspect that there are things that would be good to > document, and perhaps > padding of IIHs is one. If you were to go over the list of > potential issues > and present it, it might generate some interest. I doubt > that this is work > that anyone is eager to take on out of public interest, but if you are > willing to drive the work, I'm sure you would get lots of feedback ;-) > > Concerning creating a new spec that combines ISO 10589 and RFC-1195, > this sure would be nice for those trying to learn integrated IS-IS > and newcomers to the field. However, there are significant issues: > > 1. It would be a lot of hard work. > > 2. Any new wording of these specs would create new > ambiguity problems. > Which spec would be the definitive one? Would the new > document be > definitive or just descriptive? > > 3. There would be a temptation to "fix" things, which > would be a disaster. > If there is any new text, it should start out with the > intention of > being identical in meaning to the previous specs. > Unfortunately, > this would make it less helpful and clear for the IP-only crowd. > But at least, it could be used as a starting point, so that any > changes could be written against it, and therefore anyone could > tell what changed between two subsequent versions. > > All of these issues could be worked through, if there is > enough commitment > among all players. But I doubt that we will find this kind > of commitment, > and I question whether the result would justify the amount of work and > haggling that would be required. > > Alternatively, someone could write a good book on implementing IS-IS. > They'd probably sell upwards of 50 copies ;-) > > Regards, > Jeff > > Disclaimer: This is my opinion. I do not represent Cisco in this > forum and I have never worked on IS-IS at Cisco. > > At 10:34 AM 1/2/2002, Manral, Vishwas wrote: > >Dave, > > > >Changed the subject line to actually reflect the contents of > the discussion. > > > >No matter how small the difference, don't you think it would > be good to > >document it somewhere(may be, "not all that sticky" issues, could be > >documented too)? > > > >To think of it, wouldn't it be nice, if we could actually have an > >informational document(all ISIS work in IETF is > informational anyway, I > >guess) which could talk about ISIS for IP specifically. This > could talk > >about the entire protocol(instead of a delta with the ISO spec as in > >RFC1195) and could incorporate the best current practices. > > > >Would there be any interest in the group for this kind of a > document? I > >personally feel it would be a good idea, and would help in easier > >understanding and better implementation of ISIS(atleast for > those who are > >not all that well versed). I have no idea of the IETF/ISO > laison though.(I > >tried to check if this thing had been raised before in the > mailing list > >couldn't find it) > > > >Thanks, > >Vishwas > > > > > >--------------------------------------------------------------------- > >I think the number of things that are done in practical conflict with > >the spec is vanishingly small, where "practical conflict" is > >interpreted as "a reasonable implementation would notice." > >Excessively pedantic boxes have a way of fixing themselves one way or > >another. > > > >Most of these things are pretty obvious to anyone reasonably > versed in > >the art, though the potentially sticky ones (like not bothering with > >ISHs) should probably be documented. > > > >--Dave > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 02:36:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00693 for ; Wed, 9 Jan 2002 02:36:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g097Wl152199; Tue, 8 Jan 2002 23:32:47 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g08KHi149137 for ; Tue, 8 Jan 2002 12:17:44 -0800 (PST) (envelope-from Ravindra.Sunkad@vivacenetworks.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g08KJx246733 for ; Tue, 8 Jan 2002 12:20:00 -0800 (PST) X-JNPR-Received-From: outside Received: from viva1.vivacenetworks.com ([64.221.212.135]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 12:18:42 -0800 Received: by viva1.vivacenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 12:18:53 -0800 Message-ID: From: Ravindra Sunkad To: isis-wg@juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19881.B0B2B730" X-OriginalArrivalTime: 08 Jan 2002 20:18:42.0515 (UTC) FILETIME=[AAB31230:01C19881] Subject: [Isis-wg] 3-way handshake question Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 8 Jan 2002 12:18:52 -0800 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. ------_=_NextPart_001_01C19881.B0B2B730 Content-Type: text/plain Hi, Clause c) of Section 3.2 requires skipping sections 8.2.4.2 c) and d) of 10589. However the CircuitID calculated in 8.2.4.2 c) is used for the removal of excess paths during the decision process. See section 7.2.7 of 10589. So, how is the ptptCircuitID computed for circuits over which an adjacency is established using the 3-way handshake? And how is this ptptCircuitID comparable to the ptptCircuitID computed for a circuit that has a 2-way adjacency? Thanks, Ravi ------_=_NextPart_001_01C19881.B0B2B730 Content-Type: text/html Message
Hi,
 
Clause c) of Section 3.2 requires skipping sections 8.2.4.2 c) and d) of 10589.
However the CircuitID calculated in 8.2.4.2 c) is used for the removal of
excess paths during the decision process. See section 7.2.7 of 10589.
 
So, how is the ptptCircuitID computed for circuits over which an adjacency is established using the 3-way handshake? And how is this ptptCircuitID comparable to the ptptCircuitID computed for a circuit that has a 2-way adjacency?
 
Thanks,
Ravi
 
 
------_=_NextPart_001_01C19881.B0B2B730-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 03:40:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01205 for ; Wed, 9 Jan 2002 03:40:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g098a1152653; Wed, 9 Jan 2002 00:36:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g098ZN152641 for ; Wed, 9 Jan 2002 00:35:23 -0800 (PST) (envelope-from prz@net4u.ch) Received: from net4u.ch ([63.200.52.11]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GPN00EUYXAR1E@mta5.snfc21.pbi.net> for isis-wg@spider.juniper.net; Wed, 09 Jan 2002 00:37:40 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] Regarding document for best current practices To: Les Ginsberg Cc: "'Jeff Learman'" , "Manral, Vishwas" , "'Dave Katz'" , isis-wg@spider.juniper.net Message-id: <3C3C0841.6070409@net4u.ch> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 References: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 09 Jan 2002 01:07:13 -0800 Content-Transfer-Encoding: 7BIT Les Ginsberg wrote: >In the work plan in ISO SC6/WG7 which produced the revised 10589:2001 spec, >there was a Phase 2 specified which was aimed at producing a document which >covered changes to the protocol introduced in the IP world. The exact form >this was to take was never agreed upon, the idea was floated on this list >(by me) with a rather tepid response. As the 10589 revision work progressed, >it became clear to me that ISO was the wrong place for this Phase 2 work to >take place - if it was going to take place at all it needed to be driven by >the community which was driving the evolution of the protocol. > Modulo Tony Li's opinion, if we see enough cycles of cluefull people being committed to make an update of RFC1195 happen, that's something that can be talked about. Reality of things being that we have a set of RFCs (or should have, the guys upstairs are taking their time) that albeit informational pretty well document what it out there today. Split RFCs allow to move fast but do not make for such a nice reading as a single 1195 (or OSPF spec for that matter ;-) of course. More RFCs are obviously needed along the lines of max-age restrictions or hello padding practices and there is nothing that stops people from writing them. thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 03:59:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01406 for ; Wed, 9 Jan 2002 03:59:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g098u4152777; Wed, 9 Jan 2002 00:56:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g098nt152734 for ; Wed, 9 Jan 2002 00:49:55 -0800 (PST) (envelope-from tli@Procket.com) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g098p2Hb013601; Wed, 9 Jan 2002 00:51:02 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g098p1lf021310; Wed, 9 Jan 2002 00:51:01 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15420.1141.905364.108908@alpha-tli.procket.com> To: Tony Przygienda Cc: Les Ginsberg , "'Jeff Learman'" , "Manral, Vishwas" , "'Dave Katz'" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Regarding document for best current practices In-Reply-To: <3C3C0841.6070409@net4u.ch> References: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com> <3C3C0841.6070409@net4u.ch> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 00:51:01 -0800 Content-Transfer-Encoding: 7bit | Modulo Tony Li's opinion, if we see enough cycles of cluefull people | being committed to make an update of RFC1195 happen, that's something | that can be talked about. No disagreement. However, folks should understand that it will still be informational. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 08:30:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03621 for ; Wed, 9 Jan 2002 08:30:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09DQ1154413; Wed, 9 Jan 2002 05:26:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09DPa154401 for ; Wed, 9 Jan 2002 05:25:36 -0800 (PST) (envelope-from rja@inet.org) Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id EC14767103; Wed, 9 Jan 2002 08:40:32 -0500 (EST) Message-Id: <5.1.0.14.2.20020109081156.01dda230@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Les Ginsberg From: RJ Atkinson Subject: RE: [Isis-wg] Regarding document for best current practices Cc: isis-wg@spider.juniper.net In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 09 Jan 2002 08:17:33 -0500 At 14:44 08/01/02, Les Ginsberg wrote: >In my view, what is needed is not a BCP document, but rather a new version >of RFC 1195. This would not need to supplant existing RFCs describing >protocol extensions, but it should at a minimum correct inaccuracies and >obsolete items in 1195, and hopefully go on to define extensions to the >protocol which have become common practice but have never been documented - >and have interoperability issues. This is not necessarily a bad thing. A major question is whether someone with a fair amount of implementation experience would have the time and inclination to edit such a draft together. >It is not a good thing when protocol extensions are made and left purely >to word-of-mouth/reverse engineering style documentation. Quite so; that historical and problematic practice is precisely why this IETF group exists (and why a former O&M AD drove creation of this WG). >I would love to believe that a meaningful liason between IETF/ISO/ITU >regarding IS-IS could be achieved, since that would allow all the interested >communities to participate in the evolution of the protocol - but having >spent a fair amount of effort trying to make that happen, I am not >optimistic. Where did this liaison initiative wedge (in your view) ? Certainly everyone *could* participate here, so such an effort could be undertaken in the IETF provided ITU/ISO didn't object to letting IETF have formal change control. Under ITU-T rules, not everyone could participate equally. I don't know how ISO rules work these days, so am not sure how that factors in. Ran rja@inet.org _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 10:15:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05169 for ; Wed, 9 Jan 2002 10:15:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09FB4154871; Wed, 9 Jan 2002 07:11:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09F5x154839 for ; Wed, 9 Jan 2002 07:05:59 -0800 (PST) (envelope-from jfleming@anet.com) Received: from RepliGate (as1-112.chi.il.dial.anet.com [198.92.156.112]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g09F80Gx015431; Wed, 9 Jan 2002 09:08:01 -0600 (CST) Message-ID: <22e401c19938$197d60b0$0100a8c0@RepliGate> From: "Jim Fleming" To: "Les Ginsberg" , "'Jeff Learman'" , "Manral, Vishwas" Cc: "'Dave Katz'" , "Les Ginsberg" , References: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com> Subject: Re: [Isis-wg] Regarding document for best current practices MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 10:04:34 -0800 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Les Ginsberg" > > It is a good thing that the way this group works tries to be responsive to > real world (AKA customer) requirements. It is not a good thing when protocol > extensions are made and left purely to word-of-mouth/reverse engineering > style documentation. > I doubt that customers will want to read (1970's vintage) nroff ASCII documents. Do you use a 2002 prefix ? http://www.dot-biz.com/INFO/Papers/ Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 11:05:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06149 for ; Wed, 9 Jan 2002 11:05:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09G18155110; Wed, 9 Jan 2002 08:01:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09Fk1155038 for ; Wed, 9 Jan 2002 07:46:01 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 10:48:21 -0500 Message-ID: From: "Manral, Vishwas" To: "'Les Ginsberg'" , "'Jeff Learman'" Cc: "'Dave Katz'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 10:48:26 -0500 Folks, Here are some more things I think "could"(based on what the list feels) be documented too(though they may not necessarily have any interoperability concerns). 1. Some draft obsoleting TLV type 10. (though I know the draft on reserved TLV codepoints calls it illegal, it is supposed to be a database of TLV's, or will this suffice??). This issue seems to have been raised numerous times, by different people. 2. There is talk about System-ID being 6 bytes and MaxAreaAddresses being 3(should this thing be documented too, to avoid confusion(anyway nobody uses any other values), could these be made a constant for IP???) This was raised by Radia, I guess !!! 3. Besides the MaxAge even the ISIS Hello Multiplier is configureable though its described as an architectural constant(that could be documented too, as we do not probably want the MIB to violate the specs) 4. An LSP received with wrong checksum should be dropped, instead of trying to purge it.(this was listed in one of Dave's mail). Wouldn't it be good to document this too? The MIB does talk about an object isisSysLSPIgnoreErrors but that seems to be slightly different(or is it the same?). Thanks, Vishwas -----Original Message----- From: Les Ginsberg [mailto:ginsberg@pluris.com] Sent: Wednesday, January 09, 2002 1:14 AM To: 'Jeff Learman'; Manral, Vishwas Cc: 'Dave Katz'; Les Ginsberg; isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices In the work plan in ISO SC6/WG7 which produced the revised 10589:2001 spec, there was a Phase 2 specified which was aimed at producing a document which covered changes to the protocol introduced in the IP world. The exact form this was to take was never agreed upon, the idea was floated on this list (by me) with a rather tepid response. As the 10589 revision work progressed, it became clear to me that ISO was the wrong place for this Phase 2 work to take place - if it was going to take place at all it needed to be driven by the community which was driving the evolution of the protocol. In my view, what is needed is not a BCP document, but rather a new version of RFC 1195. This would not need to supplant existing RFCs describing protocol extensions, but it should at a minimum correct inaccuracies and obsolete items in 1195, and hopefully go on to define extensions to the protocol which have become common practice but have never been documented - and have interoperability issues. The MAXAGE issue is a minor example - as Mike Shand's keen eye has demonstrated - a strictly conformant implementation based on 10589 would reject LSPs with a lifetime > 1200. The fact that no one seems to do this does not diminish the need for having a document that clearly states this. It is a good thing that the way this group works tries to be responsive to real world (AKA customer) requirements. It is not a good thing when protocol extensions are made and left purely to word-of-mouth/reverse engineering style documentation. Given the extension of ISIS for IP into the formerly OSI only world of SONET, the need for formalizing protocol extensions becomes even greater - else we will end up with multiple/non-interoperable solutions. I would love to believe that a meaningful liason between IETF/ISO/ITU regarding IS-IS could be achieved, since that would allow all the interested communities to participate in the evolution of the protocol - but having spent a fair amount of effort trying to make that happen, I am not optimistic. (No disrespect to a number of interested parties who were supportive along the way). Jeff Learman's comments below are pretty much on the mark - but if there is sufficient interest in addressing things, I will be a willing participant. Les > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Tuesday, January 08, 2002 8:49 AM > To: Manral, Vishwas > Cc: 'Dave Katz'; ginsberg@pluris.com; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Regarding document for best current practices > > > > Vishwas, > > You repeated your request for a new document on IS-IS, either a > compendium of best practices or a new spec that describes Integrated > IS-IS. One response I saw was that there weren't many discrepancies > between spec and practice, and that most "best practices" were matters > of implementation, not specification. > > I suspect that there are things that would be good to > document, and perhaps > padding of IIHs is one. If you were to go over the list of > potential issues > and present it, it might generate some interest. I doubt > that this is work > that anyone is eager to take on out of public interest, but if you are > willing to drive the work, I'm sure you would get lots of feedback ;-) > > Concerning creating a new spec that combines ISO 10589 and RFC-1195, > this sure would be nice for those trying to learn integrated IS-IS > and newcomers to the field. However, there are significant issues: > > 1. It would be a lot of hard work. > > 2. Any new wording of these specs would create new > ambiguity problems. > Which spec would be the definitive one? Would the new > document be > definitive or just descriptive? > > 3. There would be a temptation to "fix" things, which > would be a disaster. > If there is any new text, it should start out with the > intention of > being identical in meaning to the previous specs. > Unfortunately, > this would make it less helpful and clear for the IP-only crowd. > But at least, it could be used as a starting point, so that any > changes could be written against it, and therefore anyone could > tell what changed between two subsequent versions. > > All of these issues could be worked through, if there is > enough commitment > among all players. But I doubt that we will find this kind > of commitment, > and I question whether the result would justify the amount of work and > haggling that would be required. > > Alternatively, someone could write a good book on implementing IS-IS. > They'd probably sell upwards of 50 copies ;-) > > Regards, > Jeff > > Disclaimer: This is my opinion. I do not represent Cisco in this > forum and I have never worked on IS-IS at Cisco. > > At 10:34 AM 1/2/2002, Manral, Vishwas wrote: > >Dave, > > > >Changed the subject line to actually reflect the contents of > the discussion. > > > >No matter how small the difference, don't you think it would > be good to > >document it somewhere(may be, "not all that sticky" issues, could be > >documented too)? > > > >To think of it, wouldn't it be nice, if we could actually have an > >informational document(all ISIS work in IETF is > informational anyway, I > >guess) which could talk about ISIS for IP specifically. This > could talk > >about the entire protocol(instead of a delta with the ISO spec as in > >RFC1195) and could incorporate the best current practices. > > > >Would there be any interest in the group for this kind of a > document? I > >personally feel it would be a good idea, and would help in easier > >understanding and better implementation of ISIS(atleast for > those who are > >not all that well versed). I have no idea of the IETF/ISO > laison though.(I > >tried to check if this thing had been raised before in the > mailing list > >couldn't find it) > > > >Thanks, > >Vishwas > > > > > >--------------------------------------------------------------------- > >I think the number of things that are done in practical conflict with > >the spec is vanishingly small, where "practical conflict" is > >interpreted as "a reasonable implementation would notice." > >Excessively pedantic boxes have a way of fixing themselves one way or > >another. > > > >Most of these things are pretty obvious to anyone reasonably > versed in > >the art, though the potentially sticky ones (like not bothering with > >ISHs) should probably be documented. > > > >--Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 9 11:40:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06928 for ; Wed, 9 Jan 2002 11:40:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09GVB155259; Wed, 9 Jan 2002 08:31:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from tcb.net (tcb.net [205.168.100.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09GGM155185 for ; Wed, 9 Jan 2002 08:16:22 -0800 (PST) (envelope-from danny@dog.tcb.net) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g09H9Oh04262 for ; Wed, 9 Jan 2002 10:09:25 -0700 Message-Id: <200201091709.g09H9Oh04262@tcb.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: isis-wg@spider.juniper.net From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] Regarding document for best current practices Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 09 Jan 2002 10:09:24 -0700 > 4. An LSP received with wrong checksum should be dropped, instead of trying > to purge it.(this was listed in one of Dave's mail). Wouldn't it be good to > document this too? The MIB does talk about an object isisSysLSPIgnoreErrors > but that seems to be slightly different(or is it the same?). It's the same... -danny _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:24:45 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02172 for ; Thu, 10 Jan 2002 01:24:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6KB158827; Wed, 9 Jan 2002 22:20:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09Gjc155334 for ; Wed, 9 Jan 2002 08:45:38 -0800 (PST) (envelope-from mbartell@cisco.com) Received: from MBARTELL-W2K.cisco.com (mbartell-w2k.cisco.com [64.101.135.164]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA26184; Wed, 9 Jan 2002 08:47:25 -0800 (PST) Message-Id: <4.3.2.7.2.20020109103050.017bc9d0@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: RJ Atkinson From: Micah Bartell Subject: RE: [Isis-wg] Regarding document for best current practices Cc: Les Ginsberg , isis-wg@spider.juniper.net In-Reply-To: <5.1.0.14.2.20020109081156.01dda230@10.30.15.3> References: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 09 Jan 2002 10:47:24 -0600 > > Where did this liaison initiative wedge (in your view) ? The interest in the ISO is virtually non-existent. The 2001:10589 draft probably saw actual review by 3-4 people within the ISO. I think almost everyone who was involved is already involved with this WG. > Certainly everyone *could* participate here, so such an effort >could be undertaken in the IETF provided ITU/ISO didn't object to letting >IETF have formal change control. Under ITU-T rules, not everyone could >participate equally. I don't know how ISO rules work these days, so am >not sure how that factors in. With IS-IS being protocol neutral, would it be possible to write up an informational RFC which contains the protocol framework, but not the CLNS specific details? Implementations going forward would either conform to ISO/IEC 10589 or RFC XXXX (or both). At that point, 1195 can be redrafted if it is felt there is a need as more of a TLV definition document. I just do not know about the politics involved with this. I can look into this with the SC6 Secratariat if there is sufficient interest. ISO/IEC 10589 is copyrighted...so it may be as simple as formal permission for the IETF to make use of the content in 10589, which could be put to a vote. /mpb >Ran >rja@inet.org > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:28:09 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02214 for ; Thu, 10 Jan 2002 01:28:09 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6OG158858; Wed, 9 Jan 2002 22:24:16 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09GlO155345 for ; Wed, 9 Jan 2002 08:47:24 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'danny@tcb.net'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 11:49:24 -0500 > > 4. An LSP received with wrong checksum should be dropped, > ... The MIB does talk about an object isisSysLSPIgnoreErrors > > It's the same... > > -danny Danny - Thanks: I missed that reference. Vishwas - There was a recent discussion of this, and I have removed the object from the MIB. Since no one should do what the spec suggested, it is asking for trouble to suggest that it is an option. I think the ISO group is aware of this and fixing the update. Perhaps it is time to publish the current version of the MIB: I have only been tweaking it in the last week or two. -- Removed isisSysLSPIgnoreErrors: LSPs with errors should -- always be ignored - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:30:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02266 for ; Thu, 10 Jan 2002 01:30:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6Q5158899; Wed, 9 Jan 2002 22:26:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09HKO155506 for ; Wed, 9 Jan 2002 09:20:24 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 12:22:45 -0500 Message-ID: From: "Manral, Vishwas" To: "'danny@tcb.net'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 12:22:52 -0500 Danny, If the object isisSysLSPIgnoreErrors OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, allow the router to ignore IS-IS link state packets (LSPs) that are received with internal checksum errors rather than purging the LSPs." DEFVAL { false } ::= { isisSysEntry 27 } is supposed to do the same as the mail http://people.juniper.net/pipermail/isis-wg/1999/000084.html seems to suggest. Then may be the wording instead should be "drop" instead of "ignore". I have suggested Jeff P. the same in a private mail. Shouldn't this be specifed in another draft anyway(as MIB's are not supposed to violate specs)? Thanks, Vishwas -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: Wednesday, January 09, 2002 10:39 PM To: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Regarding document for best current practices > 4. An LSP received with wrong checksum should be dropped, instead of trying > to purge it.(this was listed in one of Dave's mail). Wouldn't it be good to > document this too? The MIB does talk about an object isisSysLSPIgnoreErrors > but that seems to be slightly different(or is it the same?). It's the same... -danny _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:31:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02306 for ; Thu, 10 Jan 2002 01:31:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6Rp158940; Wed, 9 Jan 2002 22:27:51 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09Kgw156364 for ; Wed, 9 Jan 2002 12:42:58 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA07788; Wed, 9 Jan 2002 12:45:12 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 12:45:12 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F6F0@avalon.pluris.com> From: Les Ginsberg To: "'danny@tcb.net'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 12:45:03 -0800 The perils of purging an LSP received w checksum error were identified in Defect Report 1 (ISO/IEC JTC1/SC6/WG2/N523) which was written in April 1993. Item #15 of this DR specified that the spec should be changed to indicate the the corrupt LSP should be discarded, not purged. The DR was approved by ISO. Unfortunately, due to some confusion created by an earlier version of this DR which omitted Items 14-16, this spec change never got published. The 2001 revision of ISO 10589 has incorporated this change. Section 7.3.14.2e now reads: "An Intermediate system receiving a Link State PDU with an incorrect LSP Checksum or with an invalid PDU syntax shall 1) generate a corruptedLSPReceived circuit event, 2) discard the PDU." The point of all this is that a conformant implementation should always discard an LSP with wrong checksum and that a knob is unnecessary. This was discussed earlier and Jeff Parker has agreed to drop the item from the MIB entirely. Les > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net] > Sent: Wednesday, January 09, 2002 9:09 AM > To: isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Regarding document for best current practices > > > > > 4. An LSP received with wrong checksum should be dropped, > instead of trying > > to purge it.(this was listed in one of Dave's mail). > Wouldn't it be good to > > document this too? The MIB does talk about an object > isisSysLSPIgnoreErrors > > but that seems to be slightly different(or is it the same?). > > It's the same... > > -danny > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:33:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02351 for ; Thu, 10 Jan 2002 01:33:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6U1158984; Wed, 9 Jan 2002 22:30:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09LFS156510 for ; Wed, 9 Jan 2002 13:15:28 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA13752; Wed, 9 Jan 2002 13:16:25 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 13:16:25 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F6F2@avalon.pluris.com> From: Les Ginsberg To: "'Tony Li'" , Tony Przygienda Cc: Les Ginsberg , "'Jeff Learman'" , "Manral, Vishwas" , "'Dave Katz'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 13:16:15 -0800 > > > | Modulo Tony Li's opinion, if we see enough cycles of > cluefull people > | being committed to make an update of RFC1195 happen, > that's something > | that can be talked about. > > > No disagreement. However, folks should understand that it > will still be > informational. > > Tony > But isn't that precisely the problem? Significant revisions to the protocol have been and are being made via this work group. At the same time, and even more so these days because of the introduction of IP to the SONET world, the ISO/ITU community is also making revisions. But in terms of specifications, there is no real attempt to integrate. So we end up with confusion - and what is even worse - interoperability issues. The fact that things have worked as well as they have thus far is principally because: a)Since 1992 the ISO world has made only minor revisions/corrections to the protocol b)Many of the folks who developed the 1992 spec have remained involved in this WG and have kept the IP world mindful of interoperability issues But that is changing. The work going on within the ITU on revising the rules for supporting multiple protocols (IP and CLNP in their case) will have significant impact on the protocol - and relates closely to IPV4/IPV6 issues in the IP only world. It is definitely true that interest in the ISO world per se is virtually nil. As Micah has pointed out those people within ISO who took the time to comment on the 2001 draft were, with one exception, participants in this WG as well. So it would be foolish to believe that ISO will somehow manage to produce a document that incorporates the changes from the IP world. (For that matter, I wonder how the ITU folks expect their changes to be reflected in the ISO spec.) I know that considerable politics is (unfortunately) involved here - perhaps it is simply unworkable - but believing in possibilities is still a good thing. Les _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:35:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02377 for ; Thu, 10 Jan 2002 01:35:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6Vn159003; Wed, 9 Jan 2002 22:31:49 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09LjP156638 for ; Wed, 9 Jan 2002 13:45:26 -0800 (PST) (envelope-from tli@Procket.com) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g09LjcHb014915; Wed, 9 Jan 2002 13:45:38 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g09Ljbtu022787; Wed, 9 Jan 2002 13:45:37 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15420.47617.491740.857857@alpha-tli.procket.com> To: Les Ginsberg Cc: "'Tony Li'" , Tony Przygienda , "'Jeff Learman'" , "Manral, Vishwas" , "'Dave Katz'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F6F2@avalon.pluris.com> References: <17C81AD1F1FED411991E006008F6D1CA01B3F6F2@avalon.pluris.com> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 13:45:37 -0800 Content-Transfer-Encoding: 7bit | But isn't that precisely the problem? If you have a magic wand, Les, don't keep it to yourself. Until and unless ISO freely gives us control of the spec, they own it. Period. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:37:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02433 for ; Thu, 10 Jan 2002 01:37:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6Xb159037; Wed, 9 Jan 2002 22:33:37 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A0CA157268 for ; Wed, 9 Jan 2002 16:12:10 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0A0EW279759 for ; Wed, 9 Jan 2002 16:14:33 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 9 Jan 2002 16:07:26 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g0A07VF24414 for ; Wed, 9 Jan 2002 16:07:32 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id QAA14153 for ; Wed, 9 Jan 2002 16:07:31 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id QAA28536 for ; Wed, 9 Jan 2002 16:14:01 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfQAA28532 for <>; Wed Jan 9 16:13:55 2002 Received: from ems11 by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g0A03Nv27086 for ; Wed, 9 Jan 2002 16:03:23 -0800 (PST) Received: by localhost with Microsoft MAPI; Wed, 9 Jan 2002 13:12:37 -0800 Message-ID: <01C1990F.4F5F7660.ramsrm@tdd.sj.nec.com> From: ramanathan ramasamy Reply-To: "ramsrm@tdd.sj.nec.com" To: "'isis-wg@juniper.net'" X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 13 TEXT X-OriginalArrivalTime: 10 Jan 2002 00:07:26.0702 (UTC) FILETIME=[C95D90E0:01C1996A] Subject: [Isis-wg] psuedonode LSP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 13:12:36 -0800 Hi all, I have the following doubt in ISIS for IP. * In Pseudonode LSP, according to RFC 1195 sec 4.3, we won't be listing any IP reachability field( because of logical subnetting probelem). Then what is the purpose of retaining Psuedonode LSP concept in ISIS for IP. What will it contain? What is it used for? - is it there to maintain compatability in case of Integrated ISIS? Thanks rams. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:39:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02472 for ; Thu, 10 Jan 2002 01:39:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6ZP159064; Wed, 9 Jan 2002 22:35:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail4.nec.com (dns4.nec.com [131.241.15.4]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A0FG157286 for ; Wed, 9 Jan 2002 16:15:16 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g0A0HWF24953 for ; Wed, 9 Jan 2002 16:17:32 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id QAA15401 for ; Wed, 9 Jan 2002 16:17:30 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id QAA28553 for ; Wed, 9 Jan 2002 16:24:01 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfQAA28546 for <>; Wed Jan 9 16:23:20 2002 Received: from ems11 by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g0A0Cnv27164 for ; Wed, 9 Jan 2002 16:12:49 -0800 (PST) Received: by localhost with Microsoft MAPI; Wed, 9 Jan 2002 13:22:03 -0800 Message-ID: <01C19910.A0502D20.ramsrm@tdd.sj.nec.com> From: ramanathan ramasamy Reply-To: "ramsrm@tdd.sj.nec.com" To: "'isis-wg@spider.juniper.net'" X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 0 TEXT Subject: [Isis-wg] test mail Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 13:22:01 -0800 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:51:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02578 for ; Thu, 10 Jan 2002 01:51:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6l0159207; Wed, 9 Jan 2002 22:47:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6kQ159185 for ; Wed, 9 Jan 2002 22:46:26 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 01:48:50 -0500 Message-ID: From: "Manral, Vishwas" To: "'Jeff Parker'" , "'danny@tcb.net'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 01:48:54 -0500 Jeff, Instead of the word ignore, the word "discarded" or "dropped" should be used(whereever it is supposed to be). ;-) -Vishwas -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Wednesday, January 09, 2002 10:19 PM To: 'danny@tcb.net'; isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices > > 4. An LSP received with wrong checksum should be dropped, > ... The MIB does talk about an object isisSysLSPIgnoreErrors > > It's the same... > > -danny Danny - Thanks: I missed that reference. Vishwas - There was a recent discussion of this, and I have removed the object from the MIB. Since no one should do what the spec suggested, it is asking for trouble to suggest that it is an option. I think the ISO group is aware of this and fixing the update. Perhaps it is time to publish the current version of the MIB: I have only been tweaking it in the last week or two. -- Removed isisSysLSPIgnoreErrors: LSPs with errors should -- always be ignored - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 01:57:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02623 for ; Thu, 10 Jan 2002 01:56:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6r0159254; Wed, 9 Jan 2002 22:53:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A6q5159242 for ; Wed, 9 Jan 2002 22:52:05 -0800 (PST) (envelope-from tli@Procket.com) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0A6sLHb021449; Wed, 9 Jan 2002 22:54:21 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0A6sLlF023618; Wed, 9 Jan 2002 22:54:21 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15421.15005.581065.981995@alpha-tli.procket.com> To: Micah Bartell Cc: RJ Atkinson , Les Ginsberg , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices In-Reply-To: <4.3.2.7.2.20020109103050.017bc9d0@cactus.cisco.com> References: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com > <4.3.2.7.2.20020109103050.017bc9d0@cactus.cisco.com> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 22:54:21 -0800 Content-Transfer-Encoding: 7bit | With IS-IS being protocol neutral, would it be possible to write up an | informational RFC which contains the protocol framework, but not the CLNS | specific details? Implementations going forward would either conform to | ISO/IEC 10589 or RFC XXXX (or both). While that's certainly possible, I would be very concerned about the long term implications. The danger of the two versions diverging would be huge. [Example: ISO picks up and processes a defect report and issues a revised draft... but no one remembers to fix the IETF version.] | I just do not know about the politics involved with this. I can look into | this with the SC6 Secratariat if there is sufficient interest. ISO/IEC | 10589 is copyrighted...so it may be as simple as formal permission for the | IETF to make use of the content in 10589, which could be put to a vote. We would welcome any way to move forward out of this quagmire. Let me offer a germ of an idea: As has been pointed out, there is a great deal of overlap between the actual folks doing the work in both organizations. No matter where we host it, it's the same folks, doing the same thing. Why then, does it really matter, where the group is hosted? Why not have just one joint, integrated working group, which reports to two bodies? This way, the group has the clear authority to issue definitive documents. These documents get published as BOTH ISO standards and RFCs. I realize that this is probably unprecedented on both sides of the fence, but it seems only logical to construct a pseudonode adjacency here. ;-) Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 02:10:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10971 for ; Thu, 10 Jan 2002 02:10:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A761159351; Wed, 9 Jan 2002 23:06:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A75M159339 for ; Wed, 9 Jan 2002 23:05:22 -0800 (PST) (envelope-from selvarajr@future.futsoft.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0A77l285017 for ; Wed, 9 Jan 2002 23:07:47 -0800 (PST) X-JNPR-Received-From: outside Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 9 Jan 2002 23:06:38 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 10 Jan 2002 12:51:15 +0530 Received: from selvarajr (selvarajr.future.futsoft.com [10.4.6.32]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g0A76GR03281; Thu, 10 Jan 2002 12:36:16 +0530 Reply-To: From: "SelvarajR" To: , Subject: RE: [Isis-wg] psuedonode LSP Message-Id: <000701c199a6$d268f800$2006040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <01C1990F.4F5F7660.ramsrm@tdd.sj.nec.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2002 07:06:38.0655 (UTC) FILETIME=[591904F0:01C199A5] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 12:47:10 +0530 Content-Transfer-Encoding: 7bit Pseudonode LSPs are generated on behalf of DR. Each DR will generate its own unique Pseudonode LSPs. It will only contain the neighbor TLV with all the neighbors of the broadcast circuit for which it is the DR. One of its usage is Two-way check. Pseudonode LSP wont contain IP reachability Info. Because its Non-Pseudonode LSP will contain those information. So to avoid redundant information and decrease LSP size it is not included in Pseudonode LSP. Selva. -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of ramanathan ramasamy Sent: Thursday, 10 January 2002 2:43 AM To: 'isis-wg@juniper.net' Subject: [Isis-wg] psuedonode LSP Hi all, I have the following doubt in ISIS for IP. * In Pseudonode LSP, according to RFC 1195 sec 4.3, we won't be listing any IP reachability field( because of logical subnetting probelem). Then what is the purpose of retaining Psuedonode LSP concept in ISIS for IP. What will it contain? What is it used for? - is it there to maintain compatability in case of Integrated ISIS? Thanks rams. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 02:29:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11147 for ; Thu, 10 Jan 2002 02:29:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A7P1159457; Wed, 9 Jan 2002 23:25:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0A7OL159442 for ; Wed, 9 Jan 2002 23:24:21 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0A7Qe669294; Wed, 9 Jan 2002 23:26:40 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0A7Pfj86013; Wed, 9 Jan 2002 23:25:41 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201100725.g0A7Pfj86013@cirrus.juniper.net> From: Dave Katz To: selvarajr@future.futsoft.com CC: ramsrm@tdd.sj.nec.com, isis-wg@juniper.net In-reply-to: <000701c199a6$d268f800$2006040a@future.futsoft.com> (selvarajr@future.futsoft.com) Subject: Re: [Isis-wg] psuedonode LSP References: <000701c199a6$d268f800$2006040a@future.futsoft.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 23:25:41 -0800 (PST) To answer the original question, the pseudonode concept is still useful because it eliminates the N^2 topology problem, which is protocol-independent. X-JNPR-Received-From: outside Reply-To: From: "SelvarajR" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 10 Jan 2002 07:06:38.0655 (UTC) FILETIME=[591904F0:01C199A5] Sender: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 12:47:10 +0530 Pseudonode LSPs are generated on behalf of DR. Each DR will generate its own unique Pseudonode LSPs. It will only contain the neighbor TLV with all the neighbors of the broadcast circuit for which it is the DR. One of its usage is Two-way check. Pseudonode LSP wont contain IP reachability Info. Because its Non-Pseudonode LSP will contain those information. So to avoid redundant information and decrease LSP size it is not included in Pseudonode LSP. Selva. -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of ramanathan ramasamy Sent: Thursday, 10 January 2002 2:43 AM To: 'isis-wg@juniper.net' Subject: [Isis-wg] psuedonode LSP Hi all, I have the following doubt in ISIS for IP. * In Pseudonode LSP, according to RFC 1195 sec 4.3, we won't be listing any IP reachability field( because of logical subnetting probelem). Then what is the purpose of retaining Psuedonode LSP concept in ISIS for IP. What will it contain? What is it used for? - is it there to maintain compatability in case of Integrated ISIS? Thanks rams. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 08:18:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13992 for ; Thu, 10 Jan 2002 08:18:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ADE5161474; Thu, 10 Jan 2002 05:14:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AD8x161440 for ; Thu, 10 Jan 2002 05:08:59 -0800 (PST) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 08:11:25 -0500 Message-ID: From: "Manral, Vishwas" To: "'Les Ginsberg'" , "'Tony Li'" , Tony Przygienda , "'jparker@axiowave.com'" Cc: "'Jeff Learman'" , "'Dave Katz'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 08:11:13 -0500 Folks, With the use of domain-wide prefix distribution(especially L2->L1), do we necessarily need to set the Attach bit in LSP's of "ATTACHED" routers. Shouldn't that be allowed a configureable option now? Also should the rule that default routes are not permitted in Level 1 areas still be there. It could happen that a router connected to another domain(ASBR), want to send default routes in L1 areas, however default routes should be less preffered over routes to someone who originates LSP's with Attached bit. (I assume we did not allow defaults was because defaults were used for routing to nearest L2 router, right?) Thanks, Vishwas -----Original Message----- From: Les Ginsberg [mailto:ginsberg@pluris.com] Sent: Thursday, January 10, 2002 2:46 AM To: 'Tony Li'; Tony Przygienda Cc: Les Ginsberg; 'Jeff Learman'; Manral, Vishwas; 'Dave Katz'; isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Regarding document for best current practices > > > | Modulo Tony Li's opinion, if we see enough cycles of > cluefull people > | being committed to make an update of RFC1195 happen, > that's something > | that can be talked about. > > > No disagreement. However, folks should understand that it > will still be > informational. > > Tony > But isn't that precisely the problem? Significant revisions to the protocol have been and are being made via this work group. At the same time, and even more so these days because of the introduction of IP to the SONET world, the ISO/ITU community is also making revisions. But in terms of specifications, there is no real attempt to integrate. So we end up with confusion - and what is even worse - interoperability issues. The fact that things have worked as well as they have thus far is principally because: a)Since 1992 the ISO world has made only minor revisions/corrections to the protocol b)Many of the folks who developed the 1992 spec have remained involved in this WG and have kept the IP world mindful of interoperability issues But that is changing. The work going on within the ITU on revising the rules for supporting multiple protocols (IP and CLNP in their case) will have significant impact on the protocol - and relates closely to IPV4/IPV6 issues in the IP only world. It is definitely true that interest in the ISO world per se is virtually nil. As Micah has pointed out those people within ISO who took the time to comment on the 2001 draft were, with one exception, participants in this WG as well. So it would be foolish to believe that ISO will somehow manage to produce a document that incorporates the changes from the IP world. (For that matter, I wonder how the ITU folks expect their changes to be reflected in the ISO spec.) I know that considerable politics is (unfortunately) involved here - perhaps it is simply unworkable - but believing in possibilities is still a good thing. Les _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 10:12:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15994 for ; Thu, 10 Jan 2002 10:12:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AF87161992; Thu, 10 Jan 2002 07:08:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AEvx161936 for ; Thu, 10 Jan 2002 06:57:59 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0AF0Q293501; Thu, 10 Jan 2002 07:00:26 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 06:28:37 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0AESxH15954; Thu, 10 Jan 2002 09:28:59 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK60704; Thu, 10 Jan 2002 09:28:46 -0500 (EST) Message-Id: <4.3.2.7.2.20020110092615.03c91c78@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Dave Katz From: Jeff Learman Subject: Re: [Isis-wg] psuedonode LSP Cc: selvarajr@future.futsoft.com, ramsrm@tdd.sj.nec.com, isis-wg@juniper.net In-Reply-To: <200201100725.g0A7Pfj86013@cirrus.juniper.net> References: <000701c199a6$d268f800$2006040a@future.futsoft.com> <000701c199a6$d268f800$2006040a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 10 Jan 2002 14:28:37.0296 (UTC) FILETIME=[17708300:01C199E3] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 09:28:37 -0500 Dave is correct, of course. To amplify a little, a pseudonode LSP is generated by the DR on behalf of the LAN, making the LAN appear to be a router that has a point-to-point link with every IS on the LAN. So, instead of each of N routers on the LAN reporting N-1 links, we have N routers reporting 1 link and 1 imaginary router reporting N links. Jeff At 02:25 AM 1/10/2002, Dave Katz wrote: >To answer the original question, the pseudonode concept is still >useful because it eliminates the N^2 topology problem, which is >protocol-independent. > > X-JNPR-Received-From: outside > Reply-To: > From: "SelvarajR" > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 > Importance: Normal > Content-Type: text/plain; > charset="iso-8859-1" > X-OriginalArrivalTime: 10 Jan 2002 07:06:38.0655 (UTC) FILETIME=[591904F0:01C199A5] > Sender: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Thu, 10 Jan 2002 12:47:10 +0530 > > Pseudonode LSPs are generated on behalf of DR. Each DR will generate its own > unique Pseudonode LSPs. It will only contain the neighbor TLV with all the > neighbors of the broadcast circuit for which it is the DR. One of its usage > is Two-way check. > Pseudonode LSP wont contain IP reachability Info. Because its Non-Pseudonode > LSP will contain those information. So to avoid redundant information and > decrease LSP size it is not included in Pseudonode LSP. > > Selva. > > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of ramanathan > ramasamy > Sent: Thursday, 10 January 2002 2:43 AM > To: 'isis-wg@juniper.net' > Subject: [Isis-wg] psuedonode LSP > > > Hi all, > > I have the following doubt in ISIS for IP. > > * In Pseudonode LSP, according to RFC 1195 sec 4.3, we won't be listing > any IP reachability field( because of logical subnetting probelem). > Then what is the purpose of retaining Psuedonode LSP concept in ISIS > for IP. What will it contain? What is it used for? - is it there to > maintain compatability in case of Integrated ISIS? > > > Thanks > rams. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 13:08:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20474 for ; Thu, 10 Jan 2002 13:08:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AI3B162785; Thu, 10 Jan 2002 10:03:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AHmG162713 for ; Thu, 10 Jan 2002 09:48:16 -0800 (PST) (envelope-from john_hurley@agilent.com) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 229702C5E for ; Thu, 10 Jan 2002 10:50:43 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id CA30525B for ; Thu, 10 Jan 2002 10:50:42 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 10 Jan 2002 10:50:42 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 10:50:42 -0700 Message-ID: <0D9185CE635BD511ACA50090277A6FCF2A55DD@axcs18.cos.agilent.com> From: "HURLEY,JOHN (A-Portsmouth,ex1)" To: "'isis-wg@external.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Establishing Router Adjacencies Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 10:50:40 -0700 Section 4.4 of RFC 1195 it talks about maintaining router adjacencies. The first line states that these adjacencies are independent of the IP interface addresses of the routers. Does this mean that if an IS sends an IIH to another IS on the same physical LAN a) without an IP Interface Address TLV or b) with an IP Interface Address TLV that doesn't have a logical subnet in common with the other IS the ISs should establish adjacencies with each other. thanks, John _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 17:24:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25079 for ; Thu, 10 Jan 2002 17:24:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AMJT163916; Thu, 10 Jan 2002 14:19:29 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AIDo162836 for ; Thu, 10 Jan 2002 10:13:50 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 7342 invoked from network); 10 Jan 2002 18:16:16 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Jan 2002 18:16:16 -0000 From: "Ken Larmer" To: "'isis-wg@external.juniper.net'" , "HURLEY,JOHN \(A-Portsmouth,ex1\)" Cc: "Ken Larmer" Subject: RE: [Isis-wg] Establishing Router Adjacencies Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <0D9185CE635BD511ACA50090277A6FCF2A55DD@axcs18.cos.agilent.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 13:21:08 -0500 Content-Transfer-Encoding: 7bit Hi John, > Section 4.4 of RFC 1195 it talks about maintaining router adjacencies. > The first line states that these adjacencies are independent of the IP > interface > addresses of the routers. > > Does this mean that if an IS sends an IIH to another IS on the > same physical > LAN > a) without an IP Interface Address TLV > or > b) with an IP Interface Address TLV that doesn't have a logical > subnet in > common with the other IS > the ISs should establish adjacencies with each other. In accordance with RFC-1195 the answer to the above is yes! However, reality being what it is, I have only seen 1 implementation that actually works in this maner! Most implementations do require a common subnet prior to forming an adjacency. Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 17:31:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25195 for ; Thu, 10 Jan 2002 17:31:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AMRE163992; Thu, 10 Jan 2002 14:27:14 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AJmJ163267 for ; Thu, 10 Jan 2002 11:48:19 -0800 (PST) (envelope-from donkiha@yahoo.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g0AJolG88510 for ; Thu, 10 Jan 2002 11:50:47 -0800 (PST) X-JNPR-Received-From: outside Received: from web14902.mail.yahoo.com ([216.136.225.54]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 11:50:34 -0800 Message-ID: <20020110194835.15006.qmail@web14902.mail.yahoo.com> Received: from [12.104.224.46] by web14902.mail.yahoo.com via HTTP; Thu, 10 Jan 2002 11:48:35 PST From: Dong Ha To: isis-wg@juniper.net In-Reply-To: <000701c199a6$d268f800$2006040a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 10 Jan 2002 19:50:34.0171 (UTC) FILETIME=[1131B8B0:01C19A10] Subject: [Isis-wg] regeneration of pseudonode LSP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 11:48:35 -0800 (PST) Hello all, could anyone tell me in what case the router will regenerate a pseudonode LSP? ISO 10589 section 7.3.6 seems like specifying only the events for generating non-pseudonode LSP. I'm wondering if the operation of the network is normal, what would cause the router to regenerate a pseudonode LSP? Thanks. -dong __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 17:34:45 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25251 for ; Thu, 10 Jan 2002 17:34:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AMUN164028; Thu, 10 Jan 2002 14:30:23 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail4.nec.com (dns4.nec.com [131.241.15.4]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AM0K163830 for ; Thu, 10 Jan 2002 14:00:20 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g0AM2fF22223 for ; Thu, 10 Jan 2002 14:02:41 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id OAA16026 for ; Thu, 10 Jan 2002 14:02:39 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id OAA01483 for ; Thu, 10 Jan 2002 14:09:14 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfOAA01478 for <>; Thu Jan 10 14:07:44 2002 Received: from ems11 by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g0ALv8v07072 for ; Thu, 10 Jan 2002 13:57:08 -0800 (PST) Received: by localhost with Microsoft MAPI; Thu, 10 Jan 2002 11:06:23 -0800 Message-ID: <01C199C6.D75A05A0.ramsrm@tdd.sj.nec.com> From: ramanathan ramasamy Reply-To: "ramsrm@tdd.sj.nec.com" To: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] psuedonode LSP X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 133 TEXT Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 11:06:22 -0800 Hi all, Thanks for the response. Let me clarify my question again. I agree that in any general routing protocol, like ISIS for OSI, OSPF, the concept of pseudonode LSP exists to remove the N^2 topology problem as Mr Dave said. But My question is that in case of ISIS for IP alone, each router on the LAN is going to list all the subnets which are directly reachable in each of its interfaces. In ordinary terms all the ordinary routers lists all the reachable interfaces in their LSPs. ( They r not just listing their interface to the LAN alone) So In the pseudonode LSP for ISIS for IP, according to RFC we are not listing any IP reachability field. So pseudonode LSP is not going to solve the N^2 problem, because each ordinary routers itself lists what r the subnets it can reach. So what is the purpose of still retaining pseudonode LSP concept in ISIS for IP? For Selvaraj, Why do we need to have two way check in LAN? I think two way check is needed only in point to point link cases. And how come psuedonode LSP is useful for two way check?. psuedonode is a virtual concept right? so do we need to have two way check between ordinary routers and virtual psuedonodes in the LAN? I think in ISIS or any other routing protocol, pseudonode concept is brought in to remove the N^2 topology problem only not for any other purpose? Thanks rams. -----Original Message----- From: Jeff Learman [SMTP:jlearman@cisco.com] Sent: Thursday, January 10, 2002 6:29 AM To: Dave Katz Cc: selvarajr@future.futsoft.com; ramsrm@tdd.sj.nec.com; isis-wg@juniper.net Subject: Re: [Isis-wg] psuedonode LSP Dave is correct, of course. To amplify a little, a pseudonode LSP is generated by the DR on behalf of the LAN, making the LAN appear to be a router that has a point-to-point link with every IS on the LAN. So, instead of each of N routers on the LAN reporting N-1 links, we have N routers reporting 1 link and 1 imaginary router reporting N links. Jeff At 02:25 AM 1/10/2002, Dave Katz wrote: >To answer the original question, the pseudonode concept is still >useful because it eliminates the N^2 topology problem, which is >protocol-independent. > > X-JNPR-Received-From: outside > Reply-To: > From: "SelvarajR" > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 > Importance: Normal > Content-Type: text/plain; > charset="iso-8859-1" > X-OriginalArrivalTime: 10 Jan 2002 07:06:38.0655 (UTC) FILETIME=[591904F0:01C199A5] > Sender: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Thu, 10 Jan 2002 12:47:10 +0530 > > Pseudonode LSPs are generated on behalf of DR. Each DR will generate its own > unique Pseudonode LSPs. It will only contain the neighbor TLV with all the > neighbors of the broadcast circuit for which it is the DR. One of its usage > is Two-way check. > Pseudonode LSP wont contain IP reachability Info. Because its Non-Pseudonode > LSP will contain those information. So to avoid redundant information and > decrease LSP size it is not included in Pseudonode LSP. > > Selva. > > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of ramanathan > ramasamy > Sent: Thursday, 10 January 2002 2:43 AM > To: 'isis-wg@juniper.net' > Subject: [Isis-wg] psuedonode LSP > > > Hi all, > > I have the following doubt in ISIS for IP. > > * In Pseudonode LSP, according to RFC 1195 sec 4.3, we won't be listing > any IP reachability field( because of logical subnetting probelem). > Then what is the purpose of retaining Psuedonode LSP concept in ISIS > for IP. What will it contain? What is it used for? - is it there to > maintain compatability in case of Integrated ISIS? > > > Thanks > rams. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 17:53:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25569 for ; Thu, 10 Jan 2002 17:53:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AMo0164178; Thu, 10 Jan 2002 14:50:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AMnU164163 for ; Thu, 10 Jan 2002 14:49:30 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "IS-IS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] draft-ietf-isis-wg-mib-07 submitted Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 17:51:47 -0500 I've sent in revision .07 of the ISIS MIB to the IETF. The major changes were adding Notifications, UNITS, reduction of Textual Conventions defined, and various clarifications requested. The list of changes is below. Organization is chronological. -- Changes in version 07. -- Added TE variables suggested by Satish Dattatri -- Added traps culled from -- Alarms in 10589 -- MTU Mismatch (Les G.) -- Protocol Supported mismatch (Les G.) -- Auth failure (Vishwas) -- Importing Inet definitions from INET-ADDRESS-MIB -- Clarify the handling of isisManAreaAddrExistState -- Removed isisCircLevelCircID: duplicates isisCircPtToPtCircID -- Added UNITS clauses for timers and frame counters -- Added default value for isisSysType: current value is L1L2 -- Added system counter isisSysAuthTypeFails -- Revised numbering in isisCircTable -- Removed the use of "Default" in definitions of metrics -- Too easy to confuse with the metric to be used by default -- Added text to describe behavior of isisSysL1State and L2State -- Added descriptions of objects when originally introduced -- Changed mapping for isisISAdjUsage to match on-the wire rep. -- Changed mapping for 3-way handshake state to match on-wire rep. -- Updated text for isisAreaAddrTable as per SIF-AR-9905-056 -- Removed isisSysLSPIgnoreErrors: LSPs with errors should -- always be ignored -- Removed textual conventions such as NSAPPrefix, SNPAAddress -- Added text to description of isisCircMCAddr -- Added isisISAdjIndex to isisISAdjIPAddrTable. Revised text. -- Revised text for isisCircSmallHellos - jeff parker - axiowave networks - I can't remember if I'm the good twin or the evil one. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 17:57:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25609 for ; Thu, 10 Jan 2002 17:57:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AMs4164232; Thu, 10 Jan 2002 14:54:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AMpK164187 for ; Thu, 10 Jan 2002 14:51:20 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 20841 invoked from network); 10 Jan 2002 22:53:47 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Jan 2002 22:53:47 -0000 From: "Ken Larmer" To: , Subject: RE: [Isis-wg] psuedonode LSP Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <01C199C6.D75A05A0.ramsrm@tdd.sj.nec.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 17:58:39 -0500 Content-Transfer-Encoding: 7bit > Thanks for the response. Let me clarify my question again. > I agree that in any general routing protocol, like ISIS for OSI, > OSPF, the > concept of pseudonode LSP exists to remove the N^2 topology > problem as Mr > Dave said. > But My question is that in case of ISIS for IP alone, each router on the > LAN is going to list all the subnets which are directly > reachable in each > of its interfaces. In ordinary terms all the ordinary routers > lists all the > reachable interfaces in their LSPs. ( They r not just listing their > interface to the LAN alone) > So In the pseudonode LSP for ISIS for IP, according to RFC we are not > listing any IP reachability field. > So pseudonode LSP is not going to solve the N^2 problem, because each > ordinary routers itself lists what r the subnets it can reach. > So what is the purpose of still retaining pseudonode LSP concept in ISIS > for IP? Think of a Pseudonode LSP as representing the trunk of a SPF tree and the IS adjacencies serve as the branches off of that trunk. Then the IP Prefixes serve as the leafs attached to the branches of the SPF tree. Leafs do not grow directly from a trunk, so there is no need to have IP Prefixes in a Pseudonode LSP. But, this doesn't mean you still don't need a trunk to connect the branches. > For Selvaraj, > > Why do we need to have two way check in LAN? I think two way check is > needed only in point to point link cases. And how come psuedonode LSP is > useful for two way check?. psuedonode is a virtual concept right? > so do we > need to have two way check between ordinary routers and virtual > psuedonodes > in the LAN? I think in ISIS or any other routing protocol, pseudonode > concept is brought in to remove the N^2 topology problem only > not for any > other purpose? We need a two-way check on a LAN because IS-IS attempts to form adjacencies with each IS present on a common LAN, unlike OSPF routers which only form adjacencies with the DR and BDR. As a consequence, it is quite possible to have misconfigured ISs on the same LAN which do not have adjacencies to all other ISs on that common LAN. The Pseudonode LSP reports the ISs it believes should have formed proper adjacencies (L1 Subdomain or L2 Domain). I believe the Pseudonode determines the set of adjacencies based on area addresses only? Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 18:05:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25700 for ; Thu, 10 Jan 2002 18:05:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AN11164297; Thu, 10 Jan 2002 15:01:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AN0X164280 for ; Thu, 10 Jan 2002 15:00:33 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0AN3BL24781; Thu, 10 Jan 2002 18:03:11 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK76580; Thu, 10 Jan 2002 18:02:57 -0500 (EST) Message-Id: <4.3.2.7.2.20020110175027.01c4a598@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "ramsrm@tdd.sj.nec.com" From: Jeff Learman Subject: RE: [Isis-wg] psuedonode LSP Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: <01C199C6.D75A05A0.ramsrm@tdd.sj.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 18:02:50 -0500 Rams, The N we were talking about was the number of routers on a single LAN, and the N^2 is the number of "IS Neighbors" fields in all LSPs for that LAN. None of these numbers has anything to do with other subnets the routers may be able to reach, or other subnet numbers for that LAN. The N you are talking about is seems to be a set of numbers: the number of routers, and the number of subnets each router is attached to. Unless all of the routers are attached to all of the subnets, this does not yield N^2 advertisements. Note that this is equivalent (in number of advertisements) to one common LAN with N subnet addresses. If all routers are attached on one LAN and are also attached to M other subnets, and each of these subnets is only attached to one of the routers on the LAN, then we have N * M subnets, so N * M subnets must be advertised. Clearly, the reality is somewhere between the two, but is usually nowhere near N^2. Regards, Jeff At 02:06 PM 1/10/2002, ramanathan ramasamy wrote: >Hi all, > > Thanks for the response. Let me clarify my question again. >I agree that in any general routing protocol, like ISIS for OSI, OSPF, the >concept of pseudonode LSP exists to remove the N^2 topology problem as Mr >Dave said. >But My question is that in case of ISIS for IP alone, each router on the >LAN is going to list all the subnets which are directly reachable in each >of its interfaces. In ordinary terms all the ordinary routers lists all the >reachable interfaces in their LSPs. ( They r not just listing their >interface to the LAN alone) >So In the pseudonode LSP for ISIS for IP, according to RFC we are not > listing any IP reachability field. >So pseudonode LSP is not going to solve the N^2 problem, because each >ordinary routers itself lists what r the subnets it can reach. >So what is the purpose of still retaining pseudonode LSP concept in ISIS >for IP? > >For Selvaraj, > >Why do we need to have two way check in LAN? I think two way check is >needed only in point to point link cases. And how come psuedonode LSP is >useful for two way check?. psuedonode is a virtual concept right? so do we >need to have two way check between ordinary routers and virtual psuedonodes >in the LAN? I think in ISIS or any other routing protocol, pseudonode > concept is brought in to remove the N^2 topology problem only not for any >other purpose? > >Thanks >rams. > >-----Original Message----- >From: Jeff Learman [SMTP:jlearman@cisco.com] >Sent: Thursday, January 10, 2002 6:29 AM >To: Dave Katz >Cc: selvarajr@future.futsoft.com; ramsrm@tdd.sj.nec.com; >isis-wg@juniper.net >Subject: Re: [Isis-wg] psuedonode LSP > > >Dave is correct, of course. To amplify a little, a pseudonode LSP is >generated by the DR on behalf of the LAN, making the LAN appear to >be a router that has a point-to-point link with every IS on the LAN. > >So, instead of each of N routers on the LAN reporting N-1 links, we >have N routers reporting 1 link and 1 imaginary router reporting N >links. > >Jeff > >At 02:25 AM 1/10/2002, Dave Katz wrote: >>To answer the original question, the pseudonode concept is still >>useful because it eliminates the N^2 topology problem, which is >>protocol-independent. >> >> X-JNPR-Received-From: outside >> Reply-To: >> From: "SelvarajR" >> X-Priority: 3 (Normal) >> X-MSMail-Priority: Normal >> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 >> Importance: Normal >> Content-Type: text/plain; >> charset="iso-8859-1" >> X-OriginalArrivalTime: 10 Jan 2002 07:06:38.0655 (UTC) >FILETIME=[591904F0:01C199A5] >> Sender: isis-wg-admin@spider.juniper.net >> X-BeenThere: isis-wg@external.juniper.net >> X-Mailman-Version: 2.0rc1 >> Precedence: bulk >> List-Help: >> List-Post: >> List-Subscribe: , >> >> List-Id: IETF IS-IS working group >> List-Unsubscribe: >, >> > >> List-Archive: >> Date: Thu, 10 Jan 2002 12:47:10 +0530 >> >> Pseudonode LSPs are generated on behalf of DR. Each DR will generate >its own >> unique Pseudonode LSPs. It will only contain the neighbor TLV with all >the >> neighbors of the broadcast circuit for which it is the DR. One of its >usage >> is Two-way check. >> Pseudonode LSP wont contain IP reachability Info. Because its >Non-Pseudonode >> LSP will contain those information. So to avoid redundant information >and >> decrease LSP size it is not included in Pseudonode LSP. >> >> Selva. >> >> -----Original Message----- >> From: isis-wg-admin@spider.juniper.net >> [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of ramanathan >> ramasamy >> Sent: Thursday, 10 January 2002 2:43 AM >> To: 'isis-wg@juniper.net' >> Subject: [Isis-wg] psuedonode LSP >> >> >> Hi all, >> >> I have the following doubt in ISIS for IP. >> >> * In Pseudonode LSP, according to RFC 1195 sec 4.3, we won't be >listing >> any IP reachability field( because of logical subnetting probelem). >> Then what is the purpose of retaining Psuedonode LSP concept in >ISIS >> for IP. What will it contain? What is it used for? - is it there to >> maintain compatability in case of Integrated ISIS? >> >> >> Thanks >> rams. >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg >> >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@external.juniper.net >>http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 18:08:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25748 for ; Thu, 10 Jan 2002 18:08:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AN4C164327; Thu, 10 Jan 2002 15:04:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AN0X164282 for ; Thu, 10 Jan 2002 15:00:33 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0AN3AL24775; Thu, 10 Jan 2002 18:03:10 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK76579; Thu, 10 Jan 2002 18:02:57 -0500 (EST) Message-Id: <4.3.2.7.2.20020110174820.01cd6cf8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: Jeff Learman Subject: RE: [Isis-wg] Establishing Router Adjacencies Cc: "'isis-wg@external.juniper.net'" , "HURLEY,JOHN \(A-Portsmouth,ex1\)" , "Ken Larmer" In-Reply-To: References: <0D9185CE635BD511ACA50090277A6FCF2A55DD@axcs18.cos.agilent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 17:48:59 -0500 If both kinds of implementation were mixed, including OSI-only implementations, wouldn't that mess up the DR election? Regards, Jeff At 01:21 PM 1/10/2002, Ken Larmer wrote: >Hi John, > >> Section 4.4 of RFC 1195 it talks about maintaining router adjacencies. >> The first line states that these adjacencies are independent of the IP >> interface >> addresses of the routers. >> >> Does this mean that if an IS sends an IIH to another IS on the >> same physical >> LAN >> a) without an IP Interface Address TLV >> or >> b) with an IP Interface Address TLV that doesn't have a logical >> subnet in >> common with the other IS >> the ISs should establish adjacencies with each other. > > >In accordance with RFC-1195 the answer to the above is yes! However, reality >being what it is, I have only seen 1 implementation that actually works in >this maner! Most implementations do require a common subnet prior to forming >an adjacency. > >Cheers, >Ken Larmer >CommSense Networks > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 18:12:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25798 for ; Thu, 10 Jan 2002 18:12:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AN81164383; Thu, 10 Jan 2002 15:08:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AN2W164306 for ; Thu, 10 Jan 2002 15:02:32 -0800 (PST) (envelope-from Larmer@commsense.net) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0AN51203670 for ; Thu, 10 Jan 2002 15:05:01 -0800 (PST) X-JNPR-Received-From: outside Received: from mail6.speakeasy.net ([216.254.0.206]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 15:03:31 -0800 Received: (qmail 15300 invoked from network); 10 Jan 2002 23:03:43 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Jan 2002 23:03:43 -0000 From: "Ken Larmer" To: , "Dong Ha" Cc: "Ken Larmer" Subject: RE: [Isis-wg] regeneration of pseudonode LSP Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20020110194835.15006.qmail@web14902.mail.yahoo.com> X-OriginalArrivalTime: 10 Jan 2002 23:03:31.0327 (UTC) FILETIME=[05B788F0:01C19A2B] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 18:08:35 -0500 Content-Transfer-Encoding: 7bit > Hello all, > > could anyone tell me in what case the router will > regenerate a pseudonode LSP? ISO 10589 section 7.3.6 > seems like specifying only the events for generating > non-pseudonode LSP. I'm wondering if the operation of > the network is normal, what would cause the router to > regenerate a pseudonode LSP? Thanks. The basic rule is anything which changes the contents of the Pseudonode LSP (Remaining Lifetime is an exception of course). I would say the Pseudonode LSP should be regenerated under the following subset of the Non-Pseudonode LSP regeneration events. - an Adjacency or Circuit Up/Down event - a change in systemID - a change in Designated Intermediate System status - a change in the waiting status Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 18:15:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25836 for ; Thu, 10 Jan 2002 18:15:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ANBF164413; Thu, 10 Jan 2002 15:11:15 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AN4j164338 for ; Thu, 10 Jan 2002 15:04:45 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 18207 invoked from network); 10 Jan 2002 23:07:13 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Jan 2002 23:07:13 -0000 From: "Ken Larmer" To: "Jeff Learman" Cc: "'isis-wg@external.juniper.net'" , "HURLEY,JOHN \(A-Portsmouth,ex1\)" Subject: RE: [Isis-wg] Establishing Router Adjacencies Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.3.2.7.2.20020110174820.01cd6cf8@dingdong.cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 18:12:05 -0500 Content-Transfer-Encoding: 7bit Hi Jeff, > If both kinds of implementation were mixed, including OSI-only > implementations, wouldn't that mess up the DR election? > > Regards, > Jeff Not sure what you mean by this? The IP address has no impact on the DR election, though I think I'm missing your point? Cheers, Ken > > At 01:21 PM 1/10/2002, Ken Larmer wrote: > >Hi John, > > > >> Section 4.4 of RFC 1195 it talks about maintaining router adjacencies. > >> The first line states that these adjacencies are independent of the IP > >> interface > >> addresses of the routers. > >> > >> Does this mean that if an IS sends an IIH to another IS on the > >> same physical > >> LAN > >> a) without an IP Interface Address TLV > >> or > >> b) with an IP Interface Address TLV that doesn't have a logical > >> subnet in > >> common with the other IS > >> the ISs should establish adjacencies with each other. > > > > > >In accordance with RFC-1195 the answer to the above is yes! > However, reality > >being what it is, I have only seen 1 implementation that > actually works in > >this maner! Most implementations do require a common subnet > prior to forming > >an adjacency. > > > >Cheers, > >Ken Larmer > >CommSense Networks > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 18:19:09 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25898 for ; Thu, 10 Jan 2002 18:19:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ANEs164454; Thu, 10 Jan 2002 15:14:54 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0AN6V164366 for ; Thu, 10 Jan 2002 15:06:31 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0AN90203792 for ; Thu, 10 Jan 2002 15:09:00 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 15:05:49 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0AN6Bn25145; Thu, 10 Jan 2002 18:06:11 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK76667; Thu, 10 Jan 2002 18:05:59 -0500 (EST) Message-Id: <4.3.2.7.2.20020110180318.01ca5fa8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Dong Ha From: Jeff Learman Subject: Re: [Isis-wg] regeneration of pseudonode LSP Cc: isis-wg@juniper.net In-Reply-To: <20020110194835.15006.qmail@web14902.mail.yahoo.com> References: <000701c199a6$d268f800$2006040a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 10 Jan 2002 23:05:50.0046 (UTC) FILETIME=[58665FE0:01C19A2B] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 18:05:53 -0500 Clearly, the pseudonode LSP would need to be regenerated any time an router on the associated LAN goes up or down, within the constraints of the LSP min regen timer. Also, it is regenerated periodically with jitter, just as any other LSP. I didn't look at the spec so I can't justify this from a formal standpoint. Regards, Jeff At 02:48 PM 1/10/2002, Dong Ha wrote: >Hello all, > >could anyone tell me in what case the router will >regenerate a pseudonode LSP? ISO 10589 section 7.3.6 >seems like specifying only the events for generating >non-pseudonode LSP. I'm wondering if the operation of >the network is normal, what would cause the router to >regenerate a pseudonode LSP? Thanks. > >-dong > >__________________________________________________ >Do You Yahoo!? >Send FREE video emails in Yahoo! Mail! >http://promo.yahoo.com/videomail/ >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 18:35:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26124 for ; Thu, 10 Jan 2002 18:35:09 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ANV1164599; Thu, 10 Jan 2002 15:31:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ANQF164562 for ; Thu, 10 Jan 2002 15:26:15 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0ANSr526253; Thu, 10 Jan 2002 18:28:53 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK77215; Thu, 10 Jan 2002 18:28:41 -0500 (EST) Message-Id: <4.3.2.7.2.20020110182759.03cf3808@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: Jeff Learman Subject: RE: [Isis-wg] Establishing Router Adjacencies Cc: "'isis-wg@external.juniper.net'" , "HURLEY,JOHN \(A-Portsmouth,ex1\)" In-Reply-To: References: <4.3.2.7.2.20020110174820.01cd6cf8@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 18:28:29 -0500 If the IP address causes an adjacency not to form, and adjacencies are used for DR election, then they would be related (but shouldn't be!) Jeff At 06:12 PM 1/10/2002, Ken Larmer wrote: >Hi Jeff, > > >> If both kinds of implementation were mixed, including OSI-only >> implementations, wouldn't that mess up the DR election? >> >> Regards, >> Jeff > >Not sure what you mean by this? The IP address has no impact on the DR >election, though I think I'm missing your point? > >Cheers, >Ken > > >> >> At 01:21 PM 1/10/2002, Ken Larmer wrote: >> >Hi John, >> > >> >> Section 4.4 of RFC 1195 it talks about maintaining router adjacencies. >> >> The first line states that these adjacencies are independent of the IP >> >> interface >> >> addresses of the routers. >> >> >> >> Does this mean that if an IS sends an IIH to another IS on the >> >> same physical >> >> LAN >> >> a) without an IP Interface Address TLV >> >> or >> >> b) with an IP Interface Address TLV that doesn't have a logical >> >> subnet in >> >> common with the other IS >> >> the ISs should establish adjacencies with each other. >> > >> > >> >In accordance with RFC-1195 the answer to the above is yes! >> However, reality >> >being what it is, I have only seen 1 implementation that >> actually works in >> >this maner! Most implementations do require a common subnet >> prior to forming >> >an adjacency. >> > >> >Cheers, >> >Ken Larmer >> >CommSense Networks >> > >> >_______________________________________________ >> >Isis-wg mailing list - Isis-wg@external.juniper.net >> >http://external.juniper.net/mailman/listinfo/isis-wg >> >> _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 18:54:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26382 for ; Thu, 10 Jan 2002 18:54:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ANp1164714; Thu, 10 Jan 2002 15:51:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ANgF164659 for ; Thu, 10 Jan 2002 15:42:15 -0800 (PST) (envelope-from mbartell@cisco.com) Received: from MBARTELL-W2K.cisco.com (mbartell-w2k.cisco.com [64.101.135.164]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA15089; Thu, 10 Jan 2002 15:44:20 -0800 (PST) Message-Id: <4.3.2.7.2.20020110172427.02c6de88@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Li From: Micah Bartell Subject: RE: [Isis-wg] Regarding document for best current practices Cc: RJ Atkinson , Les Ginsberg , isis-wg@spider.juniper.net In-Reply-To: <15421.15005.581065.981995@alpha-tli.procket.com> References: <4.3.2.7.2.20020109103050.017bc9d0@cactus.cisco.com> <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com > <4.3.2.7.2.20020109103050.017bc9d0@cactus.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 17:44:19 -0600 At 22:54 01/09/2002 -0800, Tony Li wrote: > | With IS-IS being protocol neutral, would it be possible to write up an > | informational RFC which contains the protocol framework, but not the CLNS > | specific details? Implementations going forward would either conform to > | ISO/IEC 10589 or RFC XXXX (or both). > > >While that's certainly possible, I would be very concerned about the long >term implications. The danger of the two versions diverging would be >huge. [Example: ISO picks up and processes a defect report and issues a >revised draft... but no one remembers to fix the IETF version.] That is if the ISO can find anyone to integrate a defect report. However, point taken with respect to divergence between the standards. I think with the decline of OSI, this is likely to much more a problem in theory than in practice. The only changes that are foreseeable come through the ISO would be for the ITU modifications to provide additional support for multiple protocols in SONET. It may be that if the IETF created a version, the ITU modifications could be submitted as an RFC, in addition as Defect Report's against 10589. > | I just do not know about the politics involved with this. I can look > into > | this with the SC6 Secratariat if there is sufficient interest. ISO/IEC > | 10589 is copyrighted...so it may be as simple as formal permission for > the > | IETF to make use of the content in 10589, which could be put to a vote. > > >We would welcome any way to move forward out of this quagmire. > >Let me offer a germ of an idea: As has been pointed out, there is a great >deal of overlap between the actual folks doing the work in both >organizations. No matter where we host it, it's the same folks, doing the >same thing. Why then, does it really matter, where the group is hosted? The ISO requires paid membership. The JTC1/SC6/WG7 is a very small part of the ISO, so it is unlikely to obtain much by way of traction in making anything unusual happen. The US is no longer ever a P-Member of the JTC1 SC6. >Why not have just one joint, integrated working group, which reports to two >bodies? It is probably easier through voting to get the ISO to let go of the IS-IS spec. I have seen examples where ISO specs no longer exist. They have been removed from circulation and work on the project is officially ended. >This way, the group has the clear authority to issue definitive >documents. These documents get published as BOTH ISO standards and RFCs. That requires that both organizations agree on the documents. Many rounds of voting if there is disagreement, and potential deadlock if agreement can't be reached. >I realize that this is probably unprecedented on both sides of the fence, >but it seems only logical to construct a pseudonode adjacency here. ;-) When you migrate all of the customers from one router to another, you remove the old router from service. :) /mpb >Tony >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 10 19:56:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26852 for ; Thu, 10 Jan 2002 19:56:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0B0q8165024; Thu, 10 Jan 2002 16:52:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail4.nec.com (dns4.nec.com [131.241.15.4]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0B0aF164933 for ; Thu, 10 Jan 2002 16:36:15 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g0B0WhF27678 for ; Thu, 10 Jan 2002 16:32:43 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id QAA02542 for ; Thu, 10 Jan 2002 16:32:40 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id QAA01943 for ; Thu, 10 Jan 2002 16:39:16 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfQAA01933 for <>; Thu Jan 10 16:35:44 2002 Received: from ems11 by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g0B0P1v08971 for ; Thu, 10 Jan 2002 16:25:01 -0800 (PST) Received: by localhost with Microsoft MAPI; Thu, 10 Jan 2002 13:34:17 -0800 Message-ID: <01C199DB.80555C90.ramsrm@tdd.sj.nec.com> From: ramanathan ramasamy Reply-To: "ramsrm@tdd.sj.nec.com" To: "'isis-wg@spider.juniper.net'" X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 17 TEXT Subject: [Isis-wg] Point to point adjacency down. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 10 Jan 2002 13:34:14 -0800 Hi all, I have a following question. * If a P-P link with an ES/IS neighbour is going down, according to the specification, adjacency down event will be generated and the adjacency will be removed from the database. My question is once this happens, do we need to run the decision process also immediately after removing the adjacency in both ES neighbour and IS neighbour cases?( entire sequence needs to be done as an atomic action?) or can we wait for something to trigger the Decision Process? Is there anything specified in 10589 regarding when to run the decision process once an adjacency goes down? Thanks rams. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 09:17:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15398 for ; Fri, 11 Jan 2002 09:17:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BEC1168767; Fri, 11 Jan 2002 06:12:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BEBM168755 for ; Fri, 11 Jan 2002 06:11:22 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0BEDoD04238; Fri, 11 Jan 2002 09:13:51 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0BEDXB15490; Fri, 11 Jan 2002 14:13:33 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 14:13:54 -0000 Message-ID: <4103264BC8D3D51180B7002048400C4507141E@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Jeff Learman'" , Ken Larmer Cc: "'isis-wg@external.juniper.net'" , "HURLEY,JOHN (A-Portsmouth,ex1)" Subject: RE: [Isis-wg] Establishing Router Adjacencies MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19AAA.2F6D3AD0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 14:13:47 -0000 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. ------_=_NextPart_001_01C19AAA.2F6D3AD0 Content-Type: text/plain; charset="iso-8859-1" Clearly a router that supports CLNP and IP in a dual way, cannot gate adjacency formation upon IP addresses, but MUST act in the way that RFC 1195 states. It is only an IP-only router that can get away with this "non-conformant" behaviour. I put that in quotes because it might be considered as a positive feature, I'm not trying to suggest that it is either good or bad. The question now comes, what about a router that is a dual IPv4 and IPv6? I would say that it should either a: just ignore IP addresses and bring up adjacencies as per the various standards or b: bring up the adjacency if there is EITHER a logical IPv4 subnet, OR if there is a logical IPv6 subnet. Otherwise you get an IPv4 configuration error blocking the IPv6 traffic and vice versa, which would be wrong, I would have thought. Presumably the gating of an adjacency upon a valid IP subnet is switched off in anycase if both ends are configured to be unnumbered. Philip -----Original Message----- From: Jeff Learman [mailto:jlearman@cisco.com] Sent: 10 January 2002 23:28 To: Ken Larmer Cc: 'isis-wg@external.juniper.net'; HURLEY,JOHN (A-Portsmouth,ex1) Subject: RE: [Isis-wg] Establishing Router Adjacencies If the IP address causes an adjacency not to form, and adjacencies are used for DR election, then they would be related (but shouldn't be!) Jeff At 06:12 PM 1/10/2002, Ken Larmer wrote: >Hi Jeff, > > >> If both kinds of implementation were mixed, including OSI-only >> implementations, wouldn't that mess up the DR election? >> >> Regards, >> Jeff > >Not sure what you mean by this? The IP address has no impact on the DR >election, though I think I'm missing your point? > >Cheers, >Ken > > >> >> At 01:21 PM 1/10/2002, Ken Larmer wrote: >> >Hi John, >> > >> >> Section 4.4 of RFC 1195 it talks about maintaining router adjacencies. >> >> The first line states that these adjacencies are independent of the IP >> >> interface >> >> addresses of the routers. >> >> >> >> Does this mean that if an IS sends an IIH to another IS on the >> >> same physical >> >> LAN >> >> a) without an IP Interface Address TLV >> >> or >> >> b) with an IP Interface Address TLV that doesn't have a logical >> >> subnet in >> >> common with the other IS >> >> the ISs should establish adjacencies with each other. >> > >> > >> >In accordance with RFC-1195 the answer to the above is yes! >> However, reality >> >being what it is, I have only seen 1 implementation that >> actually works in >> >this maner! Most implementations do require a common subnet >> prior to forming >> >an adjacency. >> > >> >Cheers, >> >Ken Larmer >> >CommSense Networks >> > >> >_______________________________________________ >> >Isis-wg mailing list - Isis-wg@external.juniper.net >> >http://external.juniper.net/mailman/listinfo/isis-wg >> >> _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C19AAA.2F6D3AD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Establishing Router Adjacencies

Clearly a router that supports CLNP and IP in a dual = way, cannot gate adjacency formation upon IP addresses, but MUST act in = the way that RFC 1195 states.

It is only an IP-only router that can get away with = this "non-conformant" behaviour. I put that in quotes because = it might be considered as a positive feature, I'm not trying to suggest = that it is either good or bad.

The question now comes, what about a router that is a = dual IPv4 and IPv6?  I would say that it should either

a: just ignore IP addresses and bring up adjacencies = as per the various standards

or

b: bring up the adjacency if there is EITHER a = logical IPv4 subnet, OR if there is a logical IPv6 subnet.

Otherwise you get an IPv4 configuration error = blocking the IPv6 traffic and vice versa, which would be wrong, I would = have thought.

Presumably the gating of an adjacency upon a valid IP = subnet is switched off in anycase if both ends are configured to be = unnumbered.

Philip

-----Original Message-----
From: Jeff Learman [mailto:jlearman@cisco.com]=
Sent: 10 January 2002 23:28
To: Ken Larmer
Cc: 'isis-wg@external.juniper.net'; HURLEY,JOHN = (A-Portsmouth,ex1)
Subject: RE: [Isis-wg] Establishing Router = Adjacencies



If the IP address causes an adjacency not to form, = and adjacencies are
used for DR election, then they would be related = (but shouldn't be!)

Jeff

At 06:12 PM 1/10/2002, Ken Larmer wrote:
>Hi Jeff,
>
>
>> If both kinds of implementation were mixed, = including OSI-only
>> implementations, wouldn't that mess up the = DR election?
>>
>> Regards,
>> Jeff
>
>Not sure what you mean by this? The IP address = has no impact on the DR
>election, though I think I'm missing your = point?
>
>Cheers,
>Ken
>
>
>>
>> At 01:21 PM 1/10/2002, Ken Larmer = wrote:
>> >Hi John,
>> >
>> >> Section 4.4 of RFC 1195 it talks = about maintaining router adjacencies.
>> >> The first line states that these = adjacencies are independent of the IP
>> >> interface
>> >> addresses of the routers.
>> >>
>> >> Does this mean that if an IS sends = an IIH to another IS on the
>> >> same physical
>> >> LAN
>> >>   a) without an IP = Interface Address TLV
>> >>      = or
>> >>   b) with an IP = Interface Address TLV that doesn't have a logical
>> >> subnet in
>> >>      = common with the other IS
>> >> the ISs should establish = adjacencies with each other.
>> >
>> >
>> >In accordance with RFC-1195 the answer = to the above is yes!
>> However, reality
>> >being what it is, I have only seen 1 = implementation that
>> actually works in
>> >this maner! Most implementations do = require a common subnet
>> prior to forming
>> >an adjacency.
>> >
>> >Cheers,
>> >Ken Larmer
>> >CommSense Networks
>> >
>> = >_______________________________________________
>> >Isis-wg mailing list  -  = Isis-wg@external.juniper.net
>> >http://external.juniper.net/mailman/listinfo/isis-wg
>>
>>

_______________________________________________
Isis-wg mailing list  -  = Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg

------_=_NextPart_001_01C19AAA.2F6D3AD0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 10:38:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18235 for ; Fri, 11 Jan 2002 10:38:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BFY5169180; Fri, 11 Jan 2002 07:34:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BFTB169151 for ; Fri, 11 Jan 2002 07:29:11 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'ramsrm@tdd.sj.nec.com'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] Point to point adjacency down. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 10:31:17 -0500 > Is there anything specified in 10589 regarding when to run > the decision process once an adjacency goes down? > > rams. The adjacency down event should trigger the regeneration of LSPs by both IS's. Either would trigger a new SPF. Section 7.3.6 explicitly lists adjacency changes as a trigger for new LSP generation. See also 7.2.1, 7.3.1. Typically you schedule an SPF run, and wait for a brief period, so that related events (hearing indirectly that the other side also thinks the link is down) don't cause multiple runs. I've just run through 10589 and don't see evidence of such a value. I already have a note in my todo file to add such a variable to the MIB. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 11:47:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21121 for ; Fri, 11 Jan 2002 11:47:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BGg7169521; Fri, 11 Jan 2002 08:42:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BGX5169472 for ; Fri, 11 Jan 2002 08:33:05 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0BGZlW05893; Fri, 11 Jan 2002 11:35:47 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAK90591; Fri, 11 Jan 2002 11:35:34 -0500 (EST) Message-Id: <4.3.2.7.2.20020111100349.03571d60@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: Jeff Learman Subject: RE: [Isis-wg] Establishing Router Adjacencies Cc: Ken Larmer , "'isis-wg@external.juniper.net'" , "HURLEY,JOHN (A-Portsmouth,ex1)" In-Reply-To: <4103264BC8D3D51180B7002048400C4507141E@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_7919918==_.ALT" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 10:28:29 -0500 --=====================_7919918==_.ALT Content-Type: text/plain; charset="us-ascii" Philip, Afer giving it a little more thought, I'm going to back off a little, since a LAN that has OSI-only routers and IP-only routers is either violating RFC-1195 deployment rules, or else it's placing multiple areas on a single LAN. (The latter is not clearly and explicitly forbidden by 10589, but I've seen a pretty strong argument from Les Ginsberg that it's not intended and is a bad idea anyway.) For implementations that run SPF independently for each protocol and allow relaxation of the RFC-1195 rules, not forming adjacencies would be disaster, I think, because it would mean that different sets of routers might elect different DRs (and the elected DR may not know it was elected.) But I think the behavior of a system when placed in a network that is not according to RFC-1195 deployment rules is beyond the scope of RFC-1195 and therefore not mandated by it. As you say, this will become much more important as IPv6 support increases. Currently, we have only RFC-1195 and its very restrictive deployment rules, which I suspect will not serve the customers very well. There is a lot more to work out than adjacency formation with respect to relaxing the deployment rules, and we can't talk about adjacency formation without also discussing, very carefully, DR election and whether to run SPF independently for each protocol (not required by 1195). My opinion right now is that it's safer to always form the adjacency. If you don't, then your customers MUST follow the 1195 deployment rules. If you don't always form adjacencies and if the network does not adhere to the deployment rules on a given LAN, there might be disagreement among different implementations on which system is the DR, and careful configuration of DR priority is required to work around it. Not forming the adjacency seems sensible but take care to consider DR election and backwards compatibility. We had a lengthy discussion of this point a few months ago, some of which you may find if you peruse the archive. I thing the very first thing we should do is decide whether the RFC-1195 deployment restrictions will serve us for IPv4/IPv6 integration. If we focus on that (and consider backwards compatibility), I believe that whatever we come up with should also apply to OSI/IP combinations. That is, we should have good multiprotocol rules that are protocol independent. (We already do, but with 1195's topology restrictions.) Regards, Jeff At 09:13 AM 1/11/2002, Philip Christian wrote: >Clearly a router that supports CLNP and IP in a dual way, cannot gate adjacency formation upon IP addresses, but MUST act in the way that RFC 1195 states. > >It is only an IP-only router that can get away with this "non-conformant" behaviour. I put that in quotes because it might be considered as a positive feature, I'm not trying to suggest that it is either good or bad. > >The question now comes, what about a router that is a dual IPv4 and IPv6? I would say that it should either > >a: just ignore IP addresses and bring up adjacencies as per the various standards > >or > >b: bring up the adjacency if there is EITHER a logical IPv4 subnet, OR if there is a logical IPv6 subnet. > >Otherwise you get an IPv4 configuration error blocking the IPv6 traffic and vice versa, which would be wrong, I would have thought. > >Presumably the gating of an adjacency upon a valid IP subnet is switched off in anycase if both ends are configured to be unnumbered. > >Philip > >-----Original Message----- >From: Jeff Learman [mailto:jlearman@cisco.com] >Sent: 10 January 2002 23:28 >To: Ken Larmer >Cc: 'isis-wg@external.juniper.net'; HURLEY,JOHN (A-Portsmouth,ex1) >Subject: RE: [Isis-wg] Establishing Router Adjacencies > > >If the IP address causes an adjacency not to form, and adjacencies are >used for DR election, then they would be related (but shouldn't be!) > >Jeff > >At 06:12 PM 1/10/2002, Ken Larmer wrote: >>Hi Jeff, >> >> >>> If both kinds of implementation were mixed, including OSI-only >>> implementations, wouldn't that mess up the DR election? >>> >>> Regards, >>> Jeff >> >>Not sure what you mean by this? The IP address has no impact on the DR >>election, though I think I'm missing your point? >> >>Cheers, >>Ken >> >> >>> >>> At 01:21 PM 1/10/2002, Ken Larmer wrote: >>> >Hi John, >>> > >>> >> Section 4.4 of RFC 1195 it talks about maintaining router adjacencies. >>> >> The first line states that these adjacencies are independent of the IP >>> >> interface >>> >> addresses of the routers. >>> >> >>> >> Does this mean that if an IS sends an IIH to another IS on the >>> >> same physical >>> >> LAN >>> >> a) without an IP Interface Address TLV >>> >> or >>> >> b) with an IP Interface Address TLV that doesn't have a logical >>> >> subnet in >>> >> common with the other IS >>> >> the ISs should establish adjacencies with each other. >>> > >>> > >>> >In accordance with RFC-1195 the answer to the above is yes! >>> However, reality >>> >being what it is, I have only seen 1 implementation that >>> actually works in >>> >this maner! Most implementations do require a common subnet >>> prior to forming >>> >an adjacency. >>> > >>> >Cheers, >>> >Ken Larmer >>> >CommSense Networks >>> > >>> >_______________________________________________ >>> >Isis-wg mailing list - Isis-wg@external.juniper.net >>> >http://external.juniper.net/mailman/listinfo/isis-wg >>> >>> > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg --=====================_7919918==_.ALT Content-Type: text/html; charset="us-ascii"
Philip,

Afer giving it a little more thought, I'm going to back off a little,
since a LAN that has OSI-only routers and IP-only routers is either
violating RFC-1195 deployment rules, or else it's placing multiple
areas on a single LAN.  (The latter is not clearly and explicitly
forbidden by 10589, but I've seen a pretty strong argument from
Les Ginsberg that it's not intended and is a bad idea anyway.)

For implementations that run SPF independently for each protocol and
allow relaxation of the RFC-1195 rules, not forming adjacencies would
be disaster, I think, because it would mean that different sets of
routers might elect different DRs (and the elected DR may not know it
was elected.)  But I think the behavior of a system when placed in a
network that is not according to RFC-1195 deployment rules is beyond
the scope of RFC-1195 and therefore not mandated by it.

As you say, this will become much more important as IPv6 support
increases.  Currently, we have only RFC-1195 and its very restrictive
deployment rules, which I suspect will not serve the customers very well.
There is a lot more to work out than adjacency formation with respect
to relaxing the deployment rules, and we can't talk about adjacency
formation without also discussing, very carefully, DR election and
whether to run SPF independently for each protocol (not required by
1195).

My opinion right now is that it's safer to always form the adjacency.
If you don't, then your customers MUST follow the 1195 deployment
rules.  If you don't always form adjacencies and if the network does
not adhere to the deployment rules on a given LAN, there might be
disagreement among different implementations on which system is the
DR, and careful configuration of DR priority is required to work
around it.

Not forming the adjacency seems sensible but take care to consider
DR election and backwards compatibility.  We had a lengthy discussion
of this point a few months ago, some of which you may find if you
peruse the archive.

I thing the very first thing we should do is decide whether the
RFC-1195 deployment restrictions will serve us for IPv4/IPv6 integration.
If we focus on that (and consider backwards compatibility), I believe
that whatever we come up with should also apply to OSI/IP combinations.
That is, we should have good multiprotocol rules that are protocol
independent.  (We already do, but with 1195's topology restrictions.)

Regards,
Jeff

At 09:13 AM 1/11/2002, Philip Christian wrote:

Clearly a router that supports CLNP and IP in a dual way, cannot gate adjacency formation upon IP addresses, but MUST act in the way that RFC 1195 states.

It is only an IP-only router that can get away with this "non-conformant" behaviour. I put that in quotes because it might be considered as a positive feature, I'm not trying to suggest that it is either good or bad.

The question now comes, what about a router that is a dual IPv4 and IPv6?  I would say that it should either

a: just ignore IP addresses and bring up adjacencies as per the various standards

or

b: bring up the adjacency if there is EITHER a logical IPv4 subnet, OR if there is a logical IPv6 subnet.

Otherwise you get an IPv4 configuration error blocking the IPv6 traffic and vice versa, which would be wrong, I would have thought.

Presumably the gating of an adjacency upon a valid IP subnet is switched off in anycase if both ends are configured to be unnumbered.

Philip

-----Original Message-----
From: Jeff Learman [mailto:jlearman@cisco.com]
Sent: 10 January 2002 23:28
To: Ken Larmer
Cc: 'isis-wg@external.juniper.net'; HURLEY,JOHN (A-Portsmouth,ex1)
Subject: RE: [Isis-wg] Establishing Router Adjacencies


If the IP address causes an adjacency not to form, and adjacencies are
used for DR election, then they would be related (but shouldn't be!)

Jeff

At 06:12 PM 1/10/2002, Ken Larmer wrote:
>Hi Jeff,
>
>
>> If both kinds of implementation were mixed, including OSI-only
>> implementations, wouldn't that mess up the DR election?
>>
>> Regards,
>> Jeff
>
>Not sure what you mean by this? The IP address has no impact on the DR
>election, though I think I'm missing your point?
>
>Cheers,
>Ken
>
>
>>
>> At 01:21 PM 1/10/2002, Ken Larmer wrote:
>> >Hi John,
>> >
>> >> Section 4.4 of RFC 1195 it talks about maintaining router adjacencies.
>> >> The first line states that these adjacencies are independent of the IP
>> >> interface
>> >> addresses of the routers.
>> >>
>> >> Does this mean that if an IS sends an IIH to another IS on the
>> >> same physical
>> >> LAN
>> >>   a) without an IP Interface Address TLV
>> >>      or
>> >>   b) with an IP Interface Address TLV that doesn't have a logical
>> >> subnet in
>> >>      common with the other IS
>> >> the ISs should establish adjacencies with each other.
>> >
>> >
>> >In accordance with RFC-1195 the answer to the above is yes!
>> However, reality
>> >being what it is, I have only seen 1 implementation that
>> actually works in
>> >this maner! Most implementations do require a common subnet
>> prior to forming
>> >an adjacency.
>> >
>> >Cheers,
>> >Ken Larmer
>> >CommSense Networks
>> >
>> >_______________________________________________
>> >Isis-wg mailing list  -  Isis-wg@external.juniper.net
>> >http://external.juniper.net/mailman/listinfo/isis-wg
>>
>>

_______________________________________________
Isis-wg mailing list  -  Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg
--=====================_7919918==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 12:29:45 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22519 for ; Fri, 11 Jan 2002 12:29:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BHPC169745; Fri, 11 Jan 2002 09:25:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BHBZ169678 for ; Fri, 11 Jan 2002 09:11:35 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0BHE3638749; Fri, 11 Jan 2002 09:14:03 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0BHD0T90686; Fri, 11 Jan 2002 09:13:00 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201111713.g0BHD0T90686@cirrus.juniper.net> From: Dave Katz To: jparker@axiowave.com CC: ramsrm@tdd.sj.nec.com, isis-wg@spider.juniper.net In-reply-to: (message from Jeff Parker on Fri, 11 Jan 2002 10:31:17 -0500) Subject: Re: [Isis-wg] Point to point adjacency down. References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 09:13:00 -0800 (PST) Typically you schedule an SPF run, and wait for a brief period, so that related events (hearing indirectly that the other side also thinks the link is down) don't cause multiple runs. I've just run through 10589 and don't see evidence of such a value. I already have a note in my todo file to add such a variable to the MIB. This strays into the area of creative implementation possibilities. I suspect that a MIB variable with a scalar value that is expected to be stable does not accurately represent either of the dominant implementations. --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 13:37:45 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25022 for ; Fri, 11 Jan 2002 13:37:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BIXB170072; Fri, 11 Jan 2002 10:33:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BI6d169954 for ; Fri, 11 Jan 2002 10:06:39 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Dave Katz'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] Point to point adjacency down. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 13:09:06 -0500 > Typically you schedule an SPF run, and wait for a brief > period, so that related events (hearing indirectly that > the other side also thinks the link is down) don't > cause multiple runs. I've just run through 10589 and > don't see evidence of such a value. I already have a > note in my todo file to add such a variable to the MIB. > > This strays into the area of creative implementation possibilities. > I suspect that a MIB variable with a scalar value that is expected > to be stable does not accurately represent either of the dominant > implementations. > > --Dave Noted and removed from the list of things todo. :wq - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 14:25:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26663 for ; Fri, 11 Jan 2002 14:25:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJLJ170328; Fri, 11 Jan 2002 11:21:19 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJ4Y170233 for ; Fri, 11 Jan 2002 11:04:34 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from mail.nexsi.com (ripper1.nexsi.com [66.35.212.35]) by relay1.nexsi.com (Postfix) with ESMTP id 1BB353F65; Fri, 11 Jan 2002 11:09:52 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id LAA25997; Fri, 11 Jan 2002 11:10:39 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <2694482272.20020111110559@nexsi.com> To: Dave Katz Cc: jparker@axiowave.com, ramsrm@tdd.sj.nec.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Point to point adjacency down. In-Reply-To: <200201111713.g0BHD0T90686@cirrus.juniper.net> References: <200201111713.g0BHD0T90686@cirrus.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 11:05:59 -0800 Content-Transfer-Encoding: 7bit Dave, > Typically you schedule an SPF run, and wait for a brief > period, so that related events (hearing indirectly that > the other side also thinks the link is down) don't > cause multiple runs. I've just run through 10589 and > don't see evidence of such a value. I already have a > note in my todo file to add such a variable to the MIB. > This strays into the area of creative implementation possibilities. > I suspect that a MIB variable with a scalar value that is expected > to be stable does not accurately represent either of the dominant > implementations. BTW, this looks like another item for the document Vishwas proposed. I'm also thinking: if I were using MIB to monitor/configure routers, I guess I would like to see a variable/variables reflecting the SPF back-off values. Unless implementations diverge dramatically (e.g., one is using exp, another sqrt ;), it seems to me there should be a way to do so... In the worst scenario, we could have "opaque" variables with well-defined syntax, but flexible semantics. Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 14:27:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26685 for ; Fri, 11 Jan 2002 14:27:09 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJN9170350; Fri, 11 Jan 2002 11:23:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJ9i170258 for ; Fri, 11 Jan 2002 11:09:44 -0800 (PST) (envelope-from prz@redback.com) Received: from redback.com ([63.200.51.152]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GPS00H2SG0CP8@mta7.pltn13.pbi.net> for isis-wg@spider.juniper.net; Fri, 11 Jan 2002 11:12:13 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] Point to point adjacency down. To: Dave Katz Cc: jparker@axiowave.com, ramsrm@tdd.sj.nec.com, isis-wg@spider.juniper.net Message-id: <3C3F2585.3A45FC9F@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200201111713.g0BHD0T90686@cirrus.juniper.net> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 09:48:54 -0800 Content-Transfer-Encoding: 7BIT Dave Katz wrote: > Typically you schedule an SPF run, and wait for a brief > period, so that related events (hearing indirectly that > the other side also thinks the link is down) don't > cause multiple runs. I've just run through 10589 and > don't see evidence of such a value. I already have a > note in my todo file to add such a variable to the MIB. > > This strays into the area of creative implementation possibilities. > I suspect that a MIB variable with a scalar value that is expected > to be stable does not accurately represent either of the dominant > implementations. taking the danger of repeating trivia, yes, please do not forget that a protocol specification is governing the _external_ behavior of the protocol, so basically what and when you see on the wire (and some of the internal but only to the extent that guarantees interoperability, e.g. due to hop-by-hop paradigm everyone has to run an algorithm that delivers the same forwarding decisions, in source-routed paradigms that may not be necessary). It is superfluous, restricting and confusing to try to govern internal implementation details as of how this behavior is being achieved beside giving a reference model for description purposes. Literally, if little green men carry things around in water buckets in some implementations and manage to deliver correct ISIS packets to the wire, that's ok (of course they must be paid minimum wage but that's not our problem ;-) .... htanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 14:30:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26842 for ; Fri, 11 Jan 2002 14:30:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJQR170390; Fri, 11 Jan 2002 11:26:27 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJK8170316 for ; Fri, 11 Jan 2002 11:20:08 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Tony Przygienda'" , Dave Katz Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Point to point adjacency down. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 14:22:31 -0500 > > This strays into the area of creative implementation possibilities. > > I suspect that a MIB variable with a scalar value that is expected > > to be stable does not accurately represent either of the dominant > > implementations. > > It is superfluous, restricting and confusing to try to > govern internal implementation details ... > correct ISIS packets to the wire [is our only goal] > > -- tony Tony - I can accept that this is off task behavior, but I must ask a clarifying question. Don't we have more to do that generate and consume IS-IS packets? Don't we also need to produce consistent routing tables for the two letter protocol? If we let SPF computations run without check, or delay SPF computations unduly, doesn't that effect convergence adversly, through slow flooding in the first case, and slow updates to our tables in the second. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 14:32:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26898 for ; Fri, 11 Jan 2002 14:32:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJS5170412; Fri, 11 Jan 2002 11:28:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web14901.mail.yahoo.com (web14901.mail.yahoo.com [216.136.225.53]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g0BJNK170356 for ; Fri, 11 Jan 2002 11:23:20 -0800 (PST) (envelope-from donkiha@yahoo.com) Message-ID: <20020111192553.79887.qmail@web14901.mail.yahoo.com> Received: from [12.104.224.46] by web14901.mail.yahoo.com via HTTP; Fri, 11 Jan 2002 11:25:53 PST From: Dong Ha To: "IS-IS-WG \(E-mail\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] LSP with size bigger than ReceiveLSPBufferSize Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 11:25:53 -0800 (PST) Hi all, Can anyone tell me what a router should do when it receives a LSP with size bigger than the ReceiveLSPBufferSize? Should it forward to other routers or not? The ISO 10589 says the LSP should be treated as if it has expired lifetime but I couldn't find any information about wheather or not it should be forwarded to other routers. Thanks. -dong __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 14:34:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26917 for ; Fri, 11 Jan 2002 14:34:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJU1170441; Fri, 11 Jan 2002 11:30:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJQG170381 for ; Fri, 11 Jan 2002 11:26:16 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0BJSo646693 for ; Fri, 11 Jan 2002 11:28:50 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0BJRln91110; Fri, 11 Jan 2002 11:27:47 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201111927.g0BJRln91110@cirrus.juniper.net> From: Dave Katz To: isis-wg@spider.juniper.net In-reply-to: (message from Jeff Parker on Fri, 11 Jan 2002 13:09:06 -0500) Subject: Re: [Isis-wg] Point to point adjacency down. References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 11:27:47 -0800 (PST) This cuts at the heart of MIB-ifying things, which is that a standard MIB can really only address the things that are truly normative, where "truly" means "the protocol doesn't work without it," and the really good stuff has to be in a private MIB, if it's exposed at all. If you are quite well versed in the design and function of the protocol, there are *lots* of implementation choices you can make that will interoperate perfectly well (the only true requirement of a standard) but are not necessarily obvious, as well as some statements in the spec that do not reflect what the protocol is actually capable of (the lifetime issue, for example.) Much of this implementation flexibility is the toehold for competitive advantage, so you may find some of us less than forthcoming in the details, since competitive advantage is a pretty thin concept when dealing with standards. But as a Rude Pragmatist (tm), I also don't believe that SNMP will ever be used in any realistic way to configure a Real Router, as its Turing-machine-like semantics (thanks, jeff) are far too clumsy to be useful. XML-based stuff is looking much more promising. As such, exposing implementation-specific data in a read-only mode in a non-standard MIB is of very limited usefulness. --Dave > This strays into the area of creative implementation possibilities. > I suspect that a MIB variable with a scalar value that is expected > to be stable does not accurately represent either of the dominant > implementations. > > --Dave Noted and removed from the list of things todo. :wq - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 14:48:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27227 for ; Fri, 11 Jan 2002 14:48:42 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJi1170567; Fri, 11 Jan 2002 11:44:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJhj170555 for ; Fri, 11 Jan 2002 11:43:45 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0BJjg647721; Fri, 11 Jan 2002 11:45:42 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0BJidA91180; Fri, 11 Jan 2002 11:44:39 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201111944.g0BJidA91180@cirrus.juniper.net> From: Dave Katz To: prz@redback.com CC: jparker@axiowave.com, ramsrm@tdd.sj.nec.com, isis-wg@spider.juniper.net In-reply-to: <3C3F2585.3A45FC9F@redback.com> (message from Tony Przygienda on Fri, 11 Jan 2002 09:48:54 -0800) Subject: Re: [Isis-wg] Point to point adjacency down. References: <200201111713.g0BHD0T90686@cirrus.juniper.net> <3C3F2585.3A45FC9F@redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 11:44:39 -0800 (PST) Hey, who told you about my LGM algorithm? Good thing I've got a patent. ;-) But seriously, thanks for stating this less curtly than I would. The IETF has a long history of being confused about what is subject to standardization and what is not (the OSPF spec is a work of art in that respect--it's a great implementation guide, but 90% of it is not normative. This turns out to be a competitive advantage, since the implementation strategy it outlines has some serious scaling limitations, so I don't complain. Much.) --Dave X-JNPR-Received-From: outside Date: Fri, 11 Jan 2002 09:48:54 -0800 From: Tony Przygienda Sender: root@nodots-daemon Cc: jparker@axiowave.com, ramsrm@tdd.sj.nec.com, isis-wg@spider.juniper.net Content-type: text/plain; charset=us-ascii X-Accept-Language: en X-OriginalArrivalTime: 11 Jan 2002 19:12:00.0000 (UTC) FILETIME=[D8410000:01C19AD3] Dave Katz wrote: > Typically you schedule an SPF run, and wait for a brief > period, so that related events (hearing indirectly that > the other side also thinks the link is down) don't > cause multiple runs. I've just run through 10589 and > don't see evidence of such a value. I already have a > note in my todo file to add such a variable to the MIB. > > This strays into the area of creative implementation possibilities. > I suspect that a MIB variable with a scalar value that is expected > to be stable does not accurately represent either of the dominant > implementations. taking the danger of repeating trivia, yes, please do not forget that a protocol specification is governing the _external_ behavior of the protocol, so basically what and when you see on the wire (and some of the internal but only to the extent that guarantees interoperability, e.g. due to hop-by-hop paradigm everyone has to run an algorithm that delivers the same forwarding decisions, in source-routed paradigms that may not be necessary). It is superfluous, restricting and confusing to try to govern internal implementation details as of how this behavior is being achieved beside giving a reference model for description purposes. Literally, if little green men carry things around in water buckets in some implementations and manage to deliver correct ISIS packets to the wire, that's ok (of course they must be paid minimum wage but that's not our problem ;-) .... htanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 14:51:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27284 for ; Fri, 11 Jan 2002 14:51:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJl1170605; Fri, 11 Jan 2002 11:47:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BJiR170578 for ; Fri, 11 Jan 2002 11:44:27 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0BJfI647429; Fri, 11 Jan 2002 11:41:18 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0BJeFS91168; Fri, 11 Jan 2002 11:40:15 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201111940.g0BJeFS91168@cirrus.juniper.net> From: Dave Katz To: azinin@nexsi.com CC: jparker@axiowave.com, ramsrm@tdd.sj.nec.com, isis-wg@spider.juniper.net In-reply-to: <2694482272.20020111110559@nexsi.com> (message from Alex Zinin on Fri, 11 Jan 2002 11:05:59 -0800) Subject: Re: [Isis-wg] Point to point adjacency down. References: <200201111713.g0BHD0T90686@cirrus.juniper.net> <2694482272.20020111110559@nexsi.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 11:40:15 -0800 (PST) I'm also thinking: if I were using MIB to monitor/configure routers, I guess I would like to see a variable/variables reflecting the SPF back-off values. Unless implementations diverge dramatically (e.g., one is using exp, another sqrt ;), it seems to me there should be a way to do so... In the worst scenario, we could have "opaque" variables with well-defined syntax, but flexible semantics. Exponential SPF backoff is a red herring, but that's a good over-beer rant. In general, there is no way in a MIB to generalize this sufficiently to capture all the possibilities while actually being useful for something. At best, we'll just lie about the values. I guarantee that you won't capture my semantics that way, but that's fine, since I won't tell you anyhow, and nobody but me needs to know. But then if you're using a MIB to configure a router, please party on. ;-) (See previous rant.) --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 15:11:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27932 for ; Fri, 11 Jan 2002 15:11:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BK47170724; Fri, 11 Jan 2002 12:04:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BK3n170712 for ; Fri, 11 Jan 2002 12:03:54 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0BK6N648641; Fri, 11 Jan 2002 12:06:23 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0BK5Ko91238; Fri, 11 Jan 2002 12:05:20 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201112005.g0BK5Ko91238@cirrus.juniper.net> From: Dave Katz To: jparker@axiowave.com CC: prz@redback.com, isis-wg@spider.juniper.net In-reply-to: (message from Jeff Parker on Fri, 11 Jan 2002 14:22:31 -0500) Subject: Re: [Isis-wg] Point to point adjacency down. References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 12:05:20 -0800 (PST) Don't we have more to do that generate and consume IS-IS packets? Don't we also need to produce consistent routing tables for the two letter protocol? If we let SPF computations run without check, or delay SPF computations unduly, doesn't that effect convergence adversly, through slow flooding in the first case, and slow updates to our tables in the second. It is a distributed algorithm, so you are guaranteed to have transient disagreements between machines given the protocol design. Guarantees of a loop-free, black-hole-free network are outside the scope of the spec (and indeed are not possible.) I think the best you can hope for in this case is a statement to the effect that "reasonably synchronous route installation is a virtue" and leave it at that. Anything else will constrain implementation in one direction or the other. --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 15:54:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29239 for ; Fri, 11 Jan 2002 15:54:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BKoB170944; Fri, 11 Jan 2002 12:50:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BKnh170929 for ; Fri, 11 Jan 2002 12:49:43 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA18401; Fri, 11 Jan 2002 12:52:16 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 12:52:16 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F702@avalon.pluris.com> From: Les Ginsberg To: "'Dong Ha '" , "'IS-IS-WG (E-mail) '" Subject: RE: [Isis-wg] LSP with size bigger than ReceiveLSPBufferSize MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 12:52:15 -0800 ISO 10589:1992 7.3.14.2 clearly states: "If a ... PDU larger than this size is received, it shall be treated as if it had an invalid checksum (i.e. ignored by the Update Process..." As per earlier discissions, LSPs w invalid checksums are simply dropped (no ACK, no propagation). Les -----Original Message----- From: Dong Ha To: IS-IS-WG (E-mail) Sent: 1/11/02 11:25 AM Subject: [Isis-wg] LSP with size bigger than ReceiveLSPBufferSize Hi all, Can anyone tell me what a router should do when it receives a LSP with size bigger than the ReceiveLSPBufferSize? Should it forward to other routers or not? The ISO 10589 says the LSP should be treated as if it has expired lifetime but I couldn't find any information about wheather or not it should be forwarded to other routers. Thanks. -dong __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 16:16:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29877 for ; Fri, 11 Jan 2002 16:16:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BLB1171051; Fri, 11 Jan 2002 13:11:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BLAF171039 for ; Fri, 11 Jan 2002 13:10:15 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , "'Dong Ha '" , "'IS-IS-WG (E-mail) '" Subject: RE: [Isis-wg] LSP with size bigger than ReceiveLSPBufferSize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 16:12:22 -0500 > > Can anyone tell me what a router should do when it > > receives a LSP with size bigger than the > > ReceiveLSPBufferSize? > > > > dong > "If a ... PDU larger than this size is received, it shall be > ..... simply dropped > > Les ...and the 07 MIB defines a trap to be sent. This is Bad News that represents either a munged packet or serious missconfiguration: inconsistent max buffer sizes, or incompatible areas leaking together. - jeff parker - axiowave networks isisOriginatingLSPBufferSizeMismatch NOTIFICATION-TYPE OBJECTS { isisOriginatingBufferSize, isisSystemLevel, isisTrapLSPID, isisCircIfIndex } STATUS current DESCRIPTION "A notification sent when a Level 1 LSP or Level 2 LSP is received which is larger than the local value for originatingL1LSPBufferSize or originatingL2LSPBufferSize respectively, or when a Level 1 LSP or Level2 LSP is received containing the originatingLSPBufferSize option and the value in the PDU option field does not match the local value for originatingL1LSPBufferSize or originatingL2LSPBufferSize respectively. We pass up the size from the option field or the size of the LSP that exceeds our configuration. This should be an edge-triggered notification. We should not send a second notification about PDUs received from the same source." ::= { isisTrapPrefix 15 } _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 16:33:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00332 for ; Fri, 11 Jan 2002 16:33:27 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BLT8171169; Fri, 11 Jan 2002 13:29:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BLGg171084 for ; Fri, 11 Jan 2002 13:16:42 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0BLJG234876 for ; Fri, 11 Jan 2002 13:19:16 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Jan 2002 13:17:46 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g0BLHsF22459 for ; Fri, 11 Jan 2002 13:17:54 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id NAA27627 for ; Fri, 11 Jan 2002 13:17:52 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id NAA04607 for ; Fri, 11 Jan 2002 13:24:30 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfNAA04595 for <>; Fri Jan 11 13:21:07 2002 Received: from ems11 by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g0BLAPv17982 for ; Fri, 11 Jan 2002 13:10:25 -0800 (PST) Received: by localhost with Microsoft MAPI; Fri, 11 Jan 2002 10:19:43 -0800 Message-ID: <01C19A89.7CC38530.ramsrm@tdd.sj.nec.com> From: ramanathan ramasamy Reply-To: "ramsrm@tdd.sj.nec.com" To: "'isis-wg@juniper.net'" Subject: RE: [Isis-wg] Point to point adjacency down. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 51 TEXT X-OriginalArrivalTime: 11 Jan 2002 21:17:46.0312 (UTC) FILETIME=[6A34D480:01C19AE5] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 10:19:42 -0800 hi all, I agree with Mr. Jeff, we could see the inconistency in the database because of delaying the SPF computation and it will lead to incorrect routing for the packets arriving during that period of time. So it is better to have a standard governing thinks like this. The same problem could occur in OSPF also, there is no mib variable governing the SPF calculation. If we introduce this variable in ISIS, we can improve the convergence in ISIS. If a service provider deploys ISIS routers from different vendors, this problem may be a big bottle neck. Thanks rams. -----Original Message----- From: Jeff Parker [SMTP:jparker@axiowave.com] Sent: Friday, January 11, 2002 11:23 AM To: 'Tony Przygienda'; Dave Katz Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Point to point adjacency down. > > This strays into the area of creative implementation possibilities. > > I suspect that a MIB variable with a scalar value that is expected > > to be stable does not accurately represent either of the dominant > > implementations. > > It is superfluous, restricting and confusing to try to > govern internal implementation details ... > correct ISIS packets to the wire [is our only goal] > > -- tony Tony - I can accept that this is off task behavior, but I must ask a clarifying question. Don't we have more to do that generate and consume IS-IS packets? Don't we also need to produce consistent routing tables for the two letter protocol? If we let SPF computations run without check, or delay SPF computations unduly, doesn't that effect convergence adversly, through slow flooding in the first case, and slow updates to our tables in the second. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 17:17:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01700 for ; Fri, 11 Jan 2002 17:17:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BMCC171400; Fri, 11 Jan 2002 14:12:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web14909.mail.yahoo.com (web14909.mail.yahoo.com [216.136.225.61]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g0BLrd171309 for ; Fri, 11 Jan 2002 13:53:39 -0800 (PST) (envelope-from donkiha@yahoo.com) Message-ID: <20020111215613.80241.qmail@web14909.mail.yahoo.com> Received: from [12.104.224.46] by web14909.mail.yahoo.com via HTTP; Fri, 11 Jan 2002 13:56:13 PST From: Dong Ha Subject: RE: [Isis-wg] LSP with size bigger than ReceiveLSPBufferSize To: Les Ginsberg , "'IS-IS-WG \(E-mail\) '" In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F702@avalon.pluris.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 13:56:13 -0800 (PST) Hi, The spec also mentions something about sending out LSP with zero LSP number and zero checksum. Would this be applied in this case? Thanks. Dong --- Les Ginsberg wrote: > ISO 10589:1992 7.3.14.2 clearly states: > > "If a ... PDU larger than this size is received, it > shall be treated as if > it had an invalid checksum (i.e. ignored by the > Update Process..." > > As per earlier discissions, LSPs w invalid checksums > are simply dropped (no > ACK, no propagation). > > Les > > > -----Original Message----- > From: Dong Ha > To: IS-IS-WG (E-mail) > Sent: 1/11/02 11:25 AM > Subject: [Isis-wg] LSP with size bigger than > ReceiveLSPBufferSize > > Hi all, > > Can anyone tell me what a router should do when it > receives a LSP with size bigger than the > ReceiveLSPBufferSize? Should it forward to other > routers or not? The ISO 10589 says the LSP should be > treated as if it has expired lifetime but I couldn't > find any information about wheather or not it should > be forwarded to other routers. Thanks. > > -dong > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > _______________________________________________ > Isis-wg mailing list - > Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 17:33:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02138 for ; Fri, 11 Jan 2002 17:33:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BMTB171505; Fri, 11 Jan 2002 14:29:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BMDv171410 for ; Fri, 11 Jan 2002 14:13:57 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0BMGV654253; Fri, 11 Jan 2002 14:16:31 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0BMFSV91664; Fri, 11 Jan 2002 14:15:28 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201112215.g0BMFSV91664@cirrus.juniper.net> From: Dave Katz To: ramsrm@tdd.sj.nec.com CC: isis-wg@juniper.net In-reply-to: <01C19A89.7CC38530.ramsrm@tdd.sj.nec.com> (message from ramanathan ramasamy on Fri, 11 Jan 2002 10:19:42 -0800) Subject: Re: [Isis-wg] Point to point adjacency down. References: <01C19A89.7CC38530.ramsrm@tdd.sj.nec.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 14:15:28 -0800 (PST) I agree with Mr. Jeff, we could see the inconistency in the database because of delaying the SPF computation and it will lead to incorrect routing for the packets arriving during that period of time. So it is better to have a standard governing thinks like this. The same problem could occur in OSPF also, there is no mib variable governing the SPF calculation. If we introduce this variable in ISIS, we can improve the convergence in ISIS. If a service provider deploys ISIS routers from different vendors, this problem may be a big bottle neck. Sorry, no. All you will do is either penalize the vendors who know how to do this stuff well (and who will simply ignore the standard based on competitive reasons) or you will penalize the vendors who cannot do it well enough (who will ignore the standard based on practical reasons.) Smart vendors will provide enough configuration flexibility to work well with the least common denominator. Synchronized SPFs are a fiction in a network of any significant size anyhow. It is foolish to attempt fix *perceived* operational problems by attempting to standarize out of them, when such a standard, if adhered to, would create other operational problems. Furthermore, as Dave Oran was fond of noting, for every 100 possible random knob settings in a router, only 1 actually results in a functional network. Things like this are best left to the operators to decide whether or not they have a problem, and to work with their vendors to ameliorate the problem if in fact one exists. --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 18:44:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03032 for ; Fri, 11 Jan 2002 18:44:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BNe2171839; Fri, 11 Jan 2002 15:40:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0BNdR171824 for ; Fri, 11 Jan 2002 15:39:27 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0BNg2239047 for ; Fri, 11 Jan 2002 15:42:02 -0800 (PST) X-JNPR-Received-From: outside Received: from relay1.nexsi.com ([66.35.205.133]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Jan 2002 15:40:08 -0800 Received: from mail.nexsi.com (ripper1.nexsi.com [66.35.212.35]) by relay1.nexsi.com (Postfix) with ESMTP id E2F2B3F68; Fri, 11 Jan 2002 15:43:05 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id PAA28820; Fri, 11 Jan 2002 15:44:09 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <143710891377.20020111153929@nexsi.com> To: ramanathan ramasamy Cc: "'isis-wg@juniper.net'" Subject: Re: [Isis-wg] Point to point adjacency down. In-Reply-To: <01C19A89.7CC38530.ramsrm@tdd.sj.nec.com> References: <01C19A89.7CC38530.ramsrm@tdd.sj.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2002 23:40:08.0296 (UTC) FILETIME=[4DA02680:01C19AF9] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 15:39:29 -0800 Content-Transfer-Encoding: 7bit Just to make sure we're on the same page, *specifying* how SPF should be scheduled is useless as Tony and Dave explained. Giving clue in an informational form might help people who are new to the topic do things not as bad as they could be done (yes, there are much more places besides this where one can stumble). MIB-wise, if you don't know semantics of a specific value from a specific vendor, it is useless at least in case of that specific vendor, don't know how about others... But again, I would care if I actually used MIBs to configure routers :) -- Alex Zinin Friday, January 11, 2002, 10:19:42 AM, ramanathan ramasamy wrote: > hi all, > I agree with Mr. Jeff, we could see the inconistency in the database > because of delaying the SPF computation and it will lead to incorrect > routing for the packets arriving during that period of time. So it is > better to have a standard governing thinks like this. The same problem > could occur in OSPF also, there is no mib variable governing the SPF > calculation. If we introduce this variable in ISIS, we can improve the > convergence in ISIS. If a service provider deploys ISIS routers from > different vendors, this problem may be a big bottle neck. > Thanks > rams. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 19:51:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03898 for ; Fri, 11 Jan 2002 19:51:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0C0l1172140; Fri, 11 Jan 2002 16:47:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0C0kp172128 for ; Fri, 11 Jan 2002 16:46:51 -0800 (PST) (envelope-from prz@redback.com) Received: from redback.com ([63.200.51.152]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GPS00A2DVMDQL@mta5.snfc21.pbi.net> for isis-wg@spider.juniper.net; Fri, 11 Jan 2002 16:49:26 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] Point to point adjacency down. To: Dave Katz Cc: azinin@nexsi.com, jparker@axiowave.com, ramsrm@tdd.sj.nec.com, isis-wg@spider.juniper.net Message-id: <3C3F748E.FA215F9B@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200201111713.g0BHD0T90686@cirrus.juniper.net> <2694482272.20020111110559@nexsi.com> <200201111940.g0BJeFS91168@cirrus.juniper.net> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 15:26:06 -0800 Content-Transfer-Encoding: 7BIT Dave Katz wrote: > I'm also thinking: if I were using MIB to monitor/configure routers, > I guess I would like to see a variable/variables reflecting the SPF > back-off values. Unless implementations diverge dramatically (e.g., > one is using exp, another sqrt ;), it seems to me there should be > a way to do so... In the worst scenario, we could have "opaque" > variables with well-defined syntax, but flexible semantics. > > Exponential SPF backoff is a red herring, but that's a good over-beer > rant. > > In general, there is no way in a MIB to generalize this sufficiently > to capture all the possibilities while actually being useful for > something. At best, we'll just lie about the values. I guarantee > that you won't capture my semantics that way, but that's fine, since I > won't tell you anyhow, and nobody but me needs to know. > > But then if you're using a MIB to configure a router, please party on. ;-) > (See previous rant.) there are things called vendor-specific MIBs and that's where this kind of stuff goes into. If at all ... - -tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 11 20:55:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04374 for ; Fri, 11 Jan 2002 20:55:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0C1p5172447; Fri, 11 Jan 2002 17:51:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0C1j1172415 for ; Fri, 11 Jan 2002 17:45:01 -0800 (PST) (envelope-from prz@redback.com) Received: from redback.com ([63.200.51.152]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GPS0002OYBBO2@mta6.snfc21.pbi.net> for isis-wg@spider.juniper.net; Fri, 11 Jan 2002 17:47:36 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] Point to point adjacency down. To: Dave Katz Cc: jparker@axiowave.com, ramsrm@tdd.sj.nec.com, isis-wg@spider.juniper.net Message-id: <3C3F822F.70F616BB@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200201111713.g0BHD0T90686@cirrus.juniper.net> <3C3F2585.3A45FC9F@redback.com> <200201111944.g0BJidA91180@cirrus.juniper.net> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 16:24:15 -0800 Content-Transfer-Encoding: 7BIT Dave Katz wrote: > Hey, who told you about my LGM algorithm? Good thing I've got a patent. ;-) > > But seriously, thanks for stating this less curtly than I would. The > IETF has a long history of being confused about what is subject to > standardization and what is not (the OSPF spec is a work of art in > that respect--it's a great implementation guide, but 90% of it is not > normative. This turns out to be a competitive advantage, since the > implementation strategy it outlines has some serious scaling > limitations, so I don't complain. Much.) > yepp, implementation guidelines are something different from BCP and we should stay out of those in this group, please. Again, this group's goal is to specify/document aspect of the protocol that guarantee . interoperability . correctness . integrity (convergence is a sub-aspect of that) . some general aspects of robustness (e.g. self-stabilization) and scalability (e.g. keeping number of timer keyed pieces of state bound) . guidelines as to deployment scenarios of the protocol We have no business to specify things that affect/improve . efficiency . fairness . predictability those will be taken care of by good implementations. Things like implementaion-guidelines groups for protocols have been tried and mostly miserably failed. Too much vendor-specific knowledge on stake ... thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 12 14:39:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23314 for ; Sat, 12 Jan 2002 14:39:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0CJX1179769; Sat, 12 Jan 2002 11:33:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from gnat.inet.org ([63.108.254.91]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0CJWs179757 for ; Sat, 12 Jan 2002 11:32:54 -0800 (PST) (envelope-from rja@extremenetworks.com) Received: from localhost (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 11D5C67103; Sat, 12 Jan 2002 14:48:40 -0500 (EST) Subject: Re: [Isis-wg] Point to point adjacency down. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: isis-wg@spider.juniper.net To: Tony Przygienda From: RJ Atkinson In-Reply-To: <3C3F2585.3A45FC9F@redback.com> Message-Id: <8797436E-0793-11D6-8CBE-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 12 Jan 2002 14:35:27 -0500 Content-Transfer-Encoding: 7bit On Friday, January 11, 2002, at 12:48 PM, Tony Przygienda wrote: > taking the danger of repeating trivia, > yes, please do not forget that a protocol specification is governing > the _external_ behavior of the protocol, so basically what and when > you see on the wire (and some of the internal but > only to the extent that guarantees interoperability, e.g. due to > hop-by-hop > paradigm everyone has to run an algorithm that delivers the same > forwarding decisions, in source-routed paradigms that may not be > necessary). Tony, Moderation in all things. Let us please try to include a bit more documentation with IS-IS than IDR has (historically) done with BGP. The BGP specs are insufficiently complete for an otherwise clueful BGP implementer to fully interoperate with the leading 2 deployed BGPs. While that is financially beneficial for those small set of folks "in the know", it does not represent good protocol specification or the best of the IETF. (And yes, at least a couple folks here will have sharp objection to these words, since a small few folks think BGP is already at the right level of specification). > It is superfluous, restricting and confusing to try to > govern internal implementation details as of how this behavior is > being achieved beside giving a reference model for description purposes. A clear and complete reference model is always helpful, provided it is clearly marked as an informational reference model rather than a normative implementation constraint. If someone wants to publish an informational document with some implementation hints, then that ought not be blocked by this WG (and whether anyone else follows those hints ought to be left as a personal decision for each reader of such a document). A feature of the revised IPsec documents was that Steve Kent added such a reference model, without making it normative. This made the intent of the protocols much more clear. Regrettably, other things were broken in that editorial pass of IPsec, but adding the reference model was itself a good thing (and adding it didn't break anything). > Literally, if little green men carry things around in > water buckets in some implementations and manage to deliver > correct ISIS packets to the wire, that's ok (of course they must be paid > minimum wage but that's not our problem ;-) .... IETF operates globally. Not all locations have the concept of a minimum wage, so that's an implementation choice outside our scope. :-) :-) Ran rja@extremenetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 14 10:19:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03916 for ; Mon, 14 Jan 2002 10:19:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0EFD1191105; Mon, 14 Jan 2002 07:13:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0EFCo191093 for ; Mon, 14 Jan 2002 07:12:50 -0800 (PST) (envelope-from canningt@nortelnetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0EFFf278165 for ; Mon, 14 Jan 2002 07:15:41 -0800 (PST) X-JNPR-Received-From: outside Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Jan 2002 07:12:36 -0800 Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0EFCnK07929; Mon, 14 Jan 2002 10:12:50 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0EFCWn02860; Mon, 14 Jan 2002 15:12:33 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 15:12:58 -0000 Message-ID: <17A46A8BD7E7D41199E300508BE3A94C02D1AC77@zirey00b.europe.nortel.com> From: "Terry Canning" To: Ravindra Sunkad , isis-wg@juniper.net Subject: RE: [Isis-wg] 3-way handshake question MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D0D.F2AFFCC0" X-OriginalArrivalTime: 14 Jan 2002 15:12:36.0515 (UTC) FILETIME=[E6305F30:01C19D0D] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 14 Jan 2002 15:12:57 -0000 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. ------_=_NextPart_001_01C19D0D.F2AFFCC0 Content-Type: text/plain Hi Ravi It isn't particularly clear from the spec but I believe that we no longer need to compute the legacy circuit ID nor do we need to check it, because it is used to inform us of a change of point to point peer. This is no longer needed as the circuit ID specified in the new TLV does this job for us. As such, I believe that the new TLV obseletes the old circuit ID as specified in a point to point LSP Regards Terry -----Original Message----- From: Ravindra Sunkad [mailto:Ravindra.Sunkad@vivacenetworks.com] Sent: 08 January 2002 20:19 To: isis-wg@juniper.net Subject: [Isis-wg] 3-way handshake question Hi, Clause c) of Section 3.2 requires skipping sections 8.2.4.2 c) and d) of 10589. However the CircuitID calculated in 8.2.4.2 c) is used for the removal of excess paths during the decision process. See section 7.2.7 of 10589. So, how is the ptptCircuitID computed for circuits over which an adjacency is established using the 3-way handshake? And how is this ptptCircuitID comparable to the ptptCircuitID computed for a circuit that has a 2-way adjacency? Thanks, Ravi ------_=_NextPart_001_01C19D0D.F2AFFCC0 Content-Type: text/html Message
Hi Ravi
It isn't particularly clear from the spec but I believe that we no longer need to compute the legacy circuit ID nor do we need to check it, because it is used to inform us of a change of point to point peer. This is no longer needed as the circuit ID specified in the new TLV does this job for us.
 
As such, I believe that the new TLV obseletes the old circuit ID as specified in a point to point LSP
 
Regards
Terry
 
 
 -----Original Message-----
From: Ravindra Sunkad [mailto:Ravindra.Sunkad@vivacenetworks.com]
Sent: 08 January 2002 20:19
To: isis-wg@juniper.net
Subject: [Isis-wg] 3-way handshake question

Hi,
 
Clause c) of Section 3.2 requires skipping sections 8.2.4.2 c) and d) of 10589.
However the CircuitID calculated in 8.2.4.2 c) is used for the removal of
excess paths during the decision process. See section 7.2.7 of 10589.
 
So, how is the ptptCircuitID computed for circuits over which an adjacency is established using the 3-way handshake? And how is this ptptCircuitID comparable to the ptptCircuitID computed for a circuit that has a 2-way adjacency?
 
Thanks,
Ravi
 
 
------_=_NextPart_001_01C19D0D.F2AFFCC0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 14 12:31:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08447 for ; Mon, 14 Jan 2002 12:31:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0EHQ4191695; Mon, 14 Jan 2002 09:26:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0EHLp191666 for ; Mon, 14 Jan 2002 09:21:51 -0800 (PST) (envelope-from Sanjay.Harwani@marconi.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0EHOh281266 for ; Mon, 14 Jan 2002 09:24:43 -0800 (PST) X-JNPR-Received-From: outside Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Jan 2002 09:24:04 -0800 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA17518 for ; Mon, 14 Jan 2002 12:24:17 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06659 for ; Mon, 14 Jan 2002 12:24:18 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Jan 2002 12:24:17 -0500 Message-ID: <313680C9A886D511A06000204840E1CF529A78@whq-msgusr-02.pit.comms.marconi.com> From: "Harwani, Sanjay" To: isis-wg@juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D20.48622370" X-OriginalArrivalTime: 14 Jan 2002 17:24:05.0171 (UTC) FILETIME=[4431C030:01C19D20] Subject: [Isis-wg] loopback and passive interfaces Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 14 Jan 2002 12:24:12 -0500 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. ------_=_NextPart_001_01C19D20.48622370 Content-Type: text/plain; charset="iso-8859-1" Hi, How should isis handle loopback and passive interfaces ? Can somebody please point me in the right direction. Thanks in advance Sanjay ------_=_NextPart_001_01C19D20.48622370 Content-Type: text/html; charset="iso-8859-1" Message
Hi,
 
How should isis handle loopback and passive interfaces ?
Can somebody please point me in the right direction.
 
Thanks in advance
Sanjay
------_=_NextPart_001_01C19D20.48622370-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 14 17:00:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21373 for ; Mon, 14 Jan 2002 17:00:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ELt8192887; Mon, 14 Jan 2002 13:55:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ELeG192812 for ; Mon, 14 Jan 2002 13:40:16 -0800 (PST) (envelope-from prz@redback.com) Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id 9318E1DCC73; Mon, 14 Jan 2002 13:43:09 -0800 (PST) Message-ID: <3C433D51.D68087F4@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: RJ Atkinson Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Point to point adjacency down. References: <8797436E-0793-11D6-8CBE-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 14 Jan 2002 12:19:30 -0800 Content-Transfer-Encoding: 7bit RJ Atkinson wrote: > > It is superfluous, restricting and confusing to try to > > govern internal implementation details as of how this behavior is > > being achieved beside giving a reference model for description purposes. > > A clear and complete reference model is always helpful, provided it is > clearly marked as an informational reference model rather than a > normative > implementation constraint. If someone wants to publish an informational > document with some implementation hints, then that ought not be blocked > by this WG (and whether anyone else follows those hints ought to be left > as a personal decision for each reader of such a document). RJA, we agree in spirit here, however on the particular case of SPF thresholds that led to that thread, it does not make sense to make it normative or even include it in the reference model IMHO. Good reference model follows Occam's razor in a good spec so it is as simple as possible and only fleshed out to the point where the spec becomes understandable. SPF thresholds are falling out from real deployment and whether they do/do not make sense depends heavily on the size and structure of the network as well as how 'reactive' the network should be so it's not clear whether certain implementations need it, need it configurable and what to configure things to. As well, SPF thresholds are only one way to apply hysterisis on flooding and following internal computations and other ways are thinkable and doable. -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 14 19:55:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27788 for ; Mon, 14 Jan 2002 19:55:41 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0F0oL193700; Mon, 14 Jan 2002 16:50:21 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09IeF155853 for ; Wed, 9 Jan 2002 10:40:15 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g09IgaG64572 for ; Wed, 9 Jan 2002 10:42:36 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 9 Jan 2002 10:42:24 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g09IgUF12485 for ; Wed, 9 Jan 2002 10:42:30 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id KAA11665 for ; Wed, 9 Jan 2002 10:42:28 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id KAA27955 for ; Wed, 9 Jan 2002 10:48:58 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfKAA27943 for <>; Wed Jan 9 10:44:36 2002 Received: from ems11 by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g09IY0v24291 for ; Wed, 9 Jan 2002 10:34:00 -0800 (PST) Received: by localhost with Microsoft MAPI; Wed, 9 Jan 2002 07:43:14 -0800 Message-ID: <01C198E1.4B45BE50.ramsrm@tdd.sj.nec.com> From: ramanathan ramasamy Reply-To: "ramsrm@tdd.sj.nec.com" To: "'isis-wg@juniper.net'" X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 13 TEXT X-OriginalArrivalTime: 09 Jan 2002 18:42:24.0703 (UTC) FILETIME=[6144ACF0:01C1993D] Subject: [Isis-wg] pseudonode LSPs Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 07:43:12 -0800 Hi all, I have the following doubt in ISIS for IP. * In Pseudonode LSP, according to RFC 1195 sec 4.3, we won't be listing any IP reachability field( because of logical subnetting probelem). Then what is the purpose of retaining Psuedonode LSP concept in ISIS for IP. What will it contain? What is it used for? - is it there to maintain compatability in case of Integrated ISIS? Thanks rams. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 14 20:49:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29006 for ; Mon, 14 Jan 2002 20:49:41 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0F1jB193977; Mon, 14 Jan 2002 17:45:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0F1WM193913 for ; Mon, 14 Jan 2002 17:32:22 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0F1ZH297882 for ; Mon, 14 Jan 2002 17:35:17 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Jan 2002 17:28:14 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g0F1SPM15459 for ; Mon, 14 Jan 2002 17:28:25 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id RAA09084 for ; Mon, 14 Jan 2002 17:28:23 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id RAA11086 for ; Mon, 14 Jan 2002 17:35:14 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfRAA11083 for <>; Mon Jan 14 17:33:34 2002 Received: from ems11 by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g0F1MUv14386 for ; Mon, 14 Jan 2002 17:22:30 -0800 (PST) Received: by localhost with Microsoft MAPI; Mon, 14 Jan 2002 14:31:55 -0800 Message-ID: <01C19D08.373F0260.ramsrm@tdd.sj.nec.com> From: ramanathan ramasamy Reply-To: "ramsrm@tdd.sj.nec.com" To: "'isis-wg@juniper.net'" X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 0 TEXT X-OriginalArrivalTime: 15 Jan 2002 01:28:14.0656 (UTC) FILETIME=[E7096400:01C19D63] Subject: [Isis-wg] please ignore my mail on psuedo node LSPS. Something accidently happend. sorry for the inconveneince Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 14 Jan 2002 14:31:54 -0800 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 15 14:27:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10574 for ; Tue, 15 Jan 2002 14:27:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0FJKj199016; Tue, 15 Jan 2002 11:20:45 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g09IeF155853 for ; Wed, 9 Jan 2002 10:40:15 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g09IgaG64572 for ; Wed, 9 Jan 2002 10:42:36 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 9 Jan 2002 10:42:24 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g09IgUF12485 for ; Wed, 9 Jan 2002 10:42:30 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id KAA11665 for ; Wed, 9 Jan 2002 10:42:28 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id KAA27955 for ; Wed, 9 Jan 2002 10:48:58 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfKAA27943 for <>; Wed Jan 9 10:44:36 2002 Received: from ems11 by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g09IY0v24291 for ; Wed, 9 Jan 2002 10:34:00 -0800 (PST) Received: by localhost with Microsoft MAPI; Wed, 9 Jan 2002 07:43:14 -0800 Message-ID: <01C198E1.4B45BE50.ramsrm@tdd.sj.nec.com> From: ramanathan ramasamy Reply-To: "ramsrm@tdd.sj.nec.com" To: "'isis-wg@juniper.net'" X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 13 TEXT X-OriginalArrivalTime: 09 Jan 2002 18:42:24.0703 (UTC) FILETIME=[6144ACF0:01C1993D] Subject: [Isis-wg] pseudonode LSPs Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 07:43:12 -0800 Hi all, I have the following doubt in ISIS for IP. * In Pseudonode LSP, according to RFC 1195 sec 4.3, we won't be listing any IP reachability field( because of logical subnetting probelem). Then what is the purpose of retaining Psuedonode LSP concept in ISIS for IP. What will it contain? What is it used for? - is it there to maintain compatability in case of Integrated ISIS? Thanks rams. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 15 14:29:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10618 for ; Tue, 15 Jan 2002 14:29:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0FJPD199114; Tue, 15 Jan 2002 11:25:13 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ENwW193420 for ; Mon, 14 Jan 2002 15:58:32 -0800 (PST) (envelope-from hannes@ghostrider.gredler.at) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0F01Q295080 for ; Mon, 14 Jan 2002 16:01:26 -0800 (PST) X-JNPR-Received-From: outside Received: from ghostrider.gredler.at ([193.83.223.228]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Jan 2002 15:50:18 -0800 Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id AAA27164; Tue, 15 Jan 2002 00:50:25 +0100 From: Hannes Gredler To: "Harwani, Sanjay" Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] loopback and passive interfaces Message-ID: <20020115005025.A27158@juniper.net> References: <313680C9A886D511A06000204840E1CF529A78@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <313680C9A886D511A06000204840E1CF529A78@whq-msgusr-02.pit.comms.marconi.com>; from Sanjay.Harwani@marconi.com on Mon, Jan 14, 2002 at 12:24:12PM -0500 X-OriginalArrivalTime: 14 Jan 2002 23:50:18.0390 (UTC) FILETIME=[38825B60:01C19D56] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 Jan 2002 00:50:25 +0100 On Mon, Jan 14, 2002 at 12:24:12PM -0500, Harwani, Sanjay wrote: | Hi, | | How should isis handle loopback and passive interfaces ? | Can somebody please point me in the right direction. | | Thanks in advance | Sanjay just advertise the IPv{4,6} prefixes found on the respective circuits in a. int IP reach TLV b. extd IP reach TLV c. both TLVs /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 15 14:32:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10773 for ; Tue, 15 Jan 2002 14:32:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0FJST199202; Tue, 15 Jan 2002 11:28:29 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0FBdL197046 for ; Tue, 15 Jan 2002 03:39:30 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0FBgI208704 for ; Tue, 15 Jan 2002 03:42:18 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 15 Jan 2002 03:27:00 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17617; Tue, 15 Jan 2002 06:27:16 -0500 (EST) Message-Id: <200201151127.GAA17617@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 15 Jan 2002 11:27:00.0875 (UTC) FILETIME=[8CBB5DB0:01C19DB7] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-07.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 Jan 2002 06:27:15 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Management Information Base for IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-wg-mib-07.txt Pages : 79 Date : 14-Jan-02 This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020114174840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020114174840.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 15 14:34:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10861 for ; Tue, 15 Jan 2002 14:34:34 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0FJU7199242; Tue, 15 Jan 2002 11:30:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0FG3x198172 for ; Tue, 15 Jan 2002 08:03:59 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Manral, Vishwas'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] draft-ietf-isis-wg-mib-07 submitted MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 Jan 2002 11:06:16 -0500 > Jeff, > > Would it be advisable to make Attached bit configureable? Possible, but not advisable. > I hear it is configureable in some routers already > (or does this too stray in the area of > creative implementations). ;-) > > Any reason why we cant make the MaxAge configureable yet? > (Is it because we do not want to violate the specs till > a new document comes which wrongs the > previous, but the hello multiplier already violates that) > > Thanks, > Vishwas I don't see a big demand for it. Even if you only want to read the value, it is probably enough to look at the LSPs that the router originates to see what he is using. But I could be wrong: let's see if this is what people have been waiting for. List? - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 15 15:02:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11553 for ; Tue, 15 Jan 2002 15:02:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0FJv1199483; Tue, 15 Jan 2002 11:57:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0FJuG199469 for ; Tue, 15 Jan 2002 11:56:16 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0FJxF220100 for ; Tue, 15 Jan 2002 11:59:15 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 15 Jan 2002 11:58:21 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g0FJwWM06231 for ; Tue, 15 Jan 2002 11:58:32 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id LAA25325 for ; Tue, 15 Jan 2002 11:58:31 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id MAA13518 for ; Tue, 15 Jan 2002 12:05:25 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfMAA13515 for <>; Tue Jan 15 12:04:49 2002 Received: from ems11 by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g0FJrev23444 for ; Tue, 15 Jan 2002 11:53:41 -0800 (PST) Received: by localhost with Microsoft MAPI; Tue, 15 Jan 2002 09:03:08 -0800 Message-ID: <01C19DA3.73614870.ramsrm@tdd.sj.nec.com> From: ramanathan ramasamy Reply-To: "ramsrm@tdd.sj.nec.com" To: "'isis-wg@juniper.net'" X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 0 TEXT X-OriginalArrivalTime: 15 Jan 2002 19:58:21.0234 (UTC) FILETIME=[FBA6A120:01C19DFE] Subject: [Isis-wg] I think, there is some problem in my mail box, so that psuedonode LSP mail is automatically generated again and again. Let me fix it up. sorry for the inconvenience. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 Jan 2002 09:03:06 -0800 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 15 15:11:41 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11812 for ; Tue, 15 Jan 2002 15:11:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0FK71199551; Tue, 15 Jan 2002 12:07:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0F3pk194542 for ; Mon, 14 Jan 2002 19:51:46 -0800 (PST) (envelope-from ruwhite@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0F3sf200645 for ; Mon, 14 Jan 2002 19:54:41 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([64.102.17.77]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Jan 2002 19:46:10 -0800 Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA15259; Mon, 14 Jan 2002 22:46:20 -0500 (EST) From: Russ White Reply-To: Russ White To: ramanathan ramasamy cc: "'isis-wg@juniper.net'" Subject: Re: [Isis-wg] pseudonode LSPs In-Reply-To: <01C198E1.4B45BE50.ramsrm@tdd.sj.nec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 15 Jan 2002 03:46:10.0375 (UTC) FILETIME=[2BBFE570:01C19D77] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 14 Jan 2002 22:46:20 -0500 (EST) You still advertise reachability to all the other is' on the same segment, so it still works the same way--you don't need the ip informaiton for connectivity to other nodes int he tree, just to leaves, and the pnode won't ever be a leaf, or at least not that I can figure out. :-) Russ On Wed, 9 Jan 2002, ramanathan ramasamy wrote: > Hi all, > > I have the following doubt in ISIS for IP. > > * In Pseudonode LSP, according to RFC 1195 sec 4.3, we won't be listing > any IP reachability field( because of logical subnetting probelem). > Then what is the purpose of retaining Psuedonode LSP concept in ISIS > for IP. What will it contain? What is it used for? - is it there to > maintain compatability in case of Integrated ISIS? > > > Thanks > rams. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _____________________________ riw@cisco.com <>< Grace Alone _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 15 19:41:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17177 for ; Tue, 15 Jan 2002 19:40:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0G0a1100824; Tue, 15 Jan 2002 16:36:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0G0Zw100812 for ; Tue, 15 Jan 2002 16:35:58 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0G0cw227646 for ; Tue, 15 Jan 2002 16:38:58 -0800 (PST) X-JNPR-Received-From: outside Received: from yarilo.pluris.com ([208.227.9.200]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 15 Jan 2002 16:31:12 -0800 Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA15786 for ; Tue, 15 Jan 2002 16:31:30 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 16:31:30 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F714@avalon.pluris.com> From: Les Ginsberg To: isis-wg@juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 16 Jan 2002 00:31:12.0328 (UTC) FILETIME=[19955480:01C19E25] Subject: [Isis-wg] RE: draft-ietf-isis-3way-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 15 Jan 2002 16:31:29 -0800 I believe this revision does a fine job of resolving the issues that were raised recently. I have one small, but significant issue with the current text: If the new action is "Up", an adjacencyThreeWayStateChange(Up) event is generated. The use of "adjacencyThreeWayStateChange(Up)" event should be changed to "adjacencyStateChange(Up)" event. While there are differences between the three way adjacency states and the adjacency states defined in 10589, there should be no ambiguity in the adjacency state change events (Up/Down). "Up" means a transition has occurred which allows the neighbor to be advertised in the local LSPs. "Down" means a transition has occurred which requires the neighbor to be removed from the local LSPs. Whether these events occur with or without the use of the 3 way handshake has no bearing. There is no need to define an event specific to three way state and it is in fact invalid to do so. Les _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 15 20:00:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17452 for ; Tue, 15 Jan 2002 20:00:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0G0u4100946; Tue, 15 Jan 2002 16:56:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from smtp.huawei.com ([61.144.161.21]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0G0o8100909 for ; Tue, 15 Jan 2002 16:50:09 -0800 (PST) (envelope-from wangxp@huawei.com) Received: from wangxuepu29436 ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GQ0ADC00.I27 for ; Wed, 16 Jan 2002 08:51:12 +0800 Message-ID: <001f01c19e28$26401960$5b316e0a@huawei.com> From: =?gb2312?B?0afG1Q==?= To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C19E6B.34389FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Isis-wg] about "draft-ietf-isis-wg-mib-06" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:53:01 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C19E6B.34389FE0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG86DQpJbiB0aGUgZHJhZnQtaWV0Zi1pc2lzLXdnLW1pYi0wNix3ZSBkZWZpbmVkIDoNClN5 c3RlbUlEIDo6PSBURVhUVUFMLUNPTlZFTlRJT04NCiAgICAgICBTVEFUVVMgICAgICAgY3VycmVu dA0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgIkEgc3lzdGVtIElELiINCiAgICAgU1lO VEFYICAgICAgICAgICAgT0NURVQgU1RSSU5HIChTSVpFKDAuLjYpKSwNCmJ1dCBJIHRoaW5rIHRo ZSBzaXplIG9mIHRoZSBTeXN0ZW1JRCBzaG91bGQgYmUgYmlnZXIgdGhlIHdlIGRlZmluZWQsIGJl Y2F1c2UgdGhhdCBpbiBjb21tYW5kIGxpbmUgd2UgaW5wdXQgdGhlIG5ldCBzdWNoIGFzICJuZXQg MTAuMTExMS4xMTExLjExMTEuMDAiLHRoZSBTeXN0ZW1JRCBpcyAiMTExMTExMTExMTExIixpbiBw cm90b2NvbCdzIGludGVybmFsIHByb2Nlc3Mgd2UgY2FuIHRyZWF0IGl0IGFzIDYgYnl0ZXMsYnV0 IHdoZW4gd2Ugd2FudCB0byBnZXQgdGhlIHZhbHVlIG9mIFN5c3RlbUlEIGJ5IHRoZSBtYW5hZ2Vt ZW50IHN5c3RlbSx3ZSBjYW4ndCBwdXQgDQp0aGlzIHZhbHVlIGluIGEgb2N0ZXQgc3RyaW5nIHdo aWNoIGlzIG9ubHkgNiBieXRlcyxzaW5jZSB0aGlzIHZhbHVlIHNob3VsZCBiZSAxMiBieXRlIHRv IGRpc3BsYXkuDQpUaGUgc2FtZSBwcm9ibGVtIGlzIGluIHRoZSBPU0lOU0FkZHJlc3MsQ2lyY3Vp dElEIG1heWJlLg0KSXMgdGhhdCByaWdodD8NClRoYW5rIHlvdSENClJlZ2FyZHMNCldhbmcgeHVl cHUNCg0KIA0K ------=_NextPart_000_001C_01C19E6B.34389FE0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IZWxsbzo8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5JbiB0aGUgZHJhZnQtaWV0Zi1pc2lzLXdnLW1pYi0wNix3 ZSANCmRlZmluZWQmbmJzcDs6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+U3lzdGVt SUQgOjo9IA0KVEVYVFVBTC1DT05WRU5USU9OPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANClNUQVRVUyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CmN1cnJlbnQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KREVTQ1JJ UFRJT048QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICJBIHN5c3RlbSANCklELiI8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KU1lO VEFYJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE9DVEVUIA0KU1RSSU5HIChTSVpFKDAuLjYpKSw8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5idXQgSSB0aGluayB0aGUgc2l6ZSBvZiB0aGUgU3lzdGVtSUQgc2hv dWxkIGJlIGJpZ2VyIHRoZSB3ZSANCmRlZmluZWQsIGJlY2F1c2UgdGhhdCBpbiBjb21tYW5kIGxp bmUgd2UgaW5wdXQgdGhlIG5ldCBzdWNoIGFzICJuZXQgDQoxMC4xMTExLjExMTEuMTExMS4wMCIs dGhlIFN5c3RlbUlEIGlzICIxMTExMTExMTExMTEiLGluIHByb3RvY29sJ3MgaW50ZXJuYWwgDQpw cm9jZXNzIHdlIGNhbiB0cmVhdCBpdCBhcyA2IGJ5dGVzLGJ1dCB3aGVuIHdlIHdhbnQgdG8gZ2V0 IHRoZSB2YWx1ZSBvZiBTeXN0ZW1JRCANCmJ5IHRoZSBtYW5hZ2VtZW50IHN5c3RlbSx3ZSBjYW4n dCBwdXQgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+dGhpcyB2YWx1ZSBpbiBhIG9j dGV0IHN0cmluZyB3aGljaCBpcyBvbmx5IDYgYnl0ZXMsc2luY2UgdGhpcyANCnZhbHVlIHNob3Vs ZCBiZSAxMiBieXRlIHRvIGRpc3BsYXkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ VGhlIHNhbWUgcHJvYmxlbSBpcyBpbiB0aGUgT1NJTlNBZGRyZXNzLENpcmN1aXRJRCANCm1heWJl LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPklzIHRoYXQgcmlnaHQ/PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmsgeW91ITwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPlJlZ2FyZHM8QlI+V2FuZyB4dWVwdTwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_001C_01C19E6B.34389FE0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 10:07:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10336 for ; Wed, 16 Jan 2002 10:07:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GF25105225; Wed, 16 Jan 2002 07:02:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEq3105173 for ; Wed, 16 Jan 2002 06:52:04 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "IS-IS-WG (E-mail)" Cc: "'wangxp@huawei.com'" Subject: [Isis-wg] about draft-ietf-isis-wg-mib-06 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 09:55:03 -0500 Wang Xuepu - Use of anything other than plain text on an IETF mailing list should be avoided. > In the draft-ietf-isis-wg-mib-06,we defined : Version 07 just hit the list yesterday: I'd suggest you pick that up. But the issue you mention below is also in version 07. > SystemID ::= TEXTUAL-CONVENTION > ... > SYNTAX OCTET STRING (SIZE(0..6)), > but I think the size of the SystemID should be biger > ... the SystemID is "111111111111", > > Wang xuepu Translating from 12 character Hex to internal Octet string of length 6 is left as an exercise for the implementor. There are standard C libraries that can help. To recap history on this Textual Convention: 10589 suggests that it could be upto 8 bytes Current practice is 6 bytes 0 is left in for cases when we need an empty SystemID There are other Textual Conventions for LSP ID and the like. - jeff parker - axiowave networks - I can't remember if I'm the good twin or the evil one. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 13:16:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16422 for ; Wed, 16 Jan 2002 13:16:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GIB8106075; Wed, 16 Jan 2002 10:11:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GHw1106007 for ; Wed, 16 Jan 2002 09:58:01 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g0GI16G49211 for ; Wed, 16 Jan 2002 10:01:06 -0800 (PST) X-JNPR-Received-From: outside Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 10:00:46 -0800 Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0GI0ur21681; Wed, 16 Jan 2002 13:00:56 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0GI0bx10806; Wed, 16 Jan 2002 18:00:38 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 18:00:53 -0000 Message-ID: <4103264BC8D3D51180B7002048400C45071446@zhard0jd.europe.nortel.com> From: "Philip Christian" To: isis-wg@juniper.net, "'ginsberg@pluris.com'" Subject: RE: [Isis-wg] RE: draft-ietf-isis-3way-04.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19EB7.BDB257B0" X-OriginalArrivalTime: 16 Jan 2002 18:00:46.0859 (UTC) FILETIME=[B9542DB0:01C19EB7] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 18:00:54 -0000 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. ------_=_NextPart_001_01C19EB7.BDB257B0 Content-Type: text/plain; charset="iso-8859-1" Sorry guys, but I have another question on this. I hope it isn't another can of worms. Here is the question. Looking at the table in the draft:- I just want to understand the difference in the output from the table between "Up" and "Accept". Presumably (but not stated), if the output of the table is "Accept", as this is not a valid "three-way" state to advertise in the TLV, then you just continue to advertise "Up". This then means that the difference between "Up" and "Accept" is only that "Up" results in a further action, that the 10589 behaviour changes from whereever it was to "Up", hence the "adjacencystate(up)" event, whereas, "Accept" implies that the 10589 adjacency is already "Up", and so the event isn't needed. If I have understood it correctly, then the "Presumably (but not stated)" bit really should be stated, in my opinion. Have I got this right? Philip > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: 16 January 2002 00:31 > To: isis-wg@juniper.net > Subject: [Isis-wg] RE: draft-ietf-isis-3way-04.txt > > > > I believe this revision does a fine job of resolving the > issues that were > raised recently. > > I have one small, but significant issue with the current text: > > If the new action is "Up", an adjacencyThreeWayStateChange(Up) > event is generated. > > > The use of "adjacencyThreeWayStateChange(Up)" event should be > changed to > "adjacencyStateChange(Up)" event. > > While there are differences between the three way adjacency > states and the > adjacency states defined in 10589, there should be no ambiguity in the > adjacency state change events (Up/Down). "Up" means a transition has > occurred which allows the neighbor to be advertised in the local LSPs. > "Down" means a transition has occurred which requires the > neighbor to be > removed from the local LSPs. Whether these events occur with > or without the > use of the 3 way handshake has no bearing. There is no need > to define an > event specific to three way state and it is in fact invalid to do so. > > Les > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > ------_=_NextPart_001_01C19EB7.BDB257B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] RE: draft-ietf-isis-3way-04.txt

Sorry guys, but I have another question on this. I = hope it isn't
another can of worms. Here is the question.

Looking at the table in the draft:-

I just want to understand the difference in the = output from the
table between "Up" and "Accept". = Presumably (but not stated), if
the output of the table is "Accept", as = this is not a valid
"three-way" state to advertise in the TLV, = then you just continue
to advertise "Up".

This then means that the difference between = "Up" and "Accept" is
only that "Up" results in a further = action, that the 10589
behaviour changes from whereever it was to = "Up", hence the
"adjacencystate(up)" event, whereas, = "Accept" implies that the
10589 adjacency is already "Up", and so = the event isn't needed.

If I have understood it correctly, then the = "Presumably (but not
stated)" bit really should be stated, in my = opinion.

Have I got this right?


Philip


> -----Original Message-----
> From: Les Ginsberg [mailto:ginsberg@pluris.com]
> Sent: 16 January 2002 00:31
> To: isis-wg@juniper.net
> Subject: [Isis-wg] RE: = draft-ietf-isis-3way-04.txt
>
>
>
> I believe this revision does a fine job of = resolving the
> issues that were
> raised recently.
>
> I have one small, but significant issue with = the current text:
>
>         = If the new action is "Up", an = adjacencyThreeWayStateChange(Up)
>         = event is generated.
>
>
> The use of = "adjacencyThreeWayStateChange(Up)" event should be
> changed to
> "adjacencyStateChange(Up)" event. =
>
> While there are differences between the three = way adjacency
> states and the
> adjacency states defined in 10589, there should = be no ambiguity in the
> adjacency state change events (Up/Down). = "Up" means a transition has
> occurred which allows the neighbor to be = advertised in the local LSPs.
> "Down" means a transition has = occurred which requires the
> neighbor to be
> removed from the local LSPs. Whether these = events occur with
> or without the
> use of the 3 way handshake has no bearing. = There is no need
> to define an
> event specific to three way state and it is in = fact invalid to do so.
>
>    Les
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
>

------_=_NextPart_001_01C19EB7.BDB257B0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 14:28:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18451 for ; Wed, 16 Jan 2002 14:28:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GJJ6106408; Wed, 16 Jan 2002 11:19:06 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GIfv106233 for ; Wed, 16 Jan 2002 10:41:57 -0800 (PST) (envelope-from Ming.Chan@SpirentCom.COM) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.1/8.12.1) with ESMTP id g0GIj19E018266; Wed, 16 Jan 2002 08:45:02 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 08:50:55 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D41@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: "'Les Ginsberg'" , "'isis-wg@external.juniper.net'" Cc: "Chan, Chung Ming" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] 2001 revision of ISO 10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:50:54 -1000 >The 2001 revision of ISO 10589 has incorporated this change. Section >7.3.14.2e now reads: > > > "An Intermediate system receiving a Link State PDU with an incorrect >LSP Checksum or with an invalid PDU syntax shall > > 1) generate a corruptedLSPReceived circuit event, > > 2) discard the PDU." Any idea on when the 2001 revision will be available? Thanks ming chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 14:43:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18862 for ; Wed, 16 Jan 2002 14:43:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GJc2106519; Wed, 16 Jan 2002 11:38:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GJbN106502 for ; Wed, 16 Jan 2002 11:37:23 -0800 (PST) (envelope-from oran@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g0GJeSG52783; Wed, 16 Jan 2002 11:40:28 -0800 (PST) X-JNPR-Received-From: outside Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 11:40:09 -0800 Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0GJeMF13510; Wed, 16 Jan 2002 11:40:22 -0800 (PST) Received: from oranlt (sjc-vpn3-352.cisco.com [10.21.65.96]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ABU94971; Wed, 16 Jan 2002 11:40:30 -0800 (PST) From: "David R. Oran" To: "'Dave Katz'" , Cc: Subject: RE: [Isis-wg] Point to point adjacency down. Organization: Cisco Systems Message-ID: <002301c19ec5$a2e05000$50308640@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200201112215.g0BMFSV91664@cirrus.juniper.net> X-OriginalArrivalTime: 16 Jan 2002 19:40:09.0609 (UTC) FILETIME=[9B679F90:01C19EC5] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 14:40:20 -0500 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net] On Behalf Of Dave Katz > Sent: Friday, January 11, 2002 5:15 PM > To: ramsrm@tdd.sj.nec.com > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] Point to point adjacency down. > [snip] > It is foolish to attempt fix *perceived* operational problems > by attempting to standardize out of them, when such a > standard, if adhered to, would create other operational > problems. Furthermore, as Dave Oran was fond of noting, for > every 100 possible random knob settings in a router, only 1 > actually results in a functional network. For completeness, I feel compelled to state the full version of Oran's law of tuning parameters: "There are three types of tuning parameter: 1. Those for which all settings produce identical behavior 2. Those for which only one setting works 3. Those which control whether another tuning parameter operates as type 1 or type 2." Dave O. > Things like this > are best left to the operators to decide whether or not they > have a problem, and to work with their vendors to ameliorate > the problem if in fact one exists. > > --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 14:52:07 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19111 for ; Wed, 16 Jan 2002 14:52:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GJl1106607; Wed, 16 Jan 2002 11:47:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GJhU106570 for ; Wed, 16 Jan 2002 11:43:30 -0800 (PST) (envelope-from Ming.Chan@spirentcom.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GJkZ240795 for ; Wed, 16 Jan 2002 11:46:36 -0800 (PST) X-JNPR-Received-From: outside Received: from Thor.Adtech-Inc.COM ([63.165.80.10]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 11:43:13 -0800 Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.1/8.12.1) with ESMTP id g0GJhV9E021219 for ; Wed, 16 Jan 2002 09:43:31 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 09:49:25 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D44@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: isis-wg@juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 16 Jan 2002 19:43:13.0328 (UTC) FILETIME=[08E8EB00:01C19EC6] Subject: [Isis-wg] FW: 2001 revision of ISO 10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 09:49:24 -1000 >The 2001 revision of ISO 10589 has incorporated this change. Section >7.3.14.2e now reads: > > > "An Intermediate system receiving a Link State PDU with an incorrect >LSP Checksum or with an invalid PDU syntax shall > > 1) generate a corruptedLSPReceived circuit event, > > 2) discard the PDU." Any idea on when the 2001 revision will be available? Thanks ming chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 14:52:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19151 for ; Wed, 16 Jan 2002 14:52:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GJgp106561; Wed, 16 Jan 2002 11:42:51 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GJbP106507 for ; Wed, 16 Jan 2002 11:37:25 -0800 (PST) (envelope-from Ming.Chan@SpirentCom.COM) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.1/8.12.1) with ESMTP id g0GJeT9E021069; Wed, 16 Jan 2002 09:40:30 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 09:46:23 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D43@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: "'Les Ginsberg'" , "'isis-wg@external.juniper.net'" Cc: "Chan, Chung Ming" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Treatment of Zero checksum Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 09:46:10 -1000 >The 2001 revision of ISO 10589 has incorporated this change. Section >7.3.14.2e now reads: > > > "An Intermediate system receiving a Link State PDU with an incorrect >LSP Checksum or with an invalid PDU syntax shall > > 1) generate a corruptedLSPReceived circuit event, > > 2) discard the PDU." Would zero checksum treated as invalid checksum? In 10589, section 7.3.14.2, item-i, zero checksum shall be treated as if the RLT is zero. As described in 10589, section 7.3.16.4, It will in turn means that the receiving router will purge the LSP if there is an older LSP in the DB. Thanks Ming Chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 14:55:45 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19240 for ; Wed, 16 Jan 2002 14:55:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GJol106647; Wed, 16 Jan 2002 11:50:47 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GJjc106584 for ; Wed, 16 Jan 2002 11:45:38 -0800 (PST) (envelope-from Ming.Chan@SpirentCom.COM) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.1/8.12.1) with ESMTP id g0GJmg9E021531 for ; Wed, 16 Jan 2002 09:48:43 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 09:54:36 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D45@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: "IS-IS-WG (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] FW: Treatment of Zero checksum Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 09:54:35 -1000 -----Original Message----- From: Chan, Chung Ming Sent: Wednesday, January 16, 2002 2:46 PM To: 'Les Ginsberg'; 'isis-wg@external.juniper.net' Cc: Chan, Chung Ming Subject: Treatment of Zero checksum >The 2001 revision of ISO 10589 has incorporated this change. Section >7.3.14.2e now reads: > > > "An Intermediate system receiving a Link State PDU with an incorrect >LSP Checksum or with an invalid PDU syntax shall > > 1) generate a corruptedLSPReceived circuit event, > > 2) discard the PDU." Would zero checksum treated as invalid checksum? In 10589, section 7.3.14.2, item-i, zero checksum shall be treated as if the RLT is zero. As described in 10589, section 7.3.16.4, It will in turn means that the receiving router will purge the LSP if there is an older LSP in the DB. Thanks Ming Chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 15:55:07 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20728 for ; Wed, 16 Jan 2002 15:55:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GKo1107000; Wed, 16 Jan 2002 12:50:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GKnh106985 for ; Wed, 16 Jan 2002 12:49:43 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA12120; Wed, 16 Jan 2002 12:52:47 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 12:52:47 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F71B@avalon.pluris.com> From: Les Ginsberg To: "'Chan, Chung Ming'" , Les Ginsberg , "'isis-wg@external.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Treatment of Zero checksum Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 12:52:46 -0800 Ming Chan - A zero checksum is an indication that there is no checksum (the Fletcher algorithm guarantees that a non-zero checksum will always be generated). 7.3.14.2(i) is indicating that if an LSP is received w zero checksum then we should treat it as if it also has 0 lifetime => it is being purged. We then process the LSP based on the rules in 7.3.16.4. An "invalid checksum" means we: a)Received a non-zero checksum in the PDU b)Performed checksum validation on the PDU contents and came up w a different checksum value c)Discard the PDU without further processing. As you can see, the two cases are very different. Les > -----Original Message----- > From: Chan, Chung Ming [mailto:Ming.Chan@SpirentCom.COM] > Sent: Wednesday, January 16, 2002 11:46 AM > To: 'Les Ginsberg'; 'isis-wg@external.juniper.net' > Cc: Chan, Chung Ming > Subject: Treatment of Zero checksum > > > > > >The 2001 revision of ISO 10589 has incorporated this change. Section > >7.3.14.2e now reads: > > > > > > "An Intermediate system receiving a Link State PDU with > an incorrect > >LSP Checksum or with an invalid PDU syntax shall > > > > 1) generate a corruptedLSPReceived circuit event, > > > > 2) discard the PDU." > > > Would zero checksum treated as invalid checksum? > In 10589, section 7.3.14.2, item-i, zero checksum shall be > treated as if the > RLT is zero. > > As described in 10589, section 7.3.16.4, > It will in turn means that the receiving router will purge > the LSP if there > is an older LSP in the DB. > > > > Thanks > > > Ming Chan > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 18:19:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23410 for ; Wed, 16 Jan 2002 18:19:27 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GNE2107603; Wed, 16 Jan 2002 15:14:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GNDm107591 for ; Wed, 16 Jan 2002 15:13:48 -0800 (PST) (envelope-from myeung@Procket.com) Received: from redd2222.procket.com (IDENT:root@redd2222.procket.com [10.1.2.222]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0GNGpeR026595; Wed, 16 Jan 2002 15:16:51 -0800 (PST) Received: from procket.com (IDENT:myeung@localhost.localdomain [127.0.0.1]) by redd2222.procket.com (8.12.1/8.12.1) with ESMTP id g0GNGoFP002886; Wed, 16 Jan 2002 15:16:51 -0800 Message-ID: <3C4609E2.EFB335DD@procket.com> From: Derek Yeung X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Les Ginsberg CC: "'Chan, Chung Ming'" , "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: Treatment of Zero checksum References: <17C81AD1F1FED411991E006008F6D1CA01B3F71B@avalon.pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 15:16:50 -0800 Content-Transfer-Encoding: 7bit Any reason the two events are treated differently ? IHMO, zero checksum could be caused by the same kind of corruption which lead to wrong checksum. And discarding the zero checksum LSP is less destructive then purging the LSP, which means more stable network. - Derek Les Ginsberg wrote: > > Ming Chan - > > A zero checksum is an indication that there is no checksum (the Fletcher > algorithm guarantees that a non-zero checksum will always be generated). > 7.3.14.2(i) is indicating that if an LSP is received w zero checksum then we > should treat it as if it also has 0 lifetime => it is being purged. We then > process the LSP based on the rules in 7.3.16.4. > > An "invalid checksum" means we: > > a)Received a non-zero checksum in the PDU > b)Performed checksum validation on the PDU contents and came up w a > different checksum value > c)Discard the PDU without further processing. > > As you can see, the two cases are very different. > > Les > > > -----Original Message----- > > From: Chan, Chung Ming [mailto:Ming.Chan@SpirentCom.COM] > > Sent: Wednesday, January 16, 2002 11:46 AM > > To: 'Les Ginsberg'; 'isis-wg@external.juniper.net' > > Cc: Chan, Chung Ming > > Subject: Treatment of Zero checksum > > > > > > > > > > >The 2001 revision of ISO 10589 has incorporated this change. Section > > >7.3.14.2e now reads: > > > > > > > > > "An Intermediate system receiving a Link State PDU with > > an incorrect > > >LSP Checksum or with an invalid PDU syntax shall > > > > > > 1) generate a corruptedLSPReceived circuit event, > > > > > > 2) discard the PDU." > > > > > > Would zero checksum treated as invalid checksum? > > In 10589, section 7.3.14.2, item-i, zero checksum shall be > > treated as if the > > RLT is zero. > > > > As described in 10589, section 7.3.16.4, > > It will in turn means that the receiving router will purge > > the LSP if there > > is an older LSP in the DB. > > > > > > > > Thanks > > > > > > Ming Chan > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 16 20:27:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25284 for ; Wed, 16 Jan 2002 20:27:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0H1K1108201; Wed, 16 Jan 2002 17:20:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0H1JK108186 for ; Wed, 16 Jan 2002 17:19:20 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA06936; Wed, 16 Jan 2002 17:22:14 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 17:22:14 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F720@avalon.pluris.com> From: Les Ginsberg To: "'Derek Yeung'" Cc: "'Chan, Chung Ming'" , "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] RE: Treatment of Zero checksum MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 17:22:13 -0800 Derek - I agree with you i.e. in the case where you receive an LSP w zero checksum and non-zero lifetime, this should be treated as "invalid" and subject to the same (revised)handling as an LSP received with invalid non-zero checksum - log it and discard it. Note, however, that an LSP with zero checksum AND zero lifetime IS VALID and should be handled as per 7.3.16.4. Les > -----Original Message----- > From: Derek Yeung [mailto:myeung@Procket.com] > Sent: Wednesday, January 16, 2002 3:17 PM > To: Les Ginsberg > Cc: 'Chan, Chung Ming'; 'isis-wg@external.juniper.net' > Subject: Re: [Isis-wg] RE: Treatment of Zero checksum > > > Any reason the two events are treated differently ? IHMO, > zero checksum could be caused by the same kind of corruption > which lead to > wrong checksum. And discarding the zero checksum LSP is less > destructive > then purging the LSP, which means more stable network. > > - Derek > > Les Ginsberg wrote: > > > > Ming Chan - > > > > A zero checksum is an indication that there is no checksum > (the Fletcher > > algorithm guarantees that a non-zero checksum will always > be generated). > > 7.3.14.2(i) is indicating that if an LSP is received w zero > checksum then we > > should treat it as if it also has 0 lifetime => it is being > purged. We then > > process the LSP based on the rules in 7.3.16.4. > > > > An "invalid checksum" means we: > > > > a)Received a non-zero checksum in the PDU > > b)Performed checksum validation on the PDU contents and > came up w a > > different checksum value > > c)Discard the PDU without further processing. > > > > As you can see, the two cases are very different. > > > > Les > > > > > -----Original Message----- > > > From: Chan, Chung Ming [mailto:Ming.Chan@SpirentCom.COM] > > > Sent: Wednesday, January 16, 2002 11:46 AM > > > To: 'Les Ginsberg'; 'isis-wg@external.juniper.net' > > > Cc: Chan, Chung Ming > > > Subject: Treatment of Zero checksum > > > > > > > > > > > > > > > >The 2001 revision of ISO 10589 has incorporated this > change. Section > > > >7.3.14.2e now reads: > > > > > > > > > > > > "An Intermediate system receiving a Link State PDU with > > > an incorrect > > > >LSP Checksum or with an invalid PDU syntax shall > > > > > > > > 1) generate a corruptedLSPReceived circuit event, > > > > > > > > 2) discard the PDU." > > > > > > > > > Would zero checksum treated as invalid checksum? > > > In 10589, section 7.3.14.2, item-i, zero checksum shall be > > > treated as if the > > > RLT is zero. > > > > > > As described in 10589, section 7.3.16.4, > > > It will in turn means that the receiving router will purge > > > the LSP if there > > > is an older LSP in the DB. > > > > > > > > > > > > Thanks > > > > > > > > > Ming Chan > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 17 01:26:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00715 for ; Thu, 17 Jan 2002 01:26:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0H6L1109418; Wed, 16 Jan 2002 22:21:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0H6Kk109406 for ; Wed, 16 Jan 2002 22:20:46 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0H6Nn689606; Wed, 16 Jan 2002 22:23:49 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0H6NnO12037; Wed, 16 Jan 2002 22:23:49 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201170623.g0H6NnO12037@cirrus.juniper.net> From: Dave Katz To: oran@cisco.com CC: ramsrm@tdd.sj.nec.com, isis-wg@juniper.net In-reply-to: <002301c19ec5$a2e05000$50308640@cisco.com> (oran@cisco.com) Subject: Re: [Isis-wg] Point to point adjacency down. References: <002301c19ec5$a2e05000$50308640@cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 22:23:49 -0800 (PST) Much more succinct than my version, thanks. ;-) X-JNPR-Received-From: outside From: "David R. Oran" Cc: Date: Wed, 16 Jan 2002 14:40:20 -0500 Organization: Cisco Systems Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 16 Jan 2002 19:40:09.0609 (UTC) FILETIME=[9B679F90:01C19EC5] > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net] On Behalf Of Dave Katz > Sent: Friday, January 11, 2002 5:15 PM > To: ramsrm@tdd.sj.nec.com > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] Point to point adjacency down. > [snip] > It is foolish to attempt fix *perceived* operational problems > by attempting to standardize out of them, when such a > standard, if adhered to, would create other operational > problems. Furthermore, as Dave Oran was fond of noting, for > every 100 possible random knob settings in a router, only 1 > actually results in a functional network. For completeness, I feel compelled to state the full version of Oran's law of tuning parameters: "There are three types of tuning parameter: 1. Those for which all settings produce identical behavior 2. Those for which only one setting works 3. Those which control whether another tuning parameter operates as type 1 or type 2." Dave O. > Things like this > are best left to the operators to decide whether or not they > have a problem, and to work with their vendors to ameliorate > the problem if in fact one exists. > > --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 17 04:42:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10786 for ; Thu, 17 Jan 2002 04:42:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0H9b4110325; Thu, 17 Jan 2002 01:37:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0H9Vi110293 for ; Thu, 17 Jan 2002 01:31:44 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp14.cisco.com [10.50.0.13]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA17092; Thu, 17 Jan 2002 09:34:35 GMT Message-Id: <4.3.2.7.2.20020117092853.0337ea78@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: mike shand Subject: RE: [Isis-wg] RE: Treatment of Zero checksum Cc: "'Derek Yeung'" , "'Chan, Chung Ming'" , "'isis-wg@external.juniper.net'" In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F720@avalon.pluris.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 Jan 2002 09:32:18 +0000 At 17:22 16/01/2002 -0800, Les Ginsberg wrote: >Derek - > >I agree with you i.e. in the case where you receive an LSP w zero checksum >and non-zero lifetime, this should be treated as "invalid" and subject to >the same (revised)handling as an LSP received with invalid non-zero checksum >- log it and discard it. > >Note, however, that an LSP with zero checksum AND zero lifetime IS VALID and >should be handled as per 7.3.16.4. I agree, but for reasons which I cannot remember that is NOT what the spec says. But I can't see that any harm could come from adopting Les' behaviour, since the spec DOES say that to purge an LSP the lifetime must be set to (or have reached) zero. So there should be no cases of people trying to purge by JUST setting the checksum to zero. The spec is unclear as to what the checksum should be for a purged LSP (but my own preference is that it be set to zero). On the other hand, there is not much reason to change either. Mike > Les > > > > -----Original Message----- > > From: Derek Yeung [mailto:myeung@Procket.com] > > Sent: Wednesday, January 16, 2002 3:17 PM > > To: Les Ginsberg > > Cc: 'Chan, Chung Ming'; 'isis-wg@external.juniper.net' > > Subject: Re: [Isis-wg] RE: Treatment of Zero checksum > > > > > > Any reason the two events are treated differently ? IHMO, > > zero checksum could be caused by the same kind of corruption > > which lead to > > wrong checksum. And discarding the zero checksum LSP is less > > destructive > > then purging the LSP, which means more stable network. > > > > - Derek > > > > Les Ginsberg wrote: > > > > > > Ming Chan - > > > > > > A zero checksum is an indication that there is no checksum > > (the Fletcher > > > algorithm guarantees that a non-zero checksum will always > > be generated). > > > 7.3.14.2(i) is indicating that if an LSP is received w zero > > checksum then we > > > should treat it as if it also has 0 lifetime => it is being > > purged. We then > > > process the LSP based on the rules in 7.3.16.4. > > > > > > An "invalid checksum" means we: > > > > > > a)Received a non-zero checksum in the PDU > > > b)Performed checksum validation on the PDU contents and > > came up w a > > > different checksum value > > > c)Discard the PDU without further processing. > > > > > > As you can see, the two cases are very different. > > > > > > Les > > > > > > > -----Original Message----- > > > > From: Chan, Chung Ming [mailto:Ming.Chan@SpirentCom.COM] > > > > Sent: Wednesday, January 16, 2002 11:46 AM > > > > To: 'Les Ginsberg'; 'isis-wg@external.juniper.net' > > > > Cc: Chan, Chung Ming > > > > Subject: Treatment of Zero checksum > > > > > > > > > > > > > > > > > > > > >The 2001 revision of ISO 10589 has incorporated this > > change. Section > > > > >7.3.14.2e now reads: > > > > > > > > > > > > > > > "An Intermediate system receiving a Link State PDU with > > > > an incorrect > > > > >LSP Checksum or with an invalid PDU syntax shall > > > > > > > > > > 1) generate a corruptedLSPReceived circuit event, > > > > > > > > > > 2) discard the PDU." > > > > > > > > > > > > Would zero checksum treated as invalid checksum? > > > > In 10589, section 7.3.14.2, item-i, zero checksum shall be > > > > treated as if the > > > > RLT is zero. > > > > > > > > As described in 10589, section 7.3.16.4, > > > > It will in turn means that the receiving router will purge > > > > the LSP if there > > > > is an older LSP in the DB. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Ming Chan > > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 17 06:51:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12510 for ; Thu, 17 Jan 2002 06:51:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0HBk1111433; Thu, 17 Jan 2002 03:46:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0HBk0111421 for ; Thu, 17 Jan 2002 03:46:00 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g0HBnAG71695 for ; Thu, 17 Jan 2002 03:49:10 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Jan 2002 03:48:49 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12430; Thu, 17 Jan 2002 06:49:07 -0500 (EST) Message-Id: <200201171149.GAA12430@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 17 Jan 2002 11:48:49.0921 (UTC) FILETIME=[EDCF6F10:01C19F4C] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-06.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 Jan 2002 06:49:07 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie, D. Saha, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-06.txt Pages : 9 Date : 16-Jan-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). The description of the extensions is specified in [GMPLS- ROUTING]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020116151641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020116151641.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 17 07:58:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13709 for ; Thu, 17 Jan 2002 07:58:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0HCr1111732; Thu, 17 Jan 2002 04:53:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0HCqH111720 for ; Thu, 17 Jan 2002 04:52:17 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g0HCtRG72426 for ; Thu, 17 Jan 2002 04:55:27 -0800 (PST) X-JNPR-Received-From: outside Received: from web11203.mail.yahoo.com ([216.136.131.185]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Jan 2002 04:55:07 -0800 Message-ID: <20020117125526.11458.qmail@web11203.mail.yahoo.com> Received: from [203.196.145.150] by web11203.mail.yahoo.com via HTTP; Thu, 17 Jan 2002 04:55:26 PST From: Aravind Ravikumar To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1177650888-1011272126=:9494" X-OriginalArrivalTime: 17 Jan 2002 12:55:07.0078 (UTC) FILETIME=[30616E60:01C19F56] Subject: [Isis-wg] Doubt about LSP transmission Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 Jan 2002 04:55:26 -0800 (PST) --0-1177650888-1011272126=:9494 Content-Type: text/plain; charset=us-ascii Hi, Section 7.13.15.1.a.4 says that we shouldn't accept an LSP on a broadcast circuit if we do not have an adjacency at the same level with the same source SNPA address as the source of the LSP. Here can we consider adjacencies in state initializing? If we are considering only adjacencies in up state, while transmitting LSPs also can we apply the same check.That is if we don't have any adjacency in up state in the broadcast circuit we need'nt transmit the LSP(even if we transmit no body will accept it) Is the above assumption right Aravind --------------------------------- Do You Yahoo!? Send FREE video emails in Yahoo! Mail. --0-1177650888-1011272126=:9494 Content-Type: text/html; charset=us-ascii

Hi,

Section 7.13.15.1.a.4 says that we shouldn't accept an LSP on a broadcast circuit if
we do not have an adjacency at the same level with the same source SNPA address as the
source of the LSP.

Here can we consider adjacencies in state initializing?

If we are considering only adjacencies in up state, while transmitting LSPs also
can we apply the same check.That is if we don't have any adjacency in up state
in the broadcast circuit we need'nt transmit the LSP(even if we transmit no body will accept
it)

Is the above assumption right

Aravind


Do You Yahoo!?
Send FREE video emails in Yahoo! Mail. --0-1177650888-1011272126=:9494-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 17 15:37:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11948 for ; Thu, 17 Jan 2002 15:37:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0HKV2113510; Thu, 17 Jan 2002 12:31:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0HKU8113498 for ; Thu, 17 Jan 2002 12:30:08 -0800 (PST) (envelope-from myeung@Procket.com) Received: from redd2222.procket.com (IDENT:root@redd2222.procket.com [10.1.2.222]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0HKX9eR021152; Thu, 17 Jan 2002 12:33:09 -0800 (PST) Received: from procket.com (IDENT:myeung@localhost.localdomain [127.0.0.1]) by redd2222.procket.com (8.12.1/8.12.1) with ESMTP id g0HKX8FP003941; Thu, 17 Jan 2002 12:33:08 -0800 Message-ID: <3C473504.81A77DCA@procket.com> From: Derek Yeung X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: mike shand CC: Les Ginsberg , "'Chan, Chung Ming'" , "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] RE: Treatment of Zero checksum References: <4.3.2.7.2.20020117092853.0337ea78@jaws.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 Jan 2002 12:33:08 -0800 Content-Transfer-Encoding: 7bit IHMO, it would be nice to calculate checksum for all LSPs, including purged ones. Otherwise, the LSP ID is not protected and any corruption will cause purge on different LSP. Having said that, I am not proposing any change here. I think it is fine to keep accepting purged LSP with zero checksum in order to be compatible. Since there is no such rule that one should reject purged LSP with non-zero checksum, the sender itself could always choose to checksum the purged LSP for extra stability. - Derek mike shand wrote: > > At 17:22 16/01/2002 -0800, Les Ginsberg wrote: > >Derek - > > > >I agree with you i.e. in the case where you receive an LSP w zero checksum > >and non-zero lifetime, this should be treated as "invalid" and subject to > >the same (revised)handling as an LSP received with invalid non-zero checksum > >- log it and discard it. > > > >Note, however, that an LSP with zero checksum AND zero lifetime IS VALID and > >should be handled as per 7.3.16.4. > > I agree, but for reasons which I cannot remember that is NOT what the spec > says. But I can't see that any harm could come from adopting Les' > behaviour, since the spec DOES say that to purge an LSP the lifetime must > be set to (or have reached) zero. So there should be no cases of people > trying to purge by JUST setting the checksum to zero. > > The spec is unclear as to what the checksum should be for a purged LSP (but > my own preference is that it be set to zero). > > On the other hand, there is not much reason to change either. > > Mike > > > Les > > > > > > > -----Original Message----- > > > From: Derek Yeung [mailto:myeung@Procket.com] > > > Sent: Wednesday, January 16, 2002 3:17 PM > > > To: Les Ginsberg > > > Cc: 'Chan, Chung Ming'; 'isis-wg@external.juniper.net' > > > Subject: Re: [Isis-wg] RE: Treatment of Zero checksum > > > > > > > > > Any reason the two events are treated differently ? IHMO, > > > zero checksum could be caused by the same kind of corruption > > > which lead to > > > wrong checksum. And discarding the zero checksum LSP is less > > > destructive > > > then purging the LSP, which means more stable network. > > > > > > - Derek > > > > > > Les Ginsberg wrote: > > > > > > > > Ming Chan - > > > > > > > > A zero checksum is an indication that there is no checksum > > > (the Fletcher > > > > algorithm guarantees that a non-zero checksum will always > > > be generated). > > > > 7.3.14.2(i) is indicating that if an LSP is received w zero > > > checksum then we > > > > should treat it as if it also has 0 lifetime => it is being > > > purged. We then > > > > process the LSP based on the rules in 7.3.16.4. > > > > > > > > An "invalid checksum" means we: > > > > > > > > a)Received a non-zero checksum in the PDU > > > > b)Performed checksum validation on the PDU contents and > > > came up w a > > > > different checksum value > > > > c)Discard the PDU without further processing. > > > > > > > > As you can see, the two cases are very different. > > > > > > > > Les > > > > > > > > > -----Original Message----- > > > > > From: Chan, Chung Ming [mailto:Ming.Chan@SpirentCom.COM] > > > > > Sent: Wednesday, January 16, 2002 11:46 AM > > > > > To: 'Les Ginsberg'; 'isis-wg@external.juniper.net' > > > > > Cc: Chan, Chung Ming > > > > > Subject: Treatment of Zero checksum > > > > > > > > > > > > > > > > > > > > > > > > > >The 2001 revision of ISO 10589 has incorporated this > > > change. Section > > > > > >7.3.14.2e now reads: > > > > > > > > > > > > > > > > > > "An Intermediate system receiving a Link State PDU with > > > > > an incorrect > > > > > >LSP Checksum or with an invalid PDU syntax shall > > > > > > > > > > > > 1) generate a corruptedLSPReceived circuit event, > > > > > > > > > > > > 2) discard the PDU." > > > > > > > > > > > > > > > Would zero checksum treated as invalid checksum? > > > > > In 10589, section 7.3.14.2, item-i, zero checksum shall be > > > > > treated as if the > > > > > RLT is zero. > > > > > > > > > > As described in 10589, section 7.3.16.4, > > > > > It will in turn means that the receiving router will purge > > > > > the LSP if there > > > > > is an older LSP in the DB. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > Ming Chan > > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 17 21:22:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17726 for ; Thu, 17 Jan 2002 21:22:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0I2H4115079; Thu, 17 Jan 2002 18:17:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0I2BK115046 for ; Thu, 17 Jan 2002 18:11:20 -0800 (PST) (envelope-from Ming.Chan@spirentcom.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0I2EX261986 for ; Thu, 17 Jan 2002 18:14:33 -0800 (PST) X-JNPR-Received-From: outside Received: from Thor.Adtech-Inc.COM ([63.165.80.10]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Jan 2002 18:08:37 -0800 Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.1/8.12.1) with ESMTP id g0I28v9E023863 for ; Thu, 17 Jan 2002 16:08:57 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 16:14:52 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D60@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: isis-wg@juniper.net Cc: "Chan, Chung Ming" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 18 Jan 2002 02:08:37.0968 (UTC) FILETIME=[0AAEB500:01C19FC5] Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Number! Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 Jan 2002 16:14:44 -1000 Hi, When the next Seq. Number Exceeds Max. Sequence Number! I'm reading to ISO/IEC10589, Section7.3.16.1 and not quite understand what the text means when it talks about "... the IS Network entity shall be disabled for a period of at least MaxAge + ZeroAgeLifetime, ..." "... If an Intermediate system needs to increment its sequence number, but the sequence number is already equal to SequenceModulus - 1, the event attemptToExceed- MaximumSequenceNumber shall be generated and the IS Network entity shall be disabled for a period of at least MaxAge + ZeroAgeLifetime, in order to be sure that any ver- sions of this LSP with the high sequence number have expired. When it is re-enabled the IS shall start again with sequence number 1. ..." What is the IS supposed to do with the LSP in question? What is the IS itself supposed to do? Thanks, Ming Chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 17 22:48:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21065 for ; Thu, 17 Jan 2002 22:48:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0I3h8115505; Thu, 17 Jan 2002 19:43:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0I3Uq115438 for ; Thu, 17 Jan 2002 19:30:52 -0800 (PST) (envelope-from harishb@tdd.sj.nec.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g0I3Y6G93807 for ; Thu, 17 Jan 2002 19:34:06 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Jan 2002 19:33:45 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g0I3Xwe27814; Thu, 17 Jan 2002 19:33:58 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id TAA14915; Thu, 17 Jan 2002 19:33:55 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id TAA20600; Thu, 17 Jan 2002 19:40:59 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfTAA20594; Thu Jan 17 19:37:34 2002 Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with ESMTP id g0I3QKv20064; Thu, 17 Jan 2002 19:26:20 -0800 (PST) Received: from ems10 (ems10 [131.241.5.84]) by bunny.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g0I3QIM20820; Thu, 17 Jan 2002 19:26:18 -0800 (PST) From: "Harish Balasubramaniam" To: "Chan, Chung Ming" , Subject: RE: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Number! Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <8AC36D3167EED41184C800508BD9540501EE3D60@apollo.adtech-inc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2002 03:33:45.0203 (UTC) FILETIME=[EED4EC30:01C19FD0] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 17 Jan 2002 19:30:08 -0800 Content-Transfer-Encoding: 7bit Hi When the LSP sequence number reaches a max sequence value (say fffffff ) , the next sequence number that is allocated for a new LSP by an IS is 1 . But since 1 < fffffff , the LSP with seq=1 will be discarded if transmitted immediately. So the IS waits MaxAge (time for the Remaininglifetime/age field of the LSP (seq=ffffff) to get to zero ) + ZeroAgeLifetime (for the zero age LSP to timeout and be purged from all routers database) , before transmitting the new LSP. rgds Harish -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Chan, Chung Ming Sent: Thursday, January 17, 2002 6:15 PM To: isis-wg@juniper.net Cc: Chan, Chung Ming Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Number! Hi, When the next Seq. Number Exceeds Max. Sequence Number! I'm reading to ISO/IEC10589, Section7.3.16.1 and not quite understand what the text means when it talks about "... the IS Network entity shall be disabled for a period of at least MaxAge + ZeroAgeLifetime, ..." "... If an Intermediate system needs to increment its sequence number, but the sequence number is already equal to SequenceModulus - 1, the event attemptToExceed- MaximumSequenceNumber shall be generated and the IS Network entity shall be disabled for a period of at least MaxAge + ZeroAgeLifetime, in order to be sure that any ver- sions of this LSP with the high sequence number have expired. When it is re-enabled the IS shall start again with sequence number 1. ..." What is the IS supposed to do with the LSP in question? What is the IS itself supposed to do? Thanks, Ming Chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 11:36:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17660 for ; Fri, 18 Jan 2002 11:36:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IGV9119348; Fri, 18 Jan 2002 08:31:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IGA3119254 for ; Fri, 18 Jan 2002 08:10:03 -0800 (PST) (envelope-from Ming.Chan@spirentcom.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0IGDK270636 for ; Fri, 18 Jan 2002 08:13:20 -0800 (PST) X-JNPR-Received-From: outside Received: from Thor.Adtech-Inc.COM ([63.165.80.10]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 08:07:17 -0800 Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.1/8.12.1) with ESMTP id g0IG7L9E004980; Fri, 18 Jan 2002 06:07:22 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 06:13:16 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D62@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: "'Harish Balasubramaniam'" Cc: "Chan, Chung Ming" , isis-wg@juniper.net Subject: RE: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 18 Jan 2002 16:07:18.0171 (UTC) FILETIME=[33DC56B0:01C1A03A] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 06:13:13 -1000 Harish, I was troubled with the word "Disabled." Like in P2P circuit, should the IS Ack the received LSP with PSNP or just do nothing until the elapse of MaxAge + ZeroAgeLifetime seconds then send LSP with SN=1? Should there be no action on the LSP be taken by the IS until MaxAge + ZeroAgeLifetime seconds have passed? Ming ============================================================================ ==== Hi When the LSP sequence number reaches a max sequence value (say fffffff ) , the next sequence number that is allocated for a new LSP by an IS is 1 . But since 1 < fffffff , the LSP with seq=1 will be discarded if transmitted immediately. So the IS waits MaxAge (time for the Remaininglifetime/age field of the LSP (seq=ffffff) to get to zero ) + ZeroAgeLifetime (for the zero age LSP to timeout and be purged from all routers database) , before transmitting the new LSP. rgds Harish -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Chan, Chung Ming Sent: Thursday, January 17, 2002 6:15 PM To: isis-wg@juniper.net Cc: Chan, Chung Ming Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Number! Hi, When the next Seq. Number Exceeds Max. Sequence Number! I'm reading to ISO/IEC10589, Section7.3.16.1 and not quite understand what the text means when it talks about "... the IS Network entity shall be disabled for a period of at least MaxAge + ZeroAgeLifetime, ..." "... If an Intermediate system needs to increment its sequence number, but the sequence number is already equal to SequenceModulus - 1, the event attemptToExceed- MaximumSequenceNumber shall be generated and the IS Network entity shall be disabled for a period of at least MaxAge + ZeroAgeLifetime, in order to be sure that any ver- sions of this LSP with the high sequence number have expired. When it is re-enabled the IS shall start again with sequence number 1. ..." What is the IS supposed to do with the LSP in question? What is the IS itself supposed to do? Thanks, Ming Chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 12:16:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19381 for ; Fri, 18 Jan 2002 12:16:29 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IHBB119560; Fri, 18 Jan 2002 09:11:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IGwd119494 for ; Fri, 18 Jan 2002 08:58:39 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0IH1v272258 for ; Fri, 18 Jan 2002 09:01:57 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 09:01:13 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0IH1jo29226; Fri, 18 Jan 2002 12:01:45 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAM31027; Fri, 18 Jan 2002 12:01:28 -0500 (EST) Message-Id: <4.3.2.7.2.20020118115404.05bf0540@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Chan, Chung Ming" From: Jeff Learman Subject: RE: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! Cc: "'Harish Balasubramaniam'" , "Chan, Chung Ming" , isis-wg@juniper.net In-Reply-To: <8AC36D3167EED41184C800508BD9540501EE3D62@apollo.adtech-inc .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 18 Jan 2002 17:01:13.0406 (UTC) FILETIME=[BC3605E0:01C1A041] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 12:01:25 -0500 No IS will be sending any LSPs with an LSP ID greater than 0xFFFFFFFF, because it won't fit in the 32 bits provided. So an implementation does not have to deal with receiving an LSP with too large a sequence number. If a router finds it has generated an LSP 4 billion times and is about to exceed the sequence number space, it just shuts down for a while and starts over. If a system is regenerating its LSP every second for 136 years this would happen. Most networks probably set their min lsp regen timer to greater than 1 second, so it would take longer in those networks ;-) Regards, Jeff Note: I do not work in IS-IS at Cisco and do not represent Cisco in these discussions. At 11:13 AM 1/18/2002, Chan, Chung Ming wrote: >Harish, > >I was troubled with the word "Disabled." > >Like in P2P circuit, should the IS Ack the received LSP with PSNP or just do >nothing until the elapse of MaxAge + ZeroAgeLifetime seconds then send LSP >with SN=1? > >Should there be no action on the LSP be taken by the IS until MaxAge + >ZeroAgeLifetime seconds have passed? > >Ming > > >============================================================================ >==== >Hi > When the LSP sequence number reaches a max sequence value (say fffffff ) , >the next sequence number that is allocated for a new LSP by an IS is 1 . But >since 1 < fffffff , the LSP with seq=1 will be discarded if transmitted >immediately. > >So the IS waits MaxAge (time for the Remaininglifetime/age field of the LSP >(seq=ffffff) to get to zero ) + ZeroAgeLifetime (for the zero age LSP to >timeout and be purged from all routers database) , before transmitting the >new LSP. > >rgds >Harish > >-----Original Message----- >From: isis-wg-admin@spider.juniper.net >[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Chan, Chung Ming >Sent: Thursday, January 17, 2002 6:15 PM >To: isis-wg@juniper.net >Cc: Chan, Chung Ming >Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence >Number! > > >Hi, > >When the next Seq. Number Exceeds Max. Sequence Number! > >I'm reading to ISO/IEC10589, Section7.3.16.1 and not quite understand what >the text means when it talks about "... the IS Network entity shall be >disabled for a period of at least MaxAge + ZeroAgeLifetime, ..." > >"... >If an Intermediate system needs to increment its sequence >number, but the sequence number is already equal to >SequenceModulus - 1, the event attemptToExceed- >MaximumSequenceNumber shall be generated and the IS >Network entity shall be disabled for a period of at least >MaxAge + ZeroAgeLifetime, in order to be sure that any ver- >sions of this LSP with the high sequence number have expired. >When it is re-enabled the IS shall start again with sequence >number 1. >..." > >What is the IS supposed to do with the LSP in question? >What is the IS itself supposed to do? > > >Thanks, > > >Ming Chan >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 15:25:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25813 for ; Fri, 18 Jan 2002 15:25:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IKJG120420; Fri, 18 Jan 2002 12:19:16 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IJ1v120060 for ; Fri, 18 Jan 2002 11:01:57 -0800 (PST) (envelope-from harishb@tdd.sj.nec.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0IJ5F276482 for ; Fri, 18 Jan 2002 11:05:15 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 11:04:01 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g0IJ47e14017; Fri, 18 Jan 2002 11:04:07 -0800 (PST) Received: from nectdd-pn.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id LAA10116; Fri, 18 Jan 2002 11:04:03 -0800 (PST) Received: by nectdd-pn.tdd.sj.nec.com (8.8.5/8.7.3) id LAA22563; Fri, 18 Jan 2002 11:11:09 -0800 (PST) Received: from necsun.tdd.sj.nec.com (necsun.tdd.sj.nec.com [131.241.5.5]) by nectdd-pn.tdd.sj.nec.com id rfLAA22553; Fri Jan 18 11:07:05 2002 Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with ESMTP id g0IItlv26901; Fri, 18 Jan 2002 10:55:47 -0800 (PST) Received: from ems10 (ems10 [131.241.5.84]) by bunny.tdd.sj.nec.com (8.11.6/8.11.6) with SMTP id g0IItjM12948; Fri, 18 Jan 2002 10:55:45 -0800 (PST) From: "Harish Balasubramaniam" To: "Jeff Learman" , "Chan, Chung Ming" Cc: Subject: RE: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20020118115404.05bf0540@dingdong.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2002 19:04:01.0140 (UTC) FILETIME=[E3B90340:01C1A052] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 10:59:35 -0800 Content-Transfer-Encoding: 7bit Few queries 1) A bad/hacked router can intentionally exploit this scenario by changing some LSPs sequence number to 0xffffffff and flooding it to the network. If the original router(source of the hacked LSP) receives this LSP , then what should it do? 2) Shouldnt the router send a zero age LSP to purge the LSP (seq=fffffff) instead of waiting (MaxAge + zeroagelifetime) , so that scenarios like 1 can be handled ? rgds Harish -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Jeff Learman Sent: Friday, January 18, 2002 9:01 AM To: Chan, Chung Ming Cc: 'Harish Balasubramaniam'; Chan, Chung Ming; isis-wg@juniper.net Subject: RE: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! No IS will be sending any LSPs with an LSP ID greater than 0xFFFFFFFF, because it won't fit in the 32 bits provided. So an implementation does not have to deal with receiving an LSP with too large a sequence number. If a router finds it has generated an LSP 4 billion times and is about to exceed the sequence number space, it just shuts down for a while and starts over. If a system is regenerating its LSP every second for 136 years this would happen. Most networks probably set their min lsp regen timer to greater than 1 second, so it would take longer in those networks ;-) Regards, Jeff Note: I do not work in IS-IS at Cisco and do not represent Cisco in these discussions. At 11:13 AM 1/18/2002, Chan, Chung Ming wrote: >Harish, > >I was troubled with the word "Disabled." > >Like in P2P circuit, should the IS Ack the received LSP with PSNP or just do >nothing until the elapse of MaxAge + ZeroAgeLifetime seconds then send LSP >with SN=1? > >Should there be no action on the LSP be taken by the IS until MaxAge + >ZeroAgeLifetime seconds have passed? > >Ming > > >=========================================================================== = >==== >Hi > When the LSP sequence number reaches a max sequence value (say fffffff ) , >the next sequence number that is allocated for a new LSP by an IS is 1 . But >since 1 < fffffff , the LSP with seq=1 will be discarded if transmitted >immediately. > >So the IS waits MaxAge (time for the Remaininglifetime/age field of the LSP >(seq=ffffff) to get to zero ) + ZeroAgeLifetime (for the zero age LSP to >timeout and be purged from all routers database) , before transmitting the >new LSP. > >rgds >Harish > >-----Original Message----- >From: isis-wg-admin@spider.juniper.net >[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Chan, Chung Ming >Sent: Thursday, January 17, 2002 6:15 PM >To: isis-wg@juniper.net >Cc: Chan, Chung Ming >Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence >Number! > > >Hi, > >When the next Seq. Number Exceeds Max. Sequence Number! > >I'm reading to ISO/IEC10589, Section7.3.16.1 and not quite understand what >the text means when it talks about "... the IS Network entity shall be >disabled for a period of at least MaxAge + ZeroAgeLifetime, ..." > >"... >If an Intermediate system needs to increment its sequence >number, but the sequence number is already equal to >SequenceModulus - 1, the event attemptToExceed- >MaximumSequenceNumber shall be generated and the IS >Network entity shall be disabled for a period of at least >MaxAge + ZeroAgeLifetime, in order to be sure that any ver- >sions of this LSP with the high sequence number have expired. >When it is re-enabled the IS shall start again with sequence >number 1. >..." > >What is the IS supposed to do with the LSP in question? >What is the IS itself supposed to do? > > >Thanks, > > >Ming Chan >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 15:33:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26066 for ; Fri, 18 Jan 2002 15:33:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IKSh120500; Fri, 18 Jan 2002 12:28:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IJQE120184 for ; Fri, 18 Jan 2002 11:26:14 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0IJTW277345 for ; Fri, 18 Jan 2002 11:29:32 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 11:23:29 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0IJO2U10274; Fri, 18 Jan 2002 14:24:02 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAM35117; Fri, 18 Jan 2002 14:23:48 -0500 (EST) Message-Id: <4.3.2.7.2.20020118141738.05addbd8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Harish Balasubramaniam" From: Jeff Learman Subject: RE: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! Cc: "Chan, Chung Ming" , In-Reply-To: References: <4.3.2.7.2.20020118115404.05bf0540@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 18 Jan 2002 19:23:29.0452 (UTC) FILETIME=[9C1746C0:01C1A055] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 14:21:44 -0500 A hacked router could just as easily change some LSP sequence number to 0xfffffffe, or 0xfffff000. There is nothing special about the value 0xffffffff, except that you won't ever generate its successor. Where should one arbitrarily draw a line and assume that an LSP is bad because its sequence number is "too high"? The way to avoid hacked routers is to use authentication. A receiving router does not wait based on the sequence of an LSP. A router that's about to generate its own LSP but finds it would need to wrap the sequence number is the only one required to basically shut down and wait. And as I said earlier, this is unlikely to happen as I can't imagine a system remaining up for a thousand years or more. In any case, we won't need to worry about it in our lifetimes! Or our children's! Regards, Jeff At 01:59 PM 1/18/2002, Harish Balasubramaniam wrote: >Few queries >1) A bad/hacked router can intentionally exploit this scenario by changing >some LSPs sequence number to 0xffffffff and flooding it to the network. >If the original router(source of the hacked LSP) receives this LSP , then >what should it do? >2) Shouldnt the router send a zero age LSP to purge the LSP (seq=fffffff) > instead of waiting (MaxAge + zeroagelifetime) , so that scenarios like 1 >can be handled ? > >rgds >Harish >-----Original Message----- >From: isis-wg-admin@spider.juniper.net >[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Jeff Learman >Sent: Friday, January 18, 2002 9:01 AM >To: Chan, Chung Ming >Cc: 'Harish Balasubramaniam'; Chan, Chung Ming; isis-wg@juniper.net >Subject: RE: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence >Num ber! > > > >No IS will be sending any LSPs with an LSP ID greater than >0xFFFFFFFF, because it won't fit in the 32 bits provided. So >an implementation does not have to deal with receiving an LSP >with too large a sequence number. > >If a router finds it has generated an LSP 4 billion times and >is about to exceed the sequence number space, it just shuts down >for a while and starts over. > >If a system is regenerating its LSP every second for 136 years this >would happen. Most networks probably set their min lsp regen timer >to greater than 1 second, so it would take longer in those networks ;-) > >Regards, >Jeff > >Note: I do not work in IS-IS at Cisco and do not represent Cisco >in these discussions. > > >At 11:13 AM 1/18/2002, Chan, Chung Ming wrote: >>Harish, >> >>I was troubled with the word "Disabled." >> >>Like in P2P circuit, should the IS Ack the received LSP with PSNP or just >do >>nothing until the elapse of MaxAge + ZeroAgeLifetime seconds then send LSP >>with SN=1? >> >>Should there be no action on the LSP be taken by the IS until MaxAge + >>ZeroAgeLifetime seconds have passed? >> >>Ming >> >> >>=========================================================================== >= >>==== >>Hi >> When the LSP sequence number reaches a max sequence value (say fffffff ) , >>the next sequence number that is allocated for a new LSP by an IS is 1 . >But >>since 1 < fffffff , the LSP with seq=1 will be discarded if transmitted >>immediately. >> >>So the IS waits MaxAge (time for the Remaininglifetime/age field of the >LSP >>(seq=ffffff) to get to zero ) + ZeroAgeLifetime (for the zero age LSP to >>timeout and be purged from all routers database) , before transmitting the >>new LSP. >> >>rgds >>Harish >> >>-----Original Message----- >>From: isis-wg-admin@spider.juniper.net >>[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Chan, Chung Ming >>Sent: Thursday, January 17, 2002 6:15 PM >>To: isis-wg@juniper.net >>Cc: Chan, Chung Ming >>Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence >>Number! >> >> >>Hi, >> >>When the next Seq. Number Exceeds Max. Sequence Number! >> >>I'm reading to ISO/IEC10589, Section7.3.16.1 and not quite understand what >>the text means when it talks about "... the IS Network entity shall be >>disabled for a period of at least MaxAge + ZeroAgeLifetime, ..." >> >>"... >>If an Intermediate system needs to increment its sequence >>number, but the sequence number is already equal to >>SequenceModulus - 1, the event attemptToExceed- >>MaximumSequenceNumber shall be generated and the IS >>Network entity shall be disabled for a period of at least >>MaxAge + ZeroAgeLifetime, in order to be sure that any ver- >>sions of this LSP with the high sequence number have expired. >>When it is re-enabled the IS shall start again with sequence >>number 1. >>..." >> >>What is the IS supposed to do with the LSP in question? >>What is the IS itself supposed to do? >> >> >>Thanks, >> >> >>Ming Chan >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@external.juniper.net >>http://external.juniper.net/mailman/listinfo/isis-wg >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@external.juniper.net >>http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 15:35:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26121 for ; Fri, 18 Jan 2002 15:35:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IKUT120530; Fri, 18 Jan 2002 12:30:29 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mailsrv.coronanetworks.com ([67.104.79.164]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IKE0120387 for ; Fri, 18 Jan 2002 12:14:08 -0800 (PST) (envelope-from Sanjeev@coronanetworks.com) Received: by mailsrv.coronanetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 12:19:03 -0800 Message-ID: From: Sanjeev Chakravarty To: "IS-IS-WG (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] question on draft-ietf-isis-wg-mib-06 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 12:19:02 -0800 Hi, I'm new to this domain. The IS-IS CLI commands support assigning password (referring to Cisco CLI) #area-password password #domain-password password #isis password password {level-1 | level-2} In draft-ietf-isis-wg-mib-06.txt, I couldn't find the corresponding MIB attributes. If I'm missing something please let me know. Thanks, Sanjeev _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 15:43:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26269 for ; Fri, 18 Jan 2002 15:43:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IKZi120578; Fri, 18 Jan 2002 12:35:44 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IKNh120449 for ; Fri, 18 Jan 2002 12:23:43 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0IKQr671124; Fri, 18 Jan 2002 12:26:53 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0IKQrC17156; Fri, 18 Jan 2002 12:26:53 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201182026.g0IKQrC17156@cirrus.juniper.net> From: Dave Katz To: harishb@tdd.sj.nec.com CC: jlearman@cisco.com, Ming.Chan@spirentcom.com, isis-wg@juniper.net In-reply-to: Subject: Re: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 12:26:53 -0800 (PST) 1) A bad/hacked router can intentionally exploit this scenario by changing some LSPs sequence number to 0xffffffff and flooding it to the network. If the original router(source of the hacked LSP) receives this LSP , then what should it do? Yes, but at least you can't packet-bomb from the outside like OSPF. It should do what the spec says. 2) Shouldnt the router send a zero age LSP to purge the LSP (seq=fffffff) instead of waiting (MaxAge + zeroagelifetime) , so that scenarios like 1 can be handled ? No, because you can't guarantee that all remnants of the all-ones sequence LSP are gone unless you wait the full time. Easy scenario--the network becomes partitioned while high-numbered LSPs are in existence but before the purge takes place. If the partition heals, the high-numbered LSPs will be viewed as newer. The only way to guarantee that everything is cleaned up is to wait. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 15:56:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26625 for ; Fri, 18 Jan 2002 15:56:39 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IKph120730; Fri, 18 Jan 2002 12:51:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IKlV120690 for ; Fri, 18 Jan 2002 12:47:31 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Sanjeev Chakravarty'" , "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] question on draft-ietf-isis-wg-mib-06 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 15:49:53 -0500 > Hi, > > I'm new to this domain. The IS-IS CLI commands support > assigning password (referring to Cisco CLI) > #area-password password > #domain-password password > #isis password password {level-1 | level-2} > > In draft-ietf-isis-wg-mib-06.txt, I couldn't find the > corresponding MIB attributes. If I'm missing something > please let me know. > > Thanks, > > Sanjeev Sanjeev - This isn't really the place to discuss Cisco Commands: you can talk to your Cisco rep to find out where that might be. The fact remains that area and domain passwords are part of the IS-IS original protocol, and to modifications since then. Note that version 07 of the mib is out, and you should be complaining that this variable isn't in that version (it isn't). It was in an earlier version. However, the security folks advising us have suggested that passwords are too important to be trusted to SNMP. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 16:05:48 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27100 for ; Fri, 18 Jan 2002 16:05:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IL11120806; Fri, 18 Jan 2002 13:01:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0IKwv120782 for ; Fri, 18 Jan 2002 12:58:57 -0800 (PST) (envelope-from Radia.Perlman@sun.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0IL2F280267 for ; Fri, 18 Jan 2002 13:02:15 -0800 (PST) X-JNPR-Received-From: outside Received: from mercury.Sun.COM ([192.9.25.1]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 13:01:44 -0800 Received: from bcn.East.Sun.COM ([129.148.75.4]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03824 for ; Fri, 18 Jan 2002 13:02:04 -0800 (PST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with SMTP id QAA17725 for ; Fri, 18 Jan 2002 16:02:04 -0500 (EST) Message-Id: <200201182102.QAA17725@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IyP/YyLGiEm2z+KSqZMVdw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc X-OriginalArrivalTime: 18 Jan 2002 21:01:44.0093 (UTC) FILETIME=[55921CD0:01C1A063] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 16:02:03 -0500 (EST) From: Jeff Learman >> The way to avoid >> hacked routers is to use authentication. >> A router that's about to generate its own LSP but finds it would need to >> wrap the sequence number is the only one required to basically shut down >> and wait. And as I said earlier, this is unlikely to happen as I can't >> imagine a system remaining up for a thousand years or more. It certainly won't ever happen if routers follow the rules, but a sick router could mess up its own sequence number, and that's something that authentication won't help. But also, as you pointed out, it's not the end of the world...just that router that at one point sent bizarro sequence numbers has to sit in the corner for awhile and wait for its old LSP to get purged. I always was a bit nervous about that scenario by the way. Has it been tested operationally? Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 16:17:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27322 for ; Fri, 18 Jan 2002 16:17:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ILD2120913; Fri, 18 Jan 2002 13:13:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from gnat.inet.org ([63.108.254.91]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ILAf120894 for ; Fri, 18 Jan 2002 13:10:41 -0800 (PST) (envelope-from rja@extremenetworks.com) Received: from localhost (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 49B2467103; Fri, 18 Jan 2002 16:27:58 -0500 (EST) Subject: Re: [Isis-wg] question on draft-ietf-isis-wg-mib-06 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: "IS-IS-WG (E-mail)" To: Sanjeev Chakravarty From: RJ Atkinson In-Reply-To: Message-Id: <46964B36-0C58-11D6-8DA7-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 16:13:53 -0500 Content-Transfer-Encoding: 7bit On Friday, January 18, 2002, at 03:19 PM, Sanjeev Chakravarty wrote: > Hi, > > I'm new to this domain. The IS-IS CLI commands support assigning password > (referring to Cisco CLI) > #area-password password > #domain-password password > #isis password password {level-1 | level-2} > > In draft-ietf-isis-wg-mib-06.txt, I couldn't find the corresponding MIB > attributes. If I'm missing something please let me know. It is NOT safe (from a security perspective) to put passwords into a MIB. That approach leads to cascading security vulnerabilities, which would be a BAD state to be in. So absence from the MIB is both intentional and The Right Thing to do. Just as with "tuning knobs", not everything belongs in a MIB. Ran rja@extremenetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 18 20:50:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02699 for ; Fri, 18 Jan 2002 20:50:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J1j5122125; Fri, 18 Jan 2002 17:45:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J1cF122086 for ; Fri, 18 Jan 2002 17:38:15 -0800 (PST) (envelope-from prz@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0J1fZ286927 for ; Fri, 18 Jan 2002 17:41:35 -0800 (PST) X-JNPR-Received-From: outside Received: from mta6.snfc21.pbi.net ([206.13.28.240]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 17:32:45 -0800 Received: from redback.com ([63.200.48.86]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQ500HWEWB6F6@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Fri, 18 Jan 2002 17:33:07 -0800 (PST) From: Tony Przygienda To: internet-drafts@ietf.org Cc: isis-wg@juniper.net, Bill Fenner Message-id: <3C48B92E.B486DCFB@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-OriginalArrivalTime: 19 Jan 2002 01:32:45.0702 (UTC) FILETIME=[323EBA60:01C1A089] Subject: [Isis-wg] new version of assigned tlv numbers ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 16:09:18 -0800 Content-Transfer-Encoding: 7BIT Please update the following draft thanks -- tony ------------------------------------------------------------------------------------------------ Internet Engineering Task Force T. Przygienda INTERNET DRAFT Redback Jan 2002 Reserved TLV Codepoints in ISIS Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This draft describes implementation codepoints within IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft summarizes all TLV codepoints that are being used by the protocol and its pending extensions. Przygienda Expires Jun 2002 [Page 1] ^L Internet Draft TLV Codepoints Jan 2002 1. TLV Codepoints reserved __________________________________________________________________________ Name Value IIH LSP SNP Status __________________________________________________________________________ Area Addresses 1 y y n ISO 10589 IIS Neighbors 2 n y n ISO 10589 ES Neighbors 3 n y n ISO 10589 Part. DIS 4 n y n ISO 10589 Prefix Neighbors 5 n y n ISO 10589 IIS Neighbors 6 y n n ISO 10589 Padding 8 y n n ISO 10589 LSP Entries 9 n n y ISO 10589 Authentication 10 y y y ISO 10589 Opt. Checksum 12 y n y IETF-draft LSPBufferSize 14 n y n ISO 10589 Rev 2 Draft TE IIS Neigh. 22 n y n IETF-draft DECnet Phase IV 42 y n n DEC (ancient) Lucent Proprietary 66 n y n IP Int. Reach 128 n y n RFC 1195 Prot. Supported 129 y y n RFC 1195 IP Ext. Address 130 n y n RFC 1195 IDRPI 131 n y y RFC 1195 IP Intf. Address 132 y y n RFC 1195 Illegal 133 n n n RFC 1195 (not used) Router ID 134 n y n IETF-draft TE IP. Reach 135 n y n IETF-draft Dynamic Name 137 n y n RFC 2763 Nortel Proprietary 176 n y n Nortel Proprietary 177 n y n Restart TLV 211 y n n IETF-draft MT-ISN 222 n y n IETF-draft M-Topologies 229 y y n IETF-draft IPv6 Intf. Addr. 232 y y n IETF-draft MT IP. Reach 235 n y n IETF-draft IPv6 IP. Reach 236 n y n IETF-draft MT IPv6 IP. Reach 237 n y n IETF-draft P2P Adjacency State 240 y n n IETF-draft 2. Assignment Procedures This document is provided to avoid possible future conflicts in assignment of TLV numbers. It does not constitute or represent any standard or authority assigning TLV numbers. TLV assignment happens Przygienda Expires Jun 2002 [Page 2] ^L Internet Draft TLV Codepoints Jan 2002 on a shared, informational basis between the ISO, SIF and the IETF working groups. The core ISIS protocol is being specified in the ISO standards body, IP extensions to it however are products of the ISIS working group in IETF. Since ISO does not provide a numbering authority and IANA is only responsible for IP related coding points, no plausible central authority to assign TLV numbers exists as of today. This document will be periodically updated by never versions in the fashion of [RP94 ] and successors. It may be replaced at any given point in time by some type of official registry. This document will not indicate specific drafts using the codepoints, nor will it resolve the sub-TLV codepoints. 3. Acknowledgments Thanks to Les Ginsberg and others for pointing out details and improving this work. 4. Security Consideration ISIS security applies to the work presented. No specific security issues are being introduced. References [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. INTERNET-RFC, Internet Engineering Task Force, February 1990. [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual Environments. INTERNET-RFC, Internet Engineering Task Force, December 1990. [ISO90] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990. [RP94] J. Reynolds and J. Postel. Rfc 1700, Assigned Numbers. Internet Engineering Task Force, October 1994. Przygienda Expires Jun 2002 [Page 3] ^L Internet Draft TLV Codepoints Jan 2002 5. Authors' Addresses Tony Przygienda Redback Networks 350 Holger Way San Jose, CA, 95134-1362 prz@redback.com 6. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Przygienda Expires Jun 2002 [Page 4] _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 01:11:45 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07507 for ; Sat, 19 Jan 2002 01:11:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J661123265; Fri, 18 Jan 2002 22:06:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J656123253 for ; Fri, 18 Jan 2002 22:05:06 -0800 (PST) (envelope-from prz@redback.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0J68R290175 for ; Fri, 18 Jan 2002 22:08:27 -0800 (PST) X-JNPR-Received-From: outside Received: from mta6.snfc21.pbi.net ([206.13.28.240]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 22:07:18 -0800 Received: from redback.com ([63.200.48.86]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQ600FY290RG7@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Fri, 18 Jan 2002 22:07:40 -0800 (PST) From: Tony Przygienda To: isis-wg@juniper.net Message-id: <3C48F986.F00A7D0@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-OriginalArrivalTime: 19 Jan 2002 06:07:18.0093 (UTC) FILETIME=[8C8E1FD0:01C1A0AF] Subject: [Isis-wg] last call on draft-ietf-isis-hmac-03.txt ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 20:43:50 -0800 Content-Transfer-Encoding: 7BIT We are starting last call on draft-ietf-isis-hmac-03.txt. The last call will end 2/4/02 thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 01:21:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07564 for ; Sat, 19 Jan 2002 01:21:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J6H5123337; Fri, 18 Jan 2002 22:17:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J664123267 for ; Fri, 18 Jan 2002 22:06:04 -0800 (PST) (envelope-from prz@redback.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0J69O290181 for ; Fri, 18 Jan 2002 22:09:24 -0800 (PST) X-JNPR-Received-From: outside Received: from mta6.snfc21.pbi.net ([206.13.28.240]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 22:08:26 -0800 Received: from redback.com ([63.200.48.86]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQ600IM092O1A@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Fri, 18 Jan 2002 22:08:48 -0800 (PST) From: Tony Przygienda To: isis-wg@juniper.net Message-id: <3C48F9CB.32675D85@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-OriginalArrivalTime: 19 Jan 2002 06:08:27.0046 (UTC) FILETIME=[B5A78460:01C1A0AF] Subject: [Isis-wg] last call on draft-ietf-isis-traffic-04 ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 20:45:00 -0800 Content-Transfer-Encoding: 7BIT We are starting last call on draft-ietf-isis-traffic-04. Last call will end 2/4/02 thanks --- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 01:27:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07629 for ; Sat, 19 Jan 2002 01:27:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J6MQ123372; Fri, 18 Jan 2002 22:22:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 01:40:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07767 for ; Sat, 19 Jan 2002 01:40:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J6a9123484; Fri, 18 Jan 2002 22:36:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 01:59:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07940 for ; Sat, 19 Jan 2002 01:59:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J6s8123626; Fri, 18 Jan 2002 22:54:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 02:17:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16361 for ; Sat, 19 Jan 2002 02:17:34 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J7C8123745; Fri, 18 Jan 2002 23:12:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 02:36:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16530 for ; Sat, 19 Jan 2002 02:36:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J7V8123844; Fri, 18 Jan 2002 23:31:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 02:53:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16634 for ; Sat, 19 Jan 2002 02:53:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J7n8123975; Fri, 18 Jan 2002 23:49:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 03:12:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16899 for ; Sat, 19 Jan 2002 03:12:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J878124095; Sat, 19 Jan 2002 00:07:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 03:30:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17042 for ; Sat, 19 Jan 2002 03:30:27 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J8P9124205; Sat, 19 Jan 2002 00:25:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 03:49:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17163 for ; Sat, 19 Jan 2002 03:49:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J8i8124320; Sat, 19 Jan 2002 00:44:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 04:06:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17281 for ; Sat, 19 Jan 2002 04:06:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J928124437; Sat, 19 Jan 2002 01:02:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 04:25:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17375 for ; Sat, 19 Jan 2002 04:25:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J9K8124561; Sat, 19 Jan 2002 01:20:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 04:43:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17469 for ; Sat, 19 Jan 2002 04:43:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J9c8124683; Sat, 19 Jan 2002 01:38:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 05:02:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17629 for ; Sat, 19 Jan 2002 05:02:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0J9v9124800; Sat, 19 Jan 2002 01:57:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 05:21:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17733 for ; Sat, 19 Jan 2002 05:21:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JAG8124927; Sat, 19 Jan 2002 02:16:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 05:40:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17863 for ; Sat, 19 Jan 2002 05:40:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JAZ9125064; Sat, 19 Jan 2002 02:35:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 05:58:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17936 for ; Sat, 19 Jan 2002 05:58:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JAr8125192; Sat, 19 Jan 2002 02:53:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 06:17:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18102 for ; Sat, 19 Jan 2002 06:17:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JBC8125771; Sat, 19 Jan 2002 03:12:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 06:36:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18236 for ; Sat, 19 Jan 2002 06:36:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JBV8125887; Sat, 19 Jan 2002 03:31:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 06:55:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18331 for ; Sat, 19 Jan 2002 06:55:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JBo8126019; Sat, 19 Jan 2002 03:50:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 07:12:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18444 for ; Sat, 19 Jan 2002 07:12:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JC68126119; Sat, 19 Jan 2002 04:06:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 07:26:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18515 for ; Sat, 19 Jan 2002 07:26:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JCM8128542; Sat, 19 Jan 2002 04:22:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 07:42:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18613 for ; Sat, 19 Jan 2002 07:42:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JCc8128654; Sat, 19 Jan 2002 04:38:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 08:02:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18719 for ; Sat, 19 Jan 2002 08:02:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JCv8128788; Sat, 19 Jan 2002 04:57:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 08:21:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18816 for ; Sat, 19 Jan 2002 08:21:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JDG8128913; Sat, 19 Jan 2002 05:16:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 08:39:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18991 for ; Sat, 19 Jan 2002 08:39:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JDZ8129035; Sat, 19 Jan 2002 05:35:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 08:58:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19165 for ; Sat, 19 Jan 2002 08:58:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JDs8129152; Sat, 19 Jan 2002 05:54:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 09:16:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19292 for ; Sat, 19 Jan 2002 09:16:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JEA9129264; Sat, 19 Jan 2002 06:10:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 09:31:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19410 for ; Sat, 19 Jan 2002 09:31:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JEQ9129370; Sat, 19 Jan 2002 06:26:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 09:50:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19523 for ; Sat, 19 Jan 2002 09:50:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JEj8129505; Sat, 19 Jan 2002 06:45:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 10:08:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19684 for ; Sat, 19 Jan 2002 10:08:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JF38129608; Sat, 19 Jan 2002 07:03:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 10:25:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19760 for ; Sat, 19 Jan 2002 10:25:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JFL8129737; Sat, 19 Jan 2002 07:21:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 10:44:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19890 for ; Sat, 19 Jan 2002 10:44:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JFd8129833; Sat, 19 Jan 2002 07:39:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 11:02:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20006 for ; Sat, 19 Jan 2002 11:02:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JFw8129951; Sat, 19 Jan 2002 07:58:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 11:22:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20142 for ; Sat, 19 Jan 2002 11:22:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JGG8130083; Sat, 19 Jan 2002 08:16:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 11:36:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20292 for ; Sat, 19 Jan 2002 11:36:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JGW8130172; Sat, 19 Jan 2002 08:32:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 11:53:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20381 for ; Sat, 19 Jan 2002 11:53:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JGm8130285; Sat, 19 Jan 2002 08:48:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 12:09:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20519 for ; Sat, 19 Jan 2002 12:09:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JH49130385; Sat, 19 Jan 2002 09:04:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 12:28:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20634 for ; Sat, 19 Jan 2002 12:28:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JHN9130511; Sat, 19 Jan 2002 09:23:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 12:47:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20767 for ; Sat, 19 Jan 2002 12:47:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JHg9130646; Sat, 19 Jan 2002 09:42:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 13:06:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20931 for ; Sat, 19 Jan 2002 13:06:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JI18130769; Sat, 19 Jan 2002 10:01:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 13:22:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21133 for ; Sat, 19 Jan 2002 13:21:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JIH8130857; Sat, 19 Jan 2002 10:17:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 13:38:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21252 for ; Sat, 19 Jan 2002 13:38:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JIX8130953; Sat, 19 Jan 2002 10:33:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 13:55:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21431 for ; Sat, 19 Jan 2002 13:55:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JIn8131071; Sat, 19 Jan 2002 10:49:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 14:13:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21635 for ; Sat, 19 Jan 2002 14:13:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JJ88131211; Sat, 19 Jan 2002 11:08:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 14:32:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21856 for ; Sat, 19 Jan 2002 14:32:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JJR8131340; Sat, 19 Jan 2002 11:27:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 14:50:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22246 for ; Sat, 19 Jan 2002 14:49:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JJj8131437; Sat, 19 Jan 2002 11:45:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 15:09:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22525 for ; Sat, 19 Jan 2002 15:09:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JK48131556; Sat, 19 Jan 2002 12:04:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 15:27:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22615 for ; Sat, 19 Jan 2002 15:27:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JKM9131786; Sat, 19 Jan 2002 12:22:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 15:54:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22769 for ; Sat, 19 Jan 2002 15:54:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JKmBY31942; Sat, 19 Jan 2002 12:48:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 19 16:09:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22866 for ; Sat, 19 Jan 2002 16:09:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0JL48Y32045; Sat, 19 Jan 2002 13:04:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0GEIO105012 for ; Wed, 16 Jan 2002 06:18:24 -0800 (PST) (envelope-from jeff.pickering@caspiannetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0GELS235753 for ; Wed, 16 Jan 2002 06:21:28 -0800 (PST) X-JNPR-Received-From: outside Received: from cmail.packetcom.com ([63.108.173.139]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Jan 2002 06:15:32 -0800 Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ46073 (AUTH jeffp@caspiannetworks.com); Wed, 16 Jan 2002 06:15:50 -0800 (PST) Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2002 14:15:32.0734 (UTC) FILETIME=[424859E0:01C19E98] Subject: [Isis-wg] isis-3way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 16 Jan 2002 08:16:40 -0800 Content-Transfer-Encoding: 7bit Just a detail, but in 3.2b), I think the sentence: If the new action is "Up", an adjacencyStateChange(Up) event is generated. Should be: If the new action is "Up", an adjacencyStateChange(Up) event is generated and the adjacency three-way state shall be set to "Up". Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 21 09:43:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10880 for ; Mon, 21 Jan 2002 09:43:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0LEb1L43137; Mon, 21 Jan 2002 06:37:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0LEaQL43125 for ; Mon, 21 Jan 2002 06:36:26 -0800 (PST) (envelope-from Larmer@commsense.net) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0LEe1220812 for ; Mon, 21 Jan 2002 06:40:02 -0800 (PST) X-JNPR-Received-From: outside Received: from mail5.speakeasy.net ([216.254.0.205]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 21 Jan 2002 06:38:44 -0800 Received: (qmail 4625 invoked from network); 21 Jan 2002 14:39:08 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Jan 2002 14:39:08 -0000 From: "Ken Larmer" To: , "Radia Perlman - Boston Center for Networking" Cc: "Ken Larmer" Subject: RE: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200201182102.QAA17725@bcn.East.Sun.COM> X-OriginalArrivalTime: 21 Jan 2002 14:38:44.0484 (UTC) FILETIME=[53E54C40:01C1A289] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 21 Jan 2002 09:44:13 -0500 Content-Transfer-Encoding: 7bit > I always was a bit nervous about that scenario by the way. Has it been > tested operationally? Yes, this was tested on at least one implementation, though it was quite some time ago now. BTW, I believe Harish has a valid security concern here, which authentication will help to prevent! >Few queries >1) A bad/hacked router can intentionally exploit this scenario by changing >some LSPs sequence number to 0xffffffff and flooding it to the network. >If the original router(source of the hacked LSP) receives this LSP , then >what should it do? >2) Shouldnt the router send a zero age LSP to purge the LSP (seq=fffffff) > instead of waiting (MaxAge + zeroagelifetime) , so that scenarios like 1 > can be handled ? A hacker could pose as an adjacent IS and then flood LSPs with a sequence # = 0xffffff for every IS in the network. This would cause an instant melt-down of the network, because all IS routers would enter a wait-state in accordance with ISO-10589, section 7.3.15.1.a.9.d (the section pertaining to receipt of own LSP), which in turn references section 7.3.16.1 (Sequence Numbers). Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 22 07:59:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16869 for ; Tue, 22 Jan 2002 07:59:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0MCs2L48717; Tue, 22 Jan 2002 04:54:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0MCrhL48705 for ; Tue, 22 Jan 2002 04:53:44 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0MCvP242922 for ; Tue, 22 Jan 2002 04:57:25 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 22 Jan 2002 04:56:29 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16705; Tue, 22 Jan 2002 07:56:53 -0500 (EST) Message-Id: <200201221256.HAA16705@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 22 Jan 2002 12:56:29.0984 (UTC) FILETIME=[35DCA200:01C1A344] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-tlv-codepoints-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 22 Jan 2002 07:56:52 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Reserved TLV Codepoints in ISIS Author(s) : T. Przygienda Filename : draft-ietf-isis-wg-tlv-codepoints-01.txt Pages : Date : 21-Jan-02 This draft describes implementation codepoints within IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft summarizes all TLV codepoints that are being used by the protocol and its pending extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-tlv-codepoints-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-tlv-codepoints-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-tlv-codepoints-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020121082206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-tlv-codepoints-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-tlv-codepoints-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020121082206.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 23 06:42:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05733 for ; Wed, 23 Jan 2002 06:42:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0NBa1L54621; Wed, 23 Jan 2002 03:36:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0NBZeL54604 for ; Wed, 23 Jan 2002 03:35:40 -0800 (PST) (envelope-from sivaa@indiatimes.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0NBdRc79512 for ; Wed, 23 Jan 2002 03:39:27 -0800 (PST) X-JNPR-Received-From: outside Received: from WS0005.indiatimes.com ([203.199.93.15]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 23 Jan 2002 03:34:17 -0800 Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id QAA19237; Wed, 23 Jan 2002 16:56:17 +0530 From: "Sivakumar A" Message-Id: <200201231126.QAA19237@WS0005.indiatimes.com> To: "workgroup" CC: "Jeff Parker" Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 23 Jan 2002 11:34:17.0781 (UTC) FILETIME=[E473EE50:01C1A401] Subject: [Isis-wg] Is it missing in Mib ? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 23 Jan 2002 17:04:53 +0530 Hello All, In ISIS MIB, circuit Level table does not contain metric type (Internal or External). How is it possible for a manager to configure circuit level Default Metric as Internal or External as it has SYNTAX Default Metric (Integer Value from 1 to 63).This seems to be missing even in the mib-07. Kindly help in this regard Thanks and Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 23 06:49:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05804 for ; Wed, 23 Jan 2002 06:49:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0NBhdL54661; Wed, 23 Jan 2002 03:43:39 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0NBZgL54609 for ; Wed, 23 Jan 2002 03:35:42 -0800 (PST) (envelope-from sivaa@indiatimes.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0NBdTc79549 for ; Wed, 23 Jan 2002 03:39:29 -0800 (PST) X-JNPR-Received-From: outside Received: from WS0005.indiatimes.com ([203.199.93.15]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 23 Jan 2002 03:37:39 -0800 Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id QAA20232 for "workgroup"; Wed, 23 Jan 2002 16:59:40 +0530 From: "Sivakumar A" Message-Id: <200201231129.QAA20232@WS0005.indiatimes.com> To: "workgroup" Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 23 Jan 2002 11:37:40.0156 (UTC) FILETIME=[5D13E7C0:01C1A402] Subject: [Isis-wg] Internal/External IPRA ??? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 23 Jan 2002 17:08:16 +0530 Hi, Kindly clarify the following Whether External IPRA needs to be summarized? If yes, then consider the following. External IPRA with Internal Metric matches Summary Address Table Entry S1. We announce S1 with what ever metric that is configured in the Summary Address Table Note: SA table does not have a field indicating the type of metric whether internal or external. External IPRA with External Metric matches Summary Address Table Entry S2. What should be done now, since the metric configured in the summary Address Table does not specify whether it is internal or external can S2 now be announced for the External IPRA. Will this not violate the specification which says, that external metrics are not camparable to internal metrics? Any help on this is greatly appreciated Thanks & Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 23 10:30:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12434 for ; Wed, 23 Jan 2002 10:30:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0NFO8L55690; Wed, 23 Jan 2002 07:24:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0NFBNL55632 for ; Wed, 23 Jan 2002 07:11:23 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Sivakumar A'" Cc: "IS-IS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Is it missing in Mib ? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 23 Jan 2002 10:14:49 -0500 > In ISIS MIB, circuit Level table does not contain metric type > (Internal or External). How is it possible for a manager to > configure circuit level Default Metric as Internal or > External as it has SYNTAX Default Metric (Integer Value from > 1 to 63).This seems to be missing even in the mib-07. > > Kindly help in this regard > > Thanks and Regards > Sivakumar A Sivakumar - My understanding is that external/internal is an issue of the provenance, not the metric itself. No one makes imported beer. They make domestic beer, and then someone imports it to a new country. Thus an external metric is something I learn from another protocol, such as BGP. If there is a need to lie about where the metric came from, I'm sure someone on the list will rise up and smite me. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 23 12:19:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17003 for ; Wed, 23 Jan 2002 12:19:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0NHECL56196; Wed, 23 Jan 2002 09:14:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rchss002.chiaro.com (rchss002.chiaro.com [63.88.196.82]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g0NGwkL56120 for ; Wed, 23 Jan 2002 08:58:46 -0800 (PST) (envelope-from lliu@chiaro.com) Received: (qmail 11949 invoked from network); 23 Jan 2002 16:58:45 -0000 Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82) by rchss002.chiaro.com with SMTP; 23 Jan 2002 16:58:45 -0000 Received: by MAIL with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 10:49:36 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A50701B94A90@MAIL> From: Laura Liu To: isis-wg@spider.juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary" Subject: [Isis-wg] Questions on cird IDs in isis mib Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 23 Jan 2002 10:49:32 -0600 --=_IS_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hello, I need some clarification on the three circuit Id related mib objects. 1. isisCircIndex and isisCircIfIndex are defined as Integer32. My understanding is isisCircIndex refers to a logical id, while isisCircIfIndex are the physical id of the interface to which this circuit corresponds. 2. isisCircLocalID is Integer32(0..255), is the locally assigned one octet Local Circuit ID used for "maintaining more than 255 circuits in IS-IS". Am I correct? Another question, there is isisCircLevelDesIS object, it only report the DR's system ID part. How can I retrieve the circuit ID part of DR's LAN ID? please help, and thanks! Laura --=_IS_MIME_Boundary Content-Type: text/plain;charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit ----------------------------------------- (on Chiaro SMTP Relay) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- --=_IS_MIME_Boundary-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 23 22:20:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03129 for ; Wed, 23 Jan 2002 22:20:54 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0O3D1L58813; Wed, 23 Jan 2002 19:13:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0NIL0L56513 for ; Wed, 23 Jan 2002 10:21:01 -0800 (PST) (envelope-from koen.vermeulen@alcatel.be) Received: from alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0NIOjd00763 for ; Wed, 23 Jan 2002 19:24:45 +0100 (MET) Message-ID: <3C4EFFEA.4A5C778F@alcatel.be> From: Koen Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Isis-wg Content-Type: multipart/alternative; boundary="------------EA764333897CC61BD4B8DBD6" Subject: [Isis-wg] Making the update reliable Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 23 Jan 2002 19:24:42 +0100 --------------EA764333897CC61BD4B8DBD6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have a question concerning ISO/IEC 10589 7.3.17 'Making the update reliable'. At the end of this section is written for point-to-point circuits: When a point-to-point circuit (including non-DA DED circuits and virtual links) starts (or restarts), the IS shall a) set SRMflag for that circuit on all LSPs, and b) send a Complete set of Complete Sequence Numbers PDUs on that circuit. My question is now: what is actually meant with this 'start' (or 'restart') of a circuit? Do they mean an adjacency state change to 'up', or is it really the circuit which physically gets ready to send l2-frames? If the second answer is what is meant, then I don't understand why a CSNP is sent. This PDU will be thrown away anyhow by the receiving side if there is no adjacency (see 7.3.15.2 7: If the SNP is received on a non-broadcast circuit and there is no adjacency of the same level (e.g. a level 1 SNP with a level 1 or level 1 & 2 adjacency) on the circuit over which the SNP was received, then the IS shall discard the SNP without generating a event. ). So how can this mechanism make the update reliable? Or am I missing something? Regards, Koen --------------EA764333897CC61BD4B8DBD6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:

    When a point-to-point circuit (including non-DA DED circuits
    and virtual links) starts (or restarts), the IS shall

        a) set SRMflag for that circuit on all LSPs, and

        b) send a Complete set of Complete Sequence Numbers PDUs
           on that circuit.

My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the second answer is what is meant, then I don't
understand why a CSNP is sent. This PDU will
be thrown away anyhow by the receiving side if there is
no adjacency (see 7.3.15.2 7:

    If the SNP is received on a non-broadcast circuit and
    there is no adjacency of the same level (e.g. a level 1 SNP
    with a level 1 or level 1 & 2 adjacency) on the circuit
    over which the SNP was received, then the IS shall
    discard the SNP without generating a event.

).
So how can this mechanism make the update reliable? Or am I
missing something?

Regards,
Koen
  --------------EA764333897CC61BD4B8DBD6-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 23 22:29:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03206 for ; Wed, 23 Jan 2002 22:29:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0O3N2L58897; Wed, 23 Jan 2002 19:23:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0NJTML56801 for ; Wed, 23 Jan 2002 11:29:22 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Laura Liu'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] Questions on cird IDs in isis mib MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 23 Jan 2002 14:32:54 -0500 > 1. isisCircIndex and isisCircIfIndex are defined as Integer32. My > understanding is isisCircIndex refers to a logical id, while isisCircIndex OBJECT-TYPE SYNTAX Integer32 (1..2000000000) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of this circuit, unique within the instance of the IS-IS protocol. This object follows the index behavior. This is for SNMP Indexing purposes only and need not have any relation to any protocol value." ::= { isisCircEntry 1 } So this can be an index into an array, a hash value, or it could be the index of a port in your box. However, many devices allow multiple circuits to run over the same physical port, and would not be able to use a physical port number as the index. In brief, it is whatever you would like it to be. It could be the same as isisCircIfIndex. > isisCircIfIndex are the physical id of the > interface to which this circuit corresponds. isisCircIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value of ifIndex for the interface to which this circuit corresponds. This object cannot be modified after creation" ::= { isisCircEntry 2 } Nope, this is the MIB II IfIndex. There are rules about doling this out. What we're trying to do here is to have a value that lines up with the value of the manager will see in the Interface table. > 2. isisCircLocalID is Integer32(0..255), is the locally > assigned one octet > Local Circuit ID used for "maintaining more than 255 circuits > in IS-IS". isisCircLocalID OBJECT-TYPE SYNTAX Integer32(0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "An identification that can be used in protocol packets to identify a circuit. Values of isisCircLocalID do not need to be unique. They are only required to differ on LANs where the Intermediate System is the Designated Intermediate System." ::= { isisCircEntry 4 } The MIB does not try to address the issue of how to maintain a presence as the DIS on more than 256 LANs. Briefly, this is the octet that you use to augment the system ID to provide a unique PNodeID. This can be related to one of the other indicies, or can be independent. The implementer gets to allocate this. > Another question, there is isisCircLevelDesIS object, it only > report the > DR's system ID part. How can I retrieve the circuit ID part > of DR's LAN ID? > > please help, and thanks! > > Laura Laura - I think that is an error: thanks for catching that. The syntax should be an octet string of length 7 or 0. isisCircLevelDesIS OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..7)) MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the LAN Designated Intermediate System on this circuit at this level. If, for any reason, this system is not partaking in the relevant Designated Intermediate System election process, then the value returned is the zero length OCTET STRING." REFERENCE "{ISIS.aoi l2DesignatedIntermediateSystem (75)}" ::= { isisCircLevelEntry 4 } - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 02:14:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16666 for ; Thu, 24 Jan 2002 02:14:54 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0O792L59926; Wed, 23 Jan 2002 23:09:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0O78ZL59914 for ; Wed, 23 Jan 2002 23:08:35 -0800 (PST) (envelope-from swaminathanr@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 02:12:27 -0500 Message-ID: From: "Ramalingam, Swaminathan" To: "'Koen Vermeulen'" , Isis-wg Subject: RE: [Isis-wg] Making the update reliable MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A4A6.7375C930" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 02:12:15 -0500 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. ------_=_NextPart_001_01C1A4A6.7375C930 Content-Type: text/plain; charset="iso-8859-1" Keon, Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency. "Making the update reliable" means how the flooding made reliable using periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts. - Swami -----Original Message----- From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] Sent: Wednesday, January 23, 2002 11:55 PM To: Isis-wg Subject: [Isis-wg] Making the update reliable Hello, I have a question concerning ISO/IEC 10589 7.3.17 'Making the update reliable'. At the end of this section is written for point-to-point circuits: When a point-to-point circuit (including non-DA DED circuits and virtual links) starts (or restarts), the IS shall a) set SRMflag for that circuit on all LSPs, and b) send a Complete set of Complete Sequence Numbers PDUs on that circuit. My question is now: what is actually meant with this 'start' (or 'restart') of a circuit? Do they mean an adjacency state change to 'up', or is it really the circuit which physically gets ready to send l2-frames? If the second answer is what is meant, then I don't understand why a CSNP is sent. This PDU will be thrown away anyhow by the receiving side if there is no adjacency (see 7.3.15.2 7: If the SNP is received on a non-broadcast circuit and there is no adjacency of the same level (e.g. a level 1 SNP with a level 1 or level 1 & 2 adjacency) on the circuit over which the SNP was received, then the IS shall discard the SNP without generating a event. ). So how can this mechanism make the update reliable? Or am I missing something? Regards, Koen ------_=_NextPart_001_01C1A4A6.7375C930 Content-Type: text/html; charset="iso-8859-1"

Keon,
 
Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency.
 
"Making the update reliable" means how the flooding made reliable using  periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.
 
- Swami
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: Wednesday, January 23, 2002 11:55 PM
To: Isis-wg
Subject: [Isis-wg] Making the update reliable

Hello,

I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:

    When a point-to-point circuit (including non-DA DED circuits
    and virtual links) starts (or restarts), the IS shall

        a) set SRMflag for that circuit on all LSPs, and

        b) send a Complete set of Complete Sequence Numbers PDUs
           on that circuit.

My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the second answer is what is meant, then I don't
understand why a CSNP is sent. This PDU will
be thrown away anyhow by the receiving side if there is
no adjacency (see 7.3.15.2 7:

    If the SNP is received on a non-broadcast circuit and
    there is no adjacency of the same level (e.g. a level 1 SNP
    with a level 1 or level 1 & 2 adjacency) on the circuit
    over which the SNP was received, then the IS shall
    discard the SNP without generating a event.

).
So how can this mechanism make the update reliable? Or am I
missing something?

Regards,
Koen
 

------_=_NextPart_001_01C1A4A6.7375C930-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 03:39:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17613 for ; Thu, 24 Jan 2002 03:39:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0O8Y5L60318; Thu, 24 Jan 2002 00:34:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0O8Q6L60276 for ; Thu, 24 Jan 2002 00:26:07 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4168.cisco.com [10.50.16.71]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA13179; Thu, 24 Jan 2002 08:29:00 GMT Message-Id: <4.3.2.7.2.20020124082227.00b3be80@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ramalingam, Swaminathan" From: mike shand Subject: RE: [Isis-wg] Making the update reliable Cc: "'Koen Vermeulen'" , Isis-wg In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 08:26:39 +0000 At 02:12 24/01/2002 -0500, Ramalingam, Swaminathan wrote:
Keon,
 
Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency.

Yes.

 
"Making the update reliable" means how the flooding made reliable using  periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.

The heading is something of a misnomer here. The CSNP has NOTHING to do with reliability in the case of a p2p circuit. (It does of course on a broadcast circuit). On a P2P, the CSNP is simply an optimization which avoid the need to flood the entire LSP database when the adjacency comes up between two routers which already have (most of) the database. Reliability is of course achieved by setting SRMflags on all LSPs when the circuit comes up and using PSNPs to ACK.

        Mike


 
- Swami
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: Wednesday, January 23, 2002 11:55 PM
To: Isis-wg
Subject: [Isis-wg] Making the update reliable
Hello,

I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:

    When a point-to-point circuit (including non-DA DED circuits
    and virtual links) starts (or restarts), the IS shall

        a) set SRMflag for that circuit on all LSPs, and

        b) send a Complete set of Complete Sequence Numbers PDUs
           on that circuit.

My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the second answer is what is meant, then I don't
understand why a CSNP is sent. This PDU will
be thrown away anyhow by the receiving side if there is
no adjacency (see 7.3.15.2 7:

    If the SNP is received on a non-broadcast circuit and
    there is no adjacency of the same level (e.g. a level 1 SNP
    with a level 1 or level 1 & 2 adjacency) on the circuit
    over which the SNP was received, then the IS shall
    discard the SNP without generating a event.

).
So how can this mechanism make the update reliable? Or am I
missing something?

Regards,
Koen
 
_______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 08:42:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21246 for ; Thu, 24 Jan 2002 08:42:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ODa9L62121; Thu, 24 Jan 2002 05:36:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ODN7L62056 for ; Thu, 24 Jan 2002 05:23:07 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0ODRDp26721; Thu, 24 Jan 2002 08:27:13 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn1-300.cisco.com [10.82.225.44]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAN34595; Thu, 24 Jan 2002 08:26:58 -0500 (EST) Message-Id: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ramalingam, Swaminathan" From: Jeff Learman Subject: RE: [Isis-wg] Making the update reliable Cc: "'Koen Vermeulen'" , Isis-wg In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_27549323==_.ALT" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 08:25:55 -0500 --=====================_27549323==_.ALT Content-Type: text/plain; charset="us-ascii" Keep in mind that in 10589, IS-IS requires reliable point-to-point links, so the update reliability isn't there for PPP unless you also use the 3-way handshake. Fortunately, loss of the initial CNSP would only cause problems until every router had regenerated its LSP -- within 20 minutes using default LSP regen timer. See the 3-way draft for other problems that can happen because of running IS-IS over an unreliable link. Jeff At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote: >Keon, > >Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency. > >"Making the update reliable" means how the flooding made reliable using periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts. > >- Swami >-----Original Message----- >From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] >Sent: Wednesday, January 23, 2002 11:55 PM >To: Isis-wg >Subject: [Isis-wg] Making the update reliable > >Hello, > >I have a question concerning ISO/IEC 10589 7.3.17 'Making the >update reliable'. At the end of this section is written for >point-to-point circuits: > > When a point-to-point circuit (including non-DA DED circuits > and virtual links) starts (or restarts), the IS shall > > a) set SRMflag for that circuit on all LSPs, and > > b) send a Complete set of Complete Sequence Numbers PDUs > on that circuit. > >My question is now: what is actually meant with this >'start' (or 'restart') of a circuit? Do they mean an >adjacency state change to 'up', or is it really the circuit >which physically gets ready to send l2-frames? >If the second answer is what is meant, then I don't >understand why a CSNP is sent. This PDU will >be thrown away anyhow by the receiving side if there is >no adjacency (see 7.3.15.2 7: > > If the SNP is received on a non-broadcast circuit and > there is no adjacency of the same level (e.g. a level 1 SNP > with a level 1 or level 1 & 2 adjacency) on the circuit > over which the SNP was received, then the IS shall > discard the SNP without generating a event. > >). >So how can this mechanism make the update reliable? Or am I >missing something? > >Regards, >Koen > --=====================_27549323==_.ALT Content-Type: text/html; charset="us-ascii"
Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
so the update reliability isn't there for PPP unless you also use the 3-way
handshake.  Fortunately, loss of the initial CNSP would only cause problems
until every router had regenerated its LSP -- within 20 minutes using default
LSP regen timer.  See the 3-way draft for other problems that can happen
because of running IS-IS over an unreliable link.

Jeff

At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
Keon,
 
Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency.
 
"Making the update reliable" means how the flooding made reliable using  periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.
 
- Swami
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: Wednesday, January 23, 2002 11:55 PM
To: Isis-wg
Subject: [Isis-wg] Making the update reliable
Hello,

I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:

    When a point-to-point circuit (including non-DA DED circuits
    and virtual links) starts (or restarts), the IS shall

        a) set SRMflag for that circuit on all LSPs, and

        b) send a Complete set of Complete Sequence Numbers PDUs
           on that circuit.

My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the second answer is what is meant, then I don't
understand why a CSNP is sent. This PDU will
be thrown away anyhow by the receiving side if there is
no adjacency (see 7.3.15.2 7:

    If the SNP is received on a non-broadcast circuit and
    there is no adjacency of the same level (e.g. a level 1 SNP
    with a level 1 or level 1 & 2 adjacency) on the circuit
    over which the SNP was received, then the IS shall
    discard the SNP without generating a event.

).
So how can this mechanism make the update reliable? Or am I
missing something?

Regards,
Koen
 
--=====================_27549323==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 09:14:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21935 for ; Thu, 24 Jan 2002 09:14:41 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0OE9CL62295; Thu, 24 Jan 2002 06:09:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ODrXL62204 for ; Thu, 24 Jan 2002 05:53:33 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0ODuqS28398; Thu, 24 Jan 2002 08:56:52 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn1-300.cisco.com [10.82.225.44]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAN35096; Thu, 24 Jan 2002 08:56:37 -0500 (EST) Message-Id: <4.3.2.7.2.20020124085424.01d01c40@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Jeff Learman Subject: RE: [Isis-wg] Making the update reliable Cc: "Ramalingam, Swaminathan" , "'Koen Vermeulen'" , Isis-wg In-Reply-To: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_29328442==_.ALT" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 08:56:19 -0500 --=====================_29328442==_.ALT Content-Type: text/plain; charset="us-ascii" Evidently I should have read Mike's reply before sending this, which is evidently wrong about the consequences of losing the first CSNP. At 08:25 AM 1/24/2002, Jeff Learman wrote: >Keep in mind that in 10589, IS-IS requires reliable point-to-point links, >so the update reliability isn't there for PPP unless you also use the 3-way >handshake. Fortunately, loss of the initial CNSP would only cause problems >until every router had regenerated its LSP -- within 20 minutes using default >LSP regen timer. See the 3-way draft for other problems that can happen >because of running IS-IS over an unreliable link. > >Jeff > >At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote: >>Keon, >> >>Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency. >> >>"Making the update reliable" means how the flooding made reliable using periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts. >> >>- Swami >>-----Original Message----- >>From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] >>Sent: Wednesday, January 23, 2002 11:55 PM >>To: Isis-wg >>Subject: [Isis-wg] Making the update reliable >> >>Hello, >> >>I have a question concerning ISO/IEC 10589 7.3.17 'Making the >>update reliable'. At the end of this section is written for >>point-to-point circuits: >> >> When a point-to-point circuit (including non-DA DED circuits >> and virtual links) starts (or restarts), the IS shall >> >> a) set SRMflag for that circuit on all LSPs, and >> >> b) send a Complete set of Complete Sequence Numbers PDUs >> on that circuit. >> >>My question is now: what is actually meant with this >>'start' (or 'restart') of a circuit? Do they mean an >>adjacency state change to 'up', or is it really the circuit >>which physically gets ready to send l2-frames? >>If the second answer is what is meant, then I don't >>understand why a CSNP is sent. This PDU will >>be thrown away anyhow by the receiving side if there is >>no adjacency (see 7.3.15.2 7: >> >> If the SNP is received on a non-broadcast circuit and >> there is no adjacency of the same level (e.g. a level 1 SNP >> with a level 1 or level 1 & 2 adjacency) on the circuit >> over which the SNP was received, then the IS shall >> discard the SNP without generating a event. >> >>). >>So how can this mechanism make the update reliable? Or am I >>missing something? >> >>Regards, >>Koen >> --=====================_29328442==_.ALT Content-Type: text/html; charset="us-ascii"
Evidently I should have read Mike's reply before sending this, which
is evidently wrong about the consequences of losing the first CSNP.

At 08:25 AM 1/24/2002, Jeff Learman wrote:

Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
so the update reliability isn't there for PPP unless you also use the 3-way
handshake.  Fortunately, loss of the initial CNSP would only cause problems
until every router had regenerated its LSP -- within 20 minutes using default
LSP regen timer.  See the 3-way draft for other problems that can happen
because of running IS-IS over an unreliable link.

Jeff

At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
Keon,
 
Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency.
 
"Making the update reliable" means how the flooding made reliable using  periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.
 
- Swami
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: Wednesday, January 23, 2002 11:55 PM
To: Isis-wg
Subject: [Isis-wg] Making the update reliable
Hello,

I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:

    When a point-to-point circuit (including non-DA DED circuits
    and virtual links) starts (or restarts), the IS shall

        a) set SRMflag for that circuit on all LSPs, and

        b) send a Complete set of Complete Sequence Numbers PDUs
           on that circuit.

My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the second answer is what is meant, then I don't
understand why a CSNP is sent. This PDU will
be thrown away anyhow by the receiving side if there is
no adjacency (see 7.3.15.2 7:

    If the SNP is received on a non-broadcast circuit and
    there is no adjacency of the same level (e.g. a level 1 SNP
    with a level 1 or level 1 & 2 adjacency) on the circuit
    over which the SNP was received, then the IS shall
    discard the SNP without generating a event.

).
So how can this mechanism make the update reliable? Or am I
missing something?

Regards,
Koen
 
--=====================_29328442==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 10:23:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23568 for ; Thu, 24 Jan 2002 10:23:24 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0OFHCL62634; Thu, 24 Jan 2002 07:17:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0OF2YL62553 for ; Thu, 24 Jan 2002 07:02:34 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 23417 invoked from network); 24 Jan 2002 15:06:27 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 24 Jan 2002 15:06:27 -0000 From: "Ken Larmer" To: "Ramalingam, Swaminathan" , "mike shand" Cc: "Ken Larmer" , "Isis-wg" , "'Koen Vermeulen'" Subject: RE: [Isis-wg] Making the update reliable Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C1A4BF.8162D010" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4.3.2.7.2.20020124082227.00b3be80@jaws.cisco.com> Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 10:11:35 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C1A4BF.8162D010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mike Shand Wrote: The heading is something of a misnomer here. The CSNP has NOTHING to do with reliability in the case of a p2p circuit. (It does of course on a broadcast circuit). On a P2P, the CSNP is simply an optimization which avoid the need to flood the entire LSP database when the adjacency comes up between two routers which already have (most of) the database. Reliability is of course achieved by setting SRMflags on all LSPs when the circuit comes up and using PSNPs to ACK. Hi Mike, Doesn't a PSNP actually serve dual roles in this capacity, as a request and as an acknowledgement? After a circuit restarts and we form an adjacency, ISH and IIH PDUs are exchanged (not all implementations send ISH PDUs). Next, some implementations transmit newly generated LSP(s) as a result of the newly formed adjacency. By sending this LSP prior to issuing a CSNP, this eliminates the need for the remote IS to issue a PSNP as a request for this LSP and then issue a PSNP again as an acknowledgement for this LSP. Next, both sides of the link set the SRMflag for all LSPs in the appropriate LSP Ln Database, based on the adjacencyUsage (send these LSPs upon expiration of minimumLSPTransmissionInterval). They then transmit a CSNP with entries for all LSPs contained within the appropriate Ln LSPDB, regardless of the SSNflag settings. The receiving IS processes the newly received CSNP(s) and sets the SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP LSP Entry reference which is non-existent in the local LSPDB, it will create an entry in its LSPDB with a LSP Seq # = zero. It next sets the SSNflag for this entry (request this LSP from the remote adjacency). Once the partialSNPInterval timer expires, the PSNP shall be transmitted to the remote IS (clear SSNflag for this LSP entry upon successful transmission of the LSP in question). Upon receipt of this PSNP, the remote IS will think that the adjacent IS possesses an LSP which is older than the same LSPID it possesses in its local LSPDB (this is why the LSP Seq # is set to zero). Consequently, the SRMflag for this LSPID entry within the local LSPDB never gets cleared. Upon expiration of minimumLSPTransmissionInterval, this LSP is transmitted to the adjacent IS. Upon receipt of this LSP, the receiving IS sets the SSNflag so as to acknowledge receipt of this LSP. The LSPDBs should now be synchronized, of course, that is if all other LSP Entries are also processed properly. So, if one or both of the CSNPs were to get dropped, the LSPDBs should still get synchronized when minimumLSPTransmissionInterval expires. This is because the SRMflags are set when ever a CSNP is generated on a PtP link. Mike, does this make sense or am I just out in the weeds again? Cheers, Ken Larmer CommSense Networks ------=_NextPart_000_000C_01C1A4BF.8162D010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mike = Shand=20 Wrote:
 
The heading is something of a misnomer here. The CSNP has NOTHING = to do=20 with reliability in  the case of a p2p circuit. (It does of = course on a=20 broadcast circuit). On a P2P, the CSNP is simply an optimization which = avoid the=20 need to flood the entire LSP database when the adjacency comes up = between two=20 routers which already have (most of) the database. Reliability is of = course=20 achieved by setting SRMflags on all LSPs when the circuit comes up and = using=20 PSNPs to ACK.
 
Hi=20 Mike,
 
    Doesn't a PSNP actually serve dual roles in this capacity, = as a=20 request and as an acknowledgement?
 
   =20 After a circuit restarts and we form an adjacency, ISH and IIH PDUs are=20 exchanged (not all implementations send ISH PDUs).=20 Next, some implementations transmit newly generated = LSP(s) as a=20 result of the newly formed adjacency. By sending this LSP prior to = issuing=20 a CSNP, this eliminates the need for the remote IS to issue a = PSNP as=20 a request for this LSP and then issue a PSNP again as an = acknowledgement=20 for this LSP. Next, both sides of the link set the SRMflag for all LSPs = in the=20 appropriate LSP Ln Database, based on the adjacencyUsage (send = these LSPs=20 upon expiration of minimumLSPTransmissionInterval). They then transmit a = CSNP=20 with entries for all LSPs contained within the appropriate Ln LSPDB, = regardless=20 of the SSNflag settings.
 
    The receiving IS processes the newly received CSNP(s) and sets = the=20 SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP = LSP Entry=20 reference which is non-existent in the local LSPDB, it will create an = entry in=20 its LSPDB with a LSP Seq # =3D zero. It next sets the SSNflag for this = entry=20 (request this LSP from the remote adjacency). Once the = partialSNPInterval timer=20 expires, the PSNP shall be transmitted to the remote IS (clear SSNflag = for this=20 LSP entry upon successful transmission of the LSP in question). Upon = receipt of=20 this PSNP, the remote IS will think that the adjacent IS possesses an = LSP which=20 is older than the same LSPID it possesses in its local LSPDB (this is = why the=20 LSP Seq # is set to zero). Consequently, the SRMflag for this LSPID = entry within=20 the local LSPDB never gets cleared. Upon expiration of=20 minimumLSPTransmissionInterval, this LSP is transmitted to the adjacent = IS. Upon=20 receipt of this LSP, the receiving IS sets the SSNflag so as to = acknowledge=20 receipt of this LSP. The LSPDBs should now be synchronized, of course, = that is=20 if all other LSP Entries are also processed = properly.
 
    So, if one or both of the CSNPs were to get dropped, the LSPDBs = should=20 still get synchronized when minimumLSPTransmissionInterval expires. This = is=20 because the SRMflags are set when ever a CSNP is generated on = a PtP=20 link.
 
    Mike, does this make sense or am I just out in = the weeds=20 again?
 
Cheers,
Ken Larmer
CommSense Networks 
------=_NextPart_000_000C_01C1A4BF.8162D010-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 21:12:41 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12001 for ; Thu, 24 Jan 2002 21:12:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P26CL65482; Thu, 24 Jan 2002 18:06:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f48.law7.hotmail.com [216.33.237.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0OF8rL62588 for ; Thu, 24 Jan 2002 07:08:53 -0800 (PST) (envelope-from sboddapa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 24 Jan 2002 07:12:48 -0800 Received: from 64.160.53.12 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 24 Jan 2002 15:12:48 GMT X-Originating-IP: [64.160.53.12] From: "Suresh Boddapati" To: jlearman@cisco.com Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Making the update reliable Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jan 2002 15:12:48.0572 (UTC) FILETIME=[95819FC0:01C1A4E9] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 15:12:48 The loss of the initial CSNP on ptop links causing inconsistent databases per the three-way-handshake draft brings up a question. Once the adjacency is up, why should CSNPs be sent only ONCE on ptop links? If the PSNPs are serving as Acks on a ptop link, why not resend CSNPs for those LSPs that have not been acked within a period of time, until all LSPs get acked and the database is synchronized? Any new LSPs received in the meantime can still be flooded normally. There is nothing in the state machine either that precludes receiving CSNPs on ptop links at any point of time. Regards, Suresh >From: Jeff Learman >To: "Ramalingam, Swaminathan" >CC: "'Koen Vermeulen'" , Isis-wg > >Subject: RE: [Isis-wg] Making the update reliable >Date: Thu, 24 Jan 2002 08:25:55 -0500 > > >Keep in mind that in 10589, IS-IS requires reliable point-to-point links, >so the update reliability isn't there for PPP unless you also use the 3-way >handshake. Fortunately, loss of the initial CNSP would only cause problems >until every router had regenerated its LSP -- within 20 minutes using >default >LSP regen timer. See the 3-way draft for other problems that can happen >because of running IS-IS over an unreliable link. > >Jeff > >At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote: > >Keon, > > > >Whenever an adjacency comes up (may be because of start/restart) , CSNPs >are sent on p2p links.You can't send control packets without adjacency. > > > >"Making the update reliable" means how the flooding made reliable using >periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending >CSNPs on p2p network when it start/restarts. > > > >- Swami > >-----Original Message----- > >From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] > >Sent: Wednesday, January 23, 2002 11:55 PM > >To: Isis-wg > >Subject: [Isis-wg] Making the update reliable > > > >Hello, > > > >I have a question concerning ISO/IEC 10589 7.3.17 'Making the > >update reliable'. At the end of this section is written for > >point-to-point circuits: > > > > When a point-to-point circuit (including non-DA DED circuits > > and virtual links) starts (or restarts), the IS shall > > > > a) set SRMflag for that circuit on all LSPs, and > > > > b) send a Complete set of Complete Sequence Numbers PDUs > > on that circuit. > > > >My question is now: what is actually meant with this > >'start' (or 'restart') of a circuit? Do they mean an > >adjacency state change to 'up', or is it really the circuit > >which physically gets ready to send l2-frames? > >If the second answer is what is meant, then I don't > >understand why a CSNP is sent. This PDU will > >be thrown away anyhow by the receiving side if there is > >no adjacency (see 7.3.15.2 7: > > > > If the SNP is received on a non-broadcast circuit and > > there is no adjacency of the same level (e.g. a level 1 SNP > > with a level 1 or level 1 & 2 adjacency) on the circuit > > over which the SNP was received, then the IS shall > > discard the SNP without generating a event. > > > >). > >So how can this mechanism make the update reliable? Or am I > >missing something? > > > >Regards, > >Koen > > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 21:20:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12124 for ; Thu, 24 Jan 2002 21:20:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P2EWL65561; Thu, 24 Jan 2002 18:14:32 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0OFIZL62643 for ; Thu, 24 Jan 2002 07:18:35 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp18.cisco.com [144.254.108.85]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA01207; Thu, 24 Jan 2002 15:21:54 GMT Message-Id: <4.3.2.7.2.20020124151116.033c0e00@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: mike shand Subject: RE: [Isis-wg] Making the update reliable Cc: "Ramalingam, Swaminathan" , "Ken Larmer" , "Isis-wg" , "'Koen Vermeulen'" In-Reply-To: References: <4.3.2.7.2.20020124082227.00b3be80@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 15:18:51 +0000 At 10:11 24/01/2002 -0500, Ken Larmer wrote: >Mike Shand Wrote: > >The heading is something of a misnomer here. The CSNP has NOTHING to do >with reliability in the case of a p2p circuit. (It does of course on a >broadcast circuit). On a P2P, the CSNP is simply an optimization which >avoid the need to flood the entire LSP database when the adjacency comes >up between two routers which already have (most of) the database. >Reliability is of course achieved by setting SRMflags on all LSPs when the >circuit comes up and using PSNPs to ACK. > >Hi Mike, > > Doesn't a PSNP actually serve dual roles in this capacity, as a > request and as an acknowledgement? Well, yes, but I didn't want to get into a complete description of the operation of the update process. I was just pointing out the fact that the CSNP was completely unnecessary for effective synchronization. Its function is ONLY to attempt to limit the amount of LSP traffic exchanged. > > After a circuit restarts and we form an adjacency, ISH and IIH PDUs > are exchanged (not all implementations send ISH PDUs). Next, some > implementations transmit newly generated LSP(s) as a result of the newly > formed adjacency. By sending this LSP prior to issuing a CSNP, this > eliminates the need for the remote IS to issue a PSNP as a request for > this LSP and then issue a PSNP again as an acknowledgement for this LSP. > Next, both sides of the link set the SRMflag for all LSPs in the > appropriate LSP Ln Database, based on the adjacencyUsage (send these LSPs > upon expiration of minimumLSPTransmissionInterval). They then transmit a > CSNP with entries for all LSPs contained within the appropriate Ln LSPDB, > regardless of the SSNflag settings. > > The receiving IS processes the newly received CSNP(s) and sets the > SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP > LSP Entry reference which is non-existent in the local LSPDB, it will > create an entry in its LSPDB with a LSP Seq # = zero. It next sets the > SSNflag for this entry (request this LSP from the remote adjacency). Once > the partialSNPInterval timer expires, the PSNP shall be transmitted to > the remote IS (clear SSNflag for this LSP entry upon successful > transmission of the LSP in question). Upon receipt of this PSNP, the > remote IS will think that the adjacent IS possesses an LSP which is older > than the same LSPID it possesses in its local LSPDB (this is why the LSP > Seq # is set to zero). Consequently, the SRMflag for this LSPID entry > within the local LSPDB never gets cleared. Never is a bit strong! >Upon expiration of minimumLSPTransmissionInterval, this LSP is transmitted >to the adjacent IS. possibly for the second time > Upon receipt of this LSP, the receiving IS sets the SSNflag so as to > acknowledge receipt of this LSP. The LSPDBs should now be synchronized, > of course, that is if all other LSP Entries are also processed properly. > > So, if one or both of the CSNPs were to get dropped, the LSPDBs > should still get synchronized when minimumLSPTransmissionInterval > expires. This is because the SRMflags are set when ever a CSNP is > generated on a PtP link. Well, yes sort of. they are set whenever the adjacency goes up. > > Mike, does this make sense or am I just out in the weeds again? It sounds a lot more complicated than what I said :-) I just didn't want to get dragged down this hole. The whole point about the update process is that it works correctly by magic. That's all you need to know :-) :-) Mike > >Cheers, >Ken Larmer >CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 21:21:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12171 for ; Thu, 24 Jan 2002 21:21:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P2GAL65599; Thu, 24 Jan 2002 18:16:10 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0OFsHL62832 for ; Thu, 24 Jan 2002 07:54:17 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0OFwOu08578; Thu, 24 Jan 2002 10:58:24 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn1-300.cisco.com [10.82.225.44]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAN38360; Thu, 24 Jan 2002 10:58:09 -0500 (EST) Message-Id: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Suresh Boddapati" From: Jeff Learman Subject: RE: [Isis-wg] Making the update reliable Cc: isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 10:58:06 -0500 First of all, I think I made a mistake as evident from Mike S's reply. Since flags are set for all LSPs, they would all be sent and the CSNP is simply an optimization. The problem I referred to happens when only one side resets on an unreliable link AND the initial CSNP is lost. Without the 3-way handshake, if one side resets, the other side doesn't set the flags. If it also doesn't receive the CSNP, it won't forward any LSPs. This problem persists until every IS regens its LSP. While this would be remedied more quickly using a periodic CSNP on unreliable PTP links, the 3-way fixes this problem promptly and more efficiently. So I don't see any benefit to sending periodic CSNPs. It was worth considering, though. Regards, Jeff At 10:12 AM 1/24/2002, Suresh Boddapati wrote: >The loss of the initial CSNP on ptop links causing inconsistent databases per the three-way-handshake draft brings up a question. Once the adjacency is up, why should CSNPs be sent only ONCE on ptop links? If the PSNPs are serving as Acks on a ptop link, why not resend CSNPs for those LSPs that have not been acked within a period of time, until all LSPs get acked and the database is synchronized? Any new LSPs received in the meantime can still be flooded normally. There is nothing in the state machine either that precludes receiving CSNPs on ptop links at any point of time. > >Regards, > >Suresh > > >>From: Jeff Learman >>To: "Ramalingam, Swaminathan" >>CC: "'Koen Vermeulen'" , Isis-wg >>Subject: RE: [Isis-wg] Making the update reliable >>Date: Thu, 24 Jan 2002 08:25:55 -0500 >> >> >>Keep in mind that in 10589, IS-IS requires reliable point-to-point links, >>so the update reliability isn't there for PPP unless you also use the 3-way >>handshake. Fortunately, loss of the initial CNSP would only cause problems >>until every router had regenerated its LSP -- within 20 minutes using default >>LSP regen timer. See the 3-way draft for other problems that can happen >>because of running IS-IS over an unreliable link. >> >>Jeff >> >>At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote: >>>Keon, >>> >>>Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency. >>> >>>"Making the update reliable" means how the flooding made reliable using >>periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts. >>> >>>- Swami >>>-----Original Message----- >>>From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] >>>Sent: Wednesday, January 23, 2002 11:55 PM >>>To: Isis-wg >>>Subject: [Isis-wg] Making the update reliable >>> >>>Hello, >>> >>>I have a question concerning ISO/IEC 10589 7.3.17 'Making the >>>update reliable'. At the end of this section is written for >>>point-to-point circuits: >>> >>> When a point-to-point circuit (including non-DA DED circuits >>> and virtual links) starts (or restarts), the IS shall >>> >>> a) set SRMflag for that circuit on all LSPs, and >>> >>> b) send a Complete set of Complete Sequence Numbers PDUs >>> on that circuit. >>> >>>My question is now: what is actually meant with this >>>'start' (or 'restart') of a circuit? Do they mean an >>>adjacency state change to 'up', or is it really the circuit >>>which physically gets ready to send l2-frames? >>>If the second answer is what is meant, then I don't >>>understand why a CSNP is sent. This PDU will >>>be thrown away anyhow by the receiving side if there is >>>no adjacency (see 7.3.15.2 7: >>> >>> If the SNP is received on a non-broadcast circuit and >>> there is no adjacency of the same level (e.g. a level 1 SNP >>> with a level 1 or level 1 & 2 adjacency) on the circuit >>> over which the SNP was received, then the IS shall >>> discard the SNP without generating a event. >>> >>>). >>>So how can this mechanism make the update reliable? Or am I >>>missing something? >>> >>>Regards, >>>Koen >>> > > > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 21:23:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12216 for ; Thu, 24 Jan 2002 21:23:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P2HkL65623; Thu, 24 Jan 2002 18:17:46 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0OGmpL63063 for ; Thu, 24 Jan 2002 08:48:51 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0OGq0631914; Thu, 24 Jan 2002 08:52:00 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0OGq0835808; Thu, 24 Jan 2002 08:52:00 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201241652.g0OGq0835808@cirrus.juniper.net> From: Dave Katz To: jlearman@cisco.com CC: swaminathanr@netplane.com, koen.vermeulen@alcatel.be, isis-wg@spider.juniper.net In-reply-to: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com> (message from Jeff Learman on Thu, 24 Jan 2002 08:25:55 -0500) Subject: Re: [Isis-wg] Making the update reliable References: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 08:52:00 -0800 (PST) Additionally, some routers send periodic CSNPs on point-to-point links by default. X-Sender: jlearman@dingdong.cisco.com From: Jeff Learman Cc: "'Koen Vermeulen'" , Isis-wg Content-Type: multipart/alternative; boundary="=====================_27549323==_.ALT" Sender: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 08:25:55 -0500 --=====================_27549323==_.ALT Content-Type: text/plain; charset="us-ascii" Keep in mind that in 10589, IS-IS requires reliable point-to-point links, so the update reliability isn't there for PPP unless you also use the 3-way handshake. Fortunately, loss of the initial CNSP would only cause problems until every router had regenerated its LSP -- within 20 minutes using default LSP regen timer. See the 3-way draft for other problems that can happen because of running IS-IS over an unreliable link. Jeff At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote: >Keon, > >Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency. > >"Making the update reliable" means how the flooding made reliable using periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts. > >- Swami >-----Original Message----- >From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] >Sent: Wednesday, January 23, 2002 11:55 PM >To: Isis-wg >Subject: [Isis-wg] Making the update reliable > >Hello, > >I have a question concerning ISO/IEC 10589 7.3.17 'Making the >update reliable'. At the end of this section is written for >point-to-point circuits: > > When a point-to-point circuit (including non-DA DED circuits > and virtual links) starts (or restarts), the IS shall > > a) set SRMflag for that circuit on all LSPs, and > > b) send a Complete set of Complete Sequence Numbers PDUs > on that circuit. > >My question is now: what is actually meant with this >'start' (or 'restart') of a circuit? Do they mean an >adjacency state change to 'up', or is it really the circuit >which physically gets ready to send l2-frames? >If the second answer is what is meant, then I don't >understand why a CSNP is sent. This PDU will >be thrown away anyhow by the receiving side if there is >no adjacency (see 7.3.15.2 7: > > If the SNP is received on a non-broadcast circuit and > there is no adjacency of the same level (e.g. a level 1 SNP > with a level 1 or level 1 & 2 adjacency) on the circuit > over which the SNP was received, then the IS shall > discard the SNP without generating a event. > >). >So how can this mechanism make the update reliable? Or am I >missing something? > >Regards, >Koen > --=====================_27549323==_.ALT Content-Type: text/html; charset="us-ascii"
Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
so the update reliability isn't there for PPP unless you also use the 3-way
handshake.  Fortunately, loss of the initial CNSP would only cause problems
until every router had regenerated its LSP -- within 20 minutes using default
LSP regen timer.  See the 3-way draft for other problems that can happen
because of running IS-IS over an unreliable link.

Jeff

At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
Keon,
 
Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency.
 
"Making the update reliable" means how the flooding made reliable using  periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.
 
- Swami
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: Wednesday, January 23, 2002 11:55 PM
To: Isis-wg
Subject: [Isis-wg] Making the update reliable
Hello,

I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:

    When a point-to-point circuit (including non-DA DED circuits
    and virtual links) starts (or restarts), the IS shall

        a) set SRMflag for that circuit on all LSPs, and

        b) send a Complete set of Complete Sequence Numbers PDUs
           on that circuit.

My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the second answer is what is meant, then I don't
understand why a CSNP is sent. This PDU will
be thrown away anyhow by the receiving side if there is
no adjacency (see 7.3.15.2 7:

    If the SNP is received on a non-broadcast circuit and
    there is no adjacency of the same level (e.g. a level 1 SNP
    with a level 1 or level 1 & 2 adjacency) on the circuit
    over which the SNP was received, then the IS shall
    discard the SNP without generating a event.

).
So how can this mechanism make the update reliable? Or am I
missing something?

Regards,
Koen
 
--=====================_27549323==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 21:24:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12238 for ; Thu, 24 Jan 2002 21:24:54 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P2JML65650; Thu, 24 Jan 2002 18:19:22 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0OGpOL63080 for ; Thu, 24 Jan 2002 08:51:24 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0OGsb631987; Thu, 24 Jan 2002 08:54:37 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0OGsbR35811; Thu, 24 Jan 2002 08:54:37 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201241654.g0OGsbR35811@cirrus.juniper.net> From: Dave Katz To: Larmer@commsense.net CC: swaminathanr@netplane.com, mshand@cisco.com, larmer@commsense.net, isis-wg@spider.juniper.net, koen.vermeulen@alcatel.be In-reply-to: Subject: Re: [Isis-wg] Making the update reliable References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 08:54:37 -0800 (PST) It does server as a reliability mechanism when pruned flooding topologies are used (so as to make sure that the flooding topology is not partitioned) but it is only a last-ditch mechanism in this case. From: "Ken Larmer" Cc: "Ken Larmer" , "Isis-wg" , "'Koen Vermeulen'" Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C1A4BF.8162D010" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 10:11:35 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C1A4BF.8162D010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mike Shand Wrote: The heading is something of a misnomer here. The CSNP has NOTHING to do with reliability in the case of a p2p circuit. (It does of course on a broadcast circuit). On a P2P, the CSNP is simply an optimization which avoid the need to flood the entire LSP database when the adjacency comes up between two routers which already have (most of) the database. Reliability is of course achieved by setting SRMflags on all LSPs when the circuit comes up and using PSNPs to ACK. Hi Mike, Doesn't a PSNP actually serve dual roles in this capacity, as a request and as an acknowledgement? After a circuit restarts and we form an adjacency, ISH and IIH PDUs are exchanged (not all implementations send ISH PDUs). Next, some implementations transmit newly generated LSP(s) as a result of the newly formed adjacency. By sending this LSP prior to issuing a CSNP, this eliminates the need for the remote IS to issue a PSNP as a request for this LSP and then issue a PSNP again as an acknowledgement for this LSP. Next, both sides of the link set the SRMflag for all LSPs in the appropriate LSP Ln Database, based on the adjacencyUsage (send these LSPs upon expiration of minimumLSPTransmissionInterval). They then transmit a CSNP with entries for all LSPs contained within the appropriate Ln LSPDB, regardless of the SSNflag settings. The receiving IS processes the newly received CSNP(s) and sets the SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP LSP Entry reference which is non-existent in the local LSPDB, it will create an entry in its LSPDB with a LSP Seq # = zero. It next sets the SSNflag for this entry (request this LSP from the remote adjacency). Once the partialSNPInterval timer expires, the PSNP shall be transmitted to the remote IS (clear SSNflag for this LSP entry upon successful transmission of the LSP in question). Upon receipt of this PSNP, the remote IS will think that the adjacent IS possesses an LSP which is older than the same LSPID it possesses in its local LSPDB (this is why the LSP Seq # is set to zero). Consequently, the SRMflag for this LSPID entry within the local LSPDB never gets cleared. Upon expiration of minimumLSPTransmissionInterval, this LSP is transmitted to the adjacent IS. Upon receipt of this LSP, the receiving IS sets the SSNflag so as to acknowledge receipt of this LSP. The LSPDBs should now be synchronized, of course, that is if all other LSP Entries are also processed properly. So, if one or both of the CSNPs were to get dropped, the LSPDBs should still get synchronized when minimumLSPTransmissionInterval expires. This is because the SRMflags are set when ever a CSNP is generated on a PtP link. Mike, does this make sense or am I just out in the weeds again? Cheers, Ken Larmer CommSense Networks ------=_NextPart_000_000C_01C1A4BF.8162D010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mike = Shand=20 Wrote:
 
The heading is something of a misnomer here. The CSNP has NOTHING = to do=20 with reliability in  the case of a p2p circuit. (It does of = course on a=20 broadcast circuit). On a P2P, the CSNP is simply an optimization which = avoid the=20 need to flood the entire LSP database when the adjacency comes up = between two=20 routers which already have (most of) the database. Reliability is of = course=20 achieved by setting SRMflags on all LSPs when the circuit comes up and = using=20 PSNPs to ACK.
 
Hi=20 Mike,
 
    Doesn't a PSNP actually serve dual roles in this capacity, = as a=20 request and as an acknowledgement?
 
   =20 After a circuit restarts and we form an adjacency, ISH and IIH PDUs are=20 exchanged (not all implementations send ISH PDUs).=20 Next, some implementations transmit newly generated = LSP(s) as a=20 result of the newly formed adjacency. By sending this LSP prior to = issuing=20 a CSNP, this eliminates the need for the remote IS to issue a = PSNP as=20 a request for this LSP and then issue a PSNP again as an = acknowledgement=20 for this LSP. Next, both sides of the link set the SRMflag for all LSPs = in the=20 appropriate LSP Ln Database, based on the adjacencyUsage (send = these LSPs=20 upon expiration of minimumLSPTransmissionInterval). They then transmit a = CSNP=20 with entries for all LSPs contained within the appropriate Ln LSPDB, = regardless=20 of the SSNflag settings.
 
    The receiving IS processes the newly received CSNP(s) and sets = the=20 SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP = LSP Entry=20 reference which is non-existent in the local LSPDB, it will create an = entry in=20 its LSPDB with a LSP Seq # =3D zero. It next sets the SSNflag for this = entry=20 (request this LSP from the remote adjacency). Once the = partialSNPInterval timer=20 expires, the PSNP shall be transmitted to the remote IS (clear SSNflag = for this=20 LSP entry upon successful transmission of the LSP in question). Upon = receipt of=20 this PSNP, the remote IS will think that the adjacent IS possesses an = LSP which=20 is older than the same LSPID it possesses in its local LSPDB (this is = why the=20 LSP Seq # is set to zero). Consequently, the SRMflag for this LSPID = entry within=20 the local LSPDB never gets cleared. Upon expiration of=20 minimumLSPTransmissionInterval, this LSP is transmitted to the adjacent = IS. Upon=20 receipt of this LSP, the receiving IS sets the SSNflag so as to = acknowledge=20 receipt of this LSP. The LSPDBs should now be synchronized, of course, = that is=20 if all other LSP Entries are also processed = properly.
 
    So, if one or both of the CSNPs were to get dropped, the LSPDBs = should=20 still get synchronized when minimumLSPTransmissionInterval expires. This = is=20 because the SRMflags are set when ever a CSNP is generated on = a PtP=20 link.
 
    Mike, does this make sense or am I just out in = the weeds=20 again?
 
Cheers,
Ken Larmer
CommSense Networks 
------=_NextPart_000_000C_01C1A4BF.8162D010-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 21:27:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12261 for ; Thu, 24 Jan 2002 21:27:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P2L3L65693; Thu, 24 Jan 2002 18:21:03 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rchss002.chiaro.com (rchss002.chiaro.com [63.88.196.82]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g0OMKbL64485 for ; Thu, 24 Jan 2002 14:20:37 -0800 (PST) (envelope-from lliu@chiaro.com) Received: (qmail 1036 invoked from network); 24 Jan 2002 22:21:30 -0000 Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82) by rchss002.chiaro.com with SMTP; 24 Jan 2002 22:21:30 -0000 Received: by MAIL with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 16:23:50 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A50701B94F77@MAIL> From: Laura Liu To: Jeff Parker , Laura Liu Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] Questions on cird IDs in isis mib MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 16:23:49 -0600 --=_IS_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Jeff, I have another question on isis mib. For those table index entries, they are defined as MAX-ACCESS not-accessible Does this mean, this entry cannot be access through snmp get command, are they only used in part of oid? thanks, Laura -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Wednesday, January 23, 2002 1:33 PM To: 'Laura Liu' Cc: IS-IS-WG (E-mail) Subject: RE: [Isis-wg] Questions on cird IDs in isis mib > 1. isisCircIndex and isisCircIfIndex are defined as Integer32. My > understanding is isisCircIndex refers to a logical id, while isisCircIndex OBJECT-TYPE SYNTAX Integer32 (1..2000000000) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of this circuit, unique within the instance of the IS-IS protocol. This object follows the index behavior. This is for SNMP Indexing purposes only and need not have any relation to any protocol value." ::= { isisCircEntry 1 } So this can be an index into an array, a hash value, or it could be the index of a port in your box. However, many devices allow multiple circuits to run over the same physical port, and would not be able to use a physical port number as the index. In brief, it is whatever you would like it to be. It could be the same as isisCircIfIndex. > isisCircIfIndex are the physical id of the > interface to which this circuit corresponds. isisCircIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value of ifIndex for the interface to which this circuit corresponds. This object cannot be modified after creation" ::= { isisCircEntry 2 } Nope, this is the MIB II IfIndex. There are rules about doling this out. What we're trying to do here is to have a value that lines up with the value of the manager will see in the Interface table. > 2. isisCircLocalID is Integer32(0..255), is the locally > assigned one octet > Local Circuit ID used for "maintaining more than 255 circuits > in IS-IS". isisCircLocalID OBJECT-TYPE SYNTAX Integer32(0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "An identification that can be used in protocol packets to identify a circuit. Values of isisCircLocalID do not need to be unique. They are only required to differ on LANs where the Intermediate System is the Designated Intermediate System." ::= { isisCircEntry 4 } The MIB does not try to address the issue of how to maintain a presence as the DIS on more than 256 LANs. Briefly, this is the octet that you use to augment the system ID to provide a unique PNodeID. This can be related to one of the other indicies, or can be independent. The implementer gets to allocate this. > Another question, there is isisCircLevelDesIS object, it only > report the > DR's system ID part. How can I retrieve the circuit ID part > of DR's LAN ID? > > please help, and thanks! > > Laura Laura - I think that is an error: thanks for catching that. The syntax should be an octet string of length 7 or 0. isisCircLevelDesIS OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..7)) MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the LAN Designated Intermediate System on this circuit at this level. If, for any reason, this system is not partaking in the relevant Designated Intermediate System election process, then the value returned is the zero length OCTET STRING." REFERENCE "{ISIS.aoi l2DesignatedIntermediateSystem (75)}" ::= { isisCircLevelEntry 4 } - jeff parker - axiowave networks --=_IS_MIME_Boundary Content-Type: text/plain;charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit ----------------------------------------- (on Chiaro SMTP Relay) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- --=_IS_MIME_Boundary-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 21:28:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12278 for ; Thu, 24 Jan 2002 21:28:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P2MiL65732; Thu, 24 Jan 2002 18:22:44 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0ONRKL64781 for ; Thu, 24 Jan 2002 15:27:20 -0800 (PST) (envelope-from dhudek@ma.ultranet.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0ONVHc32611 for ; Thu, 24 Jan 2002 15:31:17 -0800 (PST) X-JNPR-Received-From: outside Received: from rly-ip02.mx.aol.com ([152.163.225.160]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 24 Jan 2002 15:23:43 -0800 Received: from logs-te.proxy.aol.com (logs-te.proxy.aol.com [152.163.195.135]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id SAA29611 for ; Thu, 24 Jan 2002 18:21:32 -0500 (EST) Received: from ma.ultranet.com (AC956568.ipt.aol.com [172.149.101.104]) by logs-te.proxy.aol.com (8.10.0/8.10.0) with ESMTP id g0ONHBR255346 for ; Thu, 24 Jan 2002 18:17:12 -0500 (EST) Message-ID: <3C5096DA.C8B51ED@ma.ultranet.com> From: David Hudek X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: Hudeks@aol.com X-OriginalArrivalTime: 24 Jan 2002 23:23:43.0359 (UTC) FILETIME=[29ED70F0:01C1A52E] Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 18:20:58 -0500 Content-Transfer-Encoding: 7bit I have a comment/concern about the current description of subTLV 6 (IPv4 Iface Addr) in the new TLV type 22 (Extended IS Reach) assuming that the doc is intended to cover unnumbered point to point interfaces as well as numbered interfaces (did not see any scope statement which restricted it to numbered only?) If one is supporting traffic engineering, the doc currently specifies that subTLV6 is mandatory... but on an unnumbered interface by definition there is no IPv4 address, and one would not have a valid IPv4 Iface Addr to place in this mandatory subTLV. There is stuff in draft-ietf-isis-gmpls-extensions-04 which provides a means of exchanging interface IDs (in the Hellos) applicable to unnumbered p2p's, and new subTLVs for TLV type 22 to convey iface IDs... I presume that is the intended behavior for unnumbered p2p's. It seems like the text for subTLV6 should state that if one is supporting traffic engineering, subTLV 6 is only mandatory for numbered interfaces and must not be used for unnumbered P2Ps (and possibly give a pointer to the gmpls extensions doc). Thanks, dave hudek dhudek@ma.ultranet.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 24 21:55:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13592 for ; Thu, 24 Jan 2002 21:55:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P2o2L66003; Thu, 24 Jan 2002 18:50:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P2njL65988 for ; Thu, 24 Jan 2002 18:49:45 -0800 (PST) (envelope-from tli@procket.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g0P2rhE78343 for ; Thu, 24 Jan 2002 18:53:43 -0800 (PST) X-JNPR-Received-From: outside Received: from miata.procket.com ([65.174.124.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 24 Jan 2002 18:53:13 -0800 Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0P2rbeR016382; Thu, 24 Jan 2002 18:53:37 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0P2raXg005526; Thu, 24 Jan 2002 18:53:36 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15440.51376.725664.842316@alpha-tli.procket.com> To: David Hudek Cc: isis-wg@juniper.net Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-04.txt In-Reply-To: <3C5096DA.C8B51ED@ma.ultranet.com> References: <3C5096DA.C8B51ED@ma.ultranet.com> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 25 Jan 2002 02:53:13.0874 (UTC) FILETIME=[6E89CF20:01C1A54B] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 18:53:36 -0800 Content-Transfer-Encoding: 7bit We were only supporting numbered interfaces. Tony David Hudek writes: | | I have a comment/concern about the current description of | subTLV 6 (IPv4 Iface Addr) in the new TLV type 22 | (Extended IS Reach) assuming that the doc is intended | to cover unnumbered point to point interfaces as well | as numbered interfaces (did not see any scope statement | which restricted it to numbered only?) | | If one is supporting traffic engineering, the doc currently | specifies that subTLV6 is mandatory... but on an unnumbered | interface by definition there is no IPv4 address, and | one would not have a valid IPv4 Iface Addr to place | in this mandatory subTLV. | | There is stuff in draft-ietf-isis-gmpls-extensions-04 | which provides a means of exchanging interface IDs | (in the Hellos) applicable to unnumbered p2p's, and | new subTLVs for TLV type 22 to convey iface IDs... | I presume that is the intended behavior for unnumbered p2p's. | | It seems like the text for subTLV6 should state that | if one is supporting traffic engineering, subTLV 6 | is only mandatory for numbered interfaces and must not | be used for unnumbered P2Ps (and possibly give a pointer to | the gmpls extensions doc). | | Thanks, | dave hudek | dhudek@ma.ultranet.com | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 00:38:48 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16948 for ; Fri, 25 Jan 2002 00:38:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P5X2L66683; Thu, 24 Jan 2002 21:33:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f63.law3.hotmail.com [209.185.241.63]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P5WKL66670 for ; Thu, 24 Jan 2002 21:32:20 -0800 (PST) (envelope-from sachidananda_k@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 24 Jan 2002 21:36:19 -0800 Received: from 203.196.145.150 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 25 Jan 2002 05:36:18 GMT X-Originating-IP: [203.196.145.150] From: "Sachidananda K" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jan 2002 05:36:19.0210 (UTC) FILETIME=[370D96A0:01C1A562] Subject: [Isis-wg] CSNP from Designated IS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 05:36:18 +0000 Hi All, When an intermediate system just comes up on a broadcast circuit it would typically not be having any LSPs in its database. Co-incidently, if this IS happens to be the designated IS for that broadcast circuit, then what start LSP ID and the end LSP ID shall be put in the CSNP constructed by this IS? To be more generic, how can we ensure that this new IS's database is synchronised with that of all the othre IS's in the LAN? Thanking you in advance for all the responses. Sachi. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 00:53:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17249 for ; Fri, 25 Jan 2002 00:53:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P5m5L66762; Thu, 24 Jan 2002 21:48:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P5hPL66733 for ; Thu, 24 Jan 2002 21:43:25 -0800 (PST) (envelope-from tli@Procket.com) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0P5lJeR005907; Thu, 24 Jan 2002 21:47:19 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0P5lJgQ006004; Thu, 24 Jan 2002 21:47:19 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15440.61799.591910.482779@alpha-tli.procket.com> To: "Sachidananda K" Cc: isis-wg@spider.juniper.net Subject: [Isis-wg] CSNP from Designated IS In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 21:47:19 -0800 Content-Transfer-Encoding: 7bit | When an intermediate system just comes up on a broadcast circuit it would | typically not be having any LSPs in its database. It should generate at least its own, even if it doesn't have any adjacencies. | Co-incidently, if this IS | happens to be the designated IS for that broadcast circuit, then what start | LSP ID and the end LSP ID shall be put in the CSNP constructed by this IS? Then it should also generate a pseudo-node LSP. The CSNP should contain the full range of the database from LSP ID 0 (zero) to the all-ones LSP ID. | To be more generic, how can we ensure that this new IS's database is | synchronised with that of all the othre IS's in the LAN? It should send out CSNPs. Anyone disagreeing should speak up. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 01:42:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17725 for ; Fri, 25 Jan 2002 01:42:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P6b9L67041; Thu, 24 Jan 2002 22:37:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P6OOL66969 for ; Thu, 24 Jan 2002 22:24:25 -0800 (PST) (envelope-from swaminathanr@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 01:28:23 -0500 Message-ID: From: "Ramalingam, Swaminathan" To: Sachidananda K Cc: isis-wg@spider.juniper.net, "'Tony Li'" Subject: RE: [Isis-wg] CSNP from Designated IS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 01:28:17 -0500 comments inlined > -----Original Message----- > From: Tony Li [mailto:tli@procket.com] > Sent: Friday, January 25, 2002 11:17 AM > To: Sachidananda K > Cc: isis-wg@spider.juniper.net > Subject: [Isis-wg] CSNP from Designated IS > > > > > | When an intermediate system just comes up on a broadcast > circuit it would > | typically not be having any LSPs in its database. > > > It should generate at least its own, even if it doesn't have > any adjacencies. > > > | Co-incidently, if this IS > | happens to be the designated IS for that broadcast > circuit, then what start > | LSP ID and the end LSP ID shall be put in the CSNP > constructed by this IS? > > > Then it should also generate a pseudo-node LSP. The CSNP > should contain > the full range of the database from LSP ID 0 (zero) to the > all-ones LSP ID. > > > | To be more generic, how can we ensure that this new IS's > database is > | synchronised with that of all the othre IS's in the LAN? > > > It should send out CSNPs. Anyone disagreeing should speak up. > > Adding to Tony's reply, DIS sends out CSNPs. When the receiver finds DIS is out of date, it will multicast the missing information (so that other IS receiving CSNP will not send again). If DIS has new information, the receiving IS multicast PSNP for missing information.Here only DIS should send the missing info, others should not. Hope this helps ~ Swami > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 01:59:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17888 for ; Fri, 25 Jan 2002 01:59:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P6sCL67140; Thu, 24 Jan 2002 22:54:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P6TxL66994 for ; Thu, 24 Jan 2002 22:29:59 -0800 (PST) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 9028A4BA219; Thu, 24 Jan 2002 22:33:57 -0800 (PST) To: "Suresh Boddapati" Cc: jlearman@cisco.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Making the update reliable In-reply-to: Mail from "Suresh Boddapati" dated Thu, 24 Jan 2002 15:12:48 From: Naiming Shen Message-Id: <20020125063357.9028A4BA219@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 22:33:57 -0800 ] The loss of the initial CSNP on ptop links causing inconsistent databases ] per the three-way-handshake draft brings up a question. Once the adjacency ] is up, why should CSNPs be sent only ONCE on ptop links? If the PSNPs are ] serving as Acks on a ptop link, why not resend CSNPs for those LSPs that ] have not been acked within a period of time, until all LSPs get acked and ] the database is synchronized? Any new LSPs received in the meantime can ] still be flooded normally. There is nothing in the state machine either that ] precludes receiving CSNPs on ptop links at any point of time. ] True. But it does not seem to help much if you keep sending CSNPs either. In the case no 3way hello is running, the first CSNP is lost, and the link becomes unidirectional, no matter how many CSNPs being sent later on, the two sides still can not syncronize, or it does get syncronized but one side will keep sending out LSPs due to no Ack back from the peer. In the case of the link being bidirectional, the initial CSNP got lost. All LSPs will be sent over the link, and the other side has to send back the PSNPs to Ack. Say A->B csnp is lost, B has to send all its LSPs to A. A has to response with PSNPs. Even A keeps sending csnps to B, A still need to send those PSNPs. And they basically contain the same info: don't send them anymore! It does seem to help, if before you send any LSPs, just send a couple of CSNP sets fast, hopefully one set gets through. Or PSNP also be able to Ack the CSNPs received, so both sides are sure CSNPs get through fine. But it does seem over optimization. And it only matters when two isolated portion of the network being first brought up through this p2p link. It does not sound like in a fast reroute of the VoIP traffic case;-) So just let it take some time, allow all the LSPs take their own pace through the poor p2p link... ] Regards, ] ] Suresh ] ] ] >From: Jeff Learman ] >To: "Ramalingam, Swaminathan" ] >CC: "'Koen Vermeulen'" , Isis-wg ] > ] >Subject: RE: [Isis-wg] Making the update reliable ] >Date: Thu, 24 Jan 2002 08:25:55 -0500 ] > ] > ] >Keep in mind that in 10589, IS-IS requires reliable point-to-point links, ] >so the update reliability isn't there for PPP unless you also use the 3-way ] >handshake. Fortunately, loss of the initial CNSP would only cause problems ] >until every router had regenerated its LSP -- within 20 minutes using ] >default ] >LSP regen timer. See the 3-way draft for other problems that can happen ] >because of running IS-IS over an unreliable link. ] > ] >Jeff ] > ] >At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote: ] > >Keon, ] > > ] > >Whenever an adjacency comes up (may be because of start/restart) , CSNPs ] >are sent on p2p links.You can't send control packets without adjacency. ] > > ] > >"Making the update reliable" means how the flooding made reliable using ] >periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending ] >CSNPs on p2p network when it start/restarts. ] > > ] > >- Swami ] > >-----Original Message----- ] > >From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] ] > >Sent: Wednesday, January 23, 2002 11:55 PM ] > >To: Isis-wg ] > >Subject: [Isis-wg] Making the update reliable ] > > ] > >Hello, ] > > ] > >I have a question concerning ISO/IEC 10589 7.3.17 'Making the ] > >update reliable'. At the end of this section is written for ] > >point-to-point circuits: ] > > ] > > When a point-to-point circuit (including non-DA DED circuits ] > > and virtual links) starts (or restarts), the IS shall ] > > ] > > a) set SRMflag for that circuit on all LSPs, and ] > > ] > > b) send a Complete set of Complete Sequence Numbers PDUs ] > > on that circuit. ] > > ] > >My question is now: what is actually meant with this ] > >'start' (or 'restart') of a circuit? Do they mean an ] > >adjacency state change to 'up', or is it really the circuit ] > >which physically gets ready to send l2-frames? ] > >If the second answer is what is meant, then I don't ] > >understand why a CSNP is sent. This PDU will ] > >be thrown away anyhow by the receiving side if there is ] > >no adjacency (see 7.3.15.2 7: ] > > ] > > If the SNP is received on a non-broadcast circuit and ] > > there is no adjacency of the same level (e.g. a level 1 SNP ] > > with a level 1 or level 1 & 2 adjacency) on the circuit > > over which the SNP was received, then the IS shall ] > > discard the SNP without generating a event. ] > > ] > >). ] > >So how can this mechanism make the update reliable? Or am I ] > >missing something? ] > > ] > >Regards, ] > >Koen ] > > ] ] ] ] ] _________________________________________________________________ ] Chat with friends online, try MSN Messenger: http://messenger.msn.com ] ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@external.juniper.net ] http://external.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 12:23:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08123 for ; Fri, 25 Jan 2002 12:23:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PHHWL70375; Fri, 25 Jan 2002 09:17:32 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P6eDL67059 for ; Thu, 24 Jan 2002 22:40:13 -0800 (PST) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 658FBCAB70; Thu, 24 Jan 2002 22:44:12 -0800 (PST) To: Tony Li Cc: "Sachidananda K" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] CSNP from Designated IS In-reply-to: Mail from Tony Li dated Thu, 24 Jan 2002 21:47:19 PST <15440.61799.591910.482779@alpha-tli.procket.com> From: Naiming Shen Message-Id: <20020125064412.658FBCAB70@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 22:44:12 -0800 ] | To be more generic, how can we ensure that this new IS's database is ] | synchronised with that of all the othre IS's in the LAN? ] ] ] It should send out CSNPs. Anyone disagreeing should speak up. yes. this one is the DR, sending out csnp is all he can do. basically he is saying "I know for sure there is no LSPs except my own", then all the other ISs on the LAN saying "you are wrong, here is ours", then they supply the DR with their LSPs. then the DR gets all the LSPs simply by being wrong. what a nice protocol. ] ] ] Tony - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 12:38:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08530 for ; Fri, 25 Jan 2002 12:38:29 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PHWRL70447; Fri, 25 Jan 2002 09:32:27 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web13201.mail.yahoo.com (web13201.mail.yahoo.com [216.136.174.186]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g0P7UAL67336 for ; Thu, 24 Jan 2002 23:30:10 -0800 (PST) (envelope-from dasnabendu@yahoo.com) Message-ID: <20020125073409.46690.qmail@web13201.mail.yahoo.com> Received: from [203.200.20.226] by web13201.mail.yahoo.com via HTTP; Thu, 24 Jan 2002 23:34:09 PST From: nabendu das To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] checksum calculation doubt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 24 Jan 2002 23:34:09 -0800 (PST) hello all, As per ISO-10589 7.3.11(Generation of checksum) " An IS shall start with C0 & C1 initialised to what they would be after computing for the systemID portion of its Source ID, The IS shall then resume Checksum computation on the contents of the PDU after the first ID Length octets of the Source ID field," & in NOTE" All checksum calculations on the LSP are performed treating the Source ID field as the first octet. This procedure prevents the source from accidentally sending out LSP with some other system'd ID as source" Now the Question is while generating the checksum what will happen if we do not initailize C0 & C1 to the computed checksum of the System ID portion of Source ID, what will be the problem if we initialize C0 & C1 to zero, as ISO document anyway is saying to initialize C0 & C1 to the calclated value of the checksum of System ID portion of the Source ID & then to resume checksum calculation on the contents of the PDU after the first ID Length octets of the Source ID field. And when a router receives an LSP, how should it verify, should it start from the LSPID field because "All checksum calculations on the LSP are performed treating the Source ID field as the first octet." is bit ambiguous, how can we take Source ID field as first octet as it is of 6 octets, Does it mean to start from the first Octet of the LSPID portion. __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 12:45:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08918 for ; Fri, 25 Jan 2002 12:45:41 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PHdhL70495; Fri, 25 Jan 2002 09:39:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0P7utL67447 for ; Thu, 24 Jan 2002 23:56:55 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0P80n670897; Fri, 25 Jan 2002 00:00:49 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0P80nZ37529; Fri, 25 Jan 2002 00:00:49 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201250800.g0P80nZ37529@cirrus.juniper.net> From: Dave Katz To: jlearman@cisco.com CC: sboddapa@hotmail.com, isis-wg@spider.juniper.net In-reply-to: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> (message from Jeff Learman on Thu, 24 Jan 2002 10:58:06 -0500) Subject: Re: [Isis-wg] Making the update reliable References: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 00:00:49 -0800 (PST) So I don't see any benefit to sending periodic CSNPs. It was worth considering, though. We send 'em anyhow. I think I made the cisco code do the same thing, but it's been a lot of years. Or maybe you can just configure it on the cisco box, I don't remember offhand. Cheap insurance when working with the ill-named mesh groups. --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 13:26:51 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10103 for ; Fri, 25 Jan 2002 13:26:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PIL1L70739; Fri, 25 Jan 2002 10:21:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PI55L70659 for ; Fri, 25 Jan 2002 10:05:05 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4154.cisco.com [10.50.16.57]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA28402; Fri, 25 Jan 2002 18:09:03 GMT Message-Id: <4.3.2.7.2.20020125175100.033cb130@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: nabendu das From: mike shand Subject: Re: [Isis-wg] checksum calculation doubt Cc: isis-wg@spider.juniper.net In-Reply-To: <20020125073409.46690.qmail@web13201.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 18:06:44 +0000 At 23:34 24/01/2002 -0800, nabendu das wrote: >hello all, > >As per ISO-10589 7.3.11(Generation of checksum) >" An IS shall start with C0 & C1 initialised to what >they would be after computing for the systemID portion >of its Source ID, The IS shall then resume Checksum >computation on the contents of the PDU after the first >ID Length octets of the Source ID field," > >& in NOTE" All checksum calculations on the LSP are >performed treating the Source ID field as the first >octet. This procedure prevents the source from >accidentally sending out LSP with some other system'd >ID as source" > >Now the Question is while generating the checksum what >will happen if we do not initailize C0 & C1 to the >computed checksum of the System ID portion of Source >ID, what will be the problem if we initialize C0 & C1 >to zero, as ISO document anyway is saying to >initialize C0 & C1 to the calclated value of the >checksum of System ID portion of the Source ID & then >to resume checksum calculation on the contents of the >PDU after the first ID Length octets of the Source ID >field. As I recall, the idea was that the router's checksum code knew what the system ID was supposed to be (it was initialized when the router was booted). So if when generating the LSP, it accidentally put the wrong source ID, or more likely if the LSP somehow got corrupted as it was being built, the LSP would get sent out with a bogus checksum and so would be ignored. The protection it gives is I think marginal, and I'm not sure it is very important. In fact it is arguable whether it should appear in the standard at all, since it is not possible to tell by looking at the packet whether it is being done or not. I suppose one could try installing flakey RAM in the router and seeing if it does the wrong thing? However, this is similar to statements that you must not recompute the checksum of an IP packet when you change it, but should rather use an incremental checksum modifier, hence giving protection between the time that the packet is received (and the checksum verified) and when it is modified. Again, its very hard to tell if you are doing this right, but it is still a good idea to do it. But perhaps Radia has stronger opinions on this one, since I think it was her idea. >And when a router receives an LSP, how should it >verify, should it start from the LSPID field because >"All checksum calculations on the LSP are performed >treating the Source ID field as the first octet." is >bit ambiguous, how can we take Source ID field as >first octet as it is of 6 octets, Does it mean to >start from the first Octet of the LSPID portion. From the start of the source ID, i.e. octet 13 counting the first octet as octet one. >__________________________________________________ >Do You Yahoo!? >Great stuff seeking new owners in Yahoo! Auctions! >http://auctions.yahoo.com >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 13:36:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10409 for ; Fri, 25 Jan 2002 13:36:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PIVCL70791; Fri, 25 Jan 2002 10:31:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PIA8L70684 for ; Fri, 25 Jan 2002 10:10:08 -0800 (PST) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 2B18B262804; Fri, 25 Jan 2002 10:14:10 -0800 (PST) To: "Ken Larmer" Cc: "Suresh Boddapati" , "Naiming Shen" , isis-wg@spider.juniper.net, jlearman@cisco.com Subject: Re: [Isis-wg] Making the update reliable In-reply-to: Mail from "Ken Larmer" dated Fri, 25 Jan 2002 10:06:21 EST From: Naiming Shen Message-Id: <20020125181410.2B18B262804@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 10:14:10 -0800 I was referring to how much useful if one send repeated resend CSNPs. My understanding is: very little, why bother. ] Naiming Wrote: ] ] > In the case no 3way hello is running, the first CSNP is lost, and ] > the link becomes unidirectional, no matter how many CSNPs being ] > sent later on, the two sides still can not syncronize, or it does get ] > syncronized but one side will keep sending out LSPs due to no Ack ] > back from the peer. I think I had the second paragraph from 3way draft below in mind, which is the link came up, the initial CSNP got lost and also the link became unidirectional. ----->--- X ------ A B -----<------------ in the above diagram, the connection from A to B is down, but from B to A is up. Assume both sides are out of sync. 1) A -> B initial csnp is lost well, the link is down, no matter how many CSNPs A trys to resend, obviously they are wasted. 2) B -> A initial csnp is lost If B do not resend CSNP, A will try to send all its LSPs over the broken link and get lost. If B do resend CSNPs, A will only try to resend partial of its LSPs, and all get lost. So it does not matter CSNPs get resend or not. Actually, if a link is unidirectional, out sync maybe is better, since it can be noticed by operators sooner. If A and B has parallel links, then both sides are always synced, assume the other link is ok, then resend or not of CSNP does not matter either. These days, one can hardly find any routers do not do 3way by default, so its not a very interesting subject; for 3way draft, it is THE subject. ] ] >In the case of the link being bidirectional, the initial CSNP got lost. ] >All LSPs will be sent over the link, and the other side has to send back ] >the PSNPs to Ack. Say A->B csnp is lost, B has to send all its LSPs to A. ] >A has to response with PSNPs. Even A keeps sending csnps to B, A still ] >need to send those PSNPs. And they basically contain the same info: don't ] >send them anymore! ----->------------ A B -----<------------ borrow the same diagram, only the link is good, bi-directional. but this has no relation with the 3way draft. If A -> B initial CSNP is lost. B has to send all its LSPs over this link to A. Due to the Ack mechanism, A needs to send PSNPs to ack those LSPs from B, or send its LSPs to B if they are more recent. This is what A has to do after receiving LSPs from B. This is regardless of B resend CSNPs to A or not. Which means those resent CSNPs are wasted. The only time it seems to help for repeated resending CSNPs seems if both side initial CSNPs get lost, and also some of the LSPs also get lost during the transmission. Then resend CSNPs can reduce keep resending those lost LSPs which has no need to sync on both sides in the first place. So its just an optimization. That's why I suggested some "over-optimization" steps before sending out your LSPs over this link: - at link comes up, keep sending a couple of sets CSNP, hope at least one set gets through. - have some kind of Ack for p2p initial CSNPs. But this is not without a price to pay, obviously any one of those will delay the sending out LSPs, which will delay the network convergence. ] ] Hi Naming, can you please explain the two scenarios above in more detail? ] Are they the same as the scenarios referenced in the "Three-Way Handshake ] for IS-IS Point-to-Point Adjacencies" draft as referenced below: ] ] Three failure modes are known. First, if the link goes down and then ] comes back up, or one of the systems restarts, and the CSNP packet is ] lost, and the network has a cut set of one through the link, the link ] state databases on either side of the link will not synchronize for a ] full LSP refresh period (up to eighteen hours). ] ] A second, more serious failure, is that if the link fails in only one ] direction, the failure will only be detected by one of the systems. ] Normally, this is not a serious issue; only one of the two systems ] will announce the adjacency in its link state packets, and the SPF ] algorithm will thus ignore the link. However, if there are two ] parallel links between systems and one of them fails in one ] direction, SPF will still calculate paths between the two systems, ] and the system that does not notice the failure will attempt to pass ] traffic down the failed link (in the direction that does not work). ] ] The third issue is that on some physical layers, the ] interconnectivity between endpoints can change without causing a ] link-layer-down condition. In this case, a system may receive packets ] that are actually destined for a different system (or a different ] link on the same system). The receiving system may end up thinking ] that it has an adjacency with the remote system when in fact the ] remote system is adjacent with a third system. ] ] ] Cheers, ] Ken Larmer ] CommSense Networks ] ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 17:12:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15974 for ; Fri, 25 Jan 2002 17:11:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PM5eL71707; Fri, 25 Jan 2002 14:05:40 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PIKrL70727 for ; Fri, 25 Jan 2002 10:20:54 -0800 (PST) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 7D1D01531CB; Fri, 25 Jan 2002 10:24:55 -0800 (PST) To: Dave Katz Cc: jlearman@cisco.com, sboddapa@hotmail.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Making the update reliable In-reply-to: Mail from Dave Katz dated Fri, 25 Jan 2002 00:00:49 PST <200201250800.g0P80nZ37529@cirrus.juniper.net> From: Naiming Shen Message-Id: <20020125182455.7D1D01531CB@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 10:24:55 -0800 ] So I don't see any benefit to sending periodic CSNPs. It was worth ] considering, though. Yes. I was just referring to the case at initial stage of syncing up, I don't see a reason of lots of CSNPs flowing through. But send them periodically, say once every 15 minutes may not be a bad network insurance approach. Especially the router software is just upgraded:-) ] ] We send 'em anyhow. I think I made the cisco code do the same thing, ] but it's been a lot of years. Or maybe you can just configure it ] on the cisco box, I don't remember offhand. ] ] Cheap insurance when working with the ill-named mesh groups. Yes, its definitely recommended if the link is configured as mesh-group blocking lsps. Then periodically exchange of CSNPs over the p2p links makes lots of sense. But again, you were the one created those problems at the first place... ] ] --Dave - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 22:29:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21537 for ; Fri, 25 Jan 2002 22:29:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0Q3LFL73067; Fri, 25 Jan 2002 19:21:15 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PJ9xL70987 for ; Fri, 25 Jan 2002 11:09:59 -0800 (PST) (envelope-from jharper@cisco.com) Received: from JHARPER-W2K1.cisco.com (dhcp-128-107-163-83.cisco.com [128.107.163.83]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA01127; Fri, 25 Jan 2002 19:13:57 GMT Message-Id: <4.3.2.7.2.20020125111331.03fbfaf0@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: mike shand From: John Harper Subject: Re: [Isis-wg] checksum calculation doubt Cc: nabendu das , isis-wg@spider.juniper.net In-Reply-To: <4.3.2.7.2.20020125175100.033cb130@jaws.cisco.com> References: <20020125073409.46690.qmail@web13201.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 11:13:58 -0800 Nah, I bet you dinner it was Tony. This is exactly the kind of thing he got excited about. John At 18:06 25/01/2002 +0000, mike shand wrote: >But perhaps Radia has stronger opinions on this one, since I think it was >her idea. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 22:37:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22532 for ; Fri, 25 Jan 2002 22:37:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0Q3TSL73110; Fri, 25 Jan 2002 19:29:28 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PJPQL71054 for ; Fri, 25 Jan 2002 11:25:26 -0800 (PST) (envelope-from tli@Procket.com) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0PJTDeR026056; Fri, 25 Jan 2002 11:29:13 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0PJTDJR011859; Fri, 25 Jan 2002 11:29:13 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.45577.649058.450053@alpha-tli.procket.com> To: Dave Katz Cc: jlearman@cisco.com, sboddapa@hotmail.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Making the update reliable In-Reply-To: <200201250800.g0P80nZ37529@cirrus.juniper.net> References: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> <200201250800.g0P80nZ37529@cirrus.juniper.net> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 11:29:13 -0800 Content-Transfer-Encoding: 7bit | So I don't see any benefit to sending periodic CSNPs. It was worth | considering, though. | | We send 'em anyhow. I think I made the cisco code do the same thing, | but it's been a lot of years. Or maybe you can just configure it | on the cisco box, I don't remember offhand. | | Cheap insurance when working with the ill-named mesh groups. I'd say they're damn cheap insurance period. But then I was always a belt and suspenders kinda guy. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 22:59:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22837 for ; Fri, 25 Jan 2002 22:59:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0Q3oYL73282; Fri, 25 Jan 2002 19:50:34 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PEkXL69697 for ; Fri, 25 Jan 2002 06:46:33 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Laura Liu'" , Jeff Parker Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] Questions on cird IDs in isis mib MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 09:49:43 -0500 > For those table index entries, [that] are defined as > > MAX-ACCESS not-accessible > > Does this mean, this entry cannot be access through > snmp get command, are they only used in part of oid? > > Laura I believe you are right. They -can- be discovered through a get-next walk of the table. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 25 23:48:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23672 for ; Fri, 25 Jan 2002 23:48:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0Q4e2L73563; Fri, 25 Jan 2002 20:40:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0Q4dvL73548 for ; Fri, 25 Jan 2002 20:39:57 -0800 (PST) (envelope-from Radia.Perlman@Sun.COM) Received: from bcn.East.Sun.COM ([129.148.75.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29752 for ; Fri, 25 Jan 2002 21:44:01 -0700 (MST) Received: from bcn (bcn [129.148.75.4]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with SMTP id XAA07143 for ; Fri, 25 Jan 2002 23:43:59 -0500 (EST) Message-Id: <200201260443.XAA07143@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] checksum calculation doubt To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: EfsrFxRc6fc4H78MguSybQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 23:43:59 -0500 (EST) Yeah, I think Mike owes you dinner, John. I may have typed the words in, but it was Tony that got excited about that sort of stuff, and it was his idea. It seemed harmless to put it in. Obviously it doesn't prevent malicious errors. I suspect that in all the years of running IS-IS it didn't catch any accidental errors, either, but who knows. Was the quoted text correct, by the way? "treating the source ID field as the first octet" Wouldn't it be the first 6 octets (oh yeah, the ID-length number of octets)? And without looking at the packet format, I assume that the first thing in the packet must be the source ID? Otherwise you'd get a different checksum if you just ignore that text and do the checksum from the beginning and initialize to 0. If the first thing is the source ID (it must be), then starting after the source ID, with the value that the checksum would be at that point, and starting at the beginning with checksums initialized to 0 would be the same answer, and as Mike pointed out, you'd never be able to detect from the outside of the box which strategy the router was doing. I could claim I was saving computation because the checksum could be precomputed for the first 6 bytes. :-) Radia >>John Harper said: >> Nah, I bet you dinner it was Tony. This is exactly the kind of thing he got >> excited >> about. At 18:06 25/01/2002 +0000, mike shand wrote: >But perhaps Radia has stronger opinions on this one, since I think it was >her idea. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 26 04:10:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04144 for ; Sat, 26 Jan 2002 04:10:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0Q8xlL74709; Sat, 26 Jan 2002 00:59:47 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0Q8ctL74615 for ; Sat, 26 Jan 2002 00:38:55 -0800 (PST) (envelope-from prz@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0Q8h1c55402 for ; Sat, 26 Jan 2002 00:43:01 -0800 (PST) X-JNPR-Received-From: outside Received: from mta5.snfc21.pbi.net ([206.13.28.241]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 26 Jan 2002 00:40:48 -0800 Received: from redback.com ([63.200.49.97]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQJ00KRCESVP7@mta5.snfc21.pbi.net> for isis-wg@juniper.net; Sat, 26 Jan 2002 00:41:19 -0800 (PST) From: Tony Przygienda To: isis-wg@juniper.net Message-id: <3C524D0A.49EAA9D4@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-OriginalArrivalTime: 26 Jan 2002 08:40:48.0733 (UTC) FILETIME=[276A80D0:01C1A645] Subject: [Isis-wg] last call on draft-ietf-isis-wg-tlv-codepoints-01 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 22:30:34 -0800 Content-Transfer-Encoding: 7BIT We are starting last call on draft-ietf-isis-wg-tlv-codepoints-01. The last call will end 2/9/02 thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Jan 26 08:56:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07001 for ; Sat, 26 Jan 2002 08:56:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0QDlRL78786; Sat, 26 Jan 2002 05:47:27 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from venus.postmark.net (venus.postmark.net [207.244.122.71]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g0QDYUL78721 for ; Sat, 26 Jan 2002 05:34:30 -0800 (PST) (envelope-from Chaitanya77@postmark.net) Received: (qmail 2980 invoked by uid 501); 26 Jan 2002 14:19:37 -0000 Message-ID: <20020126141937.2979.qmail@venus.postmark.net> Received: from 203.200.20.226 by www.postmark.net with HTTP; 26 Jan 2002 14:19:37 -0000 Mime-Version: 1.0 From: Chaitanya Huilgol To: isis-wg@spider.juniper.net Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] SPF optimization Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 26 Jan 2002 14:19:37 +0000 hi all I have a Question regarding addition of IP reachability entries in to the forwarding database, without recomputation of SPF. ref rfc1195 AnnexC: 3) If only End System LSP information has changed,it is not necessary to recompute the entire Dijkstra tree. If the proper data structures are used, End Systems (including IP reachability entries) may be attached and detached as leaves of the tree and their forwarding information base entries altered as appropriate. -- I believe IF the IP reachibality entries are taken from a static Table there is very little chance of such a change in info. now my question is (1)If an IS advertise a new IP reachability, How can you be sure that the shortest PATH to this network is through this IS. it is quite possible that a route already exists with a smaller/larger cost through another IS in the forwarding database. (2)Again if you want to remove an entry how can be sure that the path was calculated through the IS. for Eg: 10 10 R1------R2------R3 | |--IP/24 | 10 | |---------------R4 if R1 runs SPF.route to IP/24 through R4 later if R3 reports IP/24..How do u Know that the entry in forwarding database was through R4 which is the shortest and you should not replace. --In case R3 and R4 have advertised IP/24 and R1 calculates path through R4 and then R3 dose not advertise IP/24 --you should not be removing the entry for the forwarding DB ---finally do the implementations support this optimization. --------------------------------------------- Chaitanya Huilgol. Chaitanya77@postmark.net B.M.S college of Engineering. Bangalore,India. --------------------------------------------- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 28 04:04:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20829 for ; Mon, 28 Jan 2002 04:04:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0S8s9L90849; Mon, 28 Jan 2002 00:54:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f15.law3.hotmail.com [209.185.241.15]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0S8VfL90742 for ; Mon, 28 Jan 2002 00:31:41 -0800 (PST) (envelope-from sachidananda_k@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 28 Jan 2002 00:35:56 -0800 Received: from 203.196.145.150 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 28 Jan 2002 08:35:54 GMT X-Originating-IP: [203.196.145.150] From: "Sachidananda K" To: swaminathanr@netplane.com Cc: isis-wg@spider.juniper.net, tli@procket.com Subject: RE: [Isis-wg] CSNP from Designated IS Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jan 2002 08:35:56.0502 (UTC) FILETIME=[CE0F1760:01C1A7D6] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 08:35:54 +0000 Thank you for the clarification. I would like to know as to, whether is it permissible to keep the start LSP ID of the first CSNP as all 0's and the end LSP ID of the last CSNP packet as all 1's in a complete set of CSNP. Thanking you in advance for the clarification. Regards, Sachi. ----Original Message Follows---- From: "Ramalingam, Swaminathan" To: Sachidananda K CC: isis-wg@spider.juniper.net, "'Tony Li'" Subject: RE: [Isis-wg] CSNP from Designated IS Date: Fri, 25 Jan 2002 01:28:17 -0500 comments inlined > -----Original Message----- > From: Tony Li [mailto:tli@procket.com] > Sent: Friday, January 25, 2002 11:17 AM > To: Sachidananda K > Cc: isis-wg@spider.juniper.net > Subject: [Isis-wg] CSNP from Designated IS > > > > > | When an intermediate system just comes up on a broadcast > circuit it would > | typically not be having any LSPs in its database. > > > It should generate at least its own, even if it doesn't have > any adjacencies. > > > | Co-incidently, if this IS > | happens to be the designated IS for that broadcast > circuit, then what start > | LSP ID and the end LSP ID shall be put in the CSNP > constructed by this IS? > > > Then it should also generate a pseudo-node LSP. The CSNP > should contain > the full range of the database from LSP ID 0 (zero) to the > all-ones LSP ID. > > > | To be more generic, how can we ensure that this new IS's > database is > | synchronised with that of all the othre IS's in the LAN? > > > It should send out CSNPs. Anyone disagreeing should speak up. > > Adding to Tony's reply, DIS sends out CSNPs. When the receiver finds DIS is out of date, it will multicast the missing information (so that other IS receiving CSNP will not send again). If DIS has new information, the receiving IS multicast PSNP for missing information.Here only DIS should send the missing info, others should not. Hope this helps ~ Swami > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 28 04:28:34 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21212 for ; Mon, 28 Jan 2002 04:28:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0S9JsL90989; Mon, 28 Jan 2002 01:19:54 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0S8xUL90873 for ; Mon, 28 Jan 2002 00:59:30 -0800 (PST) (envelope-from tli@Procket.com) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0S93EeR007345; Mon, 28 Jan 2002 01:03:14 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0S93DWm021892; Mon, 28 Jan 2002 01:03:13 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.5073.780922.258651@alpha-tli.procket.com> To: "Sachidananda K" Cc: swaminathanr@netplane.com, isis-wg@spider.juniper.net, tli@Procket.com Subject: RE: [Isis-wg] CSNP from Designated IS In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 01:03:13 -0800 Content-Transfer-Encoding: 7bit | I would like to know as to, whether is it permissible to keep the start LSP | ID of the first CSNP as all 0's and the end LSP ID of the last CSNP packet | as all 1's in a complete set of CSNP. Not only is that permissible, but it is also required if you want true database synchronization. If a complete set of CSNPs does not completely cover the LSP ID space, then the receiver could have an LSP in any space that is not included and thereby it might not be synchronized with the DIS. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 28 08:42:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25031 for ; Mon, 28 Jan 2002 08:42:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SDaDL92669; Mon, 28 Jan 2002 05:36:13 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SA0sL91207 for ; Mon, 28 Jan 2002 02:00:55 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (rtp-vpn2-43.cisco.com [10.82.240.43]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA20598; Mon, 28 Jan 2002 10:05:08 GMT Message-Id: <4.3.2.7.2.20020128095414.01a12008@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Radia Perlman - Boston Center for Networking From: mike shand Subject: Re: [Isis-wg] checksum calculation doubt Cc: isis-wg@spider.juniper.net In-Reply-To: <200201260443.XAA07143@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 09:58:02 +0000 At 23:43 25/01/2002 -0500, Radia Perlman - Boston Center for Networking wrote: >Yeah, I think Mike owes you dinner, John. I may have typed the words in, but >it was Tony that got excited about that sort of stuff, and it was his >idea. It seemed harmless to put it in. Obviously it >doesn't prevent malicious errors. I suspect that in all the years of >running IS-IS it didn't catch any accidental errors, either, but who knows. My apologies Radia. I should have guessed that this had Tony's hallmark:-) For those reading this list who may otherwise be confused, we are not of course referring to either of our illustrious WG chairs, but to Tony Lauck who ran the network architecture group in DEC when Radia, John and I worked there sometime last century. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 28 09:06:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26185 for ; Mon, 28 Jan 2002 09:06:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SDxxL92817; Mon, 28 Jan 2002 05:59:59 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PEvCL69745 for ; Fri, 25 Jan 2002 06:57:12 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 3084 invoked from network); 25 Jan 2002 15:01:12 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 25 Jan 2002 15:01:12 -0000 From: "Ken Larmer" To: "Suresh Boddapati" , "Naiming Shen" Cc: "Ken Larmer" , , Subject: RE: [Isis-wg] Making the update reliable Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020125063357.9028A4BA219@prattle.redback.com> Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 10:06:21 -0500 Content-Transfer-Encoding: 7bit Naiming Wrote: > In the case no 3way hello is running, the first CSNP is lost, and > the link becomes unidirectional, no matter how many CSNPs being > sent later on, the two sides still can not syncronize, or it does get > syncronized but one side will keep sending out LSPs due to no Ack > back from the peer. >In the case of the link being bidirectional, the initial CSNP got lost. >All LSPs will be sent over the link, and the other side has to send back >the PSNPs to Ack. Say A->B csnp is lost, B has to send all its LSPs to A. >A has to response with PSNPs. Even A keeps sending csnps to B, A still >need to send those PSNPs. And they basically contain the same info: don't >send them anymore! Hi Naming, can you please explain the two scenarios above in more detail? Are they the same as the scenarios referenced in the "Three-Way Handshake for IS-IS Point-to-Point Adjacencies" draft as referenced below: Three failure modes are known. First, if the link goes down and then comes back up, or one of the systems restarts, and the CSNP packet is lost, and the network has a cut set of one through the link, the link state databases on either side of the link will not synchronize for a full LSP refresh period (up to eighteen hours). A second, more serious failure, is that if the link fails in only one direction, the failure will only be detected by one of the systems. Normally, this is not a serious issue; only one of the two systems will announce the adjacency in its link state packets, and the SPF algorithm will thus ignore the link. However, if there are two parallel links between systems and one of them fails in one direction, SPF will still calculate paths between the two systems, and the system that does not notice the failure will attempt to pass traffic down the failed link (in the direction that does not work). The third issue is that on some physical layers, the interconnectivity between endpoints can change without causing a link-layer-down condition. In this case, a system may receive packets that are actually destined for a different system (or a different link on the same system). The receiving system may end up thinking that it has an adjacency with the remote system when in fact the remote system is adjacent with a third system. Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 28 09:44:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27623 for ; Mon, 28 Jan 2002 09:44:34 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SEc8L93040; Mon, 28 Jan 2002 06:38:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SEMOL92955 for ; Mon, 28 Jan 2002 06:22:24 -0800 (PST) (envelope-from rameshrr@future.futsoft.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SEQhc91314 for ; Mon, 28 Jan 2002 06:26:43 -0800 (PST) X-JNPR-Received-From: outside Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 06:24:35 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 28 Jan 2002 20:10:43 +0530 Received: from rameshrr (rameshrr.future.futsoft.com [192.168.5.19]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g0SEOHu29334; Mon, 28 Jan 2002 19:54:17 +0530 Reply-To: From: "Rayapureddi Ramesh" To: "ISIS (E-mail)" , "ISISWG (E-mail)" Message-Id: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C1A837.4F5913B0" X-OriginalArrivalTime: 28 Jan 2002 14:24:36.0030 (UTC) FILETIME=[8311BDE0:01C1A807] Subject: [Isis-wg] Reg: route preference Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 20:06:43 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C1A837.4F5913B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, In ISIS we can add manual adjacencies also, they are nothing but static routes. We can add prefix addresses (reachable address) also these also static routes only. When we want to send some data to some destination "DST" if there three routes with different next hops with "same cost" 1. route learned by ISIS with next hop NH1 2. Static route (manual adjacency) with next hop NH2 3. Reachable address with next hop NH3 Which route I should take as a best route? If any one knows pl tell me. Regards, Ramesh ------=_NextPart_000_000C_01C1A837.4F5913B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
In = ISIS we  can=20 add manual adjacencies also, they are nothing but static=20 routes.
We can = add prefix=20 addresses (reachable address) also these also static routes=20 only.
 
When = we want to send=20 some data to some destination "DST"
 
if = there three=20 routes with different next hops with "same cost"
 
1. = route learned by=20 ISIS with next hop NH1  
2. = Static route=20 (manual adjacency)   with next hop NH2
3. = Reachable address=20 with next hop NH3
 
Which=20 route  I should take as a best route?
 
If any = one knows pl=20 tell me.
 
 
Regards,
Ramesh
------=_NextPart_000_000C_01C1A837.4F5913B0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 28 10:30:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29218 for ; Mon, 28 Jan 2002 10:30:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SFNtL93297; Mon, 28 Jan 2002 07:23:55 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SF8FL93218 for ; Mon, 28 Jan 2002 07:08:15 -0800 (PST) (envelope-from Larmer@commsense.net) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SFCZc92363 for ; Mon, 28 Jan 2002 07:12:35 -0800 (PST) X-JNPR-Received-From: outside Received: from mail5.speakeasy.net ([216.254.0.205]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 07:02:35 -0800 Received: (qmail 18390 invoked from network); 28 Jan 2002 15:03:07 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 28 Jan 2002 15:03:07 -0000 From: "Ken Larmer" To: , "ISIS \(E-mail\)" , "ISISWG \(E-mail\)" Subject: RE: [Isis-wg] Reg: route preference Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C1A7E3.B69D2010" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com> Importance: Normal X-OriginalArrivalTime: 28 Jan 2002 15:02:35.0093 (UTC) FILETIME=[D17F2850:01C1A80C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 10:08:20 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C1A7E3.B69D2010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Ramesh, > We can add prefix addresses (reachable address) also these also static routes only. >When we want to send some data to some destination "DST" >if there three routes with different next hops with "same cost" >1. route learned by ISIS with next hop NH1 >2. Static route (manual adjacency) with next hop NH 2 >3. Reachable address with next hop NH3 >Which route I should take as a best route? This depends upon whether or not you have path splitting enabled? If you do, then you follow the guidelines specified in ISO-10589v2-2001-07-04 section "7.2.7 Removal of excess paths" Cheers, Ken Larmer CommSense Networks ------=_NextPart_000_0044_01C1A7E3.B69D2010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Ramesh,
 
> We can add prefix addresses = (reachable=20 address) also these also static routes only. 
 
 >When we want to send some data to some = destination=20 "DST" 
 
 >if there three routes with different next = hops with=20 "same cost" 
 
 >1. route learned by ISIS with next hop = NH1  
 
 >2. Static route (manual = adjacency)   with=20 next hop NH 2
 
 >3. Reachable address with next hop NH3 
 
 >Which route  I should take as a = best=20 route? 
 
This depends upon whether = or=20 not you have path splitting enabled? If you do, then you follow the = guidelines specified in ISO-10589v2-2001-07-04 section "7.2.7=20 Removal of excess paths"
 
Cheers,
Ken=20 Larmer
CommSense=20 Networks 
------=_NextPart_000_0044_01C1A7E3.B69D2010-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 28 10:37:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29613 for ; Mon, 28 Jan 2002 10:37:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SFV2L93376; Mon, 28 Jan 2002 07:31:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SFQgL93320 for ; Mon, 28 Jan 2002 07:26:42 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SFV2c93098 for ; Mon, 28 Jan 2002 07:31:02 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 07:28:46 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0SFTW419411; Mon, 28 Jan 2002 10:29:32 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAO00726; Mon, 28 Jan 2002 10:29:16 -0500 (EST) Message-Id: <4.3.2.7.2.20020128102326.01e81490@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Jeff Learman Subject: Re: [Isis-wg] Reg: route preference Cc: "ISIS (E-mail)" , "ISISWG (E-mail)" In-Reply-To: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1298386==_.ALT" X-OriginalArrivalTime: 28 Jan 2002 15:28:46.0937 (UTC) FILETIME=[7A638490:01C1A810] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 10:29:14 -0500 --=====================_1298386==_.ALT Content-Type: text/plain; charset="us-ascii" See 10589:1992 section 7.2.7., Removal of excess paths. Jeff At 09:36 AM 1/28/2002, Rayapureddi Ramesh wrote: >Hi, > >In ISIS we can add manual adjacencies also, they are nothing but static routes. >We can add prefix addresses (reachable address) also these also static routes only. > >When we want to send some data to some destination "DST" > >if there three routes with different next hops with "same cost" > >1. route learned by ISIS with next hop NH1 >2. Static route (manual adjacency) with next hop NH2 >3. Reachable address with next hop NH3 > >Which route I should take as a best route? > >If any one knows pl tell me. > > >Regards, >Ramesh --=====================_1298386==_.ALT Content-Type: text/html; charset="us-ascii"
See 10589:1992 section 7.2.7., Removal of excess paths.

Jeff

At 09:36 AM 1/28/2002, Rayapureddi Ramesh wrote:
Hi,
 
In ISIS we  can add manual adjacencies also, they are nothing but static routes.
We can add prefix addresses (reachable address) also these also static routes only.
 
When we want to send some data to some destination "DST"
 
if there three routes with different next hops with "same cost"
 
1. route learned by ISIS with next hop NH1 
2. Static route (manual adjacency)   with next hop NH2
3. Reachable address with next hop NH3
 
Which route  I should take as a best route?
 
If any one knows pl tell me.
 
 
Regards,
Ramesh
--=====================_1298386==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 28 11:37:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01870 for ; Mon, 28 Jan 2002 11:37:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SGV2L93691; Mon, 28 Jan 2002 08:31:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SGQ0L93659 for ; Mon, 28 Jan 2002 08:26:00 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SGUKc94705 for ; Mon, 28 Jan 2002 08:30:20 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 08:24:45 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0SGPRB25064; Mon, 28 Jan 2002 11:25:27 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAO02596; Mon, 28 Jan 2002 11:25:11 -0500 (EST) Message-Id: <4.3.2.7.2.20020128112138.01e82ab8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: Jeff Learman Subject: RE: [Isis-wg] Reg: route preference Cc: In-Reply-To: References: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4653371==_.ALT" X-OriginalArrivalTime: 28 Jan 2002 16:24:45.0187 (UTC) FILETIME=[4C0FCD30:01C1A818] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 11:25:09 -0500 --=====================_4653371==_.ALT Content-Type: text/plain; charset="us-ascii" Ken, you need to follow those rules whenever the number of next hops exceeds maximumPathSplits, so you need the logic regardless of what an implementation supports. One that doesn't support load balancing would simply have maximumPathSplits set to 1. Jeff At 10:08 AM 1/28/2002, you wrote: >Hi Ramesh, > >> We can add prefix addresses (reachable address) also these also static routes only. > > >When we want to send some data to some destination "DST" > > >if there three routes with different next hops with "same cost" > > >1. route learned by ISIS with next hop NH1 > > >2. Static route (manual adjacency) with next hop NH 2 > > >3. Reachable address with next hop NH3 > > >Which route I should take as a best route? > >This depends upon whether or not you have path splitting enabled? If you do, then you follow the guidelines specified in ISO-10589v2-2001-07-04 section "7.2.7 Removal of excess paths" > >Cheers, >Ken Larmer >CommSense Networks --=====================_4653371==_.ALT Content-Type: text/html; charset="us-ascii"
Ken, you need to follow those rules whenever the number of next hops
exceeds maximumPathSplits, so you need the logic regardless of what
an implementation supports.  One that doesn't support load balancing
would simply have maximumPathSplits set to 1.

Jeff

At 10:08 AM 1/28/2002, you wrote:
Hi Ramesh,
 
> We can add prefix addresses (reachable address) also these also static routes only.
 
 >When we want to send some data to some destination "DST"
 
 >if there three routes with different next hops with "same cost"
 
 >1. route learned by ISIS with next hop NH1 
 
 >2. Static route (manual adjacency)   with next hop NH 2
 
 >3. Reachable address with next hop NH3
 
 >Which route  I should take as a best route?
 
This depends upon whether or not you have path splitting enabled? If you do, then you follow the guidelines specified in ISO-10589v2-2001-07-04 section "7.2.7 Removal of excess paths"
 
Cheers,
Ken Larmer
CommSense Networks<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
--=====================_4653371==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 28 13:06:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04446 for ; Mon, 28 Jan 2002 13:06:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SHxYL94136; Mon, 28 Jan 2002 09:59:34 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SGvXL93835 for ; Mon, 28 Jan 2002 08:57:33 -0800 (PST) (envelope-from Larmer@commsense.net) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g0SH1ru59550 for ; Mon, 28 Jan 2002 09:01:53 -0800 (PST) X-JNPR-Received-From: outside Received: from mail6.speakeasy.net ([216.254.0.206]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 08:53:02 -0800 Received: (qmail 6978 invoked from network); 28 Jan 2002 16:53:34 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 28 Jan 2002 16:53:34 -0000 From: "Ken Larmer" To: "Jeff Learman" Cc: Subject: RE: [Isis-wg] Reg: route preference Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C1A7F3.24B02660" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4.3.2.7.2.20020128112138.01e82ab8@dingdong.cisco.com> Importance: Normal X-OriginalArrivalTime: 28 Jan 2002 16:53:02.0687 (UTC) FILETIME=[3FD9BEF0:01C1A81C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 11:58:47 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C1A7F3.24B02660 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yes Jeff, you are quite right! This is not phase IV is it. Cheers, Ken Larmer CommSense Networks -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman Sent: Monday, January 28, 2002 11:25 AM To: Ken Larmer Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] Reg: route preference Ken, you need to follow those rules whenever the number of next hops exceeds maximumPathSplits, so you need the logic regardless of what an implementation supports. One that doesn't support load balancing would simply have maximumPathSplits set to 1. Jeff At 10:08 AM 1/28/2002, you wrote: Hi Ramesh, > We can add prefix addresses (reachable address) also these also static routes only. >When we want to send some data to some destination "DST" >if there three routes with different next hops with "same cost" >1. route learned by ISIS with next hop NH1 >2. Static route (manual adjacency) with next hop NH 2 >3. Reachable address with next hop NH3 >Which route I should take as a best route? This depends upon whether or not you have path splitting enabled? If you do, then you follow the guidelines specified in ISO-10589v2-2001-07-04 section "7.2.7 Removal of excess paths" Cheers, Ken Larmer CommSense Networks ------=_NextPart_000_0050_01C1A7F3.24B02660 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Yes = Jeff, you are=20 quite right! This is not phase IV is it.
 
Cheers,
Ken=20 Larmer
CommSense=20 Networks
-----Original Message-----
From:=20 isis-wg-admin@external.juniper.net=20 [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff=20 Learman
Sent: Monday, January 28, 2002 11:25 = AM
To: Ken=20 Larmer
Cc: isis-wg@juniper.net
Subject: RE: = [Isis-wg] Reg:=20 route preference


Ken, you need to follow those = rules=20 whenever the number of next hops
exceeds maximumPathSplits, so you = need the=20 logic regardless of what
an implementation supports.  One that = doesn't=20 support load balancing
would simply have maximumPathSplits set to=20 1.

Jeff

At 10:08 AM 1/28/2002, you wrote:
Hi=20 Ramesh,
 
> We can add prefix addresses (reachable address) also = these also=20 static routes only.
 
 >When we want to send some data to some = destination "DST"=20
 
 >if there = three routes=20 with different next hops with "same cost"
 
 >1. route learned by ISIS with next = hop NH1 =20
 
 >2. Static = route=20 (manual adjacency)   with next hop NH = 2
 
 >3. Reachable address with next hop = NH3=20
 
 >Which = route =20 I should take as a best route?
 
This depends = upon=20 whether or not you have path splitting enabled? If you do, then you = follow=20 the guidelines specified in ISO-10589v2-2001-07-04 section "7.2.7 = Removal of=20 excess paths"
 
Cheers,
Ken Larmer
CommSense=20 Networks<?xml:namespace prefix =3D o ns =3D=20 "urn:schemas-microsoft-com:office:office" />=20
------=_NextPart_000_0050_01C1A7F3.24B02660-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 29 02:54:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27648 for ; Tue, 29 Jan 2002 02:54:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0T7lRL97928; Mon, 28 Jan 2002 23:47:27 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0T7RNL97819 for ; Mon, 28 Jan 2002 23:27:23 -0800 (PST) (envelope-from rameshrr@future.futsoft.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g0T7Vlu68059 for ; Mon, 28 Jan 2002 23:31:47 -0800 (PST) X-JNPR-Received-From: outside Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 23:31:12 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 29 Jan 2002 13:17:24 +0530 Received: from rameshrr (rameshrr.future.futsoft.com [192.168.5.19]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g0T7Utk05101; Tue, 29 Jan 2002 13:00:56 +0530 Reply-To: From: "Rayapureddi Ramesh" To: "ISISWG (E-mail)" , "ISIS (E-mail)" Subject: Re: [Isis-wg] Reg: route preference Message-Id: <002101c1a898$a5990990$1305a8c0@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C1A8C6.BF52CC30" X-OriginalArrivalTime: 29 Jan 2002 07:31:12.0734 (UTC) FILETIME=[ED90DFE0:01C1A896] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 13:13:29 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C1A8C6.BF52CC30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I think I asked question in a wrong way. Actaully my doubt is if we are maintaining three different databases for 1. routes learned from ISIS ---route information data base RDB1 2. manual adjacencies ( is-neighbors OR es-neighbors) -- route information data base RDB2 3. reachable address (Prefix routes) -- route information data base RDB3 Is it maintaining three different data base correct? if yes if we want a route to some destination "DST" then which database should I search first RDB1 or RDB2 or RDB3 ? which is next RDB1 or RDB2 or RDB3 ? And which is last RDB1 or RDB2 or RDB3? regards, Ramesh -----Original Message----- From: Jeff Learman [mailto:jlearman@cisco.com] Sent: Monday, January 28, 2002 9:12 PM To: rameshrr@future.futsoft.com Subject: Fwd: Re: [Isis-wg] Reg: route preference By the way, don't be confused by the inclusion of "metric sum" in this list. It confused me at first, because we normally think of all of the paths having equal cost before reaching this point. However, this item only relates to routers that, rather than computing the set of equal minimum cost paths (7.2.6.2-b), compute downstream paths (7.2.6.2-c). I haven't ever heard of anyone using that method. Regards, Jeff Date: Mon, 28 Jan 2002 10:29:14 -0500 To: From: Jeff Learman Subject: Re: [Isis-wg] Reg: route preference Cc: "ISIS (E-mail)" , "ISISWG (E-mail)" See 10589:1992 section 7.2.7., Removal of excess paths. Jeff At 09:36 AM 1/28/2002, Rayapureddi Ramesh wrote: Hi, In ISIS we can add manual adjacencies also, they are nothing but static routes. We can add prefix addresses (reachable address) also these also static routes only. When we want to send some data to some destination "DST" if there three routes with different next hops with "same cost" 1. route learned by ISIS with next hop NH1 2. Static route (manual adjacency) with next hop NH2 3. Reachable address with next hop NH3 Which route I should take as a best route? If any one knows pl tell me. Regards, Ramesh ------=_NextPart_000_0022_01C1A8C6.BF52CC30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
I=20 think I asked question in a wrong way.
Actaully my doubt is
 
if we=20 are maintaining three different databases for
 
1.=20 routes learned from ISIS ---route information data base=20 RDB1
2.=20 manual adjacencies ( is-neighbors OR es-neighbors) -- route information = data=20 base RDB2
3.=20 reachable address (Prefix routes) -- route information data base=20 RDB3
 
Is it=20 maintaining three different data base correct?
 
if yes=20 if we want a route to some destination=20 "DST"  then
 
which=20 database should I search first RDB1 or RDB2 or RDB3 ?
which is next   RDB1 or RDB2 or RDB3 ?  And which is last RDB1 or RDB2 or=20 RDB3?  
 
regards,
Ramesh
 
-----Original Message-----
From: Jeff Learman=20 [mailto:jlearman@cisco.com]
Sent: Monday, January 28, 2002 = 9:12=20 PM
To: rameshrr@future.futsoft.com
Subject: Fwd: = Re:=20 [Isis-wg] Reg: route preference


By the way, = don't be=20 confused by the inclusion of "metric sum"
in this list.  It = confused=20 me at first, because we normally think of
all of the paths having = equal=20 cost before reaching this point.  However,
this item only = relates to=20 routers that, rather than computing the set
of equal minimum cost = paths=20 (7.2.6.2-b), compute downstream paths
(7.2.6.2-c).  I haven't = ever=20 heard of anyone using that method.

Regards,
Jeff

Date: Mon, 28 Jan 2002 10:29:14 = -0500
To:=20 <rameshrr@future.futsoft.com>
From: Jeff Learman=20 <jlearman@cisco.com>
Subject: Re: [Isis-wg] Reg: route=20 preference
Cc: "ISIS (E-mail)" = <isis-wg-admin@spider.juniper.net>,=20 "ISISWG (E-mail)" <isis-wg@juniper.net>


See = 10589:1992=20 section 7.2.7., Removal of excess paths.

Jeff

At 09:36 = AM=20 1/28/2002, Rayapureddi Ramesh wrote:
Hi,
 
In = ISIS we =20 can add manual adjacencies also, they are nothing but static=20 routes.
We can add prefix = addresses=20 (reachable address) also these also static routes=20 only.
 
When we want = to send=20 some data to some destination "DST"
 
if there three routes with different next hops with "same = cost"
 
1. route = learned by ISIS=20 with next hop NH1 
2. = Static route=20 (manual adjacency)   with next hop NH2
3. Reachable address with next hop=20 NH3
 
Which = route  I=20 should take as a best route?
 
If any one knows pl tell = me.
 
 
Regards,
Ramesh
------=_NextPart_000_0022_01C1A8C6.BF52CC30-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 29 03:21:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27948 for ; Tue, 29 Jan 2002 03:21:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0T8DtL98093; Tue, 29 Jan 2002 00:13:55 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0T7SWL97837 for ; Mon, 28 Jan 2002 23:28:32 -0800 (PST) (envelope-from rameshrr@future.futsoft.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g0T7Wvu68067 for ; Mon, 28 Jan 2002 23:32:57 -0800 (PST) X-JNPR-Received-From: outside Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 23:32:22 -0800 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 29 Jan 2002 13:18:26 +0530 Received: from rameshrr (rameshrr.future.futsoft.com [192.168.5.19]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g0T7Vxk05165; Tue, 29 Jan 2002 13:01:59 +0530 Reply-To: From: "Rayapureddi Ramesh" To: "ISIS (E-mail)" , "ISISWG (E-mail)" Message-Id: <002601c1a898$cb941720$1305a8c0@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C1A8C6.E54C5320" X-OriginalArrivalTime: 29 Jan 2002 07:32:22.0531 (UTC) FILETIME=[172B0D30:01C1A897] Subject: [Isis-wg] FW: reg IS & ES neighbors Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 13:14:33 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C1A8C6.E54C5320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, In Cisco there are two commands and at the interface level. If we enable both ISIS and CLNS routing on Cisco router. In both the commands whatever (area Id will be equal to areaID given in command) neighbor SNPA address we are giving ISIS is advertising as ES neighbors in neighbor options of LSP. Then what is the difference between these commands? example : config> clns routing config-router>net 47.0004.004d.1300.0102.0304.00 config-router>interface eth 1/0 config-if>clns es-neighbor 47.0004.004d.3100.0102.0304.00 1111.2222.3333 config-if>clns is-neighbor 47.0004.004d.4100.0102.0304.00 1111.2222.3333 ISIS is advertising in L1 LSP as ES neighbors (3100.0102.0304 & 4100.0102.0304) in neighbor options. Can anybody explain me. Regards, Ramesh ------=_NextPart_000_0027_01C1A8C6.E54C5320 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
In=20 Cisco there are two commands
 
<clns is-neighbor = SNPA=20 NSAP> and <clns es-neighbor SNPA = NSAP>=20 at the interface level.
 
 
If we=20 enable both ISIS and CLNS routing on Cisco router.
 
In both the commands whatever (area Id = will be=20 equal to areaID given in <net> command) 
neighbor SNPA address we are giving ISIS is=20 advertising as ES neighbors in neighbor=20
options of LSP. Then what is the difference = between=20 these commands?
 
example=20 :          =20
config> clns routing
config-router>net=20 47.0004.004d.1300.0102.0304.00
config-router>interface eth = 1/0
config-if>clns es-neighbor=20 47.0004.004d.3100.0102.0304.00 1111.2222.3333
config-if>clns is-neighbor =20 47.0004.004d.4100.0102.0304.00 1111.2222.3333
 
ISIS=20 is advertising in L1 LSP as ES neighbors (3100.0102.0304 &=20 4100.0102.0304) in neighbor options.
 
 
Can anybody explain = me.
 
 
Regards,
Ramesh
------=_NextPart_000_0027_01C1A8C6.E54C5320-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 29 08:06:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02019 for ; Tue, 29 Jan 2002 08:06:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TCwCL99975; Tue, 29 Jan 2002 04:58:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TCbmL99874 for ; Tue, 29 Jan 2002 04:37:48 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g0TCgEu70360 for ; Tue, 29 Jan 2002 04:42:14 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 04:41:39 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01151; Tue, 29 Jan 2002 07:42:10 -0500 (EST) Message-Id: <200201291242.HAA01151@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 29 Jan 2002 12:41:39.0421 (UTC) FILETIME=[4BEFC0D0:01C1A8C2] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-07.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 07:42:10 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie, D. Saha, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-07.txt Pages : 9 Date : 28-Jan-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). The description of the extensions is specified in [GMPLS- ROUTING]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020128150952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020128150952.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 29 11:38:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08645 for ; Tue, 29 Jan 2002 11:38:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TGVYL01101; Tue, 29 Jan 2002 08:31:34 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TCbsL99879 for ; Tue, 29 Jan 2002 04:37:54 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g0TCgJE19507 for ; Tue, 29 Jan 2002 04:42:19 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 04:41:44 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01169; Tue, 29 Jan 2002 07:42:16 -0500 (EST) Message-Id: <200201291242.HAA01169@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 29 Jan 2002 12:41:44.0890 (UTC) FILETIME=[4F3241A0:01C1A8C2] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-02.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 07:42:15 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : M-ISIS: Multi Topology Routing in IS-IS Author(s) : T. Przygienda et al. Filename : draft-ietf-isis-wg-multi-topology-02.txt Pages : 7 Date : 28-Jan-02 This draft describes an optional implementation technique within IS-IS [ISO90 , Cal90a , Cal90b] used today by many ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs), or Multiple views of Topology. This MT extension can be used for variety of purposes such as an in-band management network on top' of the original IGP topology, transport multiple overlapping IP address spaces in the same protocol, force a subset of an address space to follow a different topology, or finally, even maintain a restricted number of protocol based VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-multi-topology-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020128151007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020128151007.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 29 12:19:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09971 for ; Tue, 29 Jan 2002 12:19:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0THC2L01366; Tue, 29 Jan 2002 09:12:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TGupL01262 for ; Tue, 29 Jan 2002 08:56:51 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0TH1Ic18353 for ; Tue, 29 Jan 2002 09:01:18 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 08:59:38 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0TH0Pv20393; Tue, 29 Jan 2002 12:00:25 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAQ14413; Tue, 29 Jan 2002 12:00:09 -0500 (EST) Message-Id: <4.3.2.7.2.20020129110619.01ec71c0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Jeff Learman Subject: Re: [Isis-wg] FW: reg IS & ES neighbors Cc: "ISIS (E-mail)" , "ISISWG (E-mail)" In-Reply-To: <002601c1a898$cb941720$1305a8c0@future.futsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_93148740==_.ALT" X-OriginalArrivalTime: 29 Jan 2002 16:59:38.0609 (UTC) FILETIME=[56406610:01C1A8E6] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 11:11:26 -0500 --=====================_93148740==_.ALT Content-Type: text/plain; charset="us-ascii" Ramesh, Implementation-specific questions are not permitted on this exploder. Please direct any Cisco implementation questions to your Cisco support representative. I do not work on IS-IS at Cisco and have no insider knowledge of the Cisco implementation. Fortunately, this question is answerable knowing only the standards. (Note that you could have asked this question in a vendor-unspecific fashion, by stating that you had configured an IS manual adjacency and an ES manual adjacency but saw both appear in the LSPs as end-system neighbors and wondered whether this is correct.) IS-IS can't advertise a neighbor as an IS neighbor unless it has established an adjacency in the 'UP' state according to 10598. You can't manually put an adjacency in the 'UP' state. IS-IS is treating this system like an intermediate system that is not running IS-IS, which is equivalent to how it would treat an end system. Best Regards, Jeff At 02:44 AM 1/29/2002, Rayapureddi Ramesh wrote: > >Hi, > >In Cisco there are two commands > > and at the interface level. > > >If we enable both ISIS and CLNS routing on Cisco router. > >In both the commands whatever (area Id will be equal to areaID given in command) >neighbor SNPA address we are giving ISIS is advertising as ES neighbors in neighbor >options of LSP. Then what is the difference between these commands? > >example : >config> clns routing >config-router>net 47.0004.004d.1300.0102.0304.00 >config-router>interface eth 1/0 >config-if>clns es-neighbor 47.0004.004d.3100.0102.0304.00 1111.2222.3333 >config-if>clns is-neighbor 47.0004.004d.4100.0102.0304.00 1111.2222.3333 > >ISIS is advertising in L1 LSP as ES neighbors (3100.0102.0304 & 4100.0102.0304) in neighbor options. > > >Can anybody explain me. > > >Regards, >Ramesh --=====================_93148740==_.ALT Content-Type: text/html; charset="us-ascii"
Ramesh,

Implementation-specific questions are not permitted on this exploder.
Please direct any Cisco implementation questions to your Cisco support
representative.

I do not work on IS-IS at Cisco and have no insider knowledge of
the Cisco implementation.  Fortunately, this question is answerable
knowing only the standards.  (Note that you could have asked this
question in a vendor-unspecific fashion, by stating that you had
configured an IS manual adjacency and an ES manual adjacency but
saw both appear in the LSPs as end-system neighbors and wondered
whether this is correct.)

IS-IS can't advertise a neighbor as an IS neighbor unless it has
established an adjacency in the 'UP' state according to 10598.
You can't manually put an adjacency in the 'UP' state.  IS-IS is
treating this system like an intermediate system that is not running
IS-IS, which is equivalent to how it would treat an end system.

Best Regards,
Jeff

At 02:44 AM 1/29/2002, Rayapureddi Ramesh wrote:
 
Hi,
 
In Cisco there are two commands
 
<clns is-neighbor SNPA NSAP> and <clns es-neighbor SNPA NSAP> at the interface level.
 
 
If we enable both ISIS and CLNS routing on Cisco router.
 
In both the commands whatever (area Id will be equal to areaID given in <net> command) 
neighbor SNPA address we are giving ISIS is advertising as ES neighbors in neighbor
options of LSP. Then what is the difference between these commands?
 
example :          
config> clns routing
config-router>net 47.0004.004d.1300.0102.0304.00
config-router>interface eth 1/0
config-if>clns es-neighbor 47.0004.004d.3100.0102.0304.00 1111.2222.3333
config-if>clns is-neighbor  47.0004.004d.4100.0102.0304.00 1111.2222.3333
 
ISIS is advertising in L1 LSP as ES neighbors (3100.0102.0304 & 4100.0102.0304) in neighbor options.
 
 
Can anybody explain me.
 
 
Regards,
Ramesh
--=====================_93148740==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 29 18:51:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24761 for ; Tue, 29 Jan 2002 18:51:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TNj2L03099; Tue, 29 Jan 2002 15:45:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TNS7L03013 for ; Tue, 29 Jan 2002 15:28:07 -0800 (PST) (envelope-from naiming@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0TNWZc26075 for ; Tue, 29 Jan 2002 15:32:35 -0800 (PST) X-JNPR-Received-From: outside Received: from prattle.redback.com ([155.53.12.9]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 15:27:04 -0800 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 67BAE1DCC76; Tue, 29 Jan 2002 15:27:39 -0800 (PST) To: isis-wg@juniper.net Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-02.txt In-reply-to: Mail from Internet-Drafts@ietf.org dated Tue, 29 Jan 2002 07:42:15 EST <200201291242.HAA01169@ietf.org> From: Naiming Shen Message-Id: <20020129232739.67BAE1DCC76@prattle.redback.com> X-OriginalArrivalTime: 29 Jan 2002 23:27:05.0093 (UTC) FILETIME=[763C5B50:01C1A91C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 15:27:39 -0800 this paragraph is added to the 02.txt of M-ISIS draft, section 2.2. pls comment. Two Routers on a LAN SHOULD always establish adjacency regardless whether they have common MT set or not. This is to ensure all the routers on the LAN can correctly elect the same DIS. The IS may not contain the MT IS TLV in its LSP if none of the adjacencies on the LAN contains this MT. thanks. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 00:28:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02325 for ; Wed, 30 Jan 2002 00:28:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0U5LjL04601; Tue, 29 Jan 2002 21:21:45 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0T99CL98405 for ; Tue, 29 Jan 2002 01:09:12 -0800 (PST) (envelope-from tli@procket.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0T9Dac12428 for ; Tue, 29 Jan 2002 01:13:36 -0800 (PST) X-JNPR-Received-From: outside Received: from sundmz1.procket.com ([65.174.124.36]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 01:12:38 -0800 Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz1.procket.com (Postfix) with ESMTP id CDA8823C22; Tue, 29 Jan 2002 01:04:59 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0T9DCr6017952; Tue, 29 Jan 2002 01:13:12 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0T9DBYm023888; Tue, 29 Jan 2002 01:13:11 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.26535.813528.563467@alpha-tli.procket.com> To: Cc: "ISIS (E-mail)" , "ISISWG (E-mail)" Subject: [Isis-wg] FW: reg IS & ES neighbors In-Reply-To: <002601c1a898$cb941720$1305a8c0@future.futsoft.com> References: <002601c1a898$cb941720$1305a8c0@future.futsoft.com> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 29 Jan 2002 09:12:38.0765 (UTC) FILETIME=[191F81D0:01C1A8A5] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 01:13:11 -0800 Content-Transfer-Encoding: 7bit | Can anybody explain me. Please consult with your vendor. This is not a technical support mailing list. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 00:34:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02395 for ; Wed, 30 Jan 2002 00:34:42 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0U5SOL04649; Tue, 29 Jan 2002 21:28:24 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PF34L69778 for ; Fri, 25 Jan 2002 07:03:04 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0PF7G821012; Fri, 25 Jan 2002 10:07:17 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn1-308.cisco.com [10.82.225.52]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAN63390; Fri, 25 Jan 2002 10:07:02 -0500 (EST) Message-Id: <4.3.2.7.2.20020125092121.01e51f28@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Dave Katz From: Jeff Learman Subject: Re: [Isis-wg] Making the update reliable Cc: sboddapa@hotmail.com, isis-wg@spider.juniper.net In-Reply-To: <200201250800.g0P80nZ37529@cirrus.juniper.net> References: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 10:05:49 -0500 At 03:00 AM 1/25/2002, Dave Katz wrote: > So I don't see any benefit to sending periodic CSNPs. It was worth > considering, though. > >We send 'em anyhow. I think I made the cisco code do the same thing, >but it's been a lot of years. Or maybe you can just configure it >on the cisco box, I don't remember offhand. > >Cheap insurance when working with the ill-named mesh groups. I bet you did this before 3-way handshake was proposed. Without it, systems would recover from a one-sided restart much more quickly than waiting for all LSPs to be regenerated. Even with 3-way, I can't imagine them doing any harm. Any system that runs IS-IS on an unreliable PTP link and does not support 3-way handshake would be strongly advised to send periodic CSNPs. Regards, Jeff >--Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 00:36:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02423 for ; Wed, 30 Jan 2002 00:36:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0U5UHL04674; Tue, 29 Jan 2002 21:30:17 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0PGHeL70100 for ; Fri, 25 Jan 2002 08:17:40 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0PGLe683173; Fri, 25 Jan 2002 08:21:40 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g0PGLen38607; Fri, 25 Jan 2002 08:21:40 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200201251621.g0PGLen38607@cirrus.juniper.net> From: Dave Katz To: jlearman@cisco.com CC: sboddapa@hotmail.com, isis-wg@spider.juniper.net In-reply-to: <4.3.2.7.2.20020125092121.01e51f28@dingdong.cisco.com> (message from Jeff Learman on Fri, 25 Jan 2002 10:05:49 -0500) Subject: Re: [Isis-wg] Making the update reliable References: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> <4.3.2.7.2.20020125092121.01e51f28@dingdong.cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 25 Jan 2002 08:21:40 -0800 (PST) >We send 'em anyhow. I think I made the cisco code do the same thing, >but it's been a lot of years. Or maybe you can just configure it >on the cisco box, I don't remember offhand. > >Cheap insurance when working with the ill-named mesh groups. I bet you did this before 3-way handshake was proposed. Without it, systems would recover from a one-sided restart much more quickly than waiting for all LSPs to be regenerated. Even with 3-way, I can't imagine them doing any harm. Can't remember; I'm old and doddering. But they were intended to solve separate problems. Any system that runs IS-IS on an unreliable PTP link and does not support 3-way handshake would be strongly advised to send periodic CSNPs. Until the mid 90s, this described pretty much every deployed ISIS PTP link, but somehow we all survived. The case we were actually trying to solve with the 3way hack was the one where there were two parallel links between the same pair of routers, but only one of them came up fully. The half-up side would happily pump traffic down the link, and the rest of the network would route to it (since the two links cannot be distinguished from a distance) and much unhappiness resulted. (In the single link case, the SPF would fail to calculate a path through the half-up link, so nobody would use it.) --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 00:39:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02438 for ; Wed, 30 Jan 2002 00:39:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0U5WCL04777; Tue, 29 Jan 2002 21:32:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TH6oL01326 for ; Tue, 29 Jan 2002 09:06:50 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0THBGc18542 for ; Tue, 29 Jan 2002 09:11:17 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 09:08:50 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0TH9VA22329; Tue, 29 Jan 2002 12:09:32 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAQ14705; Tue, 29 Jan 2002 12:09:16 -0500 (EST) Message-Id: <4.3.2.7.2.20020129120243.03bd7298@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Jeff Learman Subject: Re: [Isis-wg] Reg: route preference Cc: "ISISWG (E-mail)" , "ISIS (E-mail)" In-Reply-To: <002101c1a898$a5990990$1305a8c0@future.futsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_93695446==_.ALT" X-OriginalArrivalTime: 29 Jan 2002 17:08:50.0828 (UTC) FILETIME=[9F6654C0:01C1A8E7] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 12:05:22 -0500 --=====================_93695446==_.ALT Content-Type: text/plain; charset="us-ascii" At 02:43 AM 1/29/2002, Rayapureddi Ramesh wrote: > >Hello, > >I think I asked question in a wrong way. >Actaully my doubt is > >if we are maintaining three different databases for > >1. routes learned from ISIS ---route information data base RDB1 >2. manual adjacencies ( is-neighbors OR es-neighbors) -- route information data base RDB2 >3. reachable address (Prefix routes) -- route information data base RDB3 > >Is it maintaining three different data base correct? By RDB, I assume you mean the result of running SPF -- called a forwarding database (FDB) in 10589. You can keep them separate as long as you can follow the rules in section 7.2.7. I think that may be tricky. >if yes if we want a route to some destination "DST" then > >which database should I search first RDB1 or RDB2 or RDB3 ? >which is next RDB1 or RDB2 or RDB3 ? And which is last RDB1 or RDB2 or RDB3? If the same destination can appear in all three RDBs with different metric sums, which is likely the case, then you will have a little trouble meeting the second criteria in 7.2.7 without consulting all RDBs and keeping the metric sum in the RDB entries, and choosing an entry with the minimum metric sum. The thing to do here is to imagine the behavior of a system that meets the criteria, and make sure that your system exhibits indistinguishable behavior. By the way, the requirement for determinism seemed very important to the designers, and from my point of view that was a very helpful property. The fact that the same routing decisions would always be made regardless of the order in which systems or links came up made debugging problem cases much easier -- as the problems would tend to be more reproducable. This was especially the case when investigating problems in our customers' customers' networks. This was before I joined Cisco, and we sold OSI middleware used in SONET network elements. Regards, Jeff >regards, >Ramesh > >-----Original Message----- >From: Jeff Learman [mailto:jlearman@cisco.com] >Sent: Monday, January 28, 2002 9:12 PM >To: rameshrr@future.futsoft.com >Subject: Fwd: Re: [Isis-wg] Reg: route preference > >By the way, don't be confused by the inclusion of "metric sum" >in this list. It confused me at first, because we normally think of >all of the paths having equal cost before reaching this point. However, >this item only relates to routers that, rather than computing the set >of equal minimum cost paths (7.2.6.2-b), compute downstream paths >(7.2.6.2-c). I haven't ever heard of anyone using that method. > >Regards, >Jeff > >>Date: Mon, 28 Jan 2002 10:29:14 -0500 >>To: >>From: Jeff Learman >>Subject: Re: [Isis-wg] Reg: route preference >>Cc: "ISIS (E-mail)" , "ISISWG (E-mail)" >> >> >> >>See 10589:1992 section 7.2.7., Removal of excess paths. >> >>Jeff >> >>At 09:36 AM 1/28/2002, Rayapureddi Ramesh wrote: >>>Hi, >>> >>>In ISIS we can add manual adjacencies also, they are nothing but static routes. >>>We can add prefix addresses (reachable address) also these also static routes only. >>> >>>When we want to send some data to some destination "DST" >>> >>>if there three routes with different next hops with "same cost" >>> >>>1. route learned by ISIS with next hop NH1 >>>2. Static route (manual adjacency) with next hop NH2 >>>3. Reachable address with next hop NH3 >>> >>>Which route I should take as a best route? >>> >>>If any one knows pl tell me. >>> >>> >>>Regards, >>>Ramesh --=====================_93695446==_.ALT Content-Type: text/html; charset="us-ascii" At 02:43 AM 1/29/2002, Rayapureddi Ramesh wrote:
 
Hello,
 
I think I asked question in a wrong way.
Actaully my doubt is
 
if we are maintaining three different databases for
 
1. routes learned from ISIS ---route information data base RDB1
2. manual adjacencies ( is-neighbors OR es-neighbors) -- route information data base RDB2
3. reachable address (Prefix routes) -- route information data base RDB3
 
Is it maintaining three different data base correct?

By RDB, I assume you mean the result of running SPF -- called
a forwarding database (FDB) in 10589.  You can keep them separate
as long as you can follow the rules in section 7.2.7.  I think that
may be tricky.

if yes if we want a route to some destination "DST"  then
 
which database should I search first RDB1 or RDB2 or RDB3 ?
which is next   RDB1 or RDB2 or RDB3 ?  And which is last RDB1 or RDB2 or RDB3?

If the same destination can appear in all three RDBs with different
metric sums, which is likely the case, then you will have a little
trouble meeting the second criteria in 7.2.7 without consulting
all RDBs and keeping the metric sum in the RDB entries, and
choosing an entry with the minimum metric sum.

The thing to do here is to imagine the behavior of a system that
meets the criteria, and make sure that your system exhibits
indistinguishable behavior.  By the way, the requirement for
determinism seemed very important to the designers, and from my
point of view that was a very helpful property.  The fact that
the same routing decisions would always be made regardless of
the order in which systems or links came up made debugging problem
cases much easier -- as the problems would tend to be more reproducable.
This was especially the case when investigating problems in our
customers' customers' networks.  This was before I joined Cisco,
and we sold OSI middleware used in SONET network elements.

Regards,
Jeff

regards,
Ramesh
 
-----Original Message-----
From: Jeff Learman [mailto:jlearman@cisco.com]
Sent: Monday, January 28, 2002 9:12 PM
To: rameshrr@future.futsoft.com
Subject: Fwd: Re: [Isis-wg] Reg: route preference
By the way, don't be confused by the inclusion of "metric sum"
in this list.  It confused me at first, because we normally think of
all of the paths having equal cost before reaching this point.  However,
this item only relates to routers that, rather than computing the set
of equal minimum cost paths (7.2.6.2-b), compute downstream paths
(7.2.6.2-c).  I haven't ever heard of anyone using that method.

Regards,
Jeff

Date: Mon, 28 Jan 2002 10:29:14 -0500
To: <rameshrr@future.futsoft.com>
From: Jeff Learman <jlearman@cisco.com>
Subject: Re: [Isis-wg] Reg: route preference
Cc: "ISIS (E-mail)" <isis-wg-admin@spider.juniper.net>, "ISISWG (E-mail)" <isis-wg@juniper.net>



See 10589:1992 section 7.2.7., Removal of excess paths.

Jeff

At 09:36 AM 1/28/2002, Rayapureddi Ramesh wrote:
Hi,
 
In ISIS we  can add manual adjacencies also, they are nothing but static routes.
We can add prefix addresses (reachable address) also these also static routes only.
 
When we want to send some data to some destination "DST"
 
if there three routes with different next hops with "same cost"
 
1. route learned by ISIS with next hop NH1 
2. Static route (manual adjacency)   with next hop NH2
3. Reachable address with next hop NH3
 
Which route  I should take as a best route?
 
If any one knows pl tell me.
 
 
Regards,
Ramesh
--=====================_93695446==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 00:40:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02462 for ; Wed, 30 Jan 2002 00:40:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0U5Y4L04817; Tue, 29 Jan 2002 21:34:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TNcEL03061 for ; Tue, 29 Jan 2002 15:38:14 -0800 (PST) (envelope-from dhudek@ma.ultranet.com) Received: from logs-wq.proxy.aol.com (logs-wq.proxy.aol.com [205.188.200.132]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id SAA16468 for ; Tue, 29 Jan 2002 18:41:12 -0500 (EST) Received: from ma.ultranet.com (AC820264.ipt.aol.com [172.130.2.100]) by logs-wq.proxy.aol.com (8.10.0/8.10.0) with ESMTP id g0TNccC319006 for ; Tue, 29 Jan 2002 18:38:38 -0500 (EST) Message-ID: <3C57336B.8C12FFA1@ma.ultranet.com> From: David Hudek X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@spider.juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: Hudeks@aol.com Subject: [Isis-wg] Another Comment on draft-ietf-isis-traffic-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 18:42:35 -0500 Content-Transfer-Encoding: 7bit I have a comment/concern about the new TLV type 22 (Extended IS Reach), regarding the reservation of subTLV types 250-254 for undocumented purposes by one particular vendor. Putting in special set-asides to favor one particular vendor seems like a strange thing to do in an RFC... would it not be better to require documentation of these subTLVs' format and purpose, just as is done for the other types? RFCs are supposed to promote multiple inter-operable vendor implementations, and endorsing secret message components and behavior known only to one vendor would seem counter to that goal... Unless I'm missing something?? :-) Thanks, dave hudek dhudek@ma.ultranet.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 02:12:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11496 for ; Wed, 30 Jan 2002 02:12:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0U762L05354; Tue, 29 Jan 2002 23:06:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0U75cL05342 for ; Tue, 29 Jan 2002 23:05:38 -0800 (PST) (envelope-from prz@net4u.ch) Received: from net4u.ch ([63.200.52.71]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQQ005G8P8WRB@mta5.snfc21.pbi.net> for isis-wg@spider.juniper.net; Tue, 29 Jan 2002 23:10:08 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] Another Comment on draft-ietf-isis-traffic-04.txt To: David Hudek Cc: isis-wg@spider.juniper.net Message-id: <3C57A397.9080508@net4u.ch> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 References: <3C57336B.8C12FFA1@ma.ultranet.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 29 Jan 2002 23:41:11 -0800 Content-Transfer-Encoding: 7BIT David Hudek wrote: >I have a comment/concern about the new TLV type 22 (Extended IS Reach), >regarding the reservation of subTLV types 250-254 for undocumented >purposes by one particular vendor. > >Putting in special set-asides to favor one particular vendor seems >like a strange thing to do in an RFC... would it not be better to >require documentation of these subTLVs' format and purpose, just as >is done for the other types? RFCs are supposed to promote multiple >inter-operable vendor implementations, and endorsing secret >message components and behavior known only to one vendor >would seem counter to that goal... Unless I'm missing something?? :-) > I think you do, two aspects a) out of 255 very loosely populated space (it's only sub-TLVs) it's trivia to give 5 away. If space is congested, you can argue that vendors should do smarter things (e.g. one vendor as first thing is sticking their reserved MAC block into the TLV to make sure it's theirs and then they have a subtype so they can play games with a single TLV only). This is not a strong argument of course and if vendors start to play 'let's get some sub-TLV space just in case' we would be forced to have a discussion on a different plane of course. b) there will always be proprietary TLVs around, e.g. would you care to have Cisco IOS version encoded in a particular TLV documented? Probably not and if you do, Cisco may have good reasons to hide it since it's a pain to have customers asking why YOUR product does not work because YOU relied on their proprietary TLV they changed on the fly. I guess what I'm trying to say, proprietary TLVs will exist and it's better to know they are around rather than crash into them because of policy 'you have to tell us what the proprietary things contain' since guess what the reality will be? Nobody will tell you about them anymore. c) there will always be proprietary features around since vendors have to differentiate and it's especially hard with an open standard. If you don't believe it, try to get Dave K. to explain you everything he did in ISIS ever for the sake of it. I guess he won't be forthcoming or if he will, you probably won't be able to foot the bill he'll send you (I hope Dave bears the joke on his expense here ;-) thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 13:49:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28839 for ; Wed, 30 Jan 2002 13:49:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0UIe6L08822; Wed, 30 Jan 2002 10:40:06 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from sundmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0UIZEL08793 for ; Wed, 30 Jan 2002 10:35:14 -0800 (PST) (envelope-from tli@Procket.com) Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz1.procket.com (Postfix) with ESMTP id D1C4F23C30; Wed, 30 Jan 2002 10:31:31 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0UIdkr6005867; Wed, 30 Jan 2002 10:39:46 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0UIdji1002069; Wed, 30 Jan 2002 10:39:45 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.15852.791452.965115@alpha-tli.procket.com> To: David Hudek Cc: isis-wg@spider.juniper.net Subject: [Isis-wg] Another Comment on draft-ietf-isis-traffic-04.txt In-Reply-To: <3C57336B.8C12FFA1@ma.ultranet.com> References: <3C57336B.8C12FFA1@ma.ultranet.com> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 30 Jan 2002 10:39:40 -0800 Content-Transfer-Encoding: 7bit Dave, We discussed this when we did it. There is ample precedent for vendor-specified information in other protocols (e.g., DHCP). We also have opaque LSAs in OSPF. In the short term, such code points allow for vendor experimentation and innovation without operational disruption. In the longer term, the vendor does not choose to interoperate with the rest of us, that is their perogative. And the marketplace is a fine mechanism for insuring that the world knows that they are not interoperable. I know, I've been on the receiving end. ;-) Tony David Hudek writes: | | I have a comment/concern about the new TLV type 22 (Extended IS Reach), | regarding the reservation of subTLV types 250-254 for undocumented | purposes by one particular vendor. | | Putting in special set-asides to favor one particular vendor seems | like a strange thing to do in an RFC... would it not be better to | require documentation of these subTLVs' format and purpose, just as | is done for the other types? RFCs are supposed to promote multiple | inter-operable vendor implementations, and endorsing secret | message components and behavior known only to one vendor | would seem counter to that goal... Unless I'm missing something?? :-) | | Thanks, | dave hudek | dhudek@ma.ultranet.com | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 20:30:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05963 for ; Wed, 30 Jan 2002 20:30:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V1N9L10568; Wed, 30 Jan 2002 17:23:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f152.law7.hotmail.com [216.33.237.152]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V16CL10493 for ; Wed, 30 Jan 2002 17:06:12 -0800 (PST) (envelope-from sboddapa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Jan 2002 17:10:47 -0800 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 31 Jan 2002 01:10:46 GMT X-Originating-IP: [63.104.212.252] From: "Suresh Boddapati" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Jan 2002 01:10:47.0490 (UTC) FILETIME=[1D7C8A20:01C1A9F4] Subject: [Isis-wg] MD5 Authentication Questions Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 31 Jan 2002 01:10:46 Per the "IS-IS Cryptographic Authentication" draft, "When LSPs are authenticated, the Checksum and Remaining Lifetime fields are set to zero before authentication is computed". 1)Is the Remaining Lifetime field set back to the original value after computing the authentication? 2)What about the checksum? Is it left at zero since the authentication value itself can be used as a mechanism to detect packet corruption? In other words, should the checksum field be always zero for MD5 authenticated packets? If not, is the checksum computed after adding the authentication information to the LSP or before? Thanks in advance. Regards, Suresh _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 21:13:41 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06422 for ; Wed, 30 Jan 2002 21:13:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V27CL10791; Wed, 30 Jan 2002 18:07:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from sundmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V1nXL10699 for ; Wed, 30 Jan 2002 17:49:33 -0800 (PST) (envelope-from tli@Procket.com) Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz1.procket.com (Postfix) with ESMTP id EEC4A23C3B; Wed, 30 Jan 2002 17:45:51 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0V1s7r6009798; Wed, 30 Jan 2002 17:54:07 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0V1s7u5002447; Wed, 30 Jan 2002 17:54:07 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.41919.645937.263706@alpha-tli.procket.com> To: "Suresh Boddapati" Cc: isis-wg@spider.juniper.net Subject: [Isis-wg] MD5 Authentication Questions In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 30 Jan 2002 17:54:07 -0800 Content-Transfer-Encoding: 7bit | Per the "IS-IS Cryptographic Authentication" draft, | "When LSPs are authenticated, the Checksum and Remaining Lifetime fields are | set to zero before authentication is computed". | | 1)Is the Remaining Lifetime field set back to the original value after | computing the authentication? | | 2)What about the checksum? Is it left at zero since the authentication value | itself can be used as a mechanism to detect packet corruption? In other | words, should the checksum field be always zero for MD5 authenticated | packets? If not, is the checksum computed after adding the authentication | information to the LSP or before? Both values should be restored after computation. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 30 22:05:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07737 for ; Wed, 30 Jan 2002 22:05:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V2wDL11040; Wed, 30 Jan 2002 18:58:13 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V2TgL10893 for ; Wed, 30 Jan 2002 18:29:42 -0800 (PST) (envelope-from Sanjeev@coronanetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0V2YHc59854 for ; Wed, 30 Jan 2002 18:34:17 -0800 (PST) X-JNPR-Received-From: outside Received: from mailsrv.coronanetworks.com ([67.104.79.164]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 30 Jan 2002 18:25:16 -0800 Received: by mailsrv.coronanetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 18:28:37 -0800 Message-ID: From: Sanjeev Chakravarty To: "ISISWG (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A9FE.FCB06310" X-OriginalArrivalTime: 31 Jan 2002 02:25:16.0264 (UTC) FILETIME=[85155680:01C1A9FE] Subject: [Isis-wg] MIB question Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 30 Jan 2002 18:28:36 -0800 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. ------_=_NextPart_001_01C1A9FE.FCB06310 Content-Type: text/plain; charset="iso-8859-1" Hi, I didn't find any Route Redistribution MIB object in http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-07.txt Wondering if they are defined in any standard MIB. Any pointers appreciated. thanks, Sanjeev ------_=_NextPart_001_01C1A9FE.FCB06310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I=20 didn't find any Route Redistribution MIB object in http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-07.txt=
 
Wondering if they are defined in any = standard MIB. Any=20 pointers appreciated.
 
thanks,
 
Sanjeev
------_=_NextPart_001_01C1A9FE.FCB06310-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 02:13:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20757 for ; Thu, 31 Jan 2002 02:13:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V762L12118; Wed, 30 Jan 2002 23:06:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f252.law7.hotmail.com [216.33.236.130]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V75XL12106 for ; Wed, 30 Jan 2002 23:05:33 -0800 (PST) (envelope-from sboddapa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Jan 2002 23:10:10 -0800 Received: from 64.163.213.66 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 31 Jan 2002 07:10:09 GMT X-Originating-IP: [64.163.213.66] From: "Suresh Boddapati" To: tli@procket.com Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] MD5 Authentication Questions Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Jan 2002 07:10:10.0265 (UTC) FILETIME=[51E6E490:01C1AA26] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 31 Jan 2002 07:10:09 What is the rationale behind making the checksum zero before computing the authentication value and then computing the checksum over the entire packet (including the authentication TLV)? Why not just leave it at zero, like OSPF MD5 authentication does? If the computation of the authentication value at both the sending and receiving ends dont match, isn't that enough to discard the packet? On the other hand, if they do match, wont the checksum claculation always yield the same result at the sending and receiving end thereby making checksum calculation and verification redundant? Regards, Suresh > | 2)What about the checksum? Is it left at zero since the authentication >value > | itself can be used as a mechanism to detect packet corruption? In other > | words, should the checksum field be always zero for MD5 authenticated > | packets? If not, is the checksum computed after adding the >authentication > | information to the LSP or before? > > >Both values should be restored after computation. > >Tony >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 02:58:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21413 for ; Thu, 31 Jan 2002 02:58:39 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V7q6L12375; Wed, 30 Jan 2002 23:52:06 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from sundmz2.procket.com (dmz2.procket.com [65.174.124.37]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0V7iIL12317 for ; Wed, 30 Jan 2002 23:44:18 -0800 (PST) (envelope-from tli@Procket.com) Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz2.procket.com (Postfix) with ESMTP id 5D3793443B; Wed, 30 Jan 2002 23:51:21 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0V7mdr6014771; Wed, 30 Jan 2002 23:48:39 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0V7mdxb002664; Wed, 30 Jan 2002 23:48:39 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.63191.291402.990616@alpha-tli.procket.com> To: "Suresh Boddapati" Cc: tli@Procket.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] MD5 Authentication Questions In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 30 Jan 2002 23:48:39 -0800 Content-Transfer-Encoding: 7bit Not all systems in a domain may support authentication because of migration issues. Thus, always providing the checksum is a good thing. Tony Suresh Boddapati writes: | What is the rationale behind making the checksum zero before computing the | authentication value and then computing the checksum over the entire packet | (including the authentication TLV)? Why not just leave it at zero, like OSPF | MD5 authentication does? If the computation of the authentication value at | both the sending and receiving ends dont match, isn't that enough to discard | the packet? On the other hand, if they do match, wont the checksum | claculation always yield the same result at the sending and receiving end | thereby making checksum calculation and verification redundant? | | Regards, | | Suresh | | > | 2)What about the checksum? Is it left at zero since the authentication | >value | > | itself can be used as a mechanism to detect packet corruption? In other | > | words, should the checksum field be always zero for MD5 authenticated | > | packets? If not, is the checksum computed after adding the | >authentication | > | information to the LSP or before? | > | > | >Both values should be restored after computation. | > | >Tony | >_______________________________________________ | >Isis-wg mailing list - Isis-wg@external.juniper.net | >http://external.juniper.net/mailman/listinfo/isis-wg | | | | | _________________________________________________________________ | Send and receive Hotmail on your mobile device: http://mobile.msn.com | _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 05:10:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22951 for ; Thu, 31 Jan 2002 05:10:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VA32L12973; Thu, 31 Jan 2002 02:03:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from coltrane.dataconnection.com (smtp.dataconnection.com [192.91.191.4]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VA2wL12961 for ; Thu, 31 Jan 2002 02:02:59 -0800 (PST) (envelope-from JRB@dataconnection.com) Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 10:07:25 -0000 Message-ID: <37701240971DD31193970000F6CCB9F70348E2B3@duke.datcon.co.uk> From: Jon Berger To: Tony Li Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] MD5 Authentication Questions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 31 Jan 2002 10:07:26 -0000 I'm slightly confused. Can you confirm that you are just talking about the receive side? My reading of ISO10589 and draft-ietf-isis-hmac-03 is that the sender - constructs the LSP - calculates the authentication TLV (as described below) - calculates the checksum over the entire PDU including the authentication TLV. Is this correct? Jon -----Original Message----- From: Tony Li [mailto:tli@procket.com] Sent: 31 January 2002 07:49 To: Suresh Boddapati Cc: tli@procket.com; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] MD5 Authentication Questions Not all systems in a domain may support authentication because of migration issues. Thus, always providing the checksum is a good thing. Tony Suresh Boddapati writes: | What is the rationale behind making the checksum zero before computing the | authentication value and then computing the checksum over the entire packet | (including the authentication TLV)? Why not just leave it at zero, like OSPF | MD5 authentication does? If the computation of the authentication value at | both the sending and receiving ends dont match, isn't that enough to discard | the packet? On the other hand, if they do match, wont the checksum | claculation always yield the same result at the sending and receiving end | thereby making checksum calculation and verification redundant? | | Regards, | | Suresh | | > | 2)What about the checksum? Is it left at zero since the authentication | >value | > | itself can be used as a mechanism to detect packet corruption? In other | > | words, should the checksum field be always zero for MD5 authenticated | > | packets? If not, is the checksum computed after adding the | >authentication | > | information to the LSP or before? | > | > | >Both values should be restored after computation. | > | >Tony | >_______________________________________________ | >Isis-wg mailing list - Isis-wg@external.juniper.net | >http://external.juniper.net/mailman/listinfo/isis-wg | | | | | _________________________________________________________________ | Send and receive Hotmail on your mobile device: http://mobile.msn.com | _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 10:10:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28797 for ; Thu, 31 Jan 2002 10:10:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VF33L14663; Thu, 31 Jan 2002 07:03:03 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VF2YL14650 for ; Thu, 31 Jan 2002 07:02:34 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Sanjeev Chakravarty'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] MIB question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 31 Jan 2002 10:06:57 -0500 > I didn't find any Route Redistribution MIB object in > > Sanjeev Nope, there isn't currently any such thing, and a quick grep through the OSPF MIB for "redistr" came up empty as well. The rules for redistribution are often quite implementation specific: ACLs, metric conversions for larger metrics, and so on. Unless there is a groundswell for this, I would rather avoid getting into this rat's nest. - jeff parker - axiowave networks PS. In a previous mail on a similar topic I mumbled something about importing a 'BGP' route. I have since learned to spell Static correctly. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 16:17:34 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12793 for ; Thu, 31 Jan 2002 16:17:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VL8DL16307; Thu, 31 Jan 2002 13:08:13 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SHopL94091 for ; Mon, 28 Jan 2002 09:50:51 -0800 (PST) (envelope-from smakgill@virata.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SHt3c97529 for ; Mon, 28 Jan 2002 09:55:12 -0800 (PST) X-JNPR-Received-From: outside Received: from portcullis.ral.virata.com ([208.209.94.122]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 09:52:45 -0800 Received: from mango.ral.virata.com (mango.ral.virata.com [10.20.5.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id NAA21310 for ; Mon, 28 Jan 2002 13:01:40 -0500 Received: from flash.ral.virata.com (flash.ral.virata.com [10.20.5.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA01493 for ; Mon, 28 Jan 2002 12:53:18 -0500 Received: by flash.ral.virata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:48:51 -0500 Message-ID: From: Steve Makgill To: isis-wg@juniper.net Subject: RE: [Isis-wg] Reg: route preference MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A824.09C1A820" X-OriginalArrivalTime: 28 Jan 2002 17:52:45.0718 (UTC) FILETIME=[9780E360:01C1A824] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 12:48:47 -0500 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. ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01C1A824.09C1A820-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 16:23:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12954 for ; Thu, 31 Jan 2002 16:23:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VLF4L16378; Thu, 31 Jan 2002 13:15:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TAFaL98722 for ; Tue, 29 Jan 2002 02:15:36 -0800 (PST) (envelope-from iprouting@rediffmail.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0TAK1c13266 for ; Tue, 29 Jan 2002 02:20:01 -0800 (PST) X-JNPR-Received-From: outside Received: from mailweb24.rediffmail.com ([203.199.83.148]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 02:18:06 -0800 Received: (qmail 18300 invoked by uid 510); 29 Jan 2002 10:18:22 -0000 Message-ID: <20020129101822.18298.qmail@mailweb24.rediffmail.com> Received: from unknown (198.62.10.2) by rediffmail.com via HTTP; 29 Jan 2002 10:18:22 -0000 MIME-Version: 1.0 From: "Vijay Nath" Reply-To: "Vijay Nath" To: isis-wg@juniper.net Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 29 Jan 2002 10:18:07.0046 (UTC) FILETIME=[3E8F9E60:01C1A8AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g0TAFbL98723 Subject: [Isis-wg] ISIS routing on DA circuit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 29 Jan 2002 10:18:22 -0000 Content-Transfer-Encoding: 8bit Hi All, As per spec 10589, DA circuits shall not send Hellos, LSPs and SNPs.Then how dynamic routing is achieved ??. or it is not possible (dynamic routing) in DA circuits??. TIA, V Nath _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 16:36:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13310 for ; Thu, 31 Jan 2002 16:36:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VLS9L16499; Thu, 31 Jan 2002 13:28:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SHopL94091 for ; Mon, 28 Jan 2002 09:50:51 -0800 (PST) (envelope-from smakgill@virata.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SHt3c97529 for ; Mon, 28 Jan 2002 09:55:12 -0800 (PST) X-JNPR-Received-From: outside Received: from portcullis.ral.virata.com ([208.209.94.122]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 09:52:45 -0800 Received: from mango.ral.virata.com (mango.ral.virata.com [10.20.5.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id NAA21310 for ; Mon, 28 Jan 2002 13:01:40 -0500 Received: from flash.ral.virata.com (flash.ral.virata.com [10.20.5.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA01493 for ; Mon, 28 Jan 2002 12:53:18 -0500 Received: by flash.ral.virata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:48:51 -0500 Message-ID: From: Steve Makgill To: isis-wg@juniper.net Subject: RE: [Isis-wg] Reg: route preference MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A824.09C1A820" X-OriginalArrivalTime: 28 Jan 2002 17:52:45.0718 (UTC) FILETIME=[9780E360:01C1A824] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 12:48:47 -0500 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. ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01C1A824.09C1A820-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 16:40:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13446 for ; Thu, 31 Jan 2002 16:40:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VLWgL16531; Thu, 31 Jan 2002 13:32:42 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TAFaL98722 for ; Tue, 29 Jan 2002 02:15:36 -0800 (PST) (envelope-from iprouting@rediffmail.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0TAK1c13266 for ; Tue, 29 Jan 2002 02:20:01 -0800 (PST) X-JNPR-Received-From: outside Received: from mailweb24.rediffmail.com ([203.199.83.148]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 02:18:06 -0800 Received: (qmail 18300 invoked by uid 510); 29 Jan 2002 10:18:22 -0000 Message-ID: <20020129101822.18298.qmail@mailweb24.rediffmail.com> Received: from unknown (198.62.10.2) by rediffmail.com via HTTP; 29 Jan 2002 10:18:22 -0000 MIME-Version: 1.0 From: "Vijay Nath" Reply-To: "Vijay Nath" To: isis-wg@juniper.net Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 29 Jan 2002 10:18:07.0046 (UTC) FILETIME=[3E8F9E60:01C1A8AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g0TAFbL98723 Subject: [Isis-wg] ISIS routing on DA circuit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 29 Jan 2002 10:18:22 -0000 Content-Transfer-Encoding: 8bit Hi All, As per spec 10589, DA circuits shall not send Hellos, LSPs and SNPs.Then how dynamic routing is achieved ??. or it is not possible (dynamic routing) in DA circuits??. TIA, V Nath _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 16:51:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13738 for ; Thu, 31 Jan 2002 16:51:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VLj9L16651; Thu, 31 Jan 2002 13:45:09 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SHopL94091 for ; Mon, 28 Jan 2002 09:50:51 -0800 (PST) (envelope-from smakgill@virata.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SHt3c97529 for ; Mon, 28 Jan 2002 09:55:12 -0800 (PST) X-JNPR-Received-From: outside Received: from portcullis.ral.virata.com ([208.209.94.122]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 09:52:45 -0800 Received: from mango.ral.virata.com (mango.ral.virata.com [10.20.5.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id NAA21310 for ; Mon, 28 Jan 2002 13:01:40 -0500 Received: from flash.ral.virata.com (flash.ral.virata.com [10.20.5.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA01493 for ; Mon, 28 Jan 2002 12:53:18 -0500 Received: by flash.ral.virata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:48:51 -0500 Message-ID: From: Steve Makgill To: isis-wg@juniper.net Subject: RE: [Isis-wg] Reg: route preference MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A824.09C1A820" X-OriginalArrivalTime: 28 Jan 2002 17:52:45.0718 (UTC) FILETIME=[9780E360:01C1A824] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 12:48:47 -0500 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. ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01C1A824.09C1A820-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 16:56:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13878 for ; Thu, 31 Jan 2002 16:56:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VLnYL16679; Thu, 31 Jan 2002 13:49:34 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TAFaL98722 for ; Tue, 29 Jan 2002 02:15:36 -0800 (PST) (envelope-from iprouting@rediffmail.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0TAK1c13266 for ; Tue, 29 Jan 2002 02:20:01 -0800 (PST) X-JNPR-Received-From: outside Received: from mailweb24.rediffmail.com ([203.199.83.148]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 02:18:06 -0800 Received: (qmail 18300 invoked by uid 510); 29 Jan 2002 10:18:22 -0000 Message-ID: <20020129101822.18298.qmail@mailweb24.rediffmail.com> Received: from unknown (198.62.10.2) by rediffmail.com via HTTP; 29 Jan 2002 10:18:22 -0000 MIME-Version: 1.0 From: "Vijay Nath" Reply-To: "Vijay Nath" To: isis-wg@juniper.net Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 29 Jan 2002 10:18:07.0046 (UTC) FILETIME=[3E8F9E60:01C1A8AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g0TAFbL98723 Subject: [Isis-wg] ISIS routing on DA circuit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 29 Jan 2002 10:18:22 -0000 Content-Transfer-Encoding: 8bit Hi All, As per spec 10589, DA circuits shall not send Hellos, LSPs and SNPs.Then how dynamic routing is achieved ??. or it is not possible (dynamic routing) in DA circuits??. TIA, V Nath _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 17:08:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14033 for ; Thu, 31 Jan 2002 17:08:29 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VM2CL16839; Thu, 31 Jan 2002 14:02:12 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SHopL94091 for ; Mon, 28 Jan 2002 09:50:51 -0800 (PST) (envelope-from smakgill@virata.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SHt3c97529 for ; Mon, 28 Jan 2002 09:55:12 -0800 (PST) X-JNPR-Received-From: outside Received: from portcullis.ral.virata.com ([208.209.94.122]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 09:52:45 -0800 Received: from mango.ral.virata.com (mango.ral.virata.com [10.20.5.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id NAA21310 for ; Mon, 28 Jan 2002 13:01:40 -0500 Received: from flash.ral.virata.com (flash.ral.virata.com [10.20.5.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA01493 for ; Mon, 28 Jan 2002 12:53:18 -0500 Received: by flash.ral.virata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:48:51 -0500 Message-ID: From: Steve Makgill To: isis-wg@juniper.net Subject: RE: [Isis-wg] Reg: route preference MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A824.09C1A820" X-OriginalArrivalTime: 28 Jan 2002 17:52:45.0718 (UTC) FILETIME=[9780E360:01C1A824] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 12:48:47 -0500 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. ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01C1A824.09C1A820-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 17:12:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14115 for ; Thu, 31 Jan 2002 17:12:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VM6SL16878; Thu, 31 Jan 2002 14:06:28 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TAFaL98722 for ; Tue, 29 Jan 2002 02:15:36 -0800 (PST) (envelope-from iprouting@rediffmail.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0TAK1c13266 for ; Tue, 29 Jan 2002 02:20:01 -0800 (PST) X-JNPR-Received-From: outside Received: from mailweb24.rediffmail.com ([203.199.83.148]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 02:18:06 -0800 Received: (qmail 18300 invoked by uid 510); 29 Jan 2002 10:18:22 -0000 Message-ID: <20020129101822.18298.qmail@mailweb24.rediffmail.com> Received: from unknown (198.62.10.2) by rediffmail.com via HTTP; 29 Jan 2002 10:18:22 -0000 MIME-Version: 1.0 From: "Vijay Nath" Reply-To: "Vijay Nath" To: isis-wg@juniper.net Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 29 Jan 2002 10:18:07.0046 (UTC) FILETIME=[3E8F9E60:01C1A8AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g0TAFbL98723 Subject: [Isis-wg] ISIS routing on DA circuit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 29 Jan 2002 10:18:22 -0000 Content-Transfer-Encoding: 8bit Hi All, As per spec 10589, DA circuits shall not send Hellos, LSPs and SNPs.Then how dynamic routing is achieved ??. or it is not possible (dynamic routing) in DA circuits??. TIA, V Nath _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 17:18:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14185 for ; Thu, 31 Jan 2002 17:18:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VMB2L16924; Thu, 31 Jan 2002 14:11:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VLswL16758 for ; Thu, 31 Jan 2002 13:54:58 -0800 (PST) (envelope-from mshand@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0VLxcc87609 for ; Thu, 31 Jan 2002 13:59:38 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 13:58:23 -0800 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp128.cisco.com [10.50.0.127]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA08901; Thu, 31 Jan 2002 21:58:55 GMT Message-Id: <4.3.2.7.2.20020131215516.0335ed08@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Vijay Nath" From: mike shand Subject: Re: [Isis-wg] ISIS routing on DA circuit Cc: isis-wg@juniper.net In-Reply-To: <20020129101822.18298.qmail@mailweb24.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Jan 2002 21:58:24.0078 (UTC) FILETIME=[677D66E0:01C1AAA2] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 31 Jan 2002 21:58:33 +0000 At 10:18 29/01/2002 +0000, Vijay Nath wrote: >Hi All, > > As per spec 10589, DA circuits shall not send Hellos, LSPs and > SNPs.Then how dynamic routing is achieved ??. >or it is not possible (dynamic routing) in DA circuits??. It's not possible. A DA circuit has a reachable address prefix (aka manual route) attached to it, and the circuit is only brought up when there is traffic to that destination. The manual route is of course advertised in LSPs and propagated to other routers so that they know where to send the traffic. It was primarily designed for use with X.25 SVCs(which tells you how old it is), where you only want to pay for a virtual circuit when you have traffic. Mike >TIA, >V Nath > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 17:30:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14481 for ; Thu, 31 Jan 2002 17:30:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VMNrL17031; Thu, 31 Jan 2002 14:23:53 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SHopL94091 for ; Mon, 28 Jan 2002 09:50:51 -0800 (PST) (envelope-from smakgill@virata.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SHt3c97529 for ; Mon, 28 Jan 2002 09:55:12 -0800 (PST) X-JNPR-Received-From: outside Received: from portcullis.ral.virata.com ([208.209.94.122]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 09:52:45 -0800 Received: from mango.ral.virata.com (mango.ral.virata.com [10.20.5.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id NAA21310 for ; Mon, 28 Jan 2002 13:01:40 -0500 Received: from flash.ral.virata.com (flash.ral.virata.com [10.20.5.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA01493 for ; Mon, 28 Jan 2002 12:53:18 -0500 Received: by flash.ral.virata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:48:51 -0500 Message-ID: From: Steve Makgill To: isis-wg@juniper.net Subject: RE: [Isis-wg] Reg: route preference MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A824.09C1A820" X-OriginalArrivalTime: 28 Jan 2002 17:52:45.0718 (UTC) FILETIME=[9780E360:01C1A824] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 12:48:47 -0500 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. ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01C1A824.09C1A820-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 17:47:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14778 for ; Thu, 31 Jan 2002 17:47:41 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VMfDL17165; Thu, 31 Jan 2002 14:41:13 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SHopL94091 for ; Mon, 28 Jan 2002 09:50:51 -0800 (PST) (envelope-from smakgill@virata.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SHt3c97529 for ; Mon, 28 Jan 2002 09:55:12 -0800 (PST) X-JNPR-Received-From: outside Received: from portcullis.ral.virata.com ([208.209.94.122]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 09:52:45 -0800 Received: from mango.ral.virata.com (mango.ral.virata.com [10.20.5.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id NAA21310 for ; Mon, 28 Jan 2002 13:01:40 -0500 Received: from flash.ral.virata.com (flash.ral.virata.com [10.20.5.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA01493 for ; Mon, 28 Jan 2002 12:53:18 -0500 Received: by flash.ral.virata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:48:51 -0500 Message-ID: From: Steve Makgill To: isis-wg@juniper.net Subject: RE: [Isis-wg] Reg: route preference MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A824.09C1A820" X-OriginalArrivalTime: 28 Jan 2002 17:52:45.0718 (UTC) FILETIME=[9780E360:01C1A824] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 12:48:47 -0500 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. ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01C1A824.09C1A820-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 18:04:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15170 for ; Thu, 31 Jan 2002 18:04:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VMwDL17278; Thu, 31 Jan 2002 14:58:13 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SHopL94091 for ; Mon, 28 Jan 2002 09:50:51 -0800 (PST) (envelope-from smakgill@virata.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SHt3c97529 for ; Mon, 28 Jan 2002 09:55:12 -0800 (PST) X-JNPR-Received-From: outside Received: from portcullis.ral.virata.com ([208.209.94.122]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 09:52:45 -0800 Received: from mango.ral.virata.com (mango.ral.virata.com [10.20.5.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id NAA21310 for ; Mon, 28 Jan 2002 13:01:40 -0500 Received: from flash.ral.virata.com (flash.ral.virata.com [10.20.5.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA01493 for ; Mon, 28 Jan 2002 12:53:18 -0500 Received: by flash.ral.virata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:48:51 -0500 Message-ID: From: Steve Makgill To: isis-wg@juniper.net Subject: RE: [Isis-wg] Reg: route preference MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A824.09C1A820" X-OriginalArrivalTime: 28 Jan 2002 17:52:45.0718 (UTC) FILETIME=[9780E360:01C1A824] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 12:48:47 -0500 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. ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01C1A824.09C1A820-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 18:13:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15279 for ; Thu, 31 Jan 2002 18:13:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VN75L17358; Thu, 31 Jan 2002 15:07:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0VMwZL17284 for ; Thu, 31 Jan 2002 14:58:35 -0800 (PST) (envelope-from Ming.Chan@spirentcom.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0VN3Gc89458 for ; Thu, 31 Jan 2002 15:03:16 -0800 (PST) X-JNPR-Received-From: outside Received: from Thor.Adtech-Inc.COM ([63.165.80.10]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 15:00:02 -0800 Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.10.2+Sun/8.10.2) with ESMTP id g0VN0ce10531 for ; Thu, 31 Jan 2002 13:00:39 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 13:06:36 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540501EE3DE9@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: "'isis-wg@juniper.net'" Cc: "Chan, Chung Ming" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 31 Jan 2002 23:00:02.0875 (UTC) FILETIME=[042508B0:01C1AAAB] Subject: [Isis-wg] Ack'ing LSP on P2P Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 31 Jan 2002 13:06:35 -1000 Hi, I've question that is related to the LSP ack mechanism based on what I observed from one of the vendor's router. If the router has two p2p interfaces, Int-A and Int-B, If on Int-A, a LSP (Seq # X) is rx and the router forwards the LSP to Int-B ( it is also expecting an Ack from the interface). Then, before an Ack is received on Int-B, a newer instance of the same LSP (Seq # Y > X) is received from Int-A again, On Int-A, the router sends out PSNP to ack the latest received LSP (Seq # Y > X) We observed that the router is still sending out LSP (Seq # X). (we purposely configure the other router that connected to Int-B to slow down on sending the Ack out). Shouldn't the next LSP sent out from Int-B be LSP (Seq #Y > X) ? Thanks, Ming Chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 23:23:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21213 for ; Thu, 31 Jan 2002 23:23:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g114GaL18817; Thu, 31 Jan 2002 20:16:37 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0SHopL94091 for ; Mon, 28 Jan 2002 09:50:51 -0800 (PST) (envelope-from smakgill@virata.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0SHt3c97529 for ; Mon, 28 Jan 2002 09:55:12 -0800 (PST) X-JNPR-Received-From: outside Received: from portcullis.ral.virata.com ([208.209.94.122]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 28 Jan 2002 09:52:45 -0800 Received: from mango.ral.virata.com (mango.ral.virata.com [10.20.5.253]) by portcullis.ral.virata.com (8.9.3/8.8.5) with ESMTP id NAA21310 for ; Mon, 28 Jan 2002 13:01:40 -0500 Received: from flash.ral.virata.com (flash.ral.virata.com [10.20.5.170]) by mango.ral.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA01493 for ; Mon, 28 Jan 2002 12:53:18 -0500 Received: by flash.ral.virata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:48:51 -0500 Message-ID: From: Steve Makgill To: isis-wg@juniper.net Subject: RE: [Isis-wg] Reg: route preference MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A824.09C1A820" X-OriginalArrivalTime: 28 Jan 2002 17:52:45.0718 (UTC) FILETIME=[9780E360:01C1A824] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 28 Jan 2002 12:48:47 -0500 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. ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01C1A824.09C1A820 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01C1A824.09C1A820-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 23:26:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21233 for ; Thu, 31 Jan 2002 23:26:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g114JmL18842; Thu, 31 Jan 2002 20:19:48 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g0TAFaL98722 for ; Tue, 29 Jan 2002 02:15:36 -0800 (PST) (envelope-from iprouting@rediffmail.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g0TAK1c13266 for ; Tue, 29 Jan 2002 02:20:01 -0800 (PST) X-JNPR-Received-From: outside Received: from mailweb24.rediffmail.com ([203.199.83.148]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 02:18:06 -0800 Received: (qmail 18300 invoked by uid 510); 29 Jan 2002 10:18:22 -0000 Message-ID: <20020129101822.18298.qmail@mailweb24.rediffmail.com> Received: from unknown (198.62.10.2) by rediffmail.com via HTTP; 29 Jan 2002 10:18:22 -0000 MIME-Version: 1.0 From: "Vijay Nath" Reply-To: "Vijay Nath" To: isis-wg@juniper.net Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 29 Jan 2002 10:18:07.0046 (UTC) FILETIME=[3E8F9E60:01C1A8AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g0TAFbL98723 Subject: [Isis-wg] ISIS routing on DA circuit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 29 Jan 2002 10:18:22 -0000 Content-Transfer-Encoding: 8bit Hi All, As per spec 10589, DA circuits shall not send Hellos, LSPs and SNPs.Then how dynamic routing is achieved ??. or it is not possible (dynamic routing) in DA circuits??. TIA, V Nath _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 31 23:56:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21885 for ; Thu, 31 Jan 2002 23:56:42 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g114o1L19059; Thu, 31 Jan 2002 20:50:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g114n9L19044 for ; Thu, 31 Jan 2002 20:49:09 -0800 (PST) (envelope-from iprouting@rediffmail.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g114rqc97983 for ; Thu, 31 Jan 2002 20:53:52 -0800 (PST) X-JNPR-Received-From: outside Received: from mailweb33.rediffmail.com ([203.199.83.31]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 20:45:49 -0800 Received: (qmail 13343 invoked by uid 510); 1 Feb 2002 04:47:04 -0000 Message-ID: <20020201044704.13342.qmail@mailweb33.rediffmail.com> Received: from unknown (198.62.10.2) by rediffmail.com via HTTP; 01 Feb 2002 04:47:04 -0000 MIME-Version: 1.0 From: "Vijay Nath" Reply-To: "Vijay Nath" To: "mike shand" Cc: isis-wg@juniper.net Subject: Re: Re: [Isis-wg] ISIS routing on DA circuit Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 01 Feb 2002 04:45:49.0578 (UTC) FILETIME=[5224AEA0:01C1AADB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g114n9L19045 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 1 Feb 2002 04:47:04 -0000 Content-Transfer-Encoding: 8bit mike, when only manual route is the solution, what is need of router sending those manual route to other routers.Even other routers too, have manual information in their Reachable address prefix table, so it knows where to send the pkt. In sec 8.3.5 "There causes this information to be included in subsequently generated LSPs as described in 7.3.3.2.Routeing PDUs (LSPs and SN PDUs) shall not be sent on DA circuits" Two contradictory statements in a clause.Pl. explain on this. TIA, V Nath On Fri, 01 Feb 2002 mike shand wrote : > At 10:18 29/01/2002 +0000, Vijay Nath wrote: > > > >Hi All, > > > > As per spec 10589, DA circuits shall not send > Hellos, LSPs and > > SNPs.Then how dynamic routing is achieved ??. > >or it is not possible (dynamic routing) in DA > circuits??. > > It's not possible. A DA circuit has a reachable address > prefix (aka manual > route) attached to it, and the circuit is only brought > up when there is > traffic to that destination. The manual route is of > course advertised in > LSPs and propagated to other routers so that they know > where to send the > traffic. It was primarily designed for use with X.25 > SVCs(which tells you > how old it is), where you only want to pay for a > virtual circuit when you > have traffic. > > Mike > > > > >TIA, > >V Nath > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg