From rameshrr@future.futsoft.com Wed Jan 2 09:08:12 2002 From: rameshrr@future.futsoft.com (Rayapureddi Ramesh) Date: Wed, 2 Jan 2002 14:38:12 +0530 Subject: [Isis-wg] Echo packet Message-ID: <007101c1936d$02d582f0$1305a8c0@future.futsoft.com> 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-- From naiming@redback.com Wed Jan 2 09:53:13 2002 From: naiming@redback.com (Naiming Shen) Date: Wed, 02 Jan 2002 01:53:13 -0800 Subject: [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> Message-ID: <20020102095313.24E1D1DCC77@prattle.redback.com> 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 From jlearman@cisco.com Wed Jan 2 15:13:19 2002 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 02 Jan 2002 10:13:19 -0500 Subject: [Isis-wg] Echo packet In-Reply-To: <007101c1936d$02d582f0$1305a8c0@future.futsoft.com> Message-ID: <4.3.2.7.2.20020102100954.01d26d40@dingdong.cisco.com> --=====================_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-- From VishwasM@netplane.com Wed Jan 2 15:34:30 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Wed, 2 Jan 2002 10:34:30 -0500 Subject: [Isis-wg] Regarding document for best current practices Message-ID: 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 From nagastabagamba@yahoo.com Wed Jan 2 20:26:36 2002 From: nagastabagamba@yahoo.com (Nagasta Bagamba) Date: Wed, 2 Jan 2002 12:26:36 -0800 (PST) Subject: [Isis-wg] IGP shortcuts In-Reply-To: <20020102095313.24E1D1DCC77@prattle.redback.com> Message-ID: <20020102202636.87813.qmail@web21101.mail.yahoo.com> 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 From naiming@redback.com Wed Jan 2 22:43:15 2002 From: naiming@redback.com (Naiming Shen) Date: Wed, 02 Jan 2002 14:43:15 -0800 Subject: [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> Message-ID: <20020102224315.2A0901DCC6A@prattle.redback.com> ]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 From jparker@axiowave.com Wed Jan 2 22:58:08 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 2 Jan 2002 17:58:08 -0500 Subject: [Isis-wg] ISIS Adjacency IP Address Table Message-ID: 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. From donkiha@yahoo.com Thu Jan 3 20:15:16 2002 From: donkiha@yahoo.com (Dong Ha) Date: Thu, 3 Jan 2002 12:15:16 -0800 (PST) Subject: [Isis-wg] bgp mailing list In-Reply-To: <20020102224315.2A0901DCC6A@prattle.redback.com> Message-ID: <20020103201516.1447.qmail@web14907.mail.yahoo.com> 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 From mshand@cisco.com Fri Jan 4 12:23:53 2002 From: mshand@cisco.com (mike shand) Date: Fri, 04 Jan 2002 12:23:53 +0000 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt In-Reply-To: <200112301844.fBUIipb50547@cirrus.juniper.net> References: < Message-ID: <4.3.2.7.2.20020104120549.0339cea0@jaws.cisco.com> 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 From VishwasM@netplane.com Fri Jan 4 12:57:15 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Fri, 4 Jan 2002 07:57:15 -0500 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Message-ID: 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 From dkatz@juniper.net Fri Jan 4 17:49:39 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 4 Jan 2002 09:49:39 -0800 (PST) Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt 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) References: < <4.3.2.7.2.20020104120549.0339cea0@jaws.cisco.com> Message-ID: <200201041749.g04Hndm64880@cirrus.juniper.net> 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 From jparker@axiowave.com Mon Jan 7 14:53:11 2002 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 7 Jan 2002 09:53:11 -0500 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Message-ID: > 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 From VishwasM@netplane.com Tue Jan 8 04:27:39 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Mon, 7 Jan 2002 23:27:39 -0500 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Message-ID: 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 From dkatz@juniper.net Tue Jan 8 05:01:38 2002 From: dkatz@juniper.net (Dave Katz) Date: Mon, 7 Jan 2002 21:01:38 -0800 (PST) Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt In-Reply-To: (VishwasM@netplane.com) References: Message-ID: <200201080501.g0851cW77660@cirrus.juniper.net> 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 VishwasM@netplane.com Tue Jan 8 05:22:40 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Tue, 8 Jan 2002 00:22:40 -0500 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Message-ID: 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 From dkatz@juniper.net Tue Jan 8 06:25:32 2002 From: dkatz@juniper.net (Dave Katz) Date: Mon, 7 Jan 2002 22:25:32 -0800 (PST) Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt In-Reply-To: (VishwasM@netplane.com) References: Message-ID: <200201080625.g086PWL77994@cirrus.juniper.net> 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 From ginsberg@pluris.com Tue Jan 8 07:37:33 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Mon, 7 Jan 2002 23:37:33 -0800 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F6E4@avalon.pluris.com> (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 VishwasM@netplane.com Tue Jan 8 09:02:57 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Tue, 8 Jan 2002 04:02:57 -0500 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Message-ID: 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 From Internet-Drafts@ietf.org Tue Jan 8 13:45:36 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 08 Jan 2002 08:45:36 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-04.txt Message-ID: <200201081345.IAA20563@ietf.org> --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-- From jlearman@cisco.com Tue Jan 8 16:24:38 2002 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 08 Jan 2002 11:24:38 -0500 Subject: Fwd: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Message-ID: <4.3.2.7.2.20020108112118.01ceded8@dingdong.cisco.com> 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 jlearman@cisco.com Tue Jan 8 16:49:21 2002 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 08 Jan 2002 11:49:21 -0500 Subject: [Isis-wg] Regarding document for best current practices In-Reply-To: Message-ID: <4.3.2.7.2.20020108112515.01cb0ec0@dingdong.cisco.com> 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 jparker@axiowave.com Tue Jan 8 17:11:28 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 8 Jan 2002 12:11:28 -0500 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Message-ID: > 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 } From VishwasM@netplane.com Tue Jan 8 17:58:02 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Tue, 8 Jan 2002 12:58:02 -0500 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt Message-ID: 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 From jlearman@cisco.com Tue Jan 8 18:41:56 2002 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 08 Jan 2002 13:41:56 -0500 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt In-Reply-To: Message-ID: <4.3.2.7.2.20020108132338.01d13008@dingdong.cisco.com> 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 From jlearman@cisco.com Tue Jan 8 18:45:17 2002 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 08 Jan 2002 13:45:17 -0500 Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt In-Reply-To: Message-ID: <4.3.2.7.2.20020108134317.04335b28@dingdong.cisco.com> 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 } From prz@redback.com Tue Jan 8 17:53:15 2002 From: prz@redback.com (Tony Przygienda) Date: Tue, 08 Jan 2002 09:53:15 -0800 Subject: [Isis-wg] Regarding document for best current practices References: <4.3.2.7.2.20020108112515.01cb0ec0@dingdong.cisco.com> Message-ID: <3C3B320B.7F736B4B@redback.com> 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 From ginsberg@pluris.com Tue Jan 8 19:44:24 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Tue, 8 Jan 2002 11:44:24 -0800 Subject: [Isis-wg] Regarding document for best current practices Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com> 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 Ravindra.Sunkad@vivacenetworks.com Tue Jan 8 20:18:52 2002 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Tue, 8 Jan 2002 12:18:52 -0800 Subject: [Isis-wg] 3-way handshake question Message-ID: 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-- From prz@net4u.ch Wed Jan 9 09:07:13 2002 From: prz@net4u.ch (Tony Przygienda) Date: Wed, 09 Jan 2002 01:07:13 -0800 Subject: [Isis-wg] Regarding document for best current practices References: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com> Message-ID: <3C3C0841.6070409@net4u.ch> 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 From tli@Procket.com Wed Jan 9 08:51:01 2002 From: tli@Procket.com (Tony Li) Date: Wed, 9 Jan 2002 00:51:01 -0800 Subject: [Isis-wg] Regarding document for best current practices In-Reply-To: <3C3C0841.6070409@net4u.ch> References: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com> <3C3C0841.6070409@net4u.ch> Message-ID: <15420.1141.905364.108908@alpha-tli.procket.com> | 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 From rja@inet.org Wed Jan 9 13:17:33 2002 From: rja@inet.org (RJ Atkinson) Date: Wed, 09 Jan 2002 08:17:33 -0500 Subject: [Isis-wg] Regarding document for best current practices In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com > Message-ID: <5.1.0.14.2.20020109081156.01dda230@10.30.15.3> 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 From jfleming@anet.com Wed Jan 9 18:04:34 2002 From: jfleming@anet.com (Jim Fleming) Date: Wed, 9 Jan 2002 10:04:34 -0800 Subject: [Isis-wg] Regarding document for best current practices References: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com> Message-ID: <22e401c19938$197d60b0$0100a8c0@RepliGate> ----- 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 From VishwasM@netplane.com Wed Jan 9 15:48:26 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Wed, 9 Jan 2002 10:48:26 -0500 Subject: [Isis-wg] Regarding document for best current practices Message-ID: 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 From danny@tcb.net Wed Jan 9 17:09:24 2002 From: danny@tcb.net (Danny McPherson) Date: Wed, 09 Jan 2002 10:09:24 -0700 Subject: [Isis-wg] Regarding document for best current practices Message-ID: <200201091709.g09H9Oh04262@tcb.net> > 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 From mbartell@cisco.com Wed Jan 9 16:47:24 2002 From: mbartell@cisco.com (Micah Bartell) Date: Wed, 09 Jan 2002 10:47:24 -0600 Subject: [Isis-wg] Regarding document for best current practices In-Reply-To: <5.1.0.14.2.20020109081156.01dda230@10.30.15.3> References: <17C81AD1F1FED411991E006008F6D1CA01B3F6E8@avalon.pluris.com > Message-ID: <4.3.2.7.2.20020109103050.017bc9d0@cactus.cisco.com> > > 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 From jparker@axiowave.com Wed Jan 9 16:49:24 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 9 Jan 2002 11:49:24 -0500 Subject: [Isis-wg] Regarding document for best current practices Message-ID: > > 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 From VishwasM@netplane.com Wed Jan 9 17:22:52 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Wed, 9 Jan 2002 12:22:52 -0500 Subject: [Isis-wg] Regarding document for best current practices Message-ID: 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 From ginsberg@pluris.com Wed Jan 9 20:45:03 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 9 Jan 2002 12:45:03 -0800 Subject: [Isis-wg] Regarding document for best current practices Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F6F0@avalon.pluris.com> 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 > From ginsberg@pluris.com Wed Jan 9 21:16:15 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 9 Jan 2002 13:16:15 -0800 Subject: [Isis-wg] Regarding document for best current practices Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F6F2@avalon.pluris.com> > > > | 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 From tli@Procket.com Wed Jan 9 21:45:37 2002 From: tli@Procket.com (Tony Li) Date: Wed, 9 Jan 2002 13:45:37 -0800 Subject: [Isis-wg] Regarding document for best current practices In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F6F2@avalon.pluris.com> References: <17C81AD1F1FED411991E006008F6D1CA01B3F6F2@avalon.pluris.com> Message-ID: <15420.47617.491740.857857@alpha-tli.procket.com> | 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 From ramsrm@tdd.sj.nec.com" 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. From ramsrm@tdd.sj.nec.com" From VishwasM@netplane.com Thu Jan 10 06:48:54 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Thu, 10 Jan 2002 01:48:54 -0500 Subject: [Isis-wg] Regarding document for best current practices Message-ID: 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 From tli@Procket.com Thu Jan 10 06:54:21 2002 From: tli@Procket.com (Tony Li) Date: Wed, 9 Jan 2002 22:54:21 -0800 Subject: [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> Message-ID: <15421.15005.581065.981995@alpha-tli.procket.com> | 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 From selvarajr@future.futsoft.com Thu Jan 10 07:17:10 2002 From: selvarajr@future.futsoft.com (SelvarajR) Date: Thu, 10 Jan 2002 12:47:10 +0530 Subject: [Isis-wg] psuedonode LSP In-Reply-To: <01C1990F.4F5F7660.ramsrm@tdd.sj.nec.com> Message-ID: <000701c199a6$d268f800$2006040a@future.futsoft.com> 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 From dkatz@juniper.net Thu Jan 10 07:25:41 2002 From: dkatz@juniper.net (Dave Katz) Date: Wed, 9 Jan 2002 23:25:41 -0800 (PST) Subject: [Isis-wg] psuedonode LSP In-Reply-To: <000701c199a6$d268f800$2006040a@future.futsoft.com> (selvarajr@future.futsoft.com) References: <000701c199a6$d268f800$2006040a@future.futsoft.com> Message-ID: <200201100725.g0A7Pfj86013@cirrus.juniper.net> 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 From VishwasM@netplane.com Thu Jan 10 13:11:13 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Thu, 10 Jan 2002 08:11:13 -0500 Subject: [Isis-wg] Regarding document for best current practices Message-ID: 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 From jlearman@cisco.com Thu Jan 10 14:28:37 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 10 Jan 2002 09:28:37 -0500 Subject: [Isis-wg] psuedonode LSP In-Reply-To: <200201100725.g0A7Pfj86013@cirrus.juniper.net> References: <000701c199a6$d268f800$2006040a@future.futsoft.com> <000701c199a6$d268f800$2006040a@future.futsoft.com> Message-ID: <4.3.2.7.2.20020110092615.03c91c78@dingdong.cisco.com> 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 From john_hurley@agilent.com Thu Jan 10 17:50:40 2002 From: john_hurley@agilent.com (HURLEY,JOHN (A-Portsmouth,ex1)) Date: Thu, 10 Jan 2002 10:50:40 -0700 Subject: [Isis-wg] Establishing Router Adjacencies Message-ID: <0D9185CE635BD511ACA50090277A6FCF2A55DD@axcs18.cos.agilent.com> 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 From Larmer@CommSense.Net Thu Jan 10 18:21:08 2002 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 10 Jan 2002 13:21:08 -0500 Subject: [Isis-wg] Establishing Router Adjacencies In-Reply-To: <0D9185CE635BD511ACA50090277A6FCF2A55DD@axcs18.cos.agilent.com> Message-ID: 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 From donkiha@yahoo.com Thu Jan 10 19:48:35 2002 From: donkiha@yahoo.com (Dong Ha) Date: Thu, 10 Jan 2002 11:48:35 -0800 (PST) Subject: [Isis-wg] regeneration of pseudonode LSP In-Reply-To: <000701c199a6$d268f800$2006040a@future.futsoft.com> Message-ID: <20020110194835.15006.qmail@web14902.mail.yahoo.com> 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/ From ramsrm@tdd.sj.nec.com" 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 From jparker@axiowave.com Thu Jan 10 22:51:47 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 10 Jan 2002 17:51:47 -0500 Subject: [Isis-wg] draft-ietf-isis-wg-mib-07 submitted Message-ID: 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. From Larmer@CommSense.Net Thu Jan 10 22:58:39 2002 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 10 Jan 2002 17:58:39 -0500 Subject: [Isis-wg] psuedonode LSP In-Reply-To: <01C199C6.D75A05A0.ramsrm@tdd.sj.nec.com> Message-ID: > 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 From jlearman@cisco.com Thu Jan 10 23:02:50 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 10 Jan 2002 18:02:50 -0500 Subject: [Isis-wg] psuedonode LSP In-Reply-To: <01C199C6.D75A05A0.ramsrm@tdd.sj.nec.com> Message-ID: <4.3.2.7.2.20020110175027.01c4a598@dingdong.cisco.com> 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 From jlearman@cisco.com Thu Jan 10 22:48:59 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 10 Jan 2002 17:48:59 -0500 Subject: [Isis-wg] Establishing Router Adjacencies In-Reply-To: References: <0D9185CE635BD511ACA50090277A6FCF2A55DD@axcs18.cos.agilent.com> Message-ID: <4.3.2.7.2.20020110174820.01cd6cf8@dingdong.cisco.com> 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 From Larmer@commsense.net Thu Jan 10 23:08:35 2002 From: Larmer@commsense.net (Ken Larmer) Date: Thu, 10 Jan 2002 18:08:35 -0500 Subject: [Isis-wg] regeneration of pseudonode LSP In-Reply-To: <20020110194835.15006.qmail@web14902.mail.yahoo.com> Message-ID: > 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 From Larmer@CommSense.Net Thu Jan 10 23:12:05 2002 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 10 Jan 2002 18:12:05 -0500 Subject: [Isis-wg] Establishing Router Adjacencies In-Reply-To: <4.3.2.7.2.20020110174820.01cd6cf8@dingdong.cisco.com> Message-ID: 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 > > From jlearman@cisco.com Thu Jan 10 23:05:53 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 10 Jan 2002 18:05:53 -0500 Subject: [Isis-wg] regeneration of pseudonode LSP In-Reply-To: <20020110194835.15006.qmail@web14902.mail.yahoo.com> References: <000701c199a6$d268f800$2006040a@future.futsoft.com> Message-ID: <4.3.2.7.2.20020110180318.01ca5fa8@dingdong.cisco.com> 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 From jlearman@cisco.com Thu Jan 10 23:28:29 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 10 Jan 2002 18:28:29 -0500 Subject: [Isis-wg] Establishing Router Adjacencies In-Reply-To: References: <4.3.2.7.2.20020110174820.01cd6cf8@dingdong.cisco.com> Message-ID: <4.3.2.7.2.20020110182759.03cf3808@dingdong.cisco.com> 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 >> >> From mbartell@cisco.com Thu Jan 10 23:44:19 2002 From: mbartell@cisco.com (Micah Bartell) Date: Thu, 10 Jan 2002 17:44:19 -0600 Subject: [Isis-wg] Regarding document for best current practices 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> Message-ID: <4.3.2.7.2.20020110172427.02c6de88@cactus.cisco.com> 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 From ramsrm@tdd.sj.nec.com" 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. From christi@nortelnetworks.com Fri Jan 11 14:13:47 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Fri, 11 Jan 2002 14:13:47 -0000 Subject: [Isis-wg] Establishing Router Adjacencies Message-ID: <4103264BC8D3D51180B7002048400C4507141E@zhard0jd.europe.nortel.com> 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-- From jparker@axiowave.com Fri Jan 11 15:31:17 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 11 Jan 2002 10:31:17 -0500 Subject: [Isis-wg] Point to point adjacency down. Message-ID: > 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 From jlearman@cisco.com Fri Jan 11 15:28:29 2002 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 11 Jan 2002 10:28:29 -0500 Subject: [Isis-wg] Establishing Router Adjacencies In-Reply-To: <4103264BC8D3D51180B7002048400C4507141E@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020111100349.03571d60@dingdong.cisco.com> --=====================_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-- From dkatz@juniper.net Fri Jan 11 17:13:00 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 11 Jan 2002 09:13:00 -0800 (PST) Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: (message from Jeff Parker on Fri, 11 Jan 2002 10:31:17 -0500) References: Message-ID: <200201111713.g0BHD0T90686@cirrus.juniper.net> 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 From jparker@axiowave.com Fri Jan 11 18:09:06 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 11 Jan 2002 13:09:06 -0500 Subject: [Isis-wg] Point to point adjacency down. Message-ID: > 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 From Alex Zinin Fri Jan 11 19:05:59 2002 From: Alex Zinin (Alex Zinin) Date: Fri, 11 Jan 2002 11:05:59 -0800 Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: <200201111713.g0BHD0T90686@cirrus.juniper.net> References: <200201111713.g0BHD0T90686@cirrus.juniper.net> Message-ID: <2694482272.20020111110559@nexsi.com> 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. From prz@redback.com Fri Jan 11 17:48:54 2002 From: prz@redback.com (Tony Przygienda) Date: Fri, 11 Jan 2002 09:48:54 -0800 Subject: [Isis-wg] Point to point adjacency down. References: <200201111713.g0BHD0T90686@cirrus.juniper.net> Message-ID: <3C3F2585.3A45FC9F@redback.com> 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 From jparker@axiowave.com Fri Jan 11 19:22:31 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 11 Jan 2002 14:22:31 -0500 Subject: [Isis-wg] Point to point adjacency down. Message-ID: > > 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 From donkiha@yahoo.com Fri Jan 11 19:25:53 2002 From: donkiha@yahoo.com (Dong Ha) Date: Fri, 11 Jan 2002 11:25:53 -0800 (PST) Subject: [Isis-wg] LSP with size bigger than ReceiveLSPBufferSize In-Reply-To: Message-ID: <20020111192553.79887.qmail@web14901.mail.yahoo.com> 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/ From dkatz@juniper.net Fri Jan 11 19:27:47 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 11 Jan 2002 11:27:47 -0800 (PST) Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: (message from Jeff Parker on Fri, 11 Jan 2002 13:09:06 -0500) References: Message-ID: <200201111927.g0BJRln91110@cirrus.juniper.net> 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 From dkatz@juniper.net Fri Jan 11 19:44:39 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 11 Jan 2002 11:44:39 -0800 (PST) Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: <3C3F2585.3A45FC9F@redback.com> (message from Tony Przygienda on Fri, 11 Jan 2002 09:48:54 -0800) References: <200201111713.g0BHD0T90686@cirrus.juniper.net> <3C3F2585.3A45FC9F@redback.com> Message-ID: <200201111944.g0BJidA91180@cirrus.juniper.net> 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 From dkatz@juniper.net Fri Jan 11 19:40:15 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 11 Jan 2002 11:40:15 -0800 (PST) Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: <2694482272.20020111110559@nexsi.com> (message from Alex Zinin on Fri, 11 Jan 2002 11:05:59 -0800) References: <200201111713.g0BHD0T90686@cirrus.juniper.net> <2694482272.20020111110559@nexsi.com> Message-ID: <200201111940.g0BJeFS91168@cirrus.juniper.net> 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 From dkatz@juniper.net Fri Jan 11 20:05:20 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 11 Jan 2002 12:05:20 -0800 (PST) Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: (message from Jeff Parker on Fri, 11 Jan 2002 14:22:31 -0500) References: Message-ID: <200201112005.g0BK5Ko91238@cirrus.juniper.net> 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 From ginsberg@pluris.com Fri Jan 11 20:52:15 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Fri, 11 Jan 2002 12:52:15 -0800 Subject: [Isis-wg] LSP with size bigger than ReceiveLSPBufferSize Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F702@avalon.pluris.com> 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 From jparker@axiowave.com Fri Jan 11 21:12:22 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 11 Jan 2002 16:12:22 -0500 Subject: [Isis-wg] LSP with size bigger than ReceiveLSPBufferSize Message-ID: > > 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 } From ramsrm@tdd.sj.nec.com" 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 From donkiha@yahoo.com Fri Jan 11 21:56:13 2002 From: donkiha@yahoo.com (Dong Ha) Date: Fri, 11 Jan 2002 13:56:13 -0800 (PST) Subject: [Isis-wg] LSP with size bigger than ReceiveLSPBufferSize In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F702@avalon.pluris.com> Message-ID: <20020111215613.80241.qmail@web14909.mail.yahoo.com> 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/ From dkatz@juniper.net Fri Jan 11 22:15:28 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 11 Jan 2002 14:15:28 -0800 (PST) Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: <01C19A89.7CC38530.ramsrm@tdd.sj.nec.com> (message from ramanathan ramasamy on Fri, 11 Jan 2002 10:19:42 -0800) References: <01C19A89.7CC38530.ramsrm@tdd.sj.nec.com> Message-ID: <200201112215.g0BMFSV91664@cirrus.juniper.net> 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 From Alex Zinin Fri Jan 11 23:39:29 2002 From: Alex Zinin (Alex Zinin) Date: Fri, 11 Jan 2002 15:39:29 -0800 Subject: [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> Message-ID: <143710891377.20020111153929@nexsi.com> 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. From prz@redback.com Fri Jan 11 23:26:06 2002 From: prz@redback.com (Tony Przygienda) Date: Fri, 11 Jan 2002 15:26:06 -0800 Subject: [Isis-wg] Point to point adjacency down. References: <200201111713.g0BHD0T90686@cirrus.juniper.net> <2694482272.20020111110559@nexsi.com> <200201111940.g0BJeFS91168@cirrus.juniper.net> Message-ID: <3C3F748E.FA215F9B@redback.com> 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 From prz@redback.com Sat Jan 12 00:24:15 2002 From: prz@redback.com (Tony Przygienda) Date: Fri, 11 Jan 2002 16:24:15 -0800 Subject: [Isis-wg] Point to point adjacency down. References: <200201111713.g0BHD0T90686@cirrus.juniper.net> <3C3F2585.3A45FC9F@redback.com> <200201111944.g0BJidA91180@cirrus.juniper.net> Message-ID: <3C3F822F.70F616BB@redback.com> 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 From rja@extremenetworks.com Sat Jan 12 19:35:27 2002 From: rja@extremenetworks.com (RJ Atkinson) Date: Sat, 12 Jan 2002 14:35:27 -0500 Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: <3C3F2585.3A45FC9F@redback.com> Message-ID: <8797436E-0793-11D6-8CBE-00039357A82A@extremenetworks.com> 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 From canningt@nortelnetworks.com Mon Jan 14 15:12:57 2002 From: canningt@nortelnetworks.com (Terry Canning) Date: Mon, 14 Jan 2002 15:12:57 -0000 Subject: [Isis-wg] 3-way handshake question Message-ID: <17A46A8BD7E7D41199E300508BE3A94C02D1AC77@zirey00b.europe.nortel.com> 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-- From Sanjay.Harwani@marconi.com Mon Jan 14 17:24:12 2002 From: Sanjay.Harwani@marconi.com (Harwani, Sanjay) Date: Mon, 14 Jan 2002 12:24:12 -0500 Subject: [Isis-wg] loopback and passive interfaces Message-ID: <313680C9A886D511A06000204840E1CF529A78@whq-msgusr-02.pit.comms.marconi.com> 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-- From prz@redback.com Mon Jan 14 20:19:30 2002 From: prz@redback.com (Tony Przygienda) Date: Mon, 14 Jan 2002 12:19:30 -0800 Subject: [Isis-wg] Point to point adjacency down. References: <8797436E-0793-11D6-8CBE-00039357A82A@extremenetworks.com> Message-ID: <3C433D51.D68087F4@redback.com> 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 From ramsrm@tdd.sj.nec.com" 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. From ramsrm@tdd.sj.nec.com" From ramsrm@tdd.sj.nec.com" 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. From hannes@juniper.net Mon Jan 14 23:50:25 2002 From: hannes@juniper.net (Hannes Gredler) Date: Tue, 15 Jan 2002 00:50:25 +0100 Subject: [Isis-wg] loopback and passive interfaces 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 References: <313680C9A886D511A06000204840E1CF529A78@whq-msgusr-02.pit.comms.marconi.com> Message-ID: <20020115005025.A27158@juniper.net> 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 From Internet-Drafts@ietf.org Tue Jan 15 11:27:15 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 15 Jan 2002 06:27:15 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-07.txt Message-ID: <200201151127.GAA17617@ietf.org> --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-- From jparker@axiowave.com Tue Jan 15 16:06:16 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 15 Jan 2002 11:06:16 -0500 Subject: [Isis-wg] draft-ietf-isis-wg-mib-07 submitted Message-ID: > 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 From ramsrm@tdd.sj.nec.com" From Russ White Tue Jan 15 03:46:20 2002 From: Russ White (Russ White) Date: Mon, 14 Jan 2002 22:46:20 -0500 (EST) Subject: [Isis-wg] pseudonode LSPs In-Reply-To: <01C198E1.4B45BE50.ramsrm@tdd.sj.nec.com> Message-ID: 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 From ginsberg@pluris.com Wed Jan 16 00:31:29 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Tue, 15 Jan 2002 16:31:29 -0800 Subject: [Isis-wg] RE: draft-ietf-isis-3way-04.txt Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F714@avalon.pluris.com> 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 From wangxp@huawei.com Wed Jan 16 00:53:01 2002 From: wangxp@huawei.com (=?gb2312?B?0afG1Q==?=) Date: Wed, 16 Jan 2002 08:53:01 +0800 Subject: [Isis-wg] about "draft-ietf-isis-wg-mib-06" Message-ID: <001f01c19e28$26401960$5b316e0a@huawei.com> 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-- From jparker@axiowave.com Wed Jan 16 14:55:03 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 16 Jan 2002 09:55:03 -0500 Subject: [Isis-wg] about draft-ietf-isis-wg-mib-06 Message-ID: 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. From christi@nortelnetworks.com Wed Jan 16 18:00:54 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Wed, 16 Jan 2002 18:00:54 -0000 Subject: [Isis-wg] RE: draft-ietf-isis-3way-04.txt Message-ID: <4103264BC8D3D51180B7002048400C45071446@zhard0jd.europe.nortel.com> 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-- From Ming.Chan@SpirentCom.COM Wed Jan 16 18:50:54 2002 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming) Date: Wed, 16 Jan 2002 08:50:54 -1000 Subject: [Isis-wg] 2001 revision of ISO 10589 Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D41@apollo.adtech-inc.com> >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 From oran@cisco.com Wed Jan 16 19:40:20 2002 From: oran@cisco.com (David R. Oran) Date: Wed, 16 Jan 2002 14:40:20 -0500 Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: <200201112215.g0BMFSV91664@cirrus.juniper.net> Message-ID: <002301c19ec5$a2e05000$50308640@cisco.com> > -----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 From Ming.Chan@SpirentCom.COM Wed Jan 16 19:46:10 2002 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming) Date: Wed, 16 Jan 2002 09:46:10 -1000 Subject: [Isis-wg] Treatment of Zero checksum Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D43@apollo.adtech-inc.com> >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 From Ming.Chan@spirentcom.com Wed Jan 16 19:49:24 2002 From: Ming.Chan@spirentcom.com (Chan, Chung Ming) Date: Wed, 16 Jan 2002 09:49:24 -1000 Subject: [Isis-wg] FW: 2001 revision of ISO 10589 Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D44@apollo.adtech-inc.com> >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 From Ming.Chan@SpirentCom.COM Wed Jan 16 19:54:35 2002 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming) Date: Wed, 16 Jan 2002 09:54:35 -1000 Subject: [Isis-wg] FW: Treatment of Zero checksum Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D45@apollo.adtech-inc.com> -----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 From ginsberg@pluris.com Wed Jan 16 20:52:46 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 16 Jan 2002 12:52:46 -0800 Subject: [Isis-wg] RE: Treatment of Zero checksum Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F71B@avalon.pluris.com> 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 > From myeung@Procket.com Wed Jan 16 23:16:50 2002 From: myeung@Procket.com (Derek Yeung) Date: Wed, 16 Jan 2002 15:16:50 -0800 Subject: [Isis-wg] RE: Treatment of Zero checksum References: <17C81AD1F1FED411991E006008F6D1CA01B3F71B@avalon.pluris.com> Message-ID: <3C4609E2.EFB335DD@procket.com> 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 From ginsberg@pluris.com Thu Jan 17 01:22:13 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 16 Jan 2002 17:22:13 -0800 Subject: [Isis-wg] RE: Treatment of Zero checksum Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F720@avalon.pluris.com> 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 > From dkatz@juniper.net Thu Jan 17 06:23:49 2002 From: dkatz@juniper.net (Dave Katz) Date: Wed, 16 Jan 2002 22:23:49 -0800 (PST) Subject: [Isis-wg] Point to point adjacency down. In-Reply-To: <002301c19ec5$a2e05000$50308640@cisco.com> (oran@cisco.com) References: <002301c19ec5$a2e05000$50308640@cisco.com> Message-ID: <200201170623.g0H6NnO12037@cirrus.juniper.net> 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 From mshand@cisco.com Thu Jan 17 09:32:18 2002 From: mshand@cisco.com (mike shand) Date: Thu, 17 Jan 2002 09:32:18 +0000 Subject: [Isis-wg] RE: Treatment of Zero checksum In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F720@avalon.pluris.com > Message-ID: <4.3.2.7.2.20020117092853.0337ea78@jaws.cisco.com> 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 From Internet-Drafts@ietf.org Thu Jan 17 11:49:07 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Thu, 17 Jan 2002 06:49:07 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-06.txt Message-ID: <200201171149.GAA12430@ietf.org> --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-- From aravindravikumar@yahoo.com Thu Jan 17 12:55:26 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Thu, 17 Jan 2002 04:55:26 -0800 (PST) Subject: [Isis-wg] Doubt about LSP transmission Message-ID: <20020117125526.11458.qmail@web11203.mail.yahoo.com> --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-- From myeung@Procket.com Thu Jan 17 20:33:08 2002 From: myeung@Procket.com (Derek Yeung) Date: Thu, 17 Jan 2002 12:33:08 -0800 Subject: [Isis-wg] RE: Treatment of Zero checksum References: <4.3.2.7.2.20020117092853.0337ea78@jaws.cisco.com> Message-ID: <3C473504.81A77DCA@procket.com> 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 From Ming.Chan@spirentcom.com Fri Jan 18 02:14:44 2002 From: Ming.Chan@spirentcom.com (Chan, Chung Ming) Date: Thu, 17 Jan 2002 16:14:44 -1000 Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Number! Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D60@apollo.adtech-inc.com> 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 From harishb@tdd.sj.nec.com Fri Jan 18 03:30:08 2002 From: harishb@tdd.sj.nec.com (Harish Balasubramaniam) Date: Thu, 17 Jan 2002 19:30:08 -0800 Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Number! In-Reply-To: <8AC36D3167EED41184C800508BD9540501EE3D60@apollo.adtech-inc.com> Message-ID: 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 From Ming.Chan@spirentcom.com Fri Jan 18 16:13:13 2002 From: Ming.Chan@spirentcom.com (Chan, Chung Ming) Date: Fri, 18 Jan 2002 06:13:13 -1000 Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! Message-ID: <8AC36D3167EED41184C800508BD9540501EE3D62@apollo.adtech-inc.com> 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 From jlearman@cisco.com Fri Jan 18 17:01:25 2002 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 18 Jan 2002 12:01:25 -0500 Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! In-Reply-To: <8AC36D3167EED41184C800508BD9540501EE3D62@apollo.adtech-inc .com> Message-ID: <4.3.2.7.2.20020118115404.05bf0540@dingdong.cisco.com> 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 From harishb@tdd.sj.nec.com Fri Jan 18 18:59:35 2002 From: harishb@tdd.sj.nec.com (Harish Balasubramaniam) Date: Fri, 18 Jan 2002 10:59:35 -0800 Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! In-Reply-To: <4.3.2.7.2.20020118115404.05bf0540@dingdong.cisco.com> Message-ID: 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 From jlearman@cisco.com Fri Jan 18 19:21:44 2002 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 18 Jan 2002 14:21:44 -0500 Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! In-Reply-To: References: <4.3.2.7.2.20020118115404.05bf0540@dingdong.cisco.com> Message-ID: <4.3.2.7.2.20020118141738.05addbd8@dingdong.cisco.com> 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 From Sanjeev@coronanetworks.com Fri Jan 18 20:19:02 2002 From: Sanjeev@coronanetworks.com (Sanjeev Chakravarty) Date: Fri, 18 Jan 2002 12:19:02 -0800 Subject: [Isis-wg] question on draft-ietf-isis-wg-mib-06 Message-ID: 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 From dkatz@juniper.net Fri Jan 18 20:26:53 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 18 Jan 2002 12:26:53 -0800 (PST) Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! In-Reply-To: References: Message-ID: <200201182026.g0IKQrC17156@cirrus.juniper.net> 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. From jparker@axiowave.com Fri Jan 18 20:49:53 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 18 Jan 2002 15:49:53 -0500 Subject: [Isis-wg] question on draft-ietf-isis-wg-mib-06 Message-ID: > 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 From Radia Perlman - Boston Center for Networking Fri Jan 18 21:02:03 2002 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Fri, 18 Jan 2002 16:02:03 -0500 (EST) Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! Message-ID: <200201182102.QAA17725@bcn.East.Sun.COM> 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 From rja@extremenetworks.com Fri Jan 18 21:13:53 2002 From: rja@extremenetworks.com (RJ Atkinson) Date: Fri, 18 Jan 2002 16:13:53 -0500 Subject: [Isis-wg] question on draft-ietf-isis-wg-mib-06 In-Reply-To: Message-ID: <46964B36-0C58-11D6-8DA7-00039357A82A@extremenetworks.com> 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 From prz@redback.com Sat Jan 19 00:09:18 2002 From: prz@redback.com (Tony Przygienda) Date: Fri, 18 Jan 2002 16:09:18 -0800 Subject: [Isis-wg] new version of assigned tlv numbers ... Message-ID: <3C48B92E.B486DCFB@redback.com> 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] From prz@redback.com Sat Jan 19 04:43:50 2002 From: prz@redback.com (Tony Przygienda) Date: Fri, 18 Jan 2002 20:43:50 -0800 Subject: [Isis-wg] last call on draft-ietf-isis-hmac-03.txt ... Message-ID: <3C48F986.F00A7D0@redback.com> We are starting last call on draft-ietf-isis-hmac-03.txt. The last call will end 2/4/02 thanks -- tony From prz@redback.com Sat Jan 19 04:45:00 2002 From: prz@redback.com (Tony Przygienda) Date: Fri, 18 Jan 2002 20:45:00 -0800 Subject: [Isis-wg] last call on draft-ietf-isis-traffic-04 ... Message-ID: <3C48F9CB.32675D85@redback.com> We are starting last call on draft-ietf-isis-traffic-04. Last call will end 2/4/02 thanks --- tony From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From jeff.pickering@caspiannetworks.com Wed Jan 16 16:16:40 2002 From: jeff.pickering@caspiannetworks.com (Jeff Pickering) Date: Wed, 16 Jan 2002 08:16:40 -0800 Subject: [Isis-wg] isis-3way Message-ID: <3C45A768.1F7562F4@caspiannetworks.com> 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 From Larmer@commsense.net Mon Jan 21 14:44:13 2002 From: Larmer@commsense.net (Ken Larmer) Date: Mon, 21 Jan 2002 09:44:13 -0500 Subject: [Isis-wg] When the next Seq. Number Exceeds Max. Sequence Num ber! In-Reply-To: <200201182102.QAA17725@bcn.East.Sun.COM> Message-ID: > 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 From Internet-Drafts@ietf.org Tue Jan 22 12:56:52 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 22 Jan 2002 07:56:52 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-tlv-codepoints-01.txt Message-ID: <200201221256.HAA16705@ietf.org> --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-- From Sivakumar A" 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 From Sivakumar A" 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 From jparker@axiowave.com Wed Jan 23 15:14:49 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 23 Jan 2002 10:14:49 -0500 Subject: [Isis-wg] RE: Is it missing in Mib ? Message-ID: > 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 From lliu@chiaro.com Wed Jan 23 16:49:32 2002 From: lliu@chiaro.com (Laura Liu) Date: Wed, 23 Jan 2002 10:49:32 -0600 Subject: [Isis-wg] Questions on cird IDs in isis mib Message-ID: <2383E22BDFF6D311BB8400B0D021A50701B94A90@MAIL> --=_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-Transfer-Encoding: 7bit Content-Disposition: inline ----------------------------------------- (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-- From koen.vermeulen@alcatel.be Wed Jan 23 18:24:42 2002 From: koen.vermeulen@alcatel.be (Koen Vermeulen) Date: Wed, 23 Jan 2002 19:24:42 +0100 Subject: [Isis-wg] Making the update reliable Message-ID: <3C4EFFEA.4A5C778F@alcatel.be> --------------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-- From jparker@axiowave.com Wed Jan 23 19:32:54 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 23 Jan 2002 14:32:54 -0500 Subject: [Isis-wg] Questions on cird IDs in isis mib Message-ID: > 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 From swaminathanr@netplane.com Thu Jan 24 07:12:15 2002 From: swaminathanr@netplane.com (Ramalingam, Swaminathan) Date: Thu, 24 Jan 2002 02:12:15 -0500 Subject: [Isis-wg] Making the update reliable Message-ID: 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-- From mshand@cisco.com Thu Jan 24 08:26:39 2002 From: mshand@cisco.com (mike shand) Date: Thu, 24 Jan 2002 08:26:39 +0000 Subject: [Isis-wg] Making the update reliable In-Reply-To: Message-ID: <4.3.2.7.2.20020124082227.00b3be80@jaws.cisco.com> 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
 
From jlearman@cisco.com Thu Jan 24 13:25:55 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 24 Jan 2002 08:25:55 -0500 Subject: [Isis-wg] Making the update reliable In-Reply-To: Message-ID: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com> --=====================_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-- From jlearman@cisco.com Thu Jan 24 13:56:19 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 24 Jan 2002 08:56:19 -0500 Subject: [Isis-wg] Making the update reliable In-Reply-To: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com> References: Message-ID: <4.3.2.7.2.20020124085424.01d01c40@dingdong.cisco.com> --=====================_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-- From Larmer@CommSense.Net Thu Jan 24 15:11:35 2002 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 24 Jan 2002 10:11:35 -0500 Subject: [Isis-wg] Making the update reliable In-Reply-To: <4.3.2.7.2.20020124082227.00b3be80@jaws.cisco.com> Message-ID: 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-- From sboddapa@hotmail.com Thu Jan 24 15:12:48 2002 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Thu, 24 Jan 2002 15:12:48 Subject: [Isis-wg] Making the update reliable Message-ID: 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 From mshand@cisco.com Thu Jan 24 15:18:51 2002 From: mshand@cisco.com (mike shand) Date: Thu, 24 Jan 2002 15:18:51 +0000 Subject: [Isis-wg] Making the update reliable In-Reply-To: References: <4.3.2.7.2.20020124082227.00b3be80@jaws.cisco.com> Message-ID: <4.3.2.7.2.20020124151116.033c0e00@jaws.cisco.com> 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 From jlearman@cisco.com Thu Jan 24 15:58:06 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 24 Jan 2002 10:58:06 -0500 Subject: [Isis-wg] Making the update reliable In-Reply-To: Message-ID: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> 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 > From dkatz@juniper.net Thu Jan 24 16:52:00 2002 From: dkatz@juniper.net (Dave Katz) Date: Thu, 24 Jan 2002 08:52:00 -0800 (PST) Subject: [Isis-wg] Making the update reliable 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) References: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com> Message-ID: <200201241652.g0OGq0835808@cirrus.juniper.net> 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 From dkatz@juniper.net Thu Jan 24 16:54:37 2002 From: dkatz@juniper.net (Dave Katz) Date: Thu, 24 Jan 2002 08:54:37 -0800 (PST) Subject: [Isis-wg] Making the update reliable In-Reply-To: References: Message-ID: <200201241654.g0OGsbR35811@cirrus.juniper.net> 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 From lliu@chiaro.com Thu Jan 24 22:23:49 2002 From: lliu@chiaro.com (Laura Liu) Date: Thu, 24 Jan 2002 16:23:49 -0600 Subject: [Isis-wg] Questions on cird IDs in isis mib Message-ID: <2383E22BDFF6D311BB8400B0D021A50701B94F77@MAIL> --=_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-Transfer-Encoding: 7bit Content-Disposition: inline ----------------------------------------- (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-- From dhudek@ma.ultranet.com Thu Jan 24 23:20:58 2002 From: dhudek@ma.ultranet.com (David Hudek) Date: Thu, 24 Jan 2002 18:20:58 -0500 Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-04.txt Message-ID: <3C5096DA.C8B51ED@ma.ultranet.com> 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 From tli@procket.com Fri Jan 25 02:53:36 2002 From: tli@procket.com (Tony Li) Date: Thu, 24 Jan 2002 18:53:36 -0800 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> Message-ID: <15440.51376.725664.842316@alpha-tli.procket.com> 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 From sachidananda_k@hotmail.com Fri Jan 25 05:36:18 2002 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Fri, 25 Jan 2002 05:36:18 +0000 Subject: [Isis-wg] CSNP from Designated IS Message-ID: 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 From tli@Procket.com Fri Jan 25 05:47:19 2002 From: tli@Procket.com (Tony Li) Date: Thu, 24 Jan 2002 21:47:19 -0800 Subject: [Isis-wg] CSNP from Designated IS In-Reply-To: References: Message-ID: <15440.61799.591910.482779@alpha-tli.procket.com> | 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 From swaminathanr@netplane.com Fri Jan 25 06:28:17 2002 From: swaminathanr@netplane.com (Ramalingam, Swaminathan) Date: Fri, 25 Jan 2002 01:28:17 -0500 Subject: [Isis-wg] CSNP from Designated IS Message-ID: 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 > From naiming@redback.com Fri Jan 25 06:33:57 2002 From: naiming@redback.com (Naiming Shen) Date: Thu, 24 Jan 2002 22:33:57 -0800 Subject: [Isis-wg] Making the update reliable In-Reply-To: Mail from "Suresh Boddapati" dated Thu, 24 Jan 2002 15:12:48 Message-ID: <20020125063357.9028A4BA219@prattle.redback.com> ] 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 From naiming@redback.com Fri Jan 25 06:44:12 2002 From: naiming@redback.com (Naiming Shen) Date: Thu, 24 Jan 2002 22:44:12 -0800 Subject: [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> Message-ID: <20020125064412.658FBCAB70@prattle.redback.com> ] | 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 From dasnabendu@yahoo.com Fri Jan 25 07:34:09 2002 From: dasnabendu@yahoo.com (nabendu das) Date: Thu, 24 Jan 2002 23:34:09 -0800 (PST) Subject: [Isis-wg] checksum calculation doubt Message-ID: <20020125073409.46690.qmail@web13201.mail.yahoo.com> 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 From dkatz@juniper.net Fri Jan 25 08:00:49 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 25 Jan 2002 00:00:49 -0800 (PST) Subject: [Isis-wg] Making the update reliable 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) References: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> Message-ID: <200201250800.g0P80nZ37529@cirrus.juniper.net> 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 From mshand@cisco.com Fri Jan 25 18:06:44 2002 From: mshand@cisco.com (mike shand) Date: Fri, 25 Jan 2002 18:06:44 +0000 Subject: [Isis-wg] checksum calculation doubt In-Reply-To: <20020125073409.46690.qmail@web13201.mail.yahoo.com> Message-ID: <4.3.2.7.2.20020125175100.033cb130@jaws.cisco.com> 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 From naiming@redback.com Fri Jan 25 18:14:10 2002 From: naiming@redback.com (Naiming Shen) Date: Fri, 25 Jan 2002 10:14:10 -0800 Subject: [Isis-wg] Making the update reliable In-Reply-To: Mail from "Ken Larmer" dated Fri, 25 Jan 2002 10:06:21 EST Message-ID: <20020125181410.2B18B262804@prattle.redback.com> 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 From naiming@redback.com Fri Jan 25 18:24:55 2002 From: naiming@redback.com (Naiming Shen) Date: Fri, 25 Jan 2002 10:24:55 -0800 Subject: [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> Message-ID: <20020125182455.7D1D01531CB@prattle.redback.com> ] 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 From jharper@cisco.com Fri Jan 25 19:13:58 2002 From: jharper@cisco.com (John Harper) Date: Fri, 25 Jan 2002 11:13:58 -0800 Subject: [Isis-wg] checksum calculation doubt In-Reply-To: <4.3.2.7.2.20020125175100.033cb130@jaws.cisco.com> References: <20020125073409.46690.qmail@web13201.mail.yahoo.com> Message-ID: <4.3.2.7.2.20020125111331.03fbfaf0@jaws.cisco.com> 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. From tli@Procket.com Fri Jan 25 19:29:13 2002 From: tli@Procket.com (Tony Li) Date: Fri, 25 Jan 2002 11:29:13 -0800 Subject: [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> Message-ID: <15441.45577.649058.450053@alpha-tli.procket.com> | 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 From jparker@axiowave.com Fri Jan 25 14:49:43 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 25 Jan 2002 09:49:43 -0500 Subject: [Isis-wg] Questions on cird IDs in isis mib Message-ID: > 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 From Radia Perlman - Boston Center for Networking Sat Jan 26 04:43:59 2002 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Fri, 25 Jan 2002 23:43:59 -0500 (EST) Subject: [Isis-wg] checksum calculation doubt Message-ID: <200201260443.XAA07143@bcn.East.Sun.COM> 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 From prz@redback.com Sat Jan 26 06:30:34 2002 From: prz@redback.com (Tony Przygienda) Date: Fri, 25 Jan 2002 22:30:34 -0800 Subject: [Isis-wg] last call on draft-ietf-isis-wg-tlv-codepoints-01 Message-ID: <3C524D0A.49EAA9D4@redback.com> We are starting last call on draft-ietf-isis-wg-tlv-codepoints-01. The last call will end 2/9/02 thanks -- tony From Chaitanya77@postmark.net Sat Jan 26 14:19:37 2002 From: Chaitanya77@postmark.net (Chaitanya Huilgol) Date: Sat, 26 Jan 2002 14:19:37 +0000 Subject: [Isis-wg] SPF optimization Message-ID: <20020126141937.2979.qmail@venus.postmark.net> 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. --------------------------------------------- From sachidananda_k@hotmail.com Mon Jan 28 08:35:54 2002 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Mon, 28 Jan 2002 08:35:54 +0000 Subject: [Isis-wg] CSNP from Designated IS Message-ID: 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 From tli@Procket.com Mon Jan 28 09:03:13 2002 From: tli@Procket.com (Tony Li) Date: Mon, 28 Jan 2002 01:03:13 -0800 Subject: [Isis-wg] CSNP from Designated IS In-Reply-To: References: Message-ID: <15445.5073.780922.258651@alpha-tli.procket.com> | 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 From mshand@cisco.com Mon Jan 28 09:58:02 2002 From: mshand@cisco.com (mike shand) Date: Mon, 28 Jan 2002 09:58:02 +0000 Subject: [Isis-wg] checksum calculation doubt In-Reply-To: <200201260443.XAA07143@bcn.East.Sun.COM> Message-ID: <4.3.2.7.2.20020128095414.01a12008@jaws.cisco.com> 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 From Larmer@CommSense.Net Fri Jan 25 15:06:21 2002 From: Larmer@CommSense.Net (Ken Larmer) Date: Fri, 25 Jan 2002 10:06:21 -0500 Subject: [Isis-wg] Making the update reliable In-Reply-To: <20020125063357.9028A4BA219@prattle.redback.com> Message-ID: 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 From rameshrr@future.futsoft.com Mon Jan 28 14:36:43 2002 From: rameshrr@future.futsoft.com (Rayapureddi Ramesh) Date: Mon, 28 Jan 2002 20:06:43 +0530 Subject: [Isis-wg] Reg: route preference Message-ID: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com> 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-- From Larmer@commsense.net Mon Jan 28 15:08:20 2002 From: Larmer@commsense.net (Ken Larmer) Date: Mon, 28 Jan 2002 10:08:20 -0500 Subject: [Isis-wg] Reg: route preference In-Reply-To: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com> Message-ID: 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-- From jlearman@cisco.com Mon Jan 28 15:29:14 2002 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 28 Jan 2002 10:29:14 -0500 Subject: [Isis-wg] Reg: route preference In-Reply-To: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com> Message-ID: <4.3.2.7.2.20020128102326.01e81490@dingdong.cisco.com> --=====================_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-- From jlearman@cisco.com Mon Jan 28 16:25:09 2002 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 28 Jan 2002 11:25:09 -0500 Subject: [Isis-wg] Reg: route preference In-Reply-To: References: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com> Message-ID: <4.3.2.7.2.20020128112138.01e82ab8@dingdong.cisco.com> --=====================_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-- From Larmer@commsense.net Mon Jan 28 16:58:47 2002 From: Larmer@commsense.net (Ken Larmer) Date: Mon, 28 Jan 2002 11:58:47 -0500 Subject: [Isis-wg] Reg: route preference In-Reply-To: <4.3.2.7.2.20020128112138.01e82ab8@dingdong.cisco.com> Message-ID: 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-- From rameshrr@future.futsoft.com Tue Jan 29 07:43:29 2002 From: rameshrr@future.futsoft.com (Rayapureddi Ramesh) Date: Tue, 29 Jan 2002 13:13:29 +0530 Subject: [Isis-wg] Reg: route preference Message-ID: <002101c1a898$a5990990$1305a8c0@future.futsoft.com> 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-- From rameshrr@future.futsoft.com Tue Jan 29 07:44:33 2002 From: rameshrr@future.futsoft.com (Rayapureddi Ramesh) Date: Tue, 29 Jan 2002 13:14:33 +0530 Subject: [Isis-wg] FW: reg IS & ES neighbors Message-ID: <002601c1a898$cb941720$1305a8c0@future.futsoft.com> 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-- From Internet-Drafts@ietf.org Tue Jan 29 12:42:10 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 29 Jan 2002 07:42:10 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-07.txt Message-ID: <200201291242.HAA01151@ietf.org> --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-- From Internet-Drafts@ietf.org Tue Jan 29 12:42:15 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 29 Jan 2002 07:42:15 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-02.txt Message-ID: <200201291242.HAA01169@ietf.org> --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-- From jlearman@cisco.com Tue Jan 29 16:11:26 2002 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 29 Jan 2002 11:11:26 -0500 Subject: [Isis-wg] FW: reg IS & ES neighbors In-Reply-To: <002601c1a898$cb941720$1305a8c0@future.futsoft.com> Message-ID: <4.3.2.7.2.20020129110619.01ec71c0@dingdong.cisco.com> --=====================_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-- From naiming@redback.com Tue Jan 29 23:27:39 2002 From: naiming@redback.com (Naiming Shen) Date: Tue, 29 Jan 2002 15:27:39 -0800 Subject: [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> Message-ID: <20020129232739.67BAE1DCC76@prattle.redback.com> 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 From tli@procket.com Tue Jan 29 09:13:11 2002 From: tli@procket.com (Tony Li) Date: Tue, 29 Jan 2002 01:13:11 -0800 Subject: [Isis-wg] FW: reg IS & ES neighbors In-Reply-To: <002601c1a898$cb941720$1305a8c0@future.futsoft.com> References: <002601c1a898$cb941720$1305a8c0@future.futsoft.com> Message-ID: <15446.26535.813528.563467@alpha-tli.procket.com> | Can anybody explain me. Please consult with your vendor. This is not a technical support mailing list. Tony From jlearman@cisco.com Fri Jan 25 15:05:49 2002 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 25 Jan 2002 10:05:49 -0500 Subject: [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> <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> Message-ID: <4.3.2.7.2.20020125092121.01e51f28@dingdong.cisco.com> 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 From dkatz@juniper.net Fri Jan 25 16:21:40 2002 From: dkatz@juniper.net (Dave Katz) Date: Fri, 25 Jan 2002 08:21:40 -0800 (PST) Subject: [Isis-wg] Making the update reliable 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) 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> Message-ID: <200201251621.g0PGLen38607@cirrus.juniper.net> >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 From jlearman@cisco.com Tue Jan 29 17:05:22 2002 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 29 Jan 2002 12:05:22 -0500 Subject: [Isis-wg] Reg: route preference In-Reply-To: <002101c1a898$a5990990$1305a8c0@future.futsoft.com> Message-ID: <4.3.2.7.2.20020129120243.03bd7298@dingdong.cisco.com> --=====================_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-- From dhudek@ma.ultranet.com Tue Jan 29 23:42:35 2002 From: dhudek@ma.ultranet.com (David Hudek) Date: Tue, 29 Jan 2002 18:42:35 -0500 Subject: [Isis-wg] Another Comment on draft-ietf-isis-traffic-04.txt Message-ID: <3C57336B.8C12FFA1@ma.ultranet.com> 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 From prz@net4u.ch Wed Jan 30 07:41:11 2002 From: prz@net4u.ch (Tony Przygienda) Date: Tue, 29 Jan 2002 23:41:11 -0800 Subject: [Isis-wg] Another Comment on draft-ietf-isis-traffic-04.txt References: <3C57336B.8C12FFA1@ma.ultranet.com> Message-ID: <3C57A397.9080508@net4u.ch> 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 From tli@Procket.com Wed Jan 30 18:39:40 2002 From: tli@Procket.com (Tony Li) Date: Wed, 30 Jan 2002 10:39:40 -0800 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> Message-ID: <15448.15852.791452.965115@alpha-tli.procket.com> 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 From sboddapa@hotmail.com Thu Jan 31 01:10:46 2002 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Thu, 31 Jan 2002 01:10:46 Subject: [Isis-wg] MD5 Authentication Questions Message-ID: 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 From tli@Procket.com Thu Jan 31 01:54:07 2002 From: tli@Procket.com (Tony Li) Date: Wed, 30 Jan 2002 17:54:07 -0800 Subject: [Isis-wg] MD5 Authentication Questions In-Reply-To: References: Message-ID: <15448.41919.645937.263706@alpha-tli.procket.com> | 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 From Sanjeev@coronanetworks.com Thu Jan 31 02:28:36 2002 From: Sanjeev@coronanetworks.com (Sanjeev Chakravarty) Date: Wed, 30 Jan 2002 18:28:36 -0800 Subject: [Isis-wg] MIB question Message-ID: 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-- From sboddapa@hotmail.com Thu Jan 31 07:10:09 2002 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Thu, 31 Jan 2002 07:10:09 Subject: [Isis-wg] MD5 Authentication Questions Message-ID: 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 From tli@Procket.com Thu Jan 31 07:48:39 2002 From: tli@Procket.com (Tony Li) Date: Wed, 30 Jan 2002 23:48:39 -0800 Subject: [Isis-wg] MD5 Authentication Questions In-Reply-To: References: Message-ID: <15448.63191.291402.990616@alpha-tli.procket.com> 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 | From JRB@dataconnection.com Thu Jan 31 10:07:26 2002 From: JRB@dataconnection.com (Jon Berger) Date: Thu, 31 Jan 2002 10:07:26 -0000 Subject: [Isis-wg] MD5 Authentication Questions Message-ID: <37701240971DD31193970000F6CCB9F70348E2B3@duke.datcon.co.uk> 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 From jparker@axiowave.com Thu Jan 31 15:06:57 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 31 Jan 2002 10:06:57 -0500 Subject: [Isis-wg] MIB question Message-ID: > 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. From smakgill@virata.com Mon Jan 28 17:48:47 2002 From: smakgill@virata.com (Steve Makgill) Date: Mon, 28 Jan 2002 12:48:47 -0500 Subject: [Isis-wg] Reg: route preference Message-ID: 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-- From Vijay Nath" 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 From smakgill@virata.com Mon Jan 28 17:48:47 2002 From: smakgill@virata.com (Steve Makgill) Date: Mon, 28 Jan 2002 12:48:47 -0500 Subject: [Isis-wg] Reg: route preference Message-ID: 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-- From Vijay Nath" 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 From smakgill@virata.com Mon Jan 28 17:48:47 2002 From: smakgill@virata.com (Steve Makgill) Date: Mon, 28 Jan 2002 12:48:47 -0500 Subject: [Isis-wg] Reg: route preference Message-ID: 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-- From Vijay Nath" 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 From smakgill@virata.com Mon Jan 28 17:48:47 2002 From: smakgill@virata.com (Steve Makgill) Date: Mon, 28 Jan 2002 12:48:47 -0500 Subject: [Isis-wg] Reg: route preference Message-ID: 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-- From Vijay Nath" 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 From mshand@cisco.com Thu Jan 31 21:58:33 2002 From: mshand@cisco.com (mike shand) Date: Thu, 31 Jan 2002 21:58:33 +0000 Subject: [Isis-wg] ISIS routing on DA circuit In-Reply-To: <20020129101822.18298.qmail@mailweb24.rediffmail.com> Message-ID: <4.3.2.7.2.20020131215516.0335ed08@jaws.cisco.com> 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 From smakgill@virata.com Mon Jan 28 17:48:47 2002 From: smakgill@virata.com (Steve Makgill) Date: Mon, 28 Jan 2002 12:48:47 -0500 Subject: [Isis-wg] Reg: route preference Message-ID: 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-- From smakgill@virata.com Mon Jan 28 17:48:47 2002 From: smakgill@virata.com (Steve Makgill) Date: Mon, 28 Jan 2002 12:48:47 -0500 Subject: [Isis-wg] Reg: route preference Message-ID: 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-- From smakgill@virata.com Mon Jan 28 17:48:47 2002 From: smakgill@virata.com (Steve Makgill) Date: Mon, 28 Jan 2002 12:48:47 -0500 Subject: [Isis-wg] Reg: route preference Message-ID: 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-- From Ming.Chan@spirentcom.com Thu Jan 31 23:06:35 2002 From: Ming.Chan@spirentcom.com (Chan, Chung Ming) Date: Thu, 31 Jan 2002 13:06:35 -1000 Subject: [Isis-wg] Ack'ing LSP on P2P Message-ID: <8AC36D3167EED41184C800508BD9540501EE3DE9@apollo.adtech-inc.com> 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 From smakgill@virata.com Mon Jan 28 17:48:47 2002 From: smakgill@virata.com (Steve Makgill) Date: Mon, 28 Jan 2002 12:48:47 -0500 Subject: [Isis-wg] Reg: route preference Message-ID: 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-- From Vijay Nath" 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