From jparker@axiowave.com Tue Jan 2 21:11:57 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 2 Jan 2001 16:11:57 -0500 Subject: [Isis-wg] Encoding of TE Sub-TLVs Message-ID: Henk, Tony - Has the layouot of TE sub-TLVs has been written up? In draft-ietf-isis-traffic-02.txt (http://ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt) you don't really describe how the sub-TLVs are encoded. All of the examples given are fixed length, allowing an unwary implementor to imagine that they might be implemented as TV's rather than TLVs (that is, one is at risk of imagining that the length could be omitted). I can propose text to the list, but won't do so if this has been described someplace. - jeff parker - axiowave networks From tli@Procket.com Wed Jan 3 04:05:30 2001 From: tli@Procket.com (Tony Li) Date: Tue, 2 Jan 2001 20:05:30 -0800 (PST) Subject: [Isis-wg] Encoding of TE Sub-TLVs In-Reply-To: References: Message-ID: <14930.42250.217268.222455@alpha-tony.procket.com> Jeff, Not doing a TLV is unthinkable, as that would completely break the spirit of the IS-IS design. If you would like to propose text, that's fine. It's probably best to give it to Henk as he has a bit more spare time than I do at present. Tony Jeff Parker writes: | Henk, Tony - | | Has the layouot of TE sub-TLVs has been written up? | In draft-ietf-isis-traffic-02.txt | | (http://ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt) | | you don't really describe how the sub-TLVs are encoded. | All of the examples given are fixed length, allowing an unwary | implementor to imagine that they might be implemented as TV's | rather than TLVs (that is, one is at risk of imagining that | the length could be omitted). I can propose text to the list, | but won't do so if this has been described someplace. | | - jeff parker | - axiowave networks From jparker@axiowave.com Wed Jan 3 14:59:36 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 3 Jan 2001 09:59:36 -0500 Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs Message-ID: Tony, Henk - This is offered to try to make the draft unambiguous to implement. You do refer to the values as "sub-TLV" throughout. However, there have been enough questions about the need for L in TLV on this and other lists recently that it would be good to remove doubt. This draft is being cited by a number of other drafts, so the effort to make it clear is worthwhile. In section in 4.0 The proposed extended IP reachability TLV contains a new data structure, consisting of: 4 bytes of metric information 1 byte of control information, consisting of 1 bit of up/down information 1 bit indicating the existence of sub-TLVs 6 bits of prefix length 0-4 bytes of IPv4 prefix 0-250 optional octets of sub-TVLs, if present consisting of 1 octet of length of sub-TLVs 0-249 octets of sub-TLVs you could replace the last line with 0-249 octets of sub-TLVs, consisting of a sequence of 1 octet of sub-type 1 octet of length 1-247 octets of value and the phrase in section 5.0 The proposed extended IS reachability TLV contains a new data structure, consisting of 7 octets of system Id and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs could be extended by 0-244 octets of sub-TLVs, consisting of a sequence of 1 octet of sub-type 1 octet of length 1-242 octets of value An example would help: either before section 4.0 or in a final section. For example, the sequence of 41 octets below 0x16 0x27 0xAAAA AAAA AAAA 00 0x00000A 0x06 0x03 0x04 0x01020304 0xBBBB BBBB BBBB 00 0x00000A 0x00 0xCCCC CCCC CCCC 00 0x00000A 0x00 is a TLV which describes three IS-IS neighbors. The first of these has an administrative color, defined by subtype 3, which consists of 4 octets of information. Someone could make the case that this is not prescriptive enough: it simply describes what should be done in a couple of cases. Such a person could argue for a special section describing the rules for a sub-TLV. - jeff parker > Not doing a TLV is unthinkable, as that would completely > break the spirit > of the IS-IS design. > > If you would like to propose text, that's fine. It's > probably best to give > it to Henk as he has a bit more spare time than I do at present. > > | All of the examples given are fixed length, allowing an unwary > | implementor to imagine that they might be implemented as TV's > | rather than TLVs (that is, one is at risk of imagining that > | the length could be omitted). I can propose text to the list, > | but won't do so if this has been described someplace. > | > | - jeff parker > | - axiowave networks > From Radia Perlman - Boston Center for Networking Wed Jan 3 18:14:12 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Wed, 3 Jan 2001 13:14:12 -0500 (EST) Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs Message-ID: <200101031814.NAA13691@bcn.East.Sun.COM> Jeff's encodings look fine to me. I'm pleased to see "7" for "system Id and pseudonode number" rather than "ID length + 1 byte". Has anyone considered getting rid of the kludge about variable length system IDs, and just saying they are 6? It would somewhat simplify the IS-IS spec. The alternative is to change Jeff's encoding to "ID length+1". Radia From jparker@axiowave.com Wed Jan 3 18:49:53 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 3 Jan 2001 13:49:53 -0500 Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs Message-ID: > Jeff's encodings look fine to me. I'm pleased to see "7" for > "system Id and pseudonode number" rather than "ID length + 1 byte". > Has anyone considered getting rid of the kludge about variable > length system IDs, and just saying they are 6? It would > somewhat simplify the IS-IS spec. The alternative is to > change Jeff's encoding to "ID length+1". > > Radia Radia - Thanks for the credit, but Tony and Henk used that language in the original draft. What I think you are asking for is agrement that System ID has length 6, and a term that we could define to be the 7 byte quantity above. Something like "Virtual System ID", but without all the baggage Virtual suggests. Using Pseudo in the name is also bad, as it would suggest that it does not apply to real router IDs. Some suggestions System Descriptor OSI Router ID Universal Name (Universal Identifier?) Vertex Identifier (Vertex Name? Universal Vertex Name?) Universal Forwarding OID (UFO) ... Then we could talk about the "System Descriptor length" rather than having to say "System ID Length + 1". - jeff parker From Radia Perlman - Boston Center for Networking Wed Jan 3 19:29:36 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Wed, 3 Jan 2001 14:29:36 -0500 (EST) Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs Message-ID: <200101031929.OAA14069@bcn.East.Sun.COM> Re: Jeff's reply assuming I was suggesting a less awkward word for the 7-byte quantity. Actually, in my note I was talking about how the system ID specified in DECnet Phase V as 6 bytes got changed by ISO to be variable length, with a kludge field in the hellos and maybe also LSPs to indicate what "ID length" was, and so everything in the spec that specified a system ID had to say it was "ID length" rather than 6 bytes. Everyone in the domain has to have the same value for ID length or you refuse to talk. Completely unnecessary flexibility I always thought. Along with the "max area addresses", which was the constant 3 in DECnet, and got changed by ISO to be variable, along with a similar field in hellos stating your value of "max area addresses". Aside from both of these things just being unnecessary complexity, it violated something I'd always strived for which was making parameters changable node by node in a running net. Like the hello interval is. So I was hoping that someone would at some point get rid of both those parameters and fix ID length at 6, and max area addresses at 3, and get rid of all the verbiage and fields for specifying otherwise. Otherwise, to fit with the way the IS-IS spec is currently written, the line "7 octets of system Id and pseudonode number" would have to be changed to "ID length+1 octets of system Id and pseudonode number" But even though it wasn't what my note was about, your suggestion of coming up with a word for the 7-byte thing is good. The one I like the best of your proposals is "vertex identifier", or perhaps "node identifier". I agree with you that "virtual" and "pseudo" have confusing connotations. "System descriptor" I'd think would include what version OS it was running, what type hardware it was, etc. "Universal name" sounds like a URN and might be confusing. I've never been able to get too enthusiastic about coming up with names for things. I couldn't think of a good name for what wound up being called "adjacency". I'm pretty sure it was Mike Shand who thought up that one, and I really like it, so maybe he can think of a good word for the 7 (err. ID length+1) byte thingie, though we've lived without it OK for 15 years or so. Radia From jparker@axiowave.com Wed Jan 3 20:00:11 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 3 Jan 2001 15:00:11 -0500 Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs Message-ID: > Actually, in my note I was talking about how the system ID specified > in DECnet Phase V as 6 bytes got changed > by ISO to be variable length, The current MIB retains this tradition. SystemID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A system ID." SYNTAX OCTET STRING (SIZE(0..8)) I will add changing this to fixed length of 6 to my todo list. You can try to badger everyone else now. - jeff parker From ginsberg@pluris.com Wed Jan 3 21:26:48 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 3 Jan 2001 13:26:48 -0800 Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs Message-ID: I admit that I don't have any clever name for the "7 byte thingie", but I do think it would be VERY BAD if we picked anything that suggested that the "7 byte thingie" was in any way an identifier for the system since a system may have a lot of "7 byte thingies" which belong to it. The first six bytes serve very well as a System ID thank you. The 7th byte is officially the "pseudonodeID" according to 10589. It is sometimes also thought of as a local circuit ID, though in reality that description does not align with actual implementations. In any event it is definitely not some sort of system thing and I am afraid that all of Jeff's suggestions imply that in some way - at least to me. In the absence of something clever, I can live with "System ID Length + 1" Les > What I think you are asking for is agrement > that System ID has length 6, and a term > that we could define to be the 7 byte quantity above. > Something like "Virtual System ID", but without > all the baggage Virtual suggests. Using Pseudo in > the name is also bad, as it would suggest that it > does not apply to real router IDs. Some suggestions > > System Descriptor > OSI Router ID > Universal Name (Universal Identifier?) > Vertex Identifier (Vertex Name? Universal Vertex Name?) > Universal Forwarding OID (UFO) > ... > > Then we could talk about the "System Descriptor length" > rather than having to say "System ID Length + 1". > > - jeff parker > From jlearman@cisco.com Wed Jan 3 21:53:01 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 03 Jan 2001 16:53:01 -0500 Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs In-Reply-To: Message-ID: <4.1.20010103165200.00a5f2f0@dingdong.cisco.com> That's why "vertex ID" is so appealing. What the heck is a vertex? Well ... it's the thing identified by a vertex ID, of course! Jeff At 01:26 PM 01/03/2001 -0800, Les Ginsberg wrote: >I admit that I don't have any clever name for the "7 byte thingie", but I do >think it would be VERY BAD if we picked anything that suggested that the "7 >byte thingie" was in any way an identifier for the system since a system may >have a lot of "7 byte thingies" which belong to it. > >The first six bytes serve very well as a System ID thank you. The 7th byte >is officially the "pseudonodeID" according to 10589. It is sometimes also >thought of as a local circuit ID, though in reality that description does >not align with actual implementations. In any event it is definitely not >some sort of system thing and I am afraid that all of Jeff's suggestions >imply that in some way - at least to me. > >In the absence of something clever, I can live with "System ID Length + 1" > > Les > > >> What I think you are asking for is agrement >> that System ID has length 6, and a term >> that we could define to be the 7 byte quantity above. >> Something like "Virtual System ID", but without >> all the baggage Virtual suggests. Using Pseudo in >> the name is also bad, as it would suggest that it >> does not apply to real router IDs. Some suggestions >> >> System Descriptor >> OSI Router ID >> Universal Name (Universal Identifier?) >> Vertex Identifier (Vertex Name? Universal Vertex Name?) >> Universal Forwarding OID (UFO) >> ... >> >> Then we could talk about the "System Descriptor length" >> rather than having to say "System ID Length + 1". >> >> - jeff parker >> >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jparker@axiowave.com Wed Jan 3 22:11:50 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 3 Jan 2001 17:11:50 -0500 Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs Message-ID: > >it would be VERY BAD if we suggested that the "7 > >byte thingie" was an identifier for the system > > > >The 7th byte is officially the "pseudonodeID" > > > > Les > That's why "vertex ID" is so appealing. What the heck is a vertex? > Well ... it's the thing identified by a vertex ID, of course! > > Jeff I confess that "Vertex ID" is my favorite of the bunch. After all, it is a valid vertex in the SPF calculation. - jdp From prz@net4u.ch Thu Jan 4 07:45:26 2001 From: prz@net4u.ch (Tony Przygienda) Date: Thu, 4 Jan 2001 08:45:26 +0100 (MET) Subject: [Isis-wg] 2 more last calls ... Message-ID: <200101040745.IAA31114@net4u.net4u.ch> 1. I kind of lost track what happened exactly to the three-way handshake so I wanted to make a last call for it again. Deployed and working. 2. Optional checksums goes last call, no comments since a while, implementation works from all I heard. 3. Ran will resubmit HMAC and we'll put it into last call then. Deployed. Ran, a small historical note about the format withouth the key ID in the RFC would be helpfull unless you put it in already. thanks much. 4. Didn't hear much from the authors but looks like TE extensions are ready for last call after the last comment from Jeff. Deployed and we have more and more drafts keying of it. Last calls end in 2 weeks thanks --- tony From mshand@cisco.com Thu Jan 4 11:07:47 2001 From: mshand@cisco.com (Mike Shand) Date: Thu, 04 Jan 2001 11:07:47 +0000 Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs In-Reply-To: <200101031929.OAA14069@bcn.East.Sun.COM> Message-ID: <4.3.2.7.2.20010104105719.00a88b40@jaws.cisco.com> At 14:29 03/01/2001 -0500, Radia Perlman - Boston Center for Networking wrote: >Re: Jeff's reply assuming I was suggesting a less awkward word >for the 7-byte quantity. > >Actually, in my note I was talking about how the system ID specified >in DECnet Phase V as 6 bytes got changed >by ISO to be variable length, with a kludge field >in the hellos and maybe also LSPs to indicate what "ID length" was, >and so everything in the spec that specified a system ID had to say it was >"ID length" rather than 6 bytes. Everyone in the domain has >to have the same value for ID length or you refuse to talk. >Completely unnecessary flexibility I always thought. Along with >the "max area addresses", which was the constant 3 in DECnet, >and got changed by ISO >to be variable, along with a similar field in >hellos stating your value of "max area addresses". Aside >from both of these things just being unnecessary complexity, it >violated something I'd always strived for which was making >parameters changable node by node in a running net. Like >the hello interval is. So I was hoping that someone would at >some point get rid of both those parameters and fix >ID length at 6, and max area addresses at 3, and get rid >of all the verbiage and fields for specifying otherwise. Otherwise, >to fit with the way the IS-IS spec is currently written, the line >"7 octets of system Id and pseudonode number" would have to >be changed to "ID length+1 octets of system Id and pseudonode number" Yes, its a shame we had to let that get changed, but there was very strong pressure to do it at the time, and it was only by compromising there that we could get the spec to make progress at all. At least it was done in a way that didn't damage the original design too much. Its interesting to note that despite all the vocal "requirements" for this "flexibility" nobody has ever made use of it (to my knowledge). >But even though it wasn't what my note was about, >your suggestion of coming up with a word for the 7-byte thing >is good. The one I like the best of your proposals >is "vertex identifier", or perhaps "node identifier". >I agree with you that "virtual" and >"pseudo" have confusing connotations. "System descriptor" I'd >think would include what version OS it was running, what type >hardware it was, etc. "Universal name" sounds like a URN and >might be confusing. I've never been able to get too >enthusiastic about coming up with names for >things. I couldn't think of a good name for what >wound up being called "adjacency". I'm pretty sure it was Mike >Shand who thought up that one, and I really like it, so maybe >he can think of a good word for the 7 (err. ID length+1) byte thingie, >though we've lived without it OK >for 15 years or so. I'm afraid it wasn't me. I always thought it was you! According to the revision history of the DECnet PhaseIV spec, the term "adjacency" was introduced then " The concept of lines became two concepts - circuits and adjacencies". So that was before my time. As for the 7 byte thingy. I agree that giving everything a name isn't necessarily necessary. In my mind this "thingy" is always a system ID + a pseudonode identifier. I guess vertex ID is the closest we can come to something meaningful. Mike >Radia > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From iduncan@nortelnetworks.com Tue Jan 9 19:16:18 2001 From: iduncan@nortelnetworks.com (Ian Duncan) Date: Tue, 09 Jan 2001 14:16:18 -0500 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012292003.VAA05987@net4u.net4u.ch> Message-ID: <3A5B6382.EA6741F6@nortelnetworks.com> Tony Przygienda wrote: > > > > > > > > > Given the current run-to-completion operating system > > > schedulers that we all > > > seem to use, you basically have two choices: either try to run to > > > completion with MUCH tighter timers throughout the ENTIRE > > > operating system > > > or convert to a pre-emptive scheduling mechanism. Both are > > > fraught with > > > risk. > > > > > > > If implementation of "very tight timers" is a real big issue (and I'll > > gladly take your word for that), how does this relate to protocols like LMP? > > This relies on timers in the milli-second range, which is hard, if not > > impossible if I understand correctly. Would these protocols (FLIP is the > > other I believe) require a complete re-do of the router OS, or can they > > implemented in another way. > > this is a very deep question to which a simplistic answer is "depends on > the layer". Analogy: it is hard to handle interrupts in unix user space, > not so hard in well-written kernel drivers. Therefore certain protocols, especially > those very close to hardware (e.g. BLSR ;-) can run in a very fine resolution. Sorry for the long delay, I was in another meta timezone for the past few weeks ... In the case of FLIP this isn't truly a deep question as thought/effort was put to make it relatively unheroic to implement. The adjacency and the "hello" messages are easily distinguished in a router "fast path" and the "hello" is designed to be simple to turn around either in hardware or low level software, i.e. in fastpath micro-code or a kernel interrupt handler. By delegating robust fast failure detection to FLIP I believe we can avoid much messing about with existing routing code. We'd also provide for two or more higher level protocols to have fast detection over the same adjacency without duplicating work, e.g. ISIS and LDP. /id From sudheer@nayna.com Wed Jan 10 20:00:19 2001 From: sudheer@nayna.com (Sudheer Dharanikota) Date: Wed, 10 Jan 2001 12:00:19 -0800 Subject: [Isis-wg] San Diego Minutes? Message-ID: <3A5CBF53.7090406@nayna.com> Has the minutes for the previous IETF sent on the mailing list? Could someone repost/post them please. - sudheer From prz@net4u.ch Wed Jan 10 20:34:07 2001 From: prz@net4u.ch (Tony Przygienda) Date: Wed, 10 Jan 2001 21:34:07 +0100 (MET) Subject: [Isis-wg] San Diego Minutes? In-Reply-To: <3A5CBF53.7090406@nayna.com> from Sudheer Dharanikota at "Jan 10, 2001 12: 0:19 pm" Message-ID: <200101102034.VAA00521@net4u.net4u.ch> > Has the minutes for the previous IETF sent on the > mailing list? Could someone repost/post them please. > > - sudheer Alex promised them to me week or more ago. Still nothing to be seen ;-) -- tony From cast@allegronetworks.com Wed Jan 10 22:40:41 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Wed, 10 Jan 2001 14:40:41 -0800 Subject: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics Message-ID: In reviewing the ISIS TE draft, I'm wondering how to mix wide (TE draft) and narrow (original) links and routes. One way to build a migration path would be to run two SPF computations, once on each metric space (using only "narrow" or "wide" metrics in each run). This method has the disadvantage that during migration wildly suboptimal routes can occur, because during migration computations only use a subset of the links. Other options include administrative control. For example: New routers compute using both "old" and/or "new" metrics. New routers can have paths composed of links with old and new metrics in it. Start: . all old routers, only reporting old metric . one by one change to new routers, also reporting only old metrics. . When all routers are "new", reconfigure each router so it repots only new metrics on each of its links. This method has disadvantages, including that the administrator needs to be extremely careful with the router versions and that routes can also be suboptimal. I don't think either of these are great solutions. Perhaps someone would like to suggest others. But at any rate, it seems that how to compute hop by hop routes needs to be specified as a part of the TE document. --Neal P.S. Sorry if this gets duplicated. From Radia Perlman - Boston Center for Networking Thu Jan 11 17:46:43 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Thu, 11 Jan 2001 12:46:43 -0500 (EST) Subject: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics Message-ID: <200101111746.MAA14080@bcn.East.Sun.COM> Good point Neal. What are routers supposed to do in a mixture of old metrics and new metrics? If different implementations do different things (for instance, some ignore one metric or the other and compute only according to one while others perhaps happily compute a path consisting of a mixture of metrics), then you can have routing loops. So it seems like the most important thing is to ensure they're doing something consistent, even when you're mixing in old routers that will be ignoring the new TLV, and the next most important thing is to optimize the consistent thing so routes are reasonable when there's a mixture of old routers and new routers. A refinement perhaps on Neal's 2nd strategy 1) start with all old routers 2) one-by-one upgrade to "new.1" routers (routers that understand the new metric, and report it, but continue to report the old metric, and compute paths according to the old metric. And both metrics have to be equal (top n-6 bits of new metric = 0) 3) one by one upgrade to "new.2" routers (still report both metrics, compute paths according to new metrics) 4) one by one upgrade to "new.3" routers that stop reporting old metric. At this point the two metrics no longer need to agree since nobody's looking at the old metric, so you get the full power of the new metric. Then I suppose there's just making a rule that you'll never mix old and new routers in an area, but that seems somewhat dangerous. Maybe not horribly dangerous if routers never report both old and new metrics, and only look at one or the other, so they wouldn't wind up actually computing paths through each other. I guess that's a clarification of the strategy Neal wrote as the first strategy? Radia From sprevidi@cisco.com Thu Jan 11 17:34:49 2001 From: sprevidi@cisco.com (stefano previdi) Date: Thu, 11 Jan 2001 18:34:49 +0100 Subject: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics In-Reply-To: Message-ID: <4.3.2.7.2.20010111101454.00b40380@brussels.cisco.com> At 23:40 10/01/2001, Neal Castagnoli wrote: >In reviewing the ISIS TE draft, I'm wondering how to mix wide (TE draft) and >narrow (original) links and routes. > >One way to build a migration path would be to run two SPF computations, once >on each metric space (using only "narrow" or "wide" metrics in each run). >This method has the disadvantage that during migration wildly suboptimal >routes can occur, because during migration computations only use a subset of >the links. > >Other options include administrative control. For example: > >New routers compute using both "old" and/or "new" metrics. New routers can >have paths composed of links with old and new metrics in it. > >Start: > . all old routers, only reporting old metric > . one by one change to new routers, also reporting only old metrics. I would suggest: "New routers report BOTH old and new metric" (using same value of course). > . When all routers are "new", reconfigure each router so it repots only >new metrics on each of its links. > >This method has disadvantages, including that the administrator needs to be >extremely careful with the router versions and that routes can also be >suboptimal. New routers should report adjacencies and IP prefixes in both TLVs (narrow and wide) and the metric value must be the same. Then, whatever is the TLV you use for your SPF, you'll get consistent SPTs. New routers will be able to consider both old and new metric but this doesn't hurt SPF as long as the metric value is the same. s. >I don't think either of these are great solutions. Perhaps someone would >like to suggest others. But at any rate, it seems that how to compute hop >by hop routes needs to be specified as a part of the TE document. > > --Neal > >P.S. Sorry if this gets duplicated. >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From prz@net4u.ch Thu Jan 11 20:58:42 2001 From: prz@net4u.ch (Tony Przygienda) Date: Thu, 11 Jan 2001 21:58:42 +0100 (MET) Subject: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics In-Reply-To: <200101111746.MAA14080@bcn.East.Sun.COM> from Radia Perlman - Boston Center for Networking at "Jan 11, 2001 12:46:43 pm" Message-ID: <200101112058.VAA28050@net4u.net4u.ch> > Good point Neal. What are routers supposed to do in a mixture of > old metrics and new metrics? If different implementations do > different things (for instance, some ignore one metric or the > other and compute only according to one while others perhaps > happily compute a path consisting of a mixture of metrics), then > you can have routing loops. So it seems like the most important > thing is to ensure they're doing something consistent, even > when you're mixing in old routers that will be ignoring the new TLV, > and the next most important thing is to optimize the consistent > thing so routes are reasonable when there's a mixture of old > routers and new routers. > > A refinement perhaps on Neal's 2nd strategy > 1) start with all old routers > 2) one-by-one upgrade to "new.1" routers (routers that understand the > new metric, and report it, but continue to report the old > metric, and compute paths according to the old metric. And both > metrics have to be equal (top n-6 bits of new metric = 0) > 3) one by one upgrade to "new.2" routers (still report both > metrics, compute paths according to new metrics) > 4) one by one upgrade to "new.3" routers that stop reporting > old metric. At this point the two metrics no longer need to > agree since nobody's looking at the old metric, so you > get the full power of the new metric. > > Then I suppose there's just making a rule that you'll never mix old > and new routers in an area, but that seems somewhat dangerous. Maybe > not horribly dangerous if routers never report both old and new metrics, > and only look at one or the other, so they wouldn't wind up actually > computing paths through each other. I guess that's a clarification of > the strategy Neal wrote as the first strategy? a strict mathematical demise of the problem (it's not for the faint of heart looking for a quick fix) that also presents a necessary and sufficient algorithm to route loop-free in a mixed scenario has been presented in an infocom'99 paper by Khotimsky et al., "Hop by Hope Routing in Networks with Overlaid Routing Domains". Simplest solution is not to mix old & new style routers in an area though. thanks -- tony From Radia Perlman - Boston Center for Networking Thu Jan 11 22:49:27 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Thu, 11 Jan 2001 17:49:27 -0500 (EST) Subject: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics Message-ID: <200101112249.RAA15552@bcn.East.Sun.COM> From: Tony Przygienda a strict mathematical demise of the problem (it's not for the faint of heart looking for a quick fix) that also presents a necessary and sufficient algorithm to route loop-free in a mixed scenario has been presented in an infocom'99 paper by Khotimsky et al., "Hop by Hope Routing in Networks with Overlaid Routing Domains". Tony, do you have a URL for the paper? But better...can you describe the algorithm? I haven't seen this paper, but I've seen incomprehensible papers, that often get by all the reviewers because they're embarrassed to say they didn't understand it. If the paper is too hard to understand, or the algorithm is too complicated to explain in a fairly short email message, I'd have doubts about whether it could work. Maybe even the algorithm would theoretically work, but if implementers can't understand it, then it's unlikely it can be implemented correctly. Of course it's simpler not to mix old and new, and even simpler to have had wide enough metrics in the first place (that's my fault). But is that really realistic? I suppose if there's no mixing strategy that allows using wider metrics while there are still old routers around, then I guess it's really not much better than just saying you have to wait until all your routers are capable of handling the wide metric, and then doing a flag day. Radia From amir@cwnt.com Thu Jan 11 21:14:43 2001 From: amir@cwnt.com (Amir H.) Date: Thu, 11 Jan 2001 21:14:43 -0000 Subject: [Isis-wg] New Internet-Draft Message-ID: <00d801c07c13$844d5fa0$2c00a8c0@amir> This is a multi-part message in MIME format. ------=_NextPart_000_00D5_01C07C13.84336F00 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Members and Chairpersons of the IS-IS for IP Internets Working Group, My name is Amir Hermelin, and I would like to submit this draft to the list for review. Please take a moment to examine it, and reply with your thoughts. Editorial comments should be sent to me, please. General comments to the list. Thanks, Amir Hermelin mailto:amir@cwnt.com Charlotte's Networks LTD. http://www.cwnt.com Abstract This document describes a mechanism to allow a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. The document describes behaviors that are backwards compatible with implementations that do not support this feature. These behaviors are specified in a way that allows previous implementations to correctly process the extended fragment information. ------=_NextPart_000_00D5_01C07C13.84336F00 Content-Type: text/plain; name="draft-hermelin-ext-lsp-frags-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-hermelin-ext-lsp-frags-00.txt" Network Working Group Amir Hermelin Internet Draft Charlotte Networks, Inc. Expiration Date: July 2001 Extending the Number of LSP Fragments Beyond the 256 Limit draft-hermelin-ext-lsp-frags-00.txt Status 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. Abstract This document describes a mechanism to allow a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. The document describes behaviors that are backwards compatible with implementations that do not support this feature. These behaviors are specified in a way that allows previous implementations to correctly process the extended fragment information. A. Hermelin Expires July 2001 [Page 1] =0C Internet Draft draft-hermelin-ext-lsp-frags-00.txt January 2001 1. Introduction In the IS-IS protocol, a system floods its link-state information in Link State Protocol Data Units, or LSPs for short. These logical LSPs can become quite large, therefore the protocol specifies a means of fragmenting this information into multiple LSP fragments. The number of fragments a system can generate is limited by ISO 10589 [1] to 256 fragments, where each fragment's size is also limited. Hence, there is a limit on the amount of link-state information a system can generate. A number of factors can contribute to exceeding this limit: - Introduction of new TLVs and sub-TLVs to be included in LSPs. - The use of LSPs to propagate various types of information (such as traffic-engineering information). - The growing size of route tables and AS topologies. This document describes a mechanism to relax the limit on the number of LSP fragments, while providing behavior that would allow previous implementations to correctly process fragments exceeding this limit. 1.1 Definitions of Commonly Used Terms This section provides definitions for terms that are used throughout the text. Originating System A router running the IS-IS protocol. Original system-id The system-id of an originating system. Extended system-id An additional system-id that is assigned by the network administrator. Each extended system-id allows generation of 256 additional, or extended, LSP fragments. The extended system-id, like the original system-id, must be unique throughout the routing domain. Virtual System The system, identified by an extended system-id, advertised as originating the extended LSP fragments. These fragments specify the extended system-id in their LSP IDs. Original LSP An LSP using the original system-id in its LSP ID. A. Hermelin Expires July 2001 [Page 2] =0C Internet Draft draft-hermelin-ext-lsp-frags-00.txt January 2001 Extended LSP An LSP using an extended system-id in its LSP ID. LSP set A group of LSP fragments constituting a logical LSP. These share a specific system-id and pseudonode number, and differ only in their LSP (or fragment) Number. Extended LSP set A group of LSP fragments using an extended system-id, and originated by the originating system. These fragments appear to other routers as having been originated by the virtual system identified by an extended system-id. 1.2 Overview Using additional unique system-ids assigned to the originating system, that system can advertise the excess link-state information in extended LSPs under these extended system-ids. It would do so as if other routers, or "virtual systems", were advertising this information. These extended LSPs will also have the specified limit on their LSP fragments; however, the originating system may generate extended LSPs under numerous virtual systems. The originating system will not advertise its extended system-ids to any of its neighbors; it will always use its original system-id in IS Hellos [3] and IS-IS Hellos. The originating system must include connectivity information in its original LSPs (the LSPs with the original system-id in their LSP ID) to all virtual systems for which extended LSPs are generated by it. This is to ensure other routers correctly process the extra information in their SPF calculation. The metric for these connections should be zero, since the cost of reaching a virtual system is the same as the cost of reaching its originating system. To other routers, virtual systems would appear reachable only through their originating system, hence loss of connectivity to the originating system means loss of connectivity to all of its information, including that advertised in its extended LSPs. Furthermore, the cost of reaching information advertised in non- extended LSPs would be the same as the cost of reaching information advertised in the new extended LSPs, with an additional hop. A. Hermelin Expires July 2001 [Page 3] =0C Internet Draft draft-hermelin-ext-lsp-frags-00.txt January 2001 +---------------------------------------------+ | Originating System | | system-id =3D S | | ( extended system-ids =3D S', S'' ) | +---------------------------------------------+ | /\ | /\ cost=3D0 | |cost=3Dmax cost=3D0 | |cost=3Dmax | | | | \/ | \/ | +------------------+ +------------------+ | Virtual System | | Virtual System | | system-id =3D S' | | system-id =3D S'' | +------------------+ +------------------+ Figure 1. Advertising connections to virtual systems The generation of extended LSPs is discussed in section 2. Not all link-state information that can be advertised in the original LSPs can be advertised in extended LSPs; this is discussed in further detail in section 3. However, most "leaf" information, i.e. information that serves only as leaves in a shortest path tree, can be advertised in extended LSPs. Other routers would behave the same as if that information was advertised in the original LSPs, with a few minor exceptions noted in section 5. Extended LSPs can be purged, in the same manner as original LSPs. This is discussed in section 4. 2. Generating Extended LSP Fragments When new extended LSP fragments are generated, these fragments should be generated as specified in ISO 10589 [1]. Furthermore, a system will treat its extended LSPs the same as it would treat its original LSPs, with the exceptions noted in section 3. Specifically, creating, flooding, renewing, purging and all other operations will be similar to both original and extended LSPs, unless stated otherwise. The extended LSPs will use one of the extended system-ids configured for the router, in their LSP ID. An extended LSP Number zero should be generated for every extended LSP set, to allow a router's SPF calculation to consider those fragments in that set. Additionally, when an extended LSP belonging to extended system-id S' is first created, the original LSP must specify S' as a neighbor, with metric set to zero. This is to ensure other routers will consider the extended LSP in their SPF A. Hermelin Expires July 2001 [Page 4] =0C Internet Draft draft-hermelin-ext-lsp-frags-00.txt January 2001 calculations, as well as consider the cost of reaching the virtual system S' the same as the cost of reaching the originating system. Note, that the restriction specified in ISO 10589 section 7.2.5 holds: if an LSP Number zero of the originating system is not present, none of that system's neighbor entries would be processed during SPF, hence none of its extended LSPs would be processed as well. Extended LSPs with number zero will be regarded in the same special manner as specified in 10589, and will include the same type of extra information as specified in 10589 and RFC 1195 [2]. So, for example, when a system reissues its LSP Number zero due to an area address change, it should reissue all extended LSPs with number zero as well. 3. Exceptions when Encoding Extended LSP Fragments 3.1 The LSP Header The LSP header of an extended LSP fragment should include the same settings as for non-extended LSP fragments with the exceptions noted below: 3.1.1 The Pseudonode ID The Pseudonode ID, which is part of the LSP ID, should be set to zero on all extended LSP fragments. 3.1.2 The Attached Bits The Attached (ATT) bits should be set to zero for all four metric types, on all extended LSPs. This is for two main reasons: - If a virtual system is reachable, so is its originating system. It is preferable, then, that an L1 IS chooses the originating system and not the virtual system as its nearest L2 exit point, as connectivity to the virtual system has a higher probability of being lost (a result of the extended LSP being no longer advertised). This could cause unnecessary processing on some implementations. - Some implementations which support weighted ECMP, might set Equal Cost Multipath weights according to how many ISs can be reached via each path. So, for example, if there are two nearest L2 ISs to a particular L1-only system, each reachable via different interfaces, and one is generating extended LSPs, then the L1 system might forward more traffic towards that destination (i.e. give it a stronger weight), as it would think it is forwarding traffic to two L2 ISs. A. Hermelin Expires July 2001 [Page 5] =0C Internet Draft draft-hermelin-ext-lsp-frags-00.txt January 2001 3.1.3 The Partition Repair Bit The Partition Repair (P) bit should be set to zero on all extended LSPs. This is for the same reasons as for the Attached bits. 3.2 TLVs Extended LSPs can contain any TLVs that non-extended LSPs can contain, with the exceptions noted below. Basically, these exceptions apply to "non-leaf" TLVs, i.e. those TLVs that don't serve only as leaves in a shortest path tree. 3.2.1 IS Neighbors TLV An Extended LSP must specify only the originating system as a neighbor, with the metric set to MaxLinkMetric. No other neighbors may be specified in an Extended LSP, as this would not satisfy the bi-directionality check in the SPF calculation. Where relevant, this adjacency should be considered as point-to-point. 3.2.2 ES Neighbors TLV ISO 10589 [1] specifies that an ES Neighbor TLV with the router's system-id be inserted in its LSPs. This is not required of IP-only routers, according to RFC 1195 [2]. However, on systems that do generate these TLVs, these should also be generated in an extended LSP belonging to virtual system-id S', with S' as the end system address. Furthermore, OSI-capable routers should accept packets destined for S'. 4. Purging Extended LSP Fragments ISO 10589 [1] section 7.3.4.4 note 21 suggests that an implementation keeps the number of LSP fragments within a certain limit based on the optimal (minimal) number of fragments needed. Section 7.3.4.6 also recommends that an IS purge its empty LSPs to conserve resources. These recommendations hold for the extended LSP fragments as well. However, an extended LSP Number zero should not be purged until all of the fragments in its set (i.e. belonging to a particular virtual system-id), are empty as well. This is to ensure implementations consider the fragments in their SPF calculations, as specified in section 7.2.5. A. Hermelin Expires July 2001 [Page 6] =0C Internet Draft draft-hermelin-ext-lsp-frags-00.txt January 2001 When all the extended LSP fragments of a particular extended system- id S' have been purged, the originating system should remove the adjacency information to S' from its original LSPs. 5. Compatibility Issues Previous implementations will interpret TLVs in extended LSPs in the same manner that they interpret TLVs in original LSPs, due to the zero metric adjacencies between the originating system and its virtual systems. However, applications that take the hop count into consideration, will misinterpret the destinations appearing in extended LSPs as being one hop further than they really are. This is due to the extra neighbor hop needed to reach these LSPs. There are two solutions to this problem: - Add extra information to specify that an adjacency should not be considered for any purpose of hop counting. - Restrict information that might be subject to hop counting, such as traffic engineering information, to appear only in the original LSPs. These restrictions should be applied with care, as too many of them could re-introduce the problem of limited LSP fragments. 6. Security Considerations This document raises no new security issues for IS-IS. 7. Acknowledgments The author would like to thank Tony Li, Radia Perlman, and Mike Shand for helpful ideas and suggestions on the subject. 8. References [1] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)" [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 [3] ISO 9542, "End System to Intermediate System Routeing Exchange Protocol for Use in Conjunction with the Protocol for Providing the A. Hermelin Expires July 2001 [Page 7] =0C Internet Draft draft-hermelin-ext-lsp-frags-00.txt January 2001 Connectionless-Mode Network Service (ISO 8473)", March 1988 9. Author's Address Amir Hermelin Charlotte Networks, Inc. 2 Hamada St. Yokneam, 26000 ISRAEL Email: amir@cwnt.com Phone: +972 4 8239207 Fax: +972 4 9593325 A. Hermelin Expires July 2001 [Page 8] =0C ------=_NextPart_000_00D5_01C07C13.84336F00-- From prz@net4u.ch Fri Jan 12 21:44:38 2001 From: prz@net4u.ch (Tony Przygienda) Date: Fri, 12 Jan 2001 22:44:38 +0100 (MET) Subject: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics In-Reply-To: <200101112249.RAA15552@bcn.East.Sun.COM> from Radia Perlman - Boston Center for Networking at "Jan 11, 2001 5:49:27 pm" Message-ID: <200101122144.WAA21995@net4u.net4u.ch> > > From: Tony Przygienda > > a strict mathematical demise of the problem (it's not for the faint of > heart looking for a quick fix) that also presents a necessary > and sufficient algorithm to route loop-free in a mixed scenario has been > presented in an infocom'99 paper by Khotimsky et al., "Hop by Hope > Routing > in Networks with Overlaid Routing Domains". I fear the paper is copyright infocom so you have to go through them. Otherwise mail Dr. Khotimsky for a copy: dkhotimsky@lucent.com and dkhotimsky@dnrc.bell-labs.com could work as well. I don't have the newest version handy. > Tony, do you have a URL for the paper? But better...can you describe > the algorithm? I haven't seen this paper, but I've seen incomprehensible > papers, that often get by all the reviewers because they're embarrassed > to say they didn't understand it. If the paper is too hard to understand, > or the algorithm is too complicated to explain in a fairly short > email message, I'd have doubts about whether it could work. Maybe even > the algorithm would theoretically work, but if implementers can't > understand it, then it's unlikely it can be implemented correctly. I remember the algorithm was a layered Dijkstra and 1) it assumes that if you're TE, you advertise TE and short-metric always and they're both equal. Short-metricc is infinity if you blow 63. 2) you start by computing first Dijkstra using TE links only. Then you run another Dijkstra using TE destinations you found and graft short-only links onto them to find possible destinations that can be only reached by first crossing TE links and then short links. You NEVER cross TE links, then short links, then TE links again because that's not loop-free. That all is generalized and can be used for many other things beside the TE/short problem and is proven to be loop-free and this condition is necessary and sufficient for that. The really cute thing is that the optimal paths to destinations do NOT form a tree anymore albeit in every topology Bellman's sub-optimality principle holds. Perplexing to me and worth a look by someone looking for a thesis topic ;-) 3) there is another approachn that Henk & Naiming did for LSP shortcuts. It's in an expired draft. I think what they did could be genearlized for the TE/short mix problem but it's just a feeling. Don't take my words 100% here, it's a while I worked on that stuff and its implemetation. As well, stuff may have IP claims tied to it. Again, my feeling is that before you implemented and deployed a solution for the TE/short porblem, the problem won't exist so easiest is migrate area by area ;-) -- tony From prz@net4u.ch Sat Jan 13 00:24:09 2001 From: prz@net4u.ch (Tony Przygienda) Date: Sat, 13 Jan 2001 01:24:09 +0100 (MET) Subject: [Isis-wg] Meeting minutes ... Message-ID: <200101130024.BAA24064@net4u.net4u.ch> Many kudos to Alex for a great job scribbling them down in the heat of the moment. -- tony TP informed the WG about upcoming last calls and gave short overview of ongoing works: o IPv6 extensions: there were no objections, last call to follow o 3-Way and more drafts that have implementation experience and have been deployed will go last call ISO Ballot: o Ballot authors were "no show". o requirements are expected from IETF o the ISO document should be published as an RFC, volunteers are sought. None materialized. Senthil presented his slides on ISIS extensions for inter-area TE LSP setup. The idea is to summarize TE information (as a min/max couple) and flood it to L1 areas in order to give head-end LSRs more info on available resources and decrease the number of signaling cranck-backs. Jim: How does min/max announcement address colors? S: For each network, there're multiple TE attributes, including colors and BW. The results depend on how much summarization is done. It is configurable on per-color/per-BW basis. Q: What about BW encoding? Bytes per sec does not scale up to OC-48 S: Agree TP: Need to agree on a format, point taken S: Good point Radia: Fixing this is one thing. Metrics do not help all the time, dynamism in BW advertisement... Sadheer: Depends on the service in the network, Granularity will vary per configuration. Curtis: I though the format was floating point. Some discussion about the floating point format occurred. Rough consensus was that floating point will allow to represent up to 10^128, which is more than enough. Curtis: there may be a way to deal with colors TP: Kireeti's draft should help C : Combinatorial explosion of color advertisements is a bit scary. Color-based summarization should have limited support George: Colors can be used as binary "AND" or "OR". Considering all possible combinations, it would be too much to announce. No use to summarize the colors. ?: Do you have any estimation on the number of TLVs announced as a result of TE summarization? S: Depends on how many networks are in the domain and how you summarize. ?: Dijkstra is the one to be simplified, so the number of links should be decreased. Alex: As mentioned at the TE WG meeting, it would be really nice to have some simulation results. Summarization may do harm to signaling---increase the number of cranckbacks or just be as good as randomly selecting the first ABR. Motion was made to make the draft a workgroup item and after short discussion in which multiple people including George Swallow observed that there was NO decision from MPLS to work on that issue, even less an agreement on what kind of approach should be taken, dismissed. Alex presented draft-ietf-ospf-isis-flood-opt-00.txt proposing some flooding optimizations for the case where neighboring nodes are connected with multiple parallel links. TP: The draft covers both ISIS & OSPF. John is going to present a counter-proposal for OSPF at the OSPF WG meeting. As for the ISIS part, we need implementation experience first. AZ: Agreed. Alex has asked a while ago to make flooding optimizations workgroup draft and it was agreed to given implementation experience. Depending how the work develops, especially in the light of similar effort going on in OSPF group, we may see or not see a submission. Don presented draft-fedyk-isis-ospf-te-metrics-01.txt effectively describing different metric types and proposing container TLVs for additional TE metrics. Don presented this draft in Washington, DC and was asked to demonstrate customer support. Enke: Is this a real problem or theoretical? ISIS has multiple metrics already Don: Metrics we propose are used for MPLS TE extensions. Different purpose. Multiple speakers indicated it would be a good idea to assign semantics to the metrics. Don suggested firming the definition of metrics, TP indicated units would be necessary. Metric started to mutate in its meaning on the fly during the discussion. Dave Oran: routers need to agree on the semantics Curtis: They do in hop-by-hop routing, but not in TE. Dave: Need to know what to do if these metrics are not understood. Curtis to Don: We already have SPs using metric as the link delay, why do we need another one? Don: It is another option. We do not specify what exactly these metrics are. Motion was made again to make it workgroup item and there was some argument back and forth about usability and necessity of these metrics and no decision has been made. Punted to ADs to look at the topic and come up with a decision. Footnote: OSPF workgroup ended up with pretty much the same result. Francois presented draft-lefaucheur-diff-te-isis-00.txt, proposing additions to ISIS TE extensions to help DiffServ-aware MPLS TE. Francois requested the draft is accepted as a WG item. Jim: Why use such encoding scheme F: to minimize impact on IGP, amount of flooding, BW overhead, may help in processing as well Kireeti to Jim: these are sub-TLVs of the Ext. Reachability TLV, it is useful to compress. K: Scope of priority per class-type? Answer unclear. F: Proposal to accept as a WG item Alex Mondrus: Should we wait for the TE WG to comment on the requirement document George: We should move further. Rough consensus was to accept the draft. TP: Will check with the other Tony but accepted until stated otherwise. Cengiz presented draft-alaettinoglu-ISIS-convergence-00.txt discussing the possibility for ISIS to improve convergence time to a subsecond level. Proposed techniques included subsecond Hello timers, incremental SPF, as well as fixing bugs affecting the flood behavior. The presentation initiated an active discussion. Alex: Not comfortable with too frequent Hellos. P2p links usually do not need this. In case of multi-access segments convergence is fast if there's a backdoor flooding path, otherwise, some smarter mechanisms could be used. IGP mechanisms should not substitute L2 ones. SPF: even without incremental SPF per se, some smarter SPF scheduling can be used. Cengiz: The point is to remove the Hello interval limitation from the IGPs, if some other mechanisms would help, then fine. VJ: Current definition of Hello intervals in IGPs is an unnecessary limitation. ? : In case of an FR cloud, SPs do not always support correct VC status announcement, so we need subsecond hellos here. Alex: Once implemented, we can't control where these hello are configured. As far as the FR example is concerned, ask the SP to fix the network, not router vendors to accept the problem. IGP should not perform L2 functions. Kireeti? : Regarding you incremental SPF modeling, did you use a single topo change or multiple. Multiple changes is where the complexity starts. C: We used a single change, but multiple is possible. K: Multiple changes is more realistic in a big network and this is a big network where we need incremental SPF. VJ: Incremental is at least as good as normal Dijkstra Alex: Was a real LSDB used in simulation of incremental SPF? Detecting which link has gone up or down is where incremental has more overhead than standard Dijkstra and may be more expensive when multiple topo changes are processed. Padma: Exponential delays for topology change announcement would be a good idea to decrease the impact of flapping interfaces. C: Up and Down interface transitions should be processed differently ?: Exponential for up, but not for the down even seems a good idea. ?: Was any traffic injected in the network while tests were done? C: No ?: In the real world, this would cause resource contention and would affect the results ?: Subsecond Hellos are dangerous, and may affect flooding, etc. TP: flooding complexity should be addressed via network partitioning (areas) Enke: It is trade-off btw stability and fast convergence. SPs care more about stability and even increase Hello interval for the sakes of it. C: The question is why there's instability. Different processing of Up and Down events should help. Enke: Also, SPF is not a concern. Jim: Full mesh topologies have different properties and may need to be addressed separately??? VJ: Some ISPs are using long timers for stability reasons. The theory says it is not necessary. We found that SPF complexity affects flooding behavior and fwd'ing functionality Alex: Regardless of how much time SPF takes, it does not affect fwd'ing and should not affect flooding. ?: One of the carriers built a huge flat fully-meshed wireless network and OSPF melted, even with normal intervals. TP: That's rather a deployment problem, pls read applicability statement of the protocol. The discussion was taken off-line. From cast@allegronetworks.com Wed Jan 10 22:30:08 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Wed, 10 Jan 2001 14:30:08 -0800 Subject: [Isis-wg] Computing routes with wide (TE Draft) metrics Message-ID: In reviewing the ISIS TE draft, I'm wondering how to mix wide (TE draft) and narrow (original) links and routes. One way to build a migration path would be to run two SPF computations, once on each metric space (using only "narrow" or "wide" metrics in each run). This method has the disadvantage that during migration wildly suboptimal routes can occur, because during migration computations only use a subset of the links. Other options include administrative control. For example: New routers compute using both "old" and/or "new" metrics. New routers can have paths composed of links with old and new metrics in it. Start: . all old routers, only reporting old metric . one by one change to new routers, also reporting only old metrics. . When all routers are "new", reconfigure each router so it repots only new metrics on each of its links. This method has disadvantages, including that the administrator needs to be extremely careful with the router versions and that routes can also be suboptimal. I don't think either of these are great solutions. Perhaps someone would like to suggest others. But at any rate, it seems like how to compute hop by hop routes needs to be specified as a part of the TE document. --Neal From amir@cwnt.com Tue Jan 16 16:57:06 2001 From: amir@cwnt.com (Amir H.) Date: Tue, 16 Jan 2001 16:57:06 -0000 Subject: [Isis-wg] draft-hermelin-ext-lsp-frags-00.txt References: <3A5F2DFD.5D858D87@tellabs.com> Message-ID: <008301c07fdd$5b7f6730$2c00a8c0@amir> Jonathan, the text implicitly prohibits the use of extended system-ids in pseudonode LSPs. The reason is that permitting this would introduce zero-cost loops, and this might upset some implementations. If the group decides using this mechanism to overcome the 255 DIS limitation is worth the added risk ( IMHO it is not ), I will add the text to support this. I'll explain: suppose system S has extended system-id V. In the current text, S never advertises V in its hellos, hence adjacencies will only be formed with S, not with V. This means (I will add this point to the text), that only S advertises an adjacency to V. So, the SPF will always run by S first and V later, hence the link from V to S can be advertised as non-zero, it doesn't really matter what the cost is. Now, if S advertises a pseudonode LSP under V, it needs to include this pseudonode-id in its LAN hellos on that LAN. It must also include V as the system ID on that LAN, to support previous implementations. So you'd have: a -- S.01 -- S V -- V.01 -- b (a and b are systems on the two LANs). So, since V can be reachable via systems other than S, you need a zero cost adjacency between S and V in BOTH directions - hence the zero-cost loop. -- Amir Hermelin mailto:amir@cwnt.com Charlotte Networks LTD. http://www.cwnt.com ----- Original Message ----- From: "Jonathan Sadler" To: Sent: Friday, January 12, 2001 4:17 PM Subject: Re: [Isis-wg] New Internet-Draft > Amir - > > Could the same form of extension be used to handle the limitation of 255 > L1 DIS interfaces per system? I realize that this is less likely to > occur than exceeding 256 fragments, but wording that supports this other > situation may be appropriate to add to your draft. > > Jonathan Sadler > From Radia Perlman - Boston Center for Networking Tue Jan 16 21:32:49 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Tue, 16 Jan 2001 16:32:49 -0500 (EST) Subject: [Isis-wg] draft-hermelin-ext-lsp-frags-00.txt Message-ID: <200101162132.QAA04373@bcn.East.Sun.COM> Draft seems very good. Re Jonathan's question...we don't need this mechanism for getting beyond the 255 adjacencies. I believe there was an email discussion on this about 2 years ago(?). The 255 adjacency limit is easier to fix, since all that matters for the pseudonode ID is that it be a 7-byte number unique in the area, so a router with ID x can general pseudonodes x.1 through x.255, but also can use ID y (provided nobody else in the area is using ID y) and x can claim adjacencies to y.1 through y.255. There's no reason for the first 6 bytes of the pseudonode ID to be the same as the DR's ID...it's just a convenient way of ensuring a unique 7-byte ID. Comment on section 3.2.1, yeah, the 2-way check would be a problem, but might it be necessary to have IS neighbors in the extended LSP if not all the neighbors fit into 255 fragments (like if you're on a multiaccess medium with thousands of IS neighbors, maybe)? Wasn't there talk at some point of doing away with the 2-way check? Is it useful? Is it more of a performance problem than its benefit warrants? Section 3.2.2...I'm sorry, but I read it several times and I don't understand that entire section. (But it's only 4 sentences, so clarifying it wouldn't be too time consuming). Are you saying ES Neighbors TLV can appear in an extended LSP or can NOT appear? And I don't understand "an ES neighbor TLV with the router's system-ID be inserted in its LSPs". Maybe I don't understand it because I don't know what "its" refers to. At any rate, this is probably only a CLNP thing, right? As for hop counting, I assume that's something totally internal to an implementation. At any rate, hop counting was never part of the design of the protocol. So, if it's just a heuristic that some implementations do for their own purposes, and it's not necessary for all routers to do the same...perhaps some words about how a zero-cost link should not count as a "hop" in any such calculation (presumably the same problem occurs with a pseudonode looking like an extra hop?). Radia From amir@cwnt.com Wed Jan 17 15:18:00 2001 From: amir@cwnt.com (Amir H.) Date: Wed, 17 Jan 2001 15:18:00 -0000 Subject: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics References: <4.3.2.7.2.20010111101454.00b40380@brussels.cisco.com> Message-ID: <029501c08098$ae146390$2c00a8c0@amir> > > New routers should report adjacencies and IP prefixes in both > TLVs (narrow and wide) and the metric value must be the same. > > Then, whatever is the TLV you use for your SPF, you'll get > consistent SPTs. New routers will be able to consider both > old and new metric but this doesn't hurt SPF as long as the > metric value is the same. > > s. > > >I don't think either of these are great solutions. Perhaps someone would > >like to suggest others. But at any rate, it seems that how to compute hop > >by hop routes needs to be specified as a part of the TE document. > > > > --Neal > > I agree with Stefano that the advertised metrics should be the same in both old and new-style TLVs; however, at least one dominant implementation doesn't always advertise it that way. In that case, Tony's mention of an algorithm that allows only paths that don't go from narrow to wide metrics (or "old" to "new" routers) would intuitively install only loop free routes. In any case, Neal has a good point that the TE document should mention this in a clear way. Specifically, the TE document should define: - What is advertised in case of a metric greater than 63 in transition mode (both metrics being advertised). - What should be the SPF procedure, in case corrective measures need to be taken? As Stefano pointed out, there is only need for special SPF in case some links differ in their narrow and wide metrics. There is also a problem if a link advertises only wide metrics, but that's more of a misconfiguration than a protocol problem. -- Amir Hermelin mailto:amir@cwnt.com Charlotte Networks Inc. http://www.cwnt.com From amir@cwnt.com Wed Jan 17 16:18:20 2001 From: amir@cwnt.com (Amir H.) Date: Wed, 17 Jan 2001 16:18:20 -0000 Subject: [Isis-wg] draft-hermelin-ext-lsp-frags-00.txt References: <200101162132.QAA04373@bcn.East.Sun.COM> Message-ID: <02ab01c080a1$286ce8d0$2c00a8c0@amir> > Draft seems very good. Thanks. > > Re Jonathan's question...we don't need this mechanism for getting > beyond the 255 adjacencies. I believe there was an email discussion > on this about 2 years ago(?). The 255 adjacency limit is easier to > fix, since all that matters for the pseudonode ID is that it be > a 7-byte number unique in the area, so a router with ID x can > general pseudonodes x.1 through x.255, but also can use ID y (provided > nobody else in the area is using ID y) and x can claim adjacencies > to y.1 through y.255. There's no reason for the first 6 bytes of > the pseudonode ID to be the same as the DR's ID...it's just a convenient > way of ensuring a unique 7-byte ID. I agree. > > Comment on section 3.2.1, yeah, the 2-way check would be a problem, > but might it be necessary to have IS neighbors in the extended LSP > if not all the neighbors fit into 255 fragments (like if you're on > a multiaccess medium with thousands of IS neighbors, maybe)? You'd actually need tens of thousands to overflow. I don't think any implementation would support that many anyway. > Wasn't there talk at some point of doing away with the 2-way check? Is it > useful? Is it more of a performance problem than its benefit warrants? Two of the main considerations here are: 1) To be backwards compatible. 2) To allow previous implementations to use the extended information. So, adjacencies should be specified only in the original LSPs for the second goal to be achieved. It is possible to form adjacencies with other systems using extended system-ids, and therefore advertise these adjacencies in extended LSPs. This would satisfy the 2-way check, but then a zero-cost adjacency in BOTH directions must be inserted between the original and extended LSP. And that might not achieve the first goal (zero-cost dijkstra loops). As for removing the 2-way check, IMHO it is useful, and I believe this was only discussed when advertising uni-directional links, such as FA-LSPs. > > Section 3.2.2...I'm sorry, but I read it several times and I don't > understand that entire section. (But it's only 4 sentences, so > clarifying it wouldn't be too time consuming). > Are you saying ES Neighbors TLV can appear in an > extended LSP or can NOT appear? And I don't understand "an ES > neighbor TLV with the router's system-ID be inserted in its LSPs". Maybe > I don't understand it because I don't know what "its" refers to. At > any rate, this is probably only a CLNP thing, right? Point taken. Bad wording on my part. 10589 section 7.3.7 specifies inserting an ESN TLV in L1 LSPs, with the system ID of the router. What I meant was that in extended LSPs the ESN should be generated using the extended system-id. I'll fix that paragraph. Anyway, you're right, this is only a CLNP thing. > > As for hop counting, I assume that's something totally internal to > an implementation. At any rate, hop counting was never part of the > design of the protocol. So, if it's just a heuristic that some > implementations do for their own purposes, and it's not necessary > for all routers to do the same...perhaps some words about how > a zero-cost link should not count as a "hop" in any such calculation > (presumably the same problem occurs with a pseudonode looking like > an extra hop?). No, I didn't mean anything implementation related, but rather applications (maybe future ones) external to the IS-IS protocol. For example, a TE application computing tunnels to a destination x, based on the shortest hop count. If x would be advertised in an extended LSP, that application might favor a different path to x because it would believe x is one hop farther, going through that LSP, than it really is. These applications should know not to count pseudonode links. They should also ignore the hop count on the adjacencies to extended LSPs. I just felt I should put in a word of warning. > > Radia > Thanks again. -- Amir Hermelin mailto:amir@cwnt.com Charlotte Networks Inc. http://www.cwnt.com From prz@net4u.ch Wed Jan 17 18:16:01 2001 From: prz@net4u.ch (Tony Przygienda) Date: Wed, 17 Jan 2001 19:16:01 +0100 (MET) Subject: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics In-Reply-To: <029501c08098$ae146390$2c00a8c0@amir> from "Amir H." at "Jan 17, 2001 3:18: 0 pm" Message-ID: <200101171816.TAA05457@net4u.net4u.ch> > > > > New routers should report adjacencies and IP prefixes in both > > TLVs (narrow and wide) and the metric value must be the same. > > > > Then, whatever is the TLV you use for your SPF, you'll get > > consistent SPTs. New routers will be able to consider both > > old and new metric but this doesn't hurt SPF as long as the > > metric value is the same. > > > > s. > > > > >I don't think either of these are great solutions. Perhaps someone would > > >like to suggest others. But at any rate, it seems that how to compute > hop > > >by hop routes needs to be specified as a part of the TE document. > > > > > > --Neal > > > > > > I agree with Stefano that the advertised metrics should be the same in both > old and new-style TLVs; however, at least one dominant implementation > doesn't always advertise it that way. my initial reaction would be they rather revisit and fix unless there is a reason to make mertics non-matching which I fail to see right now. > In any case, Neal has a good point that the TE document should mention this > in a clear way. Specifically, the TE document should define: > - What is advertised in case of a metric greater than 63 in transition mode > (both metrics being advertised). > - What should be the SPF procedure, in case corrective measures need to be > taken? As Stefano pointed out, there is only need for special SPF in case > some links differ in their narrow and wide metrics. There is also a problem > if a link advertises only wide metrics, but that's more of a > misconfiguration than a protocol problem. there is a distinction between a specification and deployment and transition issues so if you want that documented I'd rather think about another draft. TE draft will be pretty timeless (= ~5 years in Internet) whereas the migration issue if any will be a month's flavor. -- tony From amir@cwnt.com Thu Jan 18 14:39:02 2001 From: amir@cwnt.com (Amir H.) Date: Thu, 18 Jan 2001 14:39:02 -0000 Subject: [Isis-wg] Re: New Internet-Draft References: <00cf01c07c12$d610e1a0$2c00a8c0@amir> <3A5EAF01.EA33E840@redback.com> <3A5ED096.9D31AE28@home.net> <017201c07e1f$60166420$2c00a8c0@amir> <3A6698D6.46026042@home.net> Message-ID: <007a01c0815c$669f63b0$2c00a8c0@amir> Tony, I see your point. The way I see it there are two possibilities: 1. Either not advertise adjacencies in extended LSPs, and then we might run out of fragments in situations of numerous adjacencies with various information attached to them. 2. Change the text to allow advertisements of adjacencies in extended LSPs, but also insert a zero-cost adjacency between the original and its extended LSP in BOTH directions (something the first option can avoid). It was pointed out that some implementations might not behave well with these zero-cost dijkstra loops. I prefer the second option, but included only the first in the text, because backwards compatibility is IMHO an important issue here. If others can comment on the problems zero-cost loops might introduce, it would help. Thanks. -- Amir Hermelin mailto:amir@cwnt.com Charlotte Networks Inc. http://www.cwnt.com ----- Original Message ----- From: "Tony Li" To: "Amir H." Sent: Thursday, January 18, 2001 7:18 AM Subject: Re: New Internet-Draft > > Amir, > > This makes sense if you can guarantee that all adjacencies are advertised under > the original system ID. Isn't there an issue here if there are many TE > adjacencies, each of which is consuming a full TLV? Let's say you manage to put > 250 bytes per adjcency into the LSP. Then each fragment holds 6 adjacencies. > Seems like you still run out of fragments. > > Tony > > > "Amir H." wrote: > > > Tony, > > > > I hope I understood the problem correctly. This could indeed be a real > > problem, so the document suggests not using the extended system-ids for any > > hello advertisements. So, taking your example, C would never form an > > adjacency to V, only to B, and it would not know, in fact, that V and B are > > the same physical router. The only one advertising an adjacency to V would > > be B then ( I think I should mention that in the text - good point ). Hence, > > the SPF would run correctly. > > > > Thanks, > > Amir. > > > > -- > > Amir Hermelin mailto:amir@cwnt.com > > Charlotte's Networks LTD. http://www.cwnt.com > > > > ----- Original Message ----- > > From: "Tony Li" > > To: "Tony Przygienda" > > Cc: "Amir H." ; "Antoni Przygienda" > > Sent: Friday, January 12, 2001 9:38 AM > > Subject: Re: New Internet-Draft > > > > > > > > > > > I agree. Please proceed. > > > > > > I see one gotcha, I think. Please check this: > > > > > > I believe that you want a metric of zero, not max metric when going from > > the virtual > > > system back to the primary. Thought experiment: Suppose that we have > > routers A, B, C > > > and virtual router V off of B. Suppose that the topology is: > > > > > > A --- B --- C > > > > > > Suppose that C shows up as an adjacency for V. How does C SPF back to A? > > > > > > Tony > > > > > > > > > Tony Przygienda wrote: > > > > > > > "Amir H." wrote: > > > > > > > > > Abstract > > > > > > > > > > This document describes a mechanism to allow a system to originate > > > > > more than 256 LSP fragments, a limit set by the original > > Intermediate > > > > > System to Intermediate System (IS-IS) Routing protocol, as > > described > > > > > in ISO 10589. This mechanism can be used in IP-only, OSI-only, and > > > > > dual routers. > > > > > > > > gave it a quick look-over and > > > > looks good to me. If Tony's happy with it, we can make it actually a > > workgroup > > > > draft since it looks relevant and hacky enough ;-)) Seriously, yes, > > it's something > > > > we could run into and it's optional so it can't hurt to document it. > > > > > > > > -- tony > > > > > > > > > > From tli@Procket.com Fri Jan 19 06:59:17 2001 From: tli@Procket.com (Tony Li) Date: Thu, 18 Jan 2001 22:59:17 -0800 (PST) Subject: [Isis-wg] Re: New Internet-Draft In-Reply-To: <007a01c0815c$669f63b0$2c00a8c0@amir> References: <00cf01c07c12$d610e1a0$2c00a8c0@amir> <3A5EAF01.EA33E840@redback.com> <3A5ED096.9D31AE28@home.net> <017201c07e1f$60166420$2c00a8c0@amir> <3A6698D6.46026042@home.net> <007a01c0815c$669f63b0$2c00a8c0@amir> Message-ID: <14951.58821.205281.903582@alpha-tli.procket.com> | I see your point. The way I see it there are two possibilities: | 1. Either not advertise adjacencies in extended LSPs, and then we might run | out of fragments in situations of numerous adjacencies with various | information attached to them. I see this as not solving the issue that needs to be solved. If you're not putting adjacencies in those LSPs, then what are you putting there? I think we all know that loading them up with routes isn't exactly going to scale well. | 2. Change the text to allow advertisements of adjacencies in extended LSPs, | but also insert a zero-cost adjacency between the original and its extended | LSP in BOTH directions (something the first option can avoid). It was | pointed out that some implementations might not behave well with these | zero-cost dijkstra loops. | | I prefer the second option, but included only the first in the text, because | backwards compatibility is IMHO an important issue here. If others can | comment on the problems zero-cost loops might introduce, it would help. I would be very impressed to find such an implementation (that's not to say that there isn't one... ;-). To cause a loop within the SPF, the implemenation would have to be confused as to whether the extended LSP and its parent were still candidates or on the tree. Most implementations are quite explicit about this. Such an implementation is likely to fall over with even one zero cost adjacency, IMHO. I'm fairly sure that I can point to three implementations that won't have this problem. ;-) ;-) ;-) Tony From amir@cwnt.com Sun Jan 21 14:52:34 2001 From: amir@cwnt.com (Amir H.) Date: Sun, 21 Jan 2001 14:52:34 -0000 Subject: [Isis-wg] Re: New Internet-Draft References: <00cf01c07c12$d610e1a0$2c00a8c0@amir><3A5EAF01.EA33E840@redback.com><3A5ED096.9D31AE28@home.net><017201c07e1f$60166420$2c00a8c0@amir><3A6698D6.46026042@home.net><007a01c0815c$669f63b0$2c00a8c0@amir> <14951.58821.205281.903582@alpha-tli.procket.com> Message-ID: <019101c083b9$ca0ad5b0$2c00a8c0@amir> > > I would be very impressed to find such an implementation (that's not to say > that there isn't one... ;-). To cause a loop within the SPF, the > implemenation would have to be confused as to whether the extended LSP and > its parent were still candidates or on the tree. Most implementations are > quite explicit about this. > > Such an implementation is likely to fall over with even one zero cost > adjacency, IMHO. > > I'm fairly sure that I can point to three implementations that won't have > this problem. ;-) ;-) ;-) > > Tony I can point to another one ;-) So, if no one has an objection (like I said, I certainly don't), then I'll change the text to enable inclusion of adjacencies in extended LSPs and zero cost loops. I simply was under the, apparently mistaken, assumption that implementations could fail over this. Thanks. -- Amir Hermelin mailto:amir@cwnt.com Charlotte Networks Inc. http://www.cwnt.com From mshand@cisco.com Mon Jan 22 10:47:46 2001 From: mshand@cisco.com (Mike Shand) Date: Mon, 22 Jan 2001 10:47:46 +0000 Subject: [Isis-wg] Re: New Internet-Draft In-Reply-To: <019101c083b9$ca0ad5b0$2c00a8c0@amir> References: <00cf01c07c12$d610e1a0$2c00a8c0@amir> <3A5EAF01.EA33E840@redback.com> <3A5ED096.9D31AE28@home.net> <017201c07e1f$60166420$2c00a8c0@amir> <3A6698D6.46026042@home.net> <007a01c0815c$669f63b0$2c00a8c0@amir> <14951.58821.205281.903582@alpha-tli.procket.com> Message-ID: <4.3.2.7.2.20010122103745.00bc1100@jaws.cisco.com> At 14:52 21/01/2001 +0000, Amir H. wrote: > > > > I would be very impressed to find such an implementation (that's not to >say > > that there isn't one... ;-). To cause a loop within the SPF, the > > implemenation would have to be confused as to whether the extended LSP and > > its parent were still candidates or on the tree. Most implementations are > > quite explicit about this. > > > > Such an implementation is likely to fall over with even one zero cost > > adjacency, IMHO. > > > > I'm fairly sure that I can point to three implementations that won't have > > this problem. ;-) ;-) ;-) > > > > Tony > >I can point to another one ;-) > >So, if no one has an objection (like I said, I certainly don't), then I'll >change the text to enable inclusion of adjacencies in extended LSPs and zero >cost loops. I simply was under the, apparently mistaken, assumption that >implementations could fail over this. So if we assume that all implementations deal correctly with zero cost loops and non-pseudonode zero cost links, don't we still have a problem with the backwards connectivity check on non-pseudonode adjacencies? Or are you intending that somehow we advertise the extended ID in the pt-pt hellos and hence get the neighbor to claim an adjacency to the extended ID and not to the original ID. >Thanks. > >-- >Amir Hermelin mailto:amir@cwnt.com >Charlotte Networks Inc. http://www.cwnt.com > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From amir@cwnt.com Mon Jan 22 14:33:04 2001 From: amir@cwnt.com (Amir H.) Date: Mon, 22 Jan 2001 14:33:04 -0000 Subject: [Isis-wg] Re: draft-hermelin-ext-lsp-frags-00.txt References: <00cf01c07c12$d610e1a0$2c00a8c0@amir> <3A5EAF01.EA33E840@redback.com> <3A5ED096.9D31AE28@home.net> <017201c07e1f$60166420$2c00a8c0@amir> <3A6698D6.46026042@home.net> <007a01c0815c$669f63b0$2c00a8c0@amir> <14951.58821.205281.903582@alpha-tli.procket.com> <4.3.2.7.2.20010122103745.00bc1100@jaws.cisco.com> Message-ID: <009901c08480$3b295a20$2c00a8c0@amir> > > So if we assume that all implementations deal correctly with zero cost > loops and non-pseudonode zero cost links, don't we still have a problem > with the backwards connectivity check on non-pseudonode adjacencies? Or are > you intending that somehow we advertise the extended ID in the pt-pt hellos > and hence get the neighbor to claim an adjacency to the extended ID and not > to the original ID. > > Yes, that's the idea. Currently the text forbids advertising the extended id in order to satisfy the two-way check; advertising adjacencies in extended LSPs would have this restriction removed. Note, that it still stays backwards compatible; a neighbor doesn't have to know what other system ids you're using, as long as you advertise an lsp for the system-id he knows you're using. -- Amir Hermelin mailto:amir@cwnt.com Charlotte Networks Inc. http://www.cwnt.com From curtis@avici.com Wed Jan 24 02:20:38 2001 From: curtis@avici.com (Curtis Villamizar) Date: Tue, 23 Jan 2001 21:20:38 -0500 Subject: [Isis-wg] unnumberred interfaces in draft-ietf-isis-traffic-02 Message-ID: <200101240220.VAA18338@workhorse.fictitious.org> Tony, Henk, Please change the following: If the interface being advertised for Traffic Engineering purposes is unnumbered, the first two octets of the IPv4 neighbor address sub-TLV are set to zero and the next two octets are set to the interface ID of the unnumbered interface. In combination with the IPv4 interface address sub-TLV this identifies the unnumbered link over which the advertised adjacency has been established. Please specify that the first octet to be set to zero and the remaining three octets contain the ifindex. This will be consistent with the specification and the practice in OSPF (yes, I know its an ISIS doc) and it will also be much more convenient for big routers with lots of interfaces that number their pseudo-interfaces with three significant octets of numbering (like ours). Curtis From akyol@pluris.com Wed Jan 24 04:12:45 2001 From: akyol@pluris.com (Bora Akyol) Date: Tue, 23 Jan 2001 20:12:45 -0800 Subject: [Isis-wg] unnumberred interfaces in draft-ietf-isis-traffic-02 In-Reply-To: <200101240220.VAA18338@workhorse.fictitious.org> References: <200101240220.VAA18338@workhorse.fictitious.org> Message-ID: <14958.22077.592000.706649@gargle.gargle.HOWL> Curtis I was under the impression that ifindex was agreed to be 32 bits long based on the discussion about 2-3 months ago on the MPLS mailing list. Is there going to be an ID that clarifies this in a consistent manner for all of us? Bora >>>>> "Curtis" == Curtis Villamizar writes: Curtis> Tony, Henk, Curtis> Please change the following: Curtis> If the interface being advertised for Traffic Curtis> Engineering purposes is unnumbered, the first two Curtis> octets of the IPv4 neighbor address sub-TLV are set Curtis> to zero and the next two octets are set to the Curtis> interface ID of the unnumbered interface. In Curtis> combination with the IPv4 interface address sub-TLV Curtis> this identifies the unnumbered link over which the Curtis> advertised adjacency has been established. Curtis> Please specify that the first octet to be set to Curtis> zero and the remaining three octets contain the Curtis> ifindex. This will be consistent with the Curtis> specification and the practice in OSPF (yes, I know Curtis> its an ISIS doc) and it will also be much more Curtis> convenient for big routers with lots of interfaces Curtis> that number their pseudo-interfaces with three Curtis> significant octets of numbering (like ours). Curtis> Curtis Curtis> _______________________________________________ Curtis> Isis-wg mailing list - Isis-wg@external.juniper.net Curtis> http://external.juniper.net/mailman/listinfo/isis-wg From akyol@pluris.com Wed Jan 24 04:30:20 2001 From: akyol@pluris.com (Bora Akyol) Date: Tue, 23 Jan 2001 20:30:20 -0800 Subject: [Isis-wg] [2] unnumberred interfaces in draft-ietf-isis-traffic-02 In-Reply-To: <14958.22077.592000.706649@gargle.gargle.HOWL> References: <200101240220.VAA18338@workhorse.fictitious.org> <14958.22077.592000.706649@gargle.gargle.HOWL> Message-ID: <14958.23132.499000.343630@gargle.gargle.HOWL> Let me clarify myself, ifindex was "agreed" (AFAIR) to be 32 bits long to better accommodate SNMP. Our internal implementation uses 32 bits for ifindex for precisely this reason. If we have a 24 bit ifindex for MPLS, this would be yet another table/hash/hack to map between 32 bits and 24 bits. (Yes, I know there are efficient hacks that can be done, but there is some interesting properties that are associated with ifindices in SNMP like they should not repeat, strict rules for deleting them which make this somewhat more undesirable IMHO) Of course if we increase the index to 32 bits then we need to have another word to play with since we will at least need one flag to distinguish between IP addresses and ifindices. Bora >>>>> "Bora" == Bora Akyol writes: Bora> Curtis I was under the impression that ifindex was Bora> agreed to be 32 bits long based on the discussion Bora> about 2-3 months ago on the MPLS mailing list. Is Bora> there going to be an ID that clarifies this in a Bora> consistent manner for all of us? Bora> Bora >>>>> "Curtis" == Curtis Villamizar writes: Curtis> Tony, Henk, Curtis> Please change the following: Curtis> If the interface being advertised for Traffic Curtis> Engineering purposes is unnumbered, the first two Curtis> octets of the IPv4 neighbor address sub-TLV are set Curtis> to zero and the next two octets are set to the Curtis> interface ID of the unnumbered interface. In Curtis> combination with the IPv4 interface address sub-TLV Curtis> this identifies the unnumbered link over which the Curtis> advertised adjacency has been established. Curtis> Please specify that the first octet to be set to Curtis> zero and the remaining three octets contain the Curtis> ifindex. This will be consistent with the Curtis> specification and the practice in OSPF (yes, I know Curtis> its an ISIS doc) and it will also be much more Curtis> convenient for big routers with lots of interfaces Curtis> that number their pseudo-interfaces with three Curtis> significant octets of numbering (like ours). Curtis> Curtis Curtis> _______________________________________________ Curtis> Isis-wg mailing list - Isis-wg@external.juniper.net Curtis> http://external.juniper.net/mailman/listinfo/isis-wg Bora> _______________________________________________ Bora> Isis-wg mailing list - Isis-wg@external.juniper.net Bora> http://external.juniper.net/mailman/listinfo/isis-wg From curtis@avici.com Wed Jan 24 14:56:17 2001 From: curtis@avici.com (Curtis Villamizar) Date: Wed, 24 Jan 2001 09:56:17 -0500 Subject: [Isis-wg] unnumberred interfaces in draft-ietf-isis-traffic-02 In-Reply-To: Your message of "Tue, 23 Jan 2001 20:12:45 PST." <14958.22077.592000.706649@gargle.gargle.HOWL> Message-ID: <200101241456.JAA19873@workhorse.fictitious.org> In message <14958.22077.592000.706649@gargle.gargle.HOWL>, Bora Akyol writes: > Curtis > > I was under the impression that ifindex was agreed to be 32 bits > long based on the discussion about 2-3 months ago on the MPLS > mailing list. Is there going to be an ID that clarifies this in > a consistent manner for all of us? > > Bora That breaks the OSPF rule that a leading octet of zeros indicates an ifindex and non-zero leading octet indicates an address. I argued for 3 significant bytes. We can fit our ifindexes comfortably into 3 bytes even with reserving bay/slot/port bit fields in the physical address portion of ifindex space and doing fairly sloppy allocation in the vif space. Do we really need 4 bytes? If so, for most implementations the top byte will just happen to be zero and if a customer does use OSPF the scheme for allocating ifindex values won't break. A particular large and important customer of ours happens to use and prefer to use OSPF so I need to be concerned. Curtis From akyol@pluris.com Wed Jan 24 18:32:02 2001 From: akyol@pluris.com (Bora Akyol) Date: Wed, 24 Jan 2001 10:32:02 -0800 Subject: [Isis-wg] unnumberred interfaces in draft-ietf-isis-traffic-02 In-Reply-To: <200101241456.JAA19873@workhorse.fictitious.org> References: <14958.22077.592000.706649@gargle.gargle.HOWL> <200101241456.JAA19873@workhorse.fictitious.org> Message-ID: <14959.8098.474000.969288@gargle.gargle.HOWL> 4 bytes aligns well with SNMP ifindex, I can live with 3 bytes as long as it is clear when we have an IP address vs ifindex. My personal preference is that it is much better to explicitly identify the data type rather than infer it from the data itself. typedef struct { bool is_ip_addr; uint32 if_identifier; } if_identifer_t; would be the most clear cut definition IMHO, but yes it does waste 4 more bytes. On the other hand, in this day and age, do we really care about 4 more bytes per TE TLV. Either way, we should decide this and make sure that it is consistent for ISIS, OSPF, ... . Bora >>>>> "Curtis" == Curtis Villamizar writes: Curtis> In message Curtis> <14958.22077.592000.706649@gargle.gargle.HOWL>, Bora Curtis> Akyol writes: >> Curtis >> >> I was under the impression that ifindex was agreed to be >> 32 bits long based on the discussion about 2-3 months ago >> on the MPLS mailing list. Is there going to be an ID that >> clarifies this in a consistent manner for all of us? >> >> Bora Curtis> That breaks the OSPF rule that a leading octet of Curtis> zeros indicates an ifindex and non-zero leading Curtis> octet indicates an address. I argued for 3 Curtis> significant bytes. Curtis> We can fit our ifindexes comfortably into 3 bytes Curtis> even with reserving bay/slot/port bit fields in the Curtis> physical address portion of ifindex space and doing Curtis> fairly sloppy allocation in the vif space. Curtis> Do we really need 4 bytes? Curtis> If so, for most implementations the top byte will Curtis> just happen to be zero and if a customer does use Curtis> OSPF the scheme for allocating ifindex values won't Curtis> break. A particular large and important customer of Curtis> ours happens to use and prefer to use OSPF so I need Curtis> to be concerned. Curtis> Curtis Curtis> _______________________________________________ Curtis> Isis-wg mailing list - Isis-wg@external.juniper.net Curtis> http://external.juniper.net/mailman/listinfo/isis-wg From akyol@pluris.com Wed Jan 24 20:39:17 2001 From: akyol@pluris.com (Bora Akyol) Date: Wed, 24 Jan 2001 12:39:17 -0800 Subject: [Isis-wg] unnumberred interfaces in draft-ietf-isis-traffic-02 In-Reply-To: <200101242030.PAA22301@workhorse.fictitious.org> References: <14959.8098.474000.969288@gargle.gargle.HOWL> <200101242030.PAA22301@workhorse.fictitious.org> Message-ID: <14959.15733.125000.314592@gargle.gargle.HOWL> Curtis I agree with you that addition of another byte can be avoided and still give us the ability to differentiate between ifindices and IP addresses. On the other hand, the question that I would like to ask the WG(s) is whether it is worth it to add the **explicit** identification so that there are no assumptions and no confusion. As I said before, as long as this issue is settled and WG agrees on a consistent representation method, we should be OK. If there is a need for a different representation that was backwards compatible, I sure hope that people would be receptive to that later on. Regards Bora >>>>> "Curtis" == Curtis Villamizar writes: Curtis> In message Curtis> <14959.8098.474000.969288@gargle.gargle.HOWL>, Bora Curtis> Akyol writes: >> 4 bytes aligns well with SNMP ifindex, I can live with 3 >> bytes as long as it is clear when we have an IP address >> vs ifindex. >> >> My personal preference is that it is much better to >> explicitly identify the data type rather than infer it >> from the data itself. >> >> typedef struct { bool is_ip_addr; uint32 if_identifier; } >> if_identifer_t; >> >> would be the most clear cut definition IMHO, but yes it >> does waste 4 more bytes. On the other hand, in this day >> and age, do we really care about 4 more bytes per TE TLV. >> >> Either way, we should decide this and make sure that it >> is consistent for ISIS, OSPF, ... . >> >> Bora Curtis> Bora, Curtis> About two paragraphs above the one I quoted it Curtis> advises you to put the router-id in place of the Curtis> near end address if the interface is unnumbered. Curtis> The paragraph I quoted tells you to put the ifindex Curtis> in place of the far end address if the interface is Curtis> unnumbered. Curtis> If the near end interface address is equal to the Curtis> router ID, we can assume that the far end is an Curtis> interface, but that relies on the ISP not forgeting Curtis> to set the router-id to the address of the loopback Curtis> device and not the address of an interface. We can Curtis> also use the same test that is used in OSPF, if the Curtis> top octet is zero, its an ifindex but the draft Curtis> should advise against using ifindex values that do Curtis> not have all zeros in the top octet. Curtis> There is really no need to add a 5th byte just to Curtis> indicate if the value is a IP address of ifindex. Curtis> Curtis From naiming@redback.com Thu Jan 25 06:55:08 2001 From: naiming@redback.com (Naiming Shen) Date: Wed, 24 Jan 2001 22:55:08 -0800 Subject: [Isis-wg] Re: New Internet-Draft In-Reply-To: Mail from "Amir H." dated Sun, 21 Jan 2001 14:52:34 GMT <019101c083b9$ca0ad5b0$2c00a8c0@amir> Message-ID: <20010125065539.6072817BC0B@postal.redback.com> You will at least have problems for ECMP in some cases if there exists zero metric p2p links between systems. The behaviour of Dijkstra would be non-deterministic in terms of load sharing. Look at a simple example below: +------+ +--------+ | | x | | | +-----------------+ B |-- r1 | | | | | A | |========| | | y | | | +-----------------+ B" |-- r2 | | | | +------+ +--------+ A and B are connected with p2p links with equal cost on x and y. If B" is the same as B, then the prefixes r1 and r2 belong to the same LSP set as you called it. For A to reach r1 or r2, it will use both x and y. In the case of B" is B's extended system and there is a zero metric link between B and B", the load sharing is non-deterministic. It depends on whether B or B" is put onto the PATH first. If B is put on the PATH first, then A only uses x to reach r1, but will use x and y to reach r2. On the other hand, if B" is put on PATH before B, then A only uses y to reach r2, but will use x and y to reach r1. thanks. ]> ]> I would be very impressed to find such an implementation (that's not to ]say ]> that there isn't one... ;-). To cause a loop within the SPF, the ]> implemenation would have to be confused as to whether the extended LSP and ]> its parent were still candidates or on the tree. Most implementations are ]> quite explicit about this. ]> ]> Such an implementation is likely to fall over with even one zero cost ]> adjacency, IMHO. ]> ]> I'm fairly sure that I can point to three implementations that won't have ]> this problem. ;-) ;-) ;-) ]> ]> Tony ] ]I can point to another one ;-) ] ]So, if no one has an objection (like I said, I certainly don't), then I'll ]change the text to enable inclusion of adjacencies in extended LSPs and zero ]cost loops. I simply was under the, apparently mistaken, assumption that ]implementations could fail over this. ] ]Thanks. ] ]-- ]Amir Hermelin mailto:amir@cwnt.com ]Charlotte Networks Inc. http://www.cwnt.com ] ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From mshand@cisco.com Thu Jan 25 10:22:00 2001 From: mshand@cisco.com (mike shand) Date: Thu, 25 Jan 2001 10:22:00 +0000 Subject: [Isis-wg] Re: New Internet-Draft In-Reply-To: <20010125065539.6072817BC0B@postal.redback.com> References: <019101c083b9$ca0ad5b0$2c00a8c0@amir> Message-ID: <4.3.2.7.2.20010125094650.019351f8@jaws.cisco.com> At 22:55 24/01/2001 -0800, Naiming Shen wrote: > You will at least have problems for ECMP in some cases if there >exists zero metric p2p links between systems. The behaviour of Dijkstra >would be non-deterministic in terms of load sharing. Its not just non-deterministic, its broken. i.e. where you SHOULD get both path splits, you only get one (and which one you get is non-deterministic). This is a pathological case of the more general problem introduced by zero cost arcs. When we first introduced them FROM pseudonodes (to avoid the double cost) we solved that problem simply by requiring that pseudonodes be given priority over otherwise equal cost nodes when choosing the lowest cost from TENT for putting into PATHS, (and in the context of the present hack we would hope that implementations give the same treatment to ANY node which has zero cost links in its LSPs, though I'm skeptical as to whether an implementation would have the foresight to do that -- or was the intention that these would always be pseudonodes in the sense that the pseudonode identifier is non-zero?). However that simple fix was based on the assumption (correct at the time) that you would never have a zero cost arc both into and out of the same node. It is that fundamental assumption which is broken by this proposed change. Its a chicken and egg situation. We both need to give B' priority in putting it into PATHS so that we can explore its potential zero cost links, AND make sure that we have explored any zero cost links TO it BEFORE we put it in PATHS. I imagine that we could modify the SPF algorithm to deal with this (e.g. by selectively permitting additions to the adjacency set of nodes already on PATHS, or by unwrapping the zero cost links onto TENT, while keeping track of possible loops), but that is not the point. The whole rationale for this proposal is that we can allow certain nodes to expand their LSP set WITHOUT requiring any changes in the other nodes, and in particular any changes to their SPFs. So I guess the question is, do we care about the failure to make use of potential path splits? I think we do. Mike > Look at a simple example below: > > +------+ +--------+ > | | x | | > | +-----------------+ B |-- r1 > | | | | > | A | |========| > | | y | | > | +-----------------+ B" |-- r2 > | | | | > +------+ +--------+ > > A and B are connected with p2p links with equal cost on x and y. >If B" is the same as B, then the prefixes r1 and r2 belong to the same >LSP set as you called it. For A to reach r1 or r2, it will use both x and >y. In the case of B" is B's extended system and there is a zero metric >link between B and B", the load sharing is non-deterministic. It depends >on whether B or B" is put onto the PATH first. If B is put on the PATH >first, then A only uses x to reach r1, but will use x and y to reach r2. >On the other hand, if B" is put on PATH before B, then A only uses y to >reach r2, but will use x and y to reach r1. > >thanks. > > ]> > ]> I would be very impressed to find such an implementation (that's not to > ]say > ]> that there isn't one... ;-). To cause a loop within the SPF, the > ]> implemenation would have to be confused as to whether the extended > LSP and > ]> its parent were still candidates or on the tree. Most > implementations are > ]> quite explicit about this. > ]> > ]> Such an implementation is likely to fall over with even one zero cost > ]> adjacency, IMHO. > ]> > ]> I'm fairly sure that I can point to three implementations that won't have > ]> this problem. ;-) ;-) ;-) > ]> > ]> Tony > ] > ]I can point to another one ;-) > ] > ]So, if no one has an objection (like I said, I certainly don't), then I'll > ]change the text to enable inclusion of adjacencies in extended LSPs and > zero > ]cost loops. I simply was under the, apparently mistaken, assumption that > ]implementations could fail over this. > ] > ]Thanks. > ] > ]-- > ]Amir Hermelin mailto:amir@cwnt.com > ]Charlotte Networks Inc. http://www.cwnt.com > ] > ] > ]_______________________________________________ > ]Isis-wg mailing list - Isis-wg@external.juniper.net > ]http://external.juniper.net/mailman/listinfo/isis-wg > >- Naiming >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jerome@zeroknowledge.com Thu Jan 25 14:49:37 2001 From: jerome@zeroknowledge.com (Jerome Etienne) Date: Thu, 25 Jan 2001 09:49:37 -0500 Subject: [Isis-wg] Re: How many routers an OSPF or IS-IS area can have In-Reply-To: ; from david.wang@metro-optix.com on Thu, Jan 25, 2001 at 08:35:15AM -0600 References: Message-ID: <20010125094937.A8493@host-36.dyn.cia.zks.net> rfc2329 may help you. Parameter Responses Min Mode Mean Max _________________________________________________________________ Max routers in domain 8 20 350 510 1000 Max routers in single area 8 20 100 160 350 Max areas in domain 7 1 15 23 60 Max AS-external-LSAs 6 50 1K 2K 5K Table 3: OSPF domain sizes deployed On Thu, Jan 25, 2001 at 08:35:15AM -0600, David Wang wrote: > Hi, > > I have a question about the size of the IS-IS and OSPF area. What is the > guidelines in setting up the IS-IS or OSPF area? How many routers an area > can have? What are the key facts to determine how many routers an area can > have? router memory size? router interface bandwidth? or some other facts? > Is there any quantitative relationship among various parameters? > > Thank you for your help! > > David From tli@Procket.com Thu Jan 25 18:03:15 2001 From: tli@Procket.com (Tony Li) Date: Thu, 25 Jan 2001 10:03:15 -0800 (PST) Subject: [Isis-wg] Re: New Internet-Draft In-Reply-To: <4.3.2.7.2.20010125094650.019351f8@jaws.cisco.com> References: <019101c083b9$ca0ad5b0$2c00a8c0@amir> <4.3.2.7.2.20010125094650.019351f8@jaws.cisco.com> Message-ID: <14960.27235.756698.965617@alpha-tli.procket.com> | I imagine that we could modify the SPF algorithm to deal with this (e.g. by | selectively permitting additions to the adjacency set of nodes already on | PATHS, or by unwrapping the zero cost links onto TENT, while keeping track | of possible loops), but that is not the point. The whole rationale for this | proposal is that we can allow certain nodes to expand their LSP set WITHOUT | requiring any changes in the other nodes, and in particular any changes to | their SPFs. | | So I guess the question is, do we care about the failure to make use of | potential path splits? I think we do. I concur. And I agree that a solution that required no changes to existing systems would be preferable. Any suggestions? Tony From akyol@pluris.com Thu Jan 25 19:23:11 2001 From: akyol@pluris.com (Bora Akyol) Date: Thu, 25 Jan 2001 11:23:11 -0800 Subject: [Isis-wg] Re: How many routers an OSPF or IS-IS area can have In-Reply-To: <20010125094937.A8493@host-36.dyn.cia.zks.net> References: <20010125094937.A8493@host-36.dyn.cia.zks.net> Message-ID: <14960.32031.615000.692048@gargle.gargle.HOWL> I think the max numbers are somewhat conservative. There are SPs that run more than 350 routers in one area successfully these days. Bora >>>>> "Jerome" == Jerome Etienne writes: Jerome> rfc2329 may help you. Parameter Responses Min Mode Jerome> Mean Max Jerome> _________________________________________________________________ Jerome> Max routers in domain 8 20 350 510 1000 Max routers Jerome> in single area 8 20 100 160 350 Max areas in domain Jerome> 7 1 15 23 60 Max AS-external-LSAs 6 50 1K 2K 5K Jerome> Table 3: OSPF domain sizes Jerome> deployed Jerome> On Thu, Jan 25, 2001 at 08:35:15AM -0600, David Wang Jerome> wrote: >> Hi, >> >> I have a question about the size of the IS-IS and OSPF >> area. What is the guidelines in setting up the IS-IS or >> OSPF area? How many routers an area can have? What are >> the key facts to determine how many routers an area can >> have? router memory size? router interface bandwidth? or >> some other facts? Is there any quantitative relationship >> among various parameters? >> >> Thank you for your help! >> >> David From prz@redback.com Thu Jan 25 17:34:10 2001 From: prz@redback.com (Tony Przygienda) Date: Thu, 25 Jan 2001 09:34:10 -0800 Subject: [Isis-wg] Re: New Internet-Draft References: <019101c083b9$ca0ad5b0$2c00a8c0@amir> <4.3.2.7.2.20010125094650.019351f8@jaws.cisco.com> <14960.27235.756698.965617@alpha-tli.procket.com> Message-ID: <3A706392.FDFCFEDE@redback.com> Tony Li wrote: > | I imagine that we could modify the SPF algorithm to deal with this (e.g. by > | selectively permitting additions to the adjacency set of nodes already on > | PATHS, or by unwrapping the zero cost links onto TENT, while keeping track > | of possible loops), but that is not the point. The whole rationale for this > | proposal is that we can allow certain nodes to expand their LSP set WITHOUT > | requiring any changes in the other nodes, and in particular any changes to > | their SPFs. > | > | So I guess the question is, do we care about the failure to make use of > | potential path splits? I think we do. > > I concur. And I agree that a solution that required no changes to existing > systems would be preferable. Any suggestions? that's shortcut thinking here possibly but why can't we make sure that ALL the links to a specific node are being advertised by the same 'fake'-node in the implementations of the draft ? Actaully, it's probably nuff to say that ALL THE LINKS TO SAME NODE WITH SAME COST have to be included in the TLVs of the same 'fake'-node. Yes, it's quite a restriction for a specific implementation of the "hack" but doable and would not affect the old-style nodes. hope I'm clear enough and didn't jump the fence before my first morning coffee here ;-) --- tony From curtis@avici.com Wed Jan 24 20:30:25 2001 From: curtis@avici.com (Curtis Villamizar) Date: Wed, 24 Jan 2001 15:30:25 -0500 Subject: [Isis-wg] unnumberred interfaces in draft-ietf-isis-traffic-02 In-Reply-To: Your message of "Wed, 24 Jan 2001 10:32:02 PST." <14959.8098.474000.969288@gargle.gargle.HOWL> Message-ID: <200101242030.PAA22301@workhorse.fictitious.org> In message <14959.8098.474000.969288@gargle.gargle.HOWL>, Bora Akyol writes: > > 4 bytes aligns well with SNMP ifindex, I can live with 3 bytes > as long as it is clear when we have an IP address vs ifindex. > > My personal preference is that it is much better to explicitly > identify the data type rather than infer it from the data > itself. > > typedef struct { > bool is_ip_addr; > uint32 if_identifier; > } if_identifer_t; > > would be the most clear cut definition IMHO, but yes it does > waste 4 more bytes. On the other hand, in this day and age, do > we really care about 4 more bytes per TE TLV. > > Either way, we should decide this and make sure that it is > consistent for ISIS, OSPF, ... . > > Bora Bora, About two paragraphs above the one I quoted it advises you to put the router-id in place of the near end address if the interface is unnumbered. The paragraph I quoted tells you to put the ifindex in place of the far end address if the interface is unnumbered. If the near end interface address is equal to the router ID, we can assume that the far end is an interface, but that relies on the ISP not forgeting to set the router-id to the address of the loopback device and not the address of an interface. We can also use the same test that is used in OSPF, if the top octet is zero, its an ifindex but the draft should advise against using ifindex values that do not have all zeros in the top octet. There is really no need to add a 5th byte just to indicate if the value is a IP address of ifindex. Curtis From david.wang@metro-optix.com Thu Jan 25 14:35:15 2001 From: david.wang@metro-optix.com (David Wang) Date: Thu, 25 Jan 2001 08:35:15 -0600 Subject: [Isis-wg] How many routers an OSPF or IS-IS area can have Message-ID: Hi, I have a question about the size of the IS-IS and OSPF area. What is the guidelines in setting up the IS-IS or OSPF area? How many routers an area can have? What are the key facts to determine how many routers an area can have? router memory size? router interface bandwidth? or some other facts? Is there any quantitative relationship among various parameters? Thank you for your help! David From MELuallen@anl.gov Thu Jan 25 20:04:04 2001 From: MELuallen@anl.gov (Luallen, Matthew E.) Date: Thu, 25 Jan 2001 14:04:04 -0600 Subject: [Isis-wg] RE: How many routers an OSPF or IS-IS area can have Message-ID: Keep in mind that the limitations of OSPF can actually be the total number of subnetworks rather than the total number of routers. Cisco recommends that you not have an OSPF area with more than 90-100 routers. Additionally it is Cisco's recommendation that you not have more than 200 subnetworks per an area. Again .. these are recommendations and the network topology can have a dramatic effect on what are stable numbers for other networks. -matt luallen mcse, ccie, cissp argonne national laboratory -----Original Message----- From: Bora Akyol [mailto:akyol@pluris.com] Sent: Thursday, January 25, 2001 1:23 PM To: Jerome Etienne Cc: David Wang; 'isis-wg@juniper.net'; 'ietf@ietf.org' Subject: Re: How many routers an OSPF or IS-IS area can have I think the max numbers are somewhat conservative. There are SPs that run more than 350 routers in one area successfully these days. Bora >>>>> "Jerome" == Jerome Etienne writes: Jerome> rfc2329 may help you. Parameter Responses Min Mode Jerome> Mean Max Jerome> _________________________________________________________________ Jerome> Max routers in domain 8 20 350 510 1000 Max routers Jerome> in single area 8 20 100 160 350 Max areas in domain Jerome> 7 1 15 23 60 Max AS-external-LSAs 6 50 1K 2K 5K Jerome> Table 3: OSPF domain sizes Jerome> deployed Jerome> On Thu, Jan 25, 2001 at 08:35:15AM -0600, David Wang Jerome> wrote: >> Hi, >> >> I have a question about the size of the IS-IS and OSPF >> area. What is the guidelines in setting up the IS-IS or >> OSPF area? How many routers an area can have? What are >> the key facts to determine how many routers an area can >> have? router memory size? router interface bandwidth? or >> some other facts? Is there any quantitative relationship >> among various parameters? >> >> Thank you for your help! >> >> David From naiming@redback.com Thu Jan 25 20:22:04 2001 From: naiming@redback.com (Naiming Shen) Date: Thu, 25 Jan 2001 12:22:04 -0800 Subject: [Isis-wg] Re: New Internet-Draft In-Reply-To: Mail from Tony Przygienda dated Thu, 25 Jan 2001 09:34:10 PST <3A706392.FDFCFEDE@redback.com> Message-ID: <20010125202235.BC43317BC25@postal.redback.com> it does not help. as long as there exists equal cost paths from A to B, A and B does not have to be directly connected, it can have other nodes between them, it will have the same problem just as they are directly linked. ]Tony Li wrote: ] ]> | I imagine that we could modify the SPF algorithm to deal with this (e.g. by ]> | selectively permitting additions to the adjacency set of nodes already o n ]> | PATHS, or by unwrapping the zero cost links onto TENT, while keeping tra ck ]> | of possible loops), but that is not the point. The whole rationale for t his ]> | proposal is that we can allow certain nodes to expand their LSP set WITH OUT ]> | requiring any changes in the other nodes, and in particular any changes to ]> | their SPFs. ]> | ]> | So I guess the question is, do we care about the failure to make use of ]> | potential path splits? I think we do. ]> ]> I concur. And I agree that a solution that required no changes to existing ]> systems would be preferable. Any suggestions? ] ]that's shortcut thinking here possibly but why can't we make sure that ALL ]the links to a specific node are being advertised by the same 'fake'-node in ]the implementations of the draft ? Actaully, it's probably nuff to say that ]ALL THE LINKS TO SAME NODE WITH SAME COST have to be included in the TLVs ]of the same 'fake'-node. ]Yes, it's quite a restriction for a specific implementation of the "hack" but doable and ]would not affect the old-style nodes. ] ] hope I'm clear enough and didn't jump the fence ] before my first morning coffee here ;-) ] ] --- tony ] ] ] - Naiming From volkan@makesys.com Thu Jan 25 21:36:59 2001 From: volkan@makesys.com (Volkan Ozdemir) Date: Thu, 25 Jan 2001 16:36:59 -0500 (EST) Subject: [Isis-wg] (no subject) Message-ID: <200101252136.f0PLaxq19464@mail.makesys.com> Hi, I had a basic question about IS-IS. In IS-IS is a router completely in a single area or is it possible to assign interfaces to different areas? Thanks Volkan From tli@Procket.com Thu Jan 25 21:49:16 2001 From: tli@Procket.com (Tony Li) Date: Thu, 25 Jan 2001 13:49:16 -0800 (PST) Subject: [Isis-wg] (no subject) In-Reply-To: <200101252136.f0PLaxq19464@mail.makesys.com> References: <200101252136.f0PLaxq19464@mail.makesys.com> Message-ID: <14960.40796.883342.559022@alpha-tli.procket.com> Hi, This mailing list is for protocol development work. For technical support, please contact your favorite router vendor. Tony Volkan Ozdemir writes: | | Hi, | | I had a basic question about IS-IS. In IS-IS is a | router completely in a single area or is it possible to | assign interfaces to different areas? | | Thanks | | Volkan | _______________________________________________ | 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 chasmith9@hotmail.com Thu Jan 25 20:22:33 2001 From: chasmith9@hotmail.com (Charles Smith) Date: Thu, 25 Jan 2001 20:22:33 -0000 Subject: [Isis-wg] RE: How many routers an OSPF or IS-IS area can have Message-ID: c: comments? i assume Cisco's recommendations are a direct result of their implementation. i suspect the OSPF protocol itself does not imply these limitations. Keep in mind that the limitations of OSPF can actually be the total number of subnetworks rather than the total number of routers. Cisco recommends that you not have an OSPF area with more than 90-100 routers. Additionally it is Cisco's recommendation that you not have more than 200 subnetworks per an area. Again .. these are recommendations and the network topology can have a dramatic effect on what are stable numbers for other networks. -matt luallen mcse, ccie, cissp argonne national laboratory -----Original Message----- From: Bora Akyol [mailto:akyol@pluris.com] Sent: Thursday, January 25, 2001 1:23 PM To: Jerome Etienne Cc: David Wang; 'isis-wg@juniper.net'; 'ietf@ietf.org' Subject: Re: How many routers an OSPF or IS-IS area can have I think the max numbers are somewhat conservative. There are SPs that run more than 350 routers in one area successfully these days. Bora >>>>>"Jerome" == Jerome Etienne writes: Jerome> rfc2329 may help you. Parameter Responses Min Mode Jerome> Mean Max Jerome> _________________________________________________________________ Jerome> Max routers in domain 8 20 350 510 1000 Max routers Jerome> in single area 8 20 100 160 350 Max areas in domain Jerome> 7 1 15 23 60 Max AS-external-LSAs 6 50 1K 2K 5K Jerome> Table 3: OSPF domain sizes Jerome> deployed Jerome> On Thu, Jan 25, 2001 at 08:35:15AM -0600, David Wang Jerome> wrote: >> Hi, >> >> I have a question about the size of the IS-IS and OSPF >> area. What is the guidelines in setting up the IS-IS or >> OSPF area? How many routers an area can have? What are >> the key facts to determine how many routers an area can >> have? router memory size? router interface bandwidth? or >> some other facts? Is there any quantitative relationship >> among various parameters? >> >> Thank you for your help! >> >> David _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From chasmith9@hotmail.com Thu Jan 25 21:14:10 2001 From: chasmith9@hotmail.com (Charles Smith) Date: Thu, 25 Jan 2001 21:14:10 -0000 Subject: [Isis-wg] RE: How many routers an OSPF or IS-IS area can have Message-ID: forwarding to the is-is list as well... >From: "Moy, John" >To: 'Charles Smith' >CC: OSPF@DISCUSS.MICROSOFT.COM >Subject: RE: [Isis-wg] RE: How many routers an OSPF or IS-IS area can have >Date: Thu, 25 Jan 2001 15:54:44 -0500 > >Charles- > >You are correct - area size recommendations are >implementation-specific. Cisco's recommendations have >always been on the low side compared to other vendors. >These days I personally recommend that an area be limited >to 500 routers, with no explicit limit on the number >of subnetworks, but that is specific to my >implementation - there is nothing in the protocol that limits >area size (or for that matter, the number of areas). > >John > >-----Original Message----- >From: Charles Smith [mailto:chasmith9@hotmail.com] >Sent: Thursday, January 25, 2001 3:23 PM >To: John.Moy@SYCAMORENET.COM >Cc: OSPF@DISCUSS.MICROSOFT.COM; isis-wg@spider.juniper.net >Subject: RE: [Isis-wg] RE: How many routers an OSPF or IS-IS area can >have > > >c: comments? i assume Cisco's recommendations are a direct result of their >implementation. i suspect the OSPF protocol itself does not imply these >limitations. > > >Keep in mind that the limitations of OSPF can actually be the total number >of subnetworks rather than the total number of routers. Cisco recommends >that you not have an OSPF area with more than 90-100 routers. Additionally >it is Cisco's recommendation that you not have more than 200 subnetworks >per >an area. Again .. these are recommendations and the network topology can >have a dramatic effect on what are stable numbers for other networks. > > >-matt luallen >mcse, ccie, cissp >argonne national laboratory > > >-----Original Message----- >From: Bora Akyol [mailto:akyol@pluris.com] >Sent: Thursday, January 25, 2001 1:23 PM >To: Jerome Etienne >Cc: David Wang; 'isis-wg@juniper.net'; 'ietf@ietf.org' >Subject: Re: How many routers an OSPF or IS-IS area can have > > > >I think the max numbers are somewhat conservative. There are SPs >that run more than 350 routers in one area successfully these >days. > >Bora > > > >>>>>"Jerome" == Jerome Etienne writes: > > Jerome> rfc2329 may help you. Parameter Responses Min Mode > Jerome> Mean Max > Jerome> >_________________________________________________________________ > Jerome> Max routers in domain 8 20 350 510 1000 Max routers > Jerome> in single area 8 20 100 160 350 Max areas in domain > Jerome> 7 1 15 23 60 Max AS-external-LSAs 6 50 1K 2K 5K > > > Jerome> Table 3: OSPF domain sizes > Jerome> deployed > > Jerome> On Thu, Jan 25, 2001 at 08:35:15AM -0600, David Wang > Jerome> wrote: > >> Hi, > >> > >> I have a question about the size of the IS-IS and OSPF > >> area. What is the guidelines in setting up the IS-IS or > >> OSPF area? How many routers an area can have? What are > >> the key facts to determine how many routers an area can > >> have? router memory size? router interface bandwidth? or > >> some other facts? Is there any quantitative relationship > >> among various parameters? > >> > >> Thank you for your help! > >> > >> David > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From chris.flores@onfiber.com Thu Jan 25 21:45:13 2001 From: chris.flores@onfiber.com (Chris Flores) Date: Thu, 25 Jan 2001 15:45:13 -0600 Subject: [Isis-wg] (no subject) Message-ID: <2AD266216F4FD41192FC00508BD9378E74596C@cypher.onfiber.com> Volkan - A router that implements the is-is protocol can be configured to be: 1. a level-1 is 2. a level-2 is or a 3. a level-1-2 is (area border router) Therefore, individual interfaces can be configured to have level-1 or level-2 metrics depending on the is type. I hope this helps. Best regards. /cf -----Original Message----- From: Volkan Ozdemir [mailto:volkan@makesys.com] Sent: Thursday, January 25, 2001 3:37 PM To: isis-wg@spider.juniper.net Subject: [Isis-wg] (no subject) Hi, I had a basic question about IS-IS. In IS-IS is a router completely in a single area or is it possible to assign interfaces to different areas? Thanks Volkan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From E.T.Metz@kpn.com Mon Jan 29 13:05:54 2001 From: E.T.Metz@kpn.com (Metz, E.T.) Date: Mon, 29 Jan 2001 14:05:54 +0100 Subject: [Isis-wg] (no subject) Message-ID: <59063B5B4D98D311BC0D0001FA7E45220316A7FC@l04.research.kpn.com> A small note on this: - An ISIS router always resides entirely in an area, unlike OSPF where interfaces of a router reside in an area. The area of which it is member is determined by the router's system id. - An ISIS router can be part of multiple areas. A L1/L2 router in ISIS is part of one area, but exchanges L2 (backbone) routes with other L1/L2 (or pure L2) routers part of other areas -if connected to them-. There is no such thing as a distinct backbone area (like area 0 in OSPF) in ISIS. Instead the backbone is formed by a contigious set of L1/L2 routers. cheers, Eduard > -----Original Message----- > From: Chris Flores [mailto:chris.flores@onfiber.com] > Sent: donderdag 25 januari 2001 22:45 > To: 'volkan@makesys.com'; isis-wg@spider.juniper.net > Subject: RE: [Isis-wg] (no subject) > > > Volkan - > > A router that implements the is-is protocol can be configured to be: > > 1. a level-1 is > 2. a level-2 is or a > 3. a level-1-2 is (area border router) > > Therefore, individual interfaces can be configured to have level-1 or > level-2 metrics depending on the is type. > > I hope this helps. > > Best regards. > > /cf > > -----Original Message----- > From: Volkan Ozdemir [mailto:volkan@makesys.com] > Sent: Thursday, January 25, 2001 3:37 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] (no subject) > > > > Hi, > > I had a basic question about IS-IS. In IS-IS is a > router completely in a single area or is it possible to > assign interfaces to different areas? > > Thanks > > Volkan > _______________________________________________ > 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 dkatz@juniper.net Mon Jan 29 19:17:00 2001 From: dkatz@juniper.net (Dave Katz) Date: Mon, 29 Jan 2001 11:17:00 -0800 (PST) Subject: [Isis-wg] (no subject) In-Reply-To: <2AD266216F4FD41192FC00508BD9378E74596C@cypher.onfiber.com> (message from Chris Flores on Thu, 25 Jan 2001 15:45:13 -0600) Message-ID: <200101291917.LAA01702@cirrus.juniper.net> I think this misses the point of the question. IS-IS is designed in such a way that an IS lives within a single area (though it may act as L1, L2, or both) and area boundaries lie on L2 links. In contrast, OSPF area boundaries lie within routers. It would be possible to implement a router as multiple ISs so that you could put an area boundary inside the router (by means of a virtual L2 link.) I don't personally know of any implementations that do so, however. --Dave From: Chris Flores MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jan 2001 15:45:13 -0600 Volkan - A router that implements the is-is protocol can be configured to be: 1. a level-1 is 2. a level-2 is or a 3. a level-1-2 is (area border router) Therefore, individual interfaces can be configured to have level-1 or level-2 metrics depending on the is type. I hope this helps. Best regards. /cf -----Original Message----- From: Volkan Ozdemir [mailto:volkan@makesys.com] Sent: Thursday, January 25, 2001 3:37 PM To: isis-wg@spider.juniper.net Subject: [Isis-wg] (no subject) Hi, I had a basic question about IS-IS. In IS-IS is a router completely in a single area or is it possible to assign interfaces to different areas? Thanks Volkan _______________________________________________ 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 Radia Perlman - Boston Center for Networking Mon Jan 29 16:09:40 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Mon, 29 Jan 2001 11:09:40 -0500 (EST) Subject: [Isis-wg] (no subject) area/router boundary Message-ID: <200101291609.LAA02515@bcn.East.Sun.COM> Although all the replies have been correct, let me either clarify or confuse things with a bit of history. Originally IS-IS was designed for CLNP addresses, where the top part of the address (everything but the ID portion) was the "area", so an address specified an area, and a node could have lots of links in that area all with the same address, but only be in one area. So a node, by definition, if "node" is defined by the address of the node, could only exist in one area. With IS-IS for IP, though, this didn't really apply anymore since a node has an address for each interface. But even with CLNP, it was possible to implement what looked to the rest of the world like two nodes by having a router run multiple instances of IS-IS, one for each (level 1) area, and then the router could exist in both areas, and even pass routing summaries between them. This was implemented in NLSP, a variant of IS-IS for IPX. Such an implementation is straightforward and completely compatible with current IS-IS routers, who wouldn't be able to tell the difference between such a beast and two routers. But the spec does say a router is in (at most) one level 1 area, and might also be a level 2 router, as someone on this thread pointed out. Radia > > -----Original Message----- > From: Volkan Ozdemir [mailto:volkan@makesys.com] > Sent: Thursday, January 25, 2001 3:37 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] (no subject) > > > > Hi, > > I had a basic question about IS-IS. In IS-IS is a > router completely in a single area or is it possible to > assign interfaces to different areas? > > Thanks > > Volkan From jparker@axiowave.com Mon Jan 29 20:53:52 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 29 Jan 2001 15:53:52 -0500 Subject: [Isis-wg] LSP Buffersize Message-ID: IS-IS has a couple of checks to make sure that all routers in the networks can deal with a common LSP buffersize. First, (some) Hello packets are padded to at least the LSP buffersize, to verify the MTU on a link. But since the Hello size is the Max(LSP Buffersize, link MTU), it is possible for two adjacent routers A and B to form an adjacency, even though A's LSP Buffersize is 512, and B's is 1492. Radia has pointed out that this allows routers to verify that a next hop has a common link MTU. 10589 specifies an LSP TLV 12 that could help spot a mismatch between LSP Buffersizes. (See below) Does anyone know of an implementation that uses this feature? - jeff parker >From page 57, 10589. - originatingL1LSPBufferSize - the local value for originatingL1LSPBufferSize This may appear only once in an LSP with any LSP number. ....It is recommended that this option be used only in the LSP with LSP number zero. x CODE - 12 x LENGTH - 2 x VALUE - 512-1492 From jlearman@cisco.com Mon Jan 29 22:05:43 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 29 Jan 2001 17:05:43 -0500 Subject: [Isis-wg] LSP Buffersize In-Reply-To: Message-ID: <4.1.20010129165647.00a869b0@dingdong.cisco.com> The buffer size mismatch can be a serious problem in networks with varying MTU sizes -- the checks in the standard (1992) version of ISO 10589 are not sufficient to detect the problem, and the spec does not say what an implementation should do when encountering the problem. For a description of this problem and a recommended solution, see Les Ginsberg's paper, "http://www.atis.org/pub/sif/arch/ar820310.doc". I suspect that Jeff is looking at the draft spec for 10589 rather than the standard. The draft spec (the one available at the IETF ISIS WG site) has NOT been adopted and MUST NOT be considered authoratative. It is only posted on the site for discussion purposes. That said, the TLV to find the buffer size mismatch probably corresponds to Les's recommendation. Regards, Jeff At 03:53 PM 01/29/2001 -0500, Jeff Parker wrote: > IS-IS has a couple of checks to make sure that all routers >in the networks can deal with a common LSP buffersize. First, >(some) Hello packets are padded to at least the LSP buffersize, >to verify the MTU on a link. > But since the Hello size is the Max(LSP Buffersize, link MTU), >it is possible for two adjacent routers A and B to form an >adjacency, even though A's LSP Buffersize is 512, and B's is >1492. Radia has pointed out that this allows routers to verify >that a next hop has a common link MTU. > > 10589 specifies an LSP TLV 12 that could help spot a >mismatch between LSP Buffersizes. (See below) > Does anyone know of an implementation that uses >this feature? > >- jeff parker > > >From page 57, 10589. > > - originatingL1LSPBufferSize - the local value > for originatingL1LSPBufferSize > > This may appear only once in an LSP with any LSP > number. ....It is recommended that this option > be used only in the LSP with LSP number zero. > > x CODE - 12 > x LENGTH - 2 > x VALUE - 512-1492 >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From sprevidi@cisco.com Mon Jan 29 22:24:52 2001 From: sprevidi@cisco.com (stefano previdi) Date: Mon, 29 Jan 2001 23:24:52 +0100 Subject: [Isis-wg] (no subject) In-Reply-To: <200101291917.LAA01702@cirrus.juniper.net> References: <2AD266216F4FD41192FC00508BD9378E74596C@cypher.onfiber.com> Message-ID: <4.3.2.7.2.20010129231659.00b0b920@brussels.cisco.com> At 20:17 29/01/2001, Dave Katz wrote: >I think this misses the point of the question. > >IS-IS is designed in such a way that an IS lives within a single >area (though it may act as L1, L2, or both) and area boundaries lie >on L2 links. In contrast, OSPF area boundaries lie within routers. > >It would be possible to implement a router as multiple ISs so that >you could put an area boundary inside the router (by means of a virtual >L2 link.) I don't personally know of any implementations that do so, >however. I think there is one.... s. >--Dave > > From: Chris Flores > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2650.21) > Content-Type: text/plain; > charset="iso-8859-1" > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Thu, 25 Jan 2001 15:45:13 -0600 > > Volkan - > > A router that implements the is-is protocol can be configured to be: > > 1. a level-1 is > 2. a level-2 is or a > 3. a level-1-2 is (area border router) > > Therefore, individual interfaces can be configured to have level-1 or > level-2 metrics depending on the is type. > > I hope this helps. > > Best regards. > > /cf > > -----Original Message----- > From: Volkan Ozdemir [mailto:volkan@makesys.com] > Sent: Thursday, January 25, 2001 3:37 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] (no subject) > > > > Hi, > > I had a basic question about IS-IS. In IS-IS is a > router completely in a single area or is it possible to > assign interfaces to different areas? > > Thanks > > Volkan > _______________________________________________ > 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 ginsberg@pluris.com Mon Jan 29 22:45:51 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Mon, 29 Jan 2001 14:45:51 -0800 Subject: [Isis-wg] LSP Buffersize Message-ID: I believe what Jeff P. is looking at is the latest draft for Edition 2 of ISO 10589 as created by the new editor (Micah Bartell) over the past year. As has been discussed intermittently on this list, an ISO project is in progress to create a new second edition draft which avoids the pitfalls of the first attempt back in 1998. This draft is to include the various defect reports which have been filed via ISO against the spec since 1992 as well as some new work done by SIF. This work includes changes to detect MTU size misconfiguration - which was/is a real problem in SONET networks. The paper Jeff L. refers to is the solution which has been incorporated into the new draft. A copy of this draft was posted to this list a few months back. Since that time a number of comments have been submitted to the editor. At last report he was creating a comments document for submission along with the draft which has been scheduled to be voted on by ISO next month. Any further update on the document status will have to come from the editor. As far as Jeff P.'s original question - I do not know of any implementation using this TLV - but I still believe it is a worthwhile addition to the protocol. Les > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Monday, January 29, 2001 2:06 PM > To: Jeff Parker; 'isis-wg@spider.juniper.net' > Subject: Re: [Isis-wg] LSP Buffersize > > > > The buffer size mismatch can be a serious problem in networks > with varying MTU sizes -- the checks in the standard (1992) version > of ISO 10589 are not sufficient to detect the problem, and the > spec does not say what an implementation should do when encountering > the problem. For a description of this problem and a recommended > solution, see Les Ginsberg's paper, > "http://www.atis.org/pub/sif/arch/ar820310.doc". > > I suspect that Jeff is looking at the draft spec for 10589 > rather than the standard. The draft spec (the one available at > the IETF ISIS WG site) has NOT been adopted and MUST NOT be > considered authoratative. It is only posted on the site for > discussion > purposes. That said, the TLV to find the buffer size mismatch > probably corresponds to Les's recommendation. > > Regards, > Jeff > > At 03:53 PM 01/29/2001 -0500, Jeff Parker wrote: > > IS-IS has a couple of checks to make sure that all routers > >in the networks can deal with a common LSP buffersize. First, > >(some) Hello packets are padded to at least the LSP buffersize, > >to verify the MTU on a link. > > But since the Hello size is the Max(LSP Buffersize, link MTU), > >it is possible for two adjacent routers A and B to form an > >adjacency, even though A's LSP Buffersize is 512, and B's is > >1492. Radia has pointed out that this allows routers to verify > >that a next hop has a common link MTU. > > > > 10589 specifies an LSP TLV 12 that could help spot a > >mismatch between LSP Buffersizes. (See below) > > Does anyone know of an implementation that uses > >this feature? > > > >- jeff parker > > > > > >From page 57, 10589. > > > > - originatingL1LSPBufferSize - the local value > > for originatingL1LSPBufferSize > > > > This may appear only once in an LSP with any LSP > > number. ....It is recommended that this option > > be used only in the LSP with LSP number zero. > > > > x CODE - 12 > > x LENGTH - 2 > > x VALUE - 512-1492 > >_______________________________________________ > >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 rja@extremenetworks.com Mon Jan 29 22:54:03 2001 From: rja@extremenetworks.com (Ran Atkinson) Date: Mon, 29 Jan 2001 17:54:03 -0500 Subject: [Isis-wg] LSP Buffersize In-Reply-To: <4.1.20010129165647.00a869b0@dingdong.cisco.com> References: Message-ID: <5.0.0.25.2.20010129174902.009f39e0@10.30.15.2> At 17:05 29/01/01, Jeff Learman wrote: >The buffer size mismatch can be a serious problem in networks >with varying MTU sizes -- the checks in the standard (1992) version >of ISO 10589 are not sufficient to detect the problem, and the >spec does not say what an implementation should do when encountering >the problem. SIDEBAR: Due to widespread customer demand, most (all ?) major Gigabit Ethernet equipment vendors support a non-standard jumbo-frame of ~9K. Most vendors have a user-configuration knob to enable/disable this. See RFC-1626 for discussion of why ~9K bytes is a particularly interesting frame size. AFAIK, IEEE 802 hasn't blessed this officially. My main point is that it is no longer a safe assumption that all Ethernets have the same MTU. Ran From Jonathan.Sadler@tellabs.com Mon Jan 29 22:43:14 2001 From: Jonathan.Sadler@tellabs.com (Jonathan Sadler) Date: Mon, 29 Jan 2001 16:43:14 -0600 Subject: [Isis-wg] (no subject) References: Message-ID: <3A75F202.877D5B7F@tellabs.com> It seems that cisco is doing something similar to this. See: http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/1078_pp.htm#12149 Jonathan Sadler dkatz@juniper.net wrote: > > I think this misses the point of the question. > > IS-IS is designed in such a way that an IS lives within a single > area (though it may act as L1, L2, or both) and area boundaries lie > on L2 links. In contrast, OSPF area boundaries lie within routers. > > It would be possible to implement a router as multiple ISs so that > you could put an area boundary inside the router (by means of a virtual > L2 link.) I don't personally know of any implementations that do so, > however. > > --Dave > > From: Chris Flores > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2650.21) > Content-Type: text/plain; > charset="iso-8859-1" > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Thu, 25 Jan 2001 15:45:13 -0600 > > Volkan - > > A router that implements the is-is protocol can be configured to be: > > 1. a level-1 is > 2. a level-2 is or a > 3. a level-1-2 is (area border router) > > Therefore, individual interfaces can be configured to have level-1 or > level-2 metrics depending on the is type. > > I hope this helps. > > Best regards. > > /cf > > -----Original Message----- > From: Volkan Ozdemir [mailto:volkan@makesys.com] > Sent: Thursday, January 25, 2001 3:37 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] (no subject) > > Hi, > > I had a basic question about IS-IS. In IS-IS is a > router completely in a single area or is it possible to > assign interfaces to different areas? > > Thanks > > Volkan > _______________________________________________ > 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 dkatz@juniper.net Mon Jan 29 23:16:54 2001 From: dkatz@juniper.net (Dave Katz) Date: Mon, 29 Jan 2001 15:16:54 -0800 (PST) Subject: [Isis-wg] (no subject) In-Reply-To: <3A75F202.877D5B7F@tellabs.com> (message from Jonathan Sadler on Mon, 29 Jan 2001 16:43:14 -0600) Message-ID: <200101292316.PAA02917@cirrus.juniper.net> Yep, sounds like they did it. Implementing it is probably less work than the aggregate load of support questions from people who were trying to figure out how to do multiple areas, and having them magically merge into single areas. X-JNPR-Received-From: outside Date: Mon, 29 Jan 2001 16:43:14 -0600 From: Jonathan Sadler Reply-To: Jonathan.Sadler@tellabs.com Organization: Tellabs ONG SE Platform X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 CC: chris.flores@onfiber.com, volkan@makesys.com, isis-wg@spider.juniper.net References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It seems that cisco is doing something similar to this. See: http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/1078_pp.htm#12149 Jonathan Sadler dkatz@juniper.net wrote: > > I think this misses the point of the question. > > IS-IS is designed in such a way that an IS lives within a single > area (though it may act as L1, L2, or both) and area boundaries lie > on L2 links. In contrast, OSPF area boundaries lie within routers. > > It would be possible to implement a router as multiple ISs so that > you could put an area boundary inside the router (by means of a virtual > L2 link.) I don't personally know of any implementations that do so, > however. > > --Dave > > From: Chris Flores > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2650.21) > Content-Type: text/plain; > charset="iso-8859-1" > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Thu, 25 Jan 2001 15:45:13 -0600 > > Volkan - > > A router that implements the is-is protocol can be configured to be: > > 1. a level-1 is > 2. a level-2 is or a > 3. a level-1-2 is (area border router) > > Therefore, individual interfaces can be configured to have level-1 or > level-2 metrics depending on the is type. > > I hope this helps. > > Best regards. > > /cf > > -----Original Message----- > From: Volkan Ozdemir [mailto:volkan@makesys.com] > Sent: Thursday, January 25, 2001 3:37 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] (no subject) > > Hi, > > I had a basic question about IS-IS. In IS-IS is a > router completely in a single area or is it possible to > assign interfaces to different areas? > > Thanks > > Volkan > _______________________________________________ > 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 ginsberg@pluris.com Mon Jan 29 23:23:42 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Mon, 29 Jan 2001 15:23:42 -0800 Subject: [Isis-wg] LSP Buffersize Message-ID: The issue here is not whether the subnetwork MTU size is greater than origLxLSPBUffersize but rather whether any subnetwork in the area/domain over which LSPs have to be propagated is SMALLER than origLxLSPBufferSize of any system. If so, you can end up with LSPs which are too large to be propagated over all subnetworks. This issue is not a very popular one in the IP community where a subnetwork with an MTU size < 1492 is not commonly encountered. But it is a real problem in SONET networks where the current specifications call for an MTU size of 512 on the DCC. For a more complete discussion, please see the aforementioned paper http://www.atis.org/pub/sif/arch/ar820310.doc Les > -----Original Message----- > From: Ran Atkinson [mailto:rja@extremenetworks.com] > Sent: Monday, January 29, 2001 2:54 PM > To: isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] LSP Buffersize > > > At 17:05 29/01/01, Jeff Learman wrote: > > >The buffer size mismatch can be a serious problem in networks > >with varying MTU sizes -- the checks in the standard (1992) version > >of ISO 10589 are not sufficient to detect the problem, and the > >spec does not say what an implementation should do when encountering > >the problem. > > SIDEBAR: > Due to widespread customer demand, most (all ?) > major Gigabit Ethernet equipment vendors support a non-standard > jumbo-frame of ~9K. Most vendors have a user-configuration knob > to enable/disable this. See RFC-1626 for discussion of why ~9K > bytes is a particularly interesting frame size. AFAIK, IEEE 802 > hasn't blessed this officially. My main point is that it is > no longer a safe assumption that all Ethernets have the same MTU. > > Ran > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From jparker@axiowave.com Mon Jan 29 23:25:45 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 29 Jan 2001 18:25:45 -0500 Subject: [Isis-wg] LSP Buffersize Message-ID: > I believe what Jeff P. is looking at is the latest draft for > Edition 2 of ISO 10589.... > I still believe it is a worthwhile addition to the protocol. > > Les Jeff L. and Les are right on the mark. I was searching the 9/1/2000 edition, and not checking my paper copy of 1992 version, even after Les's frequent advice. I should be flogged mercilessly with a wet spec. I agree that the TLV addresses an issue that the 1992 protocol does not. Ran's example is one of several interesting mistakes waiting to happen. - jeff parker From truskows@cisco.com Tue Jan 30 04:40:57 2001 From: truskows@cisco.com (Mike Truskowski) Date: Mon, 29 Jan 2001 20:40:57 PST Subject: [Isis-wg] (no subject) In-Reply-To: <200101292316.PAA02917@cirrus.juniper.net>; from "Dave Katz" at Jan 29, 101 3:18 pm Message-ID: <200101300440.UAA26934@diablo.cisco.com> Dave, No, I think teaching the L1/L2 concepts is much harder. :-) Mike > > Yep, sounds like they did it. Implementing it is probably less work > than the aggregate load of support questions from people who were > trying to figure out how to do multiple areas, and having them > magically merge into single areas. > > X-JNPR-Received-From: outside > Date: Mon, 29 Jan 2001 16:43:14 -0600 > From: Jonathan Sadler > Reply-To: Jonathan.Sadler@tellabs.com > Organization: Tellabs ONG SE Platform > X-Mailer: Mozilla 4.75 [en] (WinNT; U) > X-Accept-Language: en,pdf > MIME-Version: 1.0 > CC: chris.flores@onfiber.com, volkan@makesys.com, isis-wg@spider.juniper.net > References: > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > It seems that cisco is doing something similar to this. See: > http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/1078_pp.htm#12149 > > Jonathan Sadler > > dkatz@juniper.net wrote: > > > > I think this misses the point of the question. > > > > IS-IS is designed in such a way that an IS lives within a single > > area (though it may act as L1, L2, or both) and area boundaries lie > > on L2 links. In contrast, OSPF area boundaries lie within routers. > > > > It would be possible to implement a router as multiple ISs so that > > you could put an area boundary inside the router (by means of a virtual > > L2 link.) I don't personally know of any implementations that do so, > > however. > > > > --Dave > > > > From: Chris Flores > > MIME-Version: 1.0 > > X-Mailer: Internet Mail Service (5.5.2650.21) > > Content-Type: text/plain; > > charset="iso-8859-1" > > Sender: isis-wg-admin@spider.juniper.net > > Errors-To: isis-wg-admin@spider.juniper.net > > X-BeenThere: isis-wg@external.juniper.net > > X-Mailman-Version: 2.0rc1 > > Precedence: bulk > > List-Help: > > List-Post: > > List-Subscribe: , > > > > List-Id: IETF IS-IS working group > > List-Unsubscribe: , > > > > List-Archive: > > Date: Thu, 25 Jan 2001 15:45:13 -0600 > > > > Volkan - > > > > A router that implements the is-is protocol can be configured to be: > > > > 1. a level-1 is > > 2. a level-2 is or a > > 3. a level-1-2 is (area border router) > > > > Therefore, individual interfaces can be configured to have level-1 or > > level-2 metrics depending on the is type. > > > > I hope this helps. > > > > Best regards. > > > > /cf > > > > -----Original Message----- > > From: Volkan Ozdemir [mailto:volkan@makesys.com] > > Sent: Thursday, January 25, 2001 3:37 PM > > To: isis-wg@spider.juniper.net > > Subject: [Isis-wg] (no subject) > > > > Hi, > > > > I had a basic question about IS-IS. In IS-IS is a > > router completely in a single area or is it possible to > > assign interfaces to different areas? > > > > Thanks > > > > Volkan > > _______________________________________________ > > 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 Tue Jan 30 15:16:28 2001 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 30 Jan 2001 10:16:28 -0500 Subject: [Isis-wg] LSP Buffersize In-Reply-To: Message-ID: <4.1.20010130101547.00a5d9b0@dingdong.cisco.com> Correction to my earlier mail: the proper URL is http://www.atis.org/pub/sif/arch/ar820317.doc which is a later rev of the same paper. At 03:23 PM 01/29/2001 -0800, Les Ginsberg wrote: >The issue here is not whether the subnetwork MTU size is greater than >origLxLSPBUffersize but rather whether any subnetwork in the area/domain >over which LSPs have to be propagated is SMALLER than origLxLSPBufferSize of >any system. If so, you can end up with LSPs which are too large to be >propagated over all subnetworks. > >This issue is not a very popular one in the IP community where a subnetwork >with an MTU size < 1492 is not commonly encountered. But it is a real >problem in SONET networks where the current specifications call for an MTU >size of 512 on the DCC. > >For a more complete discussion, please see the aforementioned paper > >http://www.atis.org/pub/sif/arch/ar820310.doc > > > Les > >> -----Original Message----- >> From: Ran Atkinson [mailto:rja@extremenetworks.com] >> Sent: Monday, January 29, 2001 2:54 PM >> To: isis-wg@spider.juniper.net >> Subject: Re: [Isis-wg] LSP Buffersize >> >> >> At 17:05 29/01/01, Jeff Learman wrote: >> >> >The buffer size mismatch can be a serious problem in networks >> >with varying MTU sizes -- the checks in the standard (1992) version >> >of ISO 10589 are not sufficient to detect the problem, and the >> >spec does not say what an implementation should do when encountering >> >the problem. >> >> SIDEBAR: >> Due to widespread customer demand, most (all ?) >> major Gigabit Ethernet equipment vendors support a non-standard >> jumbo-frame of ~9K. Most vendors have a user-configuration knob >> to enable/disable this. See RFC-1626 for discussion of why ~9K >> bytes is a particularly interesting frame size. AFAIK, IEEE 802 >> hasn't blessed this officially. My main point is that it is >> no longer a safe assumption that all Ethernets have the same MTU. >> >> Ran >> >> >> >> >> _______________________________________________ >> 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 amir@cwnt.com Sun Feb 4 19:24:29 2001 From: amir@cwnt.com (Amir H.) Date: Sun, 4 Feb 2001 19:24:29 -0000 Subject: [Isis-wg] Re: draft-hermelin-ext-lsp-frags-00.txt References: <019101c083b9$ca0ad5b0$2c00a8c0@amir><4.3.2.7.2.20010125094650.019351f8@jaws.cisco.com> <14960.27235.756698.965617@alpha-tli.procket.com> Message-ID: <02d601c08ee0$186ba460$2c00a8c0@amir> (Sorry for switching the subject line, should've done it from the beginning) Apparently, I was too hasty to dispose of the ECMP option. I don't think that non-determinism is an issue, as RFC 1195 doesn't require any determinism of IP paths greater than the MaxPathSplits. Even if some vendors do employ determinism, that would not guarantee determinism in multi-vendor environments. However, I agree that disposal of ECMP in the presence of extended-LSPs is a bad idea. Especially since not only multiple paths to the extended-LSP might be eliminated, but also paths to the original LSP (take Naming's example, there is symmetry between B and B"). For anyone that's confused, at least one path will still remain to all destinations. The options I see as available right now are: a) Don't advertise adjacencies in extended LSPs, as the original text suggests. This has the advantage of avoiding zero-cost loops. This has the dis-advantage of not being scalable in the presence of huge adjacency information (over a thousand adjacencies advertising full TE information) limited to only the original LSPs. b) Advertise adjacencies off extended LSPs. This has the advantage of being scalable to almost unlimited link-state information. However, it has the strong dis-advantage of introducing zero-cost loops, and as a result loss of equal-cost routes to some destinations. c) Hybrid approach: use option (a) until the original LSPs have no more room to hold adjacency information, then start advertising adjacencies off extended LSPs. I don't like this one (since a single adjacency addition could force a lot of ECMP paths to use just a single path), but it might be better than the former two. In any case, any of these options is better than not advertising the information at all. New options/opinions on these three are more than welcomed. -- Amir Hermelin mailto:amir@cwnt.com Charlotte Networks Inc. http://www.cwnt.com In Simplicity there is Elegance(TM) Tel: 972-4-9592203 ext. 222 Fax: 972-4-9593325 2 Ha'Mada St., POB 333, Yokneam Moshava 20600, ISRAEL. ----- Original Message ----- From: "Tony Li" To: "mike shand" Cc: "Naiming Shen" ; "Amir H." ; "Tony Li" ; "ISIS-wg" Sent: Thursday, January 25, 2001 6:03 PM Subject: Re: [Isis-wg] Re: New Internet-Draft > > | I imagine that we could modify the SPF algorithm to deal with this (e.g. by > | selectively permitting additions to the adjacency set of nodes already on > | PATHS, or by unwrapping the zero cost links onto TENT, while keeping track > | of possible loops), but that is not the point. The whole rationale for this > | proposal is that we can allow certain nodes to expand their LSP set WITHOUT > | requiring any changes in the other nodes, and in particular any changes to > | their SPFs. > | > | So I guess the question is, do we care about the failure to make use of > | potential path splits? I think we do. > > > I concur. And I agree that a solution that required no changes to existing > systems would be preferable. Any suggestions? > > Tony From rsrivats@cisco.com Tue Feb 13 21:01:18 2001 From: rsrivats@cisco.com (Radhika Srivatsa) Date: Tue, 13 Feb 2001 16:01:18 -0500 (EST) Subject: [Isis-wg] Question about a ISIS MIB variable Message-ID: Hi, I have a question regarding the following variable in the isisCirc table of the ISIS MIB draft: isisCircOutCtrlPDUs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS control PDUs sent on this circuit." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::= { isisCircEntry 17 } What exactly in the isis protocol make up the control PDUs ? Are they CSNP, PSNP and the Hello PDUs ? Does control PDUs include the LSPs too but I think LSP would be mostly categorized as data PDUs ? Thanks. -Radhika ------------------------------------------------------------------------ Radhika Srivatsa HFR Software Development Phone: 734-302-4134 Cisco Systems Fax: 734-302-4190 Ann Arbor, MI 48104 Email: rsrivats@cisco.com ------------------------------------------------------------------------ From jparker@axiowave.com Thu Feb 15 14:04:06 2001 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 15 Feb 2001 09:04:06 -0500 Subject: [Isis-wg] Question about a ISIS MIB variable Message-ID: > isisCircOutCtrlPDUs OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of IS-IS control PDUs sent on this circuit." > REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" > ::= { isisCircEntry 17 } > > What exactly in the isis protocol make up the control PDUs ? Are they > CSNP, PSNP and the Hello PDUs ? > > Does control PDUs include the LSPs too but I think LSP would be mostly > categorized as data PDUs ? > > -Radhika Radhika - Good question. I would argue that user traffic makes up the Data PDUs, and the control traffic is what is used to control the forwarding. The reference is circular... iSISControlPDUsReceived ATTRIBUTE DERIVED FROM "Rec. X.723 | ISO/IEC 10165-5":nonWrappingCounter; BEHAVIOUR iSISControlPDUsReceived-B BEHAVIOUR DEFINED AS Number of control PDUs received on this circuit;; REGISTERED AS {ISIS.aoi iSISControlPDUsReceived (44)}; But there is a reference in 7.4.4 that says "Control traffic (LSPs, Sequence Numbers PDUs)...." which would indicate everything except the Hellos. This clearly need clarification, and perhaps modification. I would prefer to see more counters: in the past, I have found it helpful to see explicit packet protocol counts for the levels. The counters above would not help: if the Rx count is zero, is it because o No Hellos have been seen? o I've seen hellos, but we couldn't agree on an area or password? Further, the levels are mashed together, making it hard to debug problems where the protocol is working at one level but not the other. I could a) clarify what is being described by these counters, or b) split into two sets of counters for the levels, c) split into 4 set of counters for hello, LSP, CSNP, and PSNP, d) split into Hello and control, e) some combination of these Any comments from the list? I would vote for c) & b). - jeff parker - axiowave networks From serge@ivmg.net Thu Feb 15 18:32:45 2001 From: serge@ivmg.net (Serge Maskalik) Date: Thu, 15 Feb 2001 10:32:45 -0800 Subject: [Isis-wg] Question about a ISIS MIB variable In-Reply-To: ; from jparker@axiowave.com on Thu, Feb 15, 2001 at 09:04:06AM -0500 References: Message-ID: <20010215103245.Q9656@ivmg.net> > This clearly need clarification, and perhaps modification. > I would prefer to see more counters: in the past, I have found > it helpful to see explicit packet protocol counts for the levels. > The counters above would not help: if the Rx count is zero, is it because > > o No Hellos have been seen? > o I've seen hellos, but we couldn't agree on an area or password? > > Further, the levels are mashed together, making it hard to debug > problems where the protocol is working at one level but not the other. > > I could > a) clarify what is being described by these counters, or > b) split into two sets of counters for the levels, > c) split into 4 set of counters for hello, LSP, CSNP, and PSNP, > d) split into Hello and control, > e) some combination of these > > Any comments from the list? I would vote for c) & b). > I agree, it would be useful to see counters at level and PDU type granularity. - Serge > - jeff parker > - axiowave networks > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From post-isis-wg@partan.com Sat Feb 17 07:55:31 2001 From: post-isis-wg@partan.com (Andrew Partan) Date: Sat, 17 Feb 2001 02:55:31 -0500 Subject: [Isis-wg] Multicast NLRI Message-ID: <20010217025531.A26970@partan.com> What is the status of sticking multicast NLRI into ISIS? I know that there are at least 2 (if not more) internet drafts out there for doing this, but I don't see much discussion of the differences between them nor seeminly any movement towards just one draft. Can someone fill us in on the status of these draft(s), the differences between them, and how we get towards just one standard? Thanks, --asp@partan.com (Andrew Partan) From oran@cisco.com Sat Feb 17 14:21:43 2001 From: oran@cisco.com (David Oran) Date: Sat, 17 Feb 2001 09:21:43 -0500 Subject: [Isis-wg] FW: (jtc1sc06.144) Announcement of Document Availability Message-ID: <00cc01c098ec$f785aa90$02d245ab@cisco.com> This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C098C3.0EAFA290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SC6 voting on update to ISIS. =20 -----Original Message----- From: SC6 Secretariat [mailto:secretariat@jtc1sc06.org] Sent: Friday, February 16, 2001 5:42 AM To: Argentina; ASN.1-J. Larmouth; ASTM-Teresa J Cen; ATM Forum; = Australia; Austria; Austria2; B. Scott; B. Wood; Belgium; Brazil; = Canada; China; Columbia; Czech Republic; Czech Republic2; Czech = Republic3; Denmark; ECMA-Isabelle Walc; ETSI-Christian Julien; Finland; = Frame Relay Forum; France1; Germany; Greece; Greg Smith; Hoyt Kesterson; = Hungary; ICAO-Albert Pelsser; ICAO-Lyse Boisvert; Iceland; IEEE = 802-Chair; IEEE-Denise Pribula; IEEE-Robert Pritchar; IETF (PKIX); IETF = (PKIX)2; IETF (Routeing); IETF (Routeing)2; IETF (Transport); IETF = (Transport)2; INTELSAT-Colin Am; Ireland; ISO/TC68/SC2-Philli; ISOC; = Italy1; Italy2; ITTF-Keith Brannon; ITU-T SG 11-TSB; ITU-T SG 16 WP 1; = ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack Houldsworth; Jan van den Beld; = Japan; Jim Long; Joon-Nyun Kim; KATS; New Zealand; Norway; OIW-Fred = Burg; Oliver Dubuisson; Phillipines; Poland1; Poland2; Portugal; = Dae-Young Kim; Republic of Korea2; Romania; Russian Federation; S. J. = Koh; SC 25-D. Popovic; SC25-Walter von Patt; SC29-Yukiko Ogura; = SC31-Maria Schneid; Singapore; SITA; Sweden; Thailand; The Netherlands; = UK-Anne Cassidy; UK-John Elwell; UK-Peter Gibbon; Ukraine1; Ukraine2; = UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; USA-Geoff Thompso; = Yugoslavia Subject: (jtc1sc06.144) Announcement of Document Availability ANNOUNCEMENT OF DOCUMENT AVAILABILITY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Document Posted : SC6 N11851- N11852 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following documents are now available from the JTC1/SC6 web site : http://www.jtc1sc06.org ------------------------------------------ =20 ------------------------------------------ Document Number : 11851 Replaces : Document Type : Summary of Voting/Table of Replies Date Assigned : 2001-02-16 Document Title : Summary of Voting on SC 6 N 11704,=20 Text for FCD Ballot or Comment, ISO/IEC FCD 10589 =20 Due Date :=20 Pages : 2 Source : SC6 Secretariat Project Number : Status : For consideration by the Project Editor and SC 6/WG 7 Action ID : ACT ------------------------------------------- ------------------------------------------- Document Number : 11852 Replaces : Document Type : Meeting Announcement Date Assigned : 2001-02-16 Document Title : Calling Notice from the SC 6/WG 7 ASN.1 Meeting,=20 5-9 March 2001, Bowdon, UK Due Date : Pages : 1 Source : ASN.1 Rapporteur Project Number : Status : For information Action ID : FYI --------------------------------------------- --------------------------------------------- =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Ms. Jooran Lee JTC1/SC6 Secretariat Korean Standards Association Phone: +82 2 369 8308 Fax: +82 2 369 8349 Email: secretariat@jtc1sc06.org http://www.jtc1sc06.org =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D ------=_NextPart_000_00CD_01C098C3.0EAFA290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
SC6=20 voting on update to ISIS.
 
-----Original Message-----
From: SC6 Secretariat=20 [mailto:secretariat@jtc1sc06.org]
Sent: Friday, February 16, = 2001 5:42=20 AM
To: Argentina; ASN.1-J. Larmouth; ASTM-Teresa J Cen; ATM = Forum;=20 Australia; Austria; Austria2; B. Scott; B. Wood; Belgium; Brazil; = Canada; China;=20 Columbia; Czech Republic; Czech Republic2; Czech Republic3; Denmark;=20 ECMA-Isabelle Walc; ETSI-Christian Julien; Finland; Frame Relay Forum; = France1;=20 Germany; Greece; Greg Smith; Hoyt Kesterson; Hungary; ICAO-Albert = Pelsser;=20 ICAO-Lyse Boisvert; Iceland; IEEE 802-Chair; IEEE-Denise Pribula; = IEEE-Robert=20 Pritchar; IETF (PKIX); IETF (PKIX)2; IETF (Routeing); IETF (Routeing)2; = IETF=20 (Transport); IETF (Transport)2; INTELSAT-Colin Am; Ireland; = ISO/TC68/SC2-Philli;=20 ISOC; Italy1; Italy2; ITTF-Keith Brannon; ITU-T SG 11-TSB; ITU-T SG 16 = WP 1;=20 ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack Houldsworth; Jan van den Beld; = Japan;=20 Jim Long; Joon-Nyun Kim; KATS; New Zealand; Norway; OIW-Fred Burg; = Oliver=20 Dubuisson; Phillipines; Poland1; Poland2; Portugal; Dae-Young Kim; = Republic of=20 Korea2; Romania; Russian Federation; S. J. Koh; SC 25-D. Popovic; = SC25-Walter=20 von Patt; SC29-Yukiko Ogura; SC31-Maria Schneid; Singapore; SITA; = Sweden;=20 Thailand; The Netherlands; UK-Anne Cassidy; UK-John Elwell; UK-Peter = Gibbon;=20 Ukraine1; Ukraine2; UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; = USA-Geoff=20 Thompso; Yugoslavia
Subject: (jtc1sc06.144) Announcement of = Document=20 Availability

ANNOUNCEMENT OF DOCUMENT=20 AVAILABILITY

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= Document Posted=20 : SC6 N11851- = N11852
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The=20 following documents are now available from the JTC1/SC6 web site :
http://www.jtc1sc06.org

------------------------------------------
 
----= --------------------------------------

Document=20 Number : 11851
Replaces :
Document Type : Summary of Voting/Table = of=20 Replies
Date Assigned : 2001-02-16
Document Title :  Summary = of=20 Voting on SC 6 N 11704,
Text for FCD Ballot or = Comment, ISO/IEC FCD=20 10589            =
Due=20 Date :
Pages : 2
Source : SC6 Secretariat
Project Number = :
Status :=20 For consideration by the Project Editor and SC 6/WG 7
Action ID :=20 ACT

-------------------------------------------

-----------= --------------------------------

Document=20 Number : 11852
Replaces :
Document Type : Meeting = Announcement
Date=20 Assigned : 2001-02-16
Document Title : Calling Notice from the SC = 6/WG 7=20 ASN.1 Meeting,
5-9 March 2001, Bowdon, = UK
Due Date :
Pages :=20 1
Source : ASN.1 Rapporteur
Project Number :
Status : For=20 information
Action ID :=20 FYI

---------------------------------------------

---------= ------------------------------------
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Ms. Jooran=20 Lee
JTC1/SC6 Secretariat
Korean Standards Association
Phone: = +82 2 369=20 8308
Fax: +82 2 369 8349
Email: secretariat@jtc1sc06.org
= http://www.jtc1sc06.org
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
------=_NextPart_000_00CD_01C098C3.0EAFA290-- From Internet-Drafts@ietf.org Wed Feb 21 11:43:51 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 21 Feb 2001 06:43:51 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-diff-te-00.txt Message-ID: <200102211143.GAA22146@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 : Extensions to ISIS for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur et al. Filename : draft-ietf-isis-diff-te-00.txt Pages : 7 Date : 20-Feb-01 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to ISIS for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-diff-te-00.txt 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-diff-te-00.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-diff-te-00.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: <20010220155949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-diff-te-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-diff-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010220155949.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed Feb 21 11:43:56 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 21 Feb 2001 06:43:56 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-transient-00.txt Message-ID: <200102211143.GAA22162@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 Transient Blackhole Avoidance Author(s) : D. McPherson Filename : draft-ietf-isis-transient-00.txt Pages : 6 Date : 20-Feb-01 This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-00.txt 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-transient-00.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-transient-00.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: <20010220155957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-transient-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-transient-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010220155957.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed Feb 21 11:43:51 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 21 Feb 2001 06:43:51 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-diff-te-00.txt Message-ID: <200102211143.GAA22146@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 : Extensions to ISIS for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur et al. Filename : draft-ietf-isis-diff-te-00.txt Pages : 7 Date : 20-Feb-01 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to ISIS for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-diff-te-00.txt 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-diff-te-00.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-diff-te-00.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: <20010220155949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-diff-te-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-diff-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010220155949.I-D@ietf.org> --OtherAccess-- --NextPart-- From Patrick.Lengel@marconi.com Fri Feb 23 18:18:11 2001 From: Patrick.Lengel@marconi.com (Lengel, Patrick) Date: Fri, 23 Feb 2001 13:18:11 -0500 Subject: [Isis-wg] Is there an Ethertype value used for the IS-IS Routing protocol? Message-ID: <4FBEA8857476D311A03300204840E1CF03518160@whq-msgusr-02.pit.comms.marconi.com> Question for the "IS-IS for IP Internets (isis)" Working Group, Is there a two byte Ethertype value used for the IS-IS Routing protocol over an Ethernet link? If so, what is it? I need to pick out all "Routed ISO" PDUs from a network card and forward them to a router. I see that RFC 2684 points out the LLC SAP value used for Routed ISO PDUs as 0xFE and that the Network Layer Protocol ID specifies the type of Routed ISO PDU that has been recieved. However, on an Ethernet link I could receive either 802.3 or Ethernet formatted PDUs. I can resolve Routed ISO traffic when packets are formatted to the 802.3 spec, however I do not know how to detect Routed ISO traffic when packets are formatted to the Ethernet spec and use a two byte Ethertype value. Any assistance in this matter would be greatly appreciated. Thank you........... Patrick Lengel ______________________________________________________________ Patrick Lengel Voice: (724)742-6780 Senior Software Engineer Fax: (724)742-6800 Marconi Communications Email: Patrick.Lengel@marconi.com 2000 FORE Drive URL: www.marconi.com Warrendale, PA 15086-7566 ______________________________________________________________ From Radia Perlman - Boston Center for Networking Sat Feb 24 17:43:35 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Sat, 24 Feb 2001 12:43:35 -0500 (EST) Subject: [Isis-wg] Is there an Ethertype value used for the IS-IS Routing protocol? Message-ID: <200102241743.MAA03994@bcn.East.Sun.COM> I'd bet there was no Ethertype, and that the only way of sending them is with the globally assigned SAP, because ISO believed in the "standard" 802 encoding, and besides there wouldn't have been a reason to send things in two different envelope types. I don't know for sure, though, so anyone else feel free to contradict. Radia From jlearman@cisco.com Sat Feb 24 18:23:04 2001 From: jlearman@cisco.com (Jeff Learman) Date: Sat, 24 Feb 2001 13:23:04 -0500 Subject: [Isis-wg] Is there an Ethertype value used for the IS-IS Routing protocol? References: <4FBEA8857476D311A03300204840E1CF03518160@whq-msgusr-02.pit.comms.marconi.com> Message-ID: <009e01c09e8e$d4604f00$8c02530a@sevsisters> Patrick, RFC 1195 says to use packet formats defined in ISO 10589, which requires 802.3 encapsulation. Any attempt to use an Ethertype code for ISO network layer packets would have caused serious interoperability problems with existing equipment, so I don't think anyone has tried to push it. I do know of a number of implementations (mostly SONET NEs) that won't recognize IS-IS or CLNP packets if they're sent using Ethernet-format frames. Regards, Jeff ----- Original Message ----- From: Lengel, Patrick To: Sent: Friday, February 23, 2001 1:18 PM Subject: [Isis-wg] Is there an Ethertype value used for the IS-IS Routing protocol? > Question for the "IS-IS for IP Internets (isis)" Working Group, > > Is there a two byte Ethertype value used for the IS-IS Routing protocol over > an Ethernet link? If so, what is it? > > I need to pick out all "Routed ISO" PDUs from a network card and forward > them to a router. I see that RFC 2684 points out the LLC SAP value used for > Routed ISO PDUs as 0xFE and that the Network Layer Protocol ID specifies the > type of Routed ISO PDU that has been recieved. However, on an Ethernet link > I could receive either 802.3 or Ethernet formatted PDUs. I can resolve > Routed ISO traffic when packets are formatted to the 802.3 spec, however I > do not know how to detect Routed ISO traffic when packets are formatted to > the Ethernet spec and use a two byte Ethertype value. > > Any assistance in this matter would be greatly appreciated. > > Thank you........... Patrick Lengel > > ______________________________________________________________ > Patrick Lengel Voice: (724)742-6780 > Senior Software Engineer Fax: (724)742-6800 > Marconi Communications Email: Patrick.Lengel@marconi.com > 2000 FORE Drive URL: www.marconi.com > Warrendale, PA 15086-7566 > ______________________________________________________________ > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From cmartin@gnilink.net Sun Feb 25 06:51:19 2001 From: cmartin@gnilink.net (Martin, Christian) Date: Sun, 25 Feb 2001 01:51:19 -0500 Subject: [Isis-wg] Interest in Supporting PTP Behavior on LAN Media in IS-IS? Message-ID: <94B9091E1149D411A45C00508BACEB359CD864@entmail.gnilink.com> Folks, I know that over the years, the idea of supporting NBMA interfaces has been tossed around the IS-IS community with little interest generated. I assume that the idea was spurred by the need to support partial-mesh, switched WANs, such as Frame Relay. The argument aginst this support was that these media could be made into PTP media through static PVCs, at the expense of address space. Recently, I have been wondering about the utility of supporting directed, PTP adjacencies over high-speed LAN interfaces, in an attempt to provide deterministic, per-adjacency metric state. Since I have no experience in IS-IS protocol development, I was hoping those who have can enlighten me on the level of difficulty required to produce such an implementation, before I embark on authoring or co-authoring a draft. Is there any interest (outside my own), in supporting per adjacency state across LAN media? Perhaps an example would help illuminate the need as I see it. Today's ISP POP architecture is often built using PTP POS trunks between all core routers in the POP. Edge/Aggregation routers are often redundnatly uplinked to multiple core routers via POS interfaces as well. In many cases, POS links may be substituted by ATM PVCs, but this case diminishes as bandwidth needs rise, and it still looks as if no vendor has any interest in building OC-48 or higher SARs. Give N core routers and M Edge/Aggregation routers, such an architecture requires N(N-1) + N(M+N) = 2N^2 + N(M-1) POS interfcaes per POP. Given the minimum required number of nodes and links needed for edge and core redundancy, M = N = 2, which results in 10 POS ports. Since many ISP POPs have N >= 3 and M >= 10, this yields a minimum 45 POS ports per POP. At OC-48/192 speeds for N-N connectivity, and OC-48/12 speeds for N-M connectivity, this results in N(N-1)* + N(N + M)* A less optimal, but much more cost effective approach would be to use 10GigE interfaces instead of OC192/48 interfaces, and GigE instead of OC-48/12 interfaces. By linking each device tigether through a pair of redundant GigE switches, the number of GigE ports on the routers reduce to 2(N + M), and the cost reduces to 2N + 2(N+M), plus 2(N+M) cost of GigE ports on the switches (which is generally an order of magnitude less than the cost of router ports of the same type when the switch density is high, utilization-wise). This obviously has significant advantages cost-wise, but there are glaring disadvantages technology-wise. In particular, link restoration mechanisms inherent in SONET are not available, as is end-to-end link management in general, thus requireing reliance upon proptocol adjacency state to detect remote link trouble. TE may be more difficult across shared LAN media as well, however, I cannot substantiate this claim from experience. In particular, though, all routers adjacent over the same subnetwork share the same metric. This subtle deficiency is exasperated when routers have different link speeds (and thus) metrics into the switch fabric. This particular deficiency renders IGP TE using metrics impossible. A potential solution to this problem would be to create Z=[N(N-1) + N(N + M)]/2 VLANs through the switch fabric, and connect the routers over /30 or /31 subnetworks. However, this causes the creation Z pseudonodes in the IS-IS domain. Given an ISP backbone consisting of N = 100 and M =200, this requires 19950 pseudonodes which has obvious drawbacks, even given the ability to support more than 255 pseudonodes as recently proposed. What would be nice would be one of two things: 1) Allow an operator to selectively turn LAN-based media into PTP links as seen by IS-IS. 2) Allow an operator to selectively define neighbors across LAN media and associate metrics to each neighbor. As I see it, both have pros and cons. 1) makes it easier on the operator, as he/she only needs to set the link type to PTP, and the rest of the configuration would be akin to real PTP interfaces. However, it requires the CLNS/IS-IS stack to be able to discover IS-IS (trivial) nodes and direct IS-IS PDUs at it and only it, which sems non-trivial (this is where I need assistance from the dvelopers). 2) makes it easier on the developers?, but harder on the operator, as now the operator has to explicitly define neighbors. Another pro, however, is that this method conserves address space, and eliminates the need to create and manage hundreds of VLANs per switch. Finally, I know of one vendor who has done this with OSPF, although the IP-ness of OSPF may or may not make this easier, particularly to those vendors with no interest in supporting a full CLNP stack. I suppose that ES-IS could be used to resolve system IDs to MAC addresses in 2), and then IIH hellos could be hacked to use the learned MAC instead of the standard multicast MAC addressed used in LAN IIHs. But, is this hard to do development-wise? Is there a workable solution to 1)? Could IS-IS be made to send IIHs on LAN media without performing DIS election? I sincerely hope I am not blowing a bunch of wind, but I am open to any and all flaming if this idea is completely baseless. If there is any interest, I'd be very willing to contribute to a draft effort. Best Regards, -chris From oran@cisco.com Sun Feb 25 14:52:28 2001 From: oran@cisco.com (David Oran) Date: Sun, 25 Feb 2001 09:52:28 -0500 Subject: [Isis-wg] FW: How can we access these documents? Message-ID: <000f01c09f3a$93394f20$02d245ab@cisco.com> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C09F10.AA634720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: SC6 Secretariat [mailto:secretariat@jtc1sc06.org] Sent: Friday, February 23, 2001 9:09 PM To: David Oran Subject: Re: How can we access these documents? Dear Dave Oran, To download the documents from the SC6 website you need Login ID : Jtc1sc06 Password : sc06 Best wishes, Jooran Lee =============================== Ms. Jooran Lee JTC1/SC6 Secretariat Korean Standards Association Phone: +82 2 369 8308 Fax: +82 2 369 8349 Email: secretariat@jtc1sc06.org http://www.jtc1sc06.org =============================== ----- Original Message ----- From: David Oran To: secretariat@jtc1sc06.org Sent: Saturday, February 24, 2001 3:48 AM Subject: How can we access these documents? We need them for the work of the ISIS working group in IETF. Any help would be greatly appreciated. Regards, Dave Oran. Area Director Routing Internet Engineering Steering Group -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Monday, February 19, 2001 6:02 AM To: David Oran Cc: micah Bartell Subject: Re: [Isis-wg] FW: (jtc1sc06.144) Announcement of Document Availability Dave, Is there a way to actually see the SoV document. It seems to want an authorized login. Mike At 09:21 17/02/2001 -0500, you wrote: SC6 voting on update to ISIS. -----Original Message----- From: SC6 Secretariat [mailto:secretariat@jtc1sc06.org] Sent: Friday, February 16, 2001 5:42 AM To: Argentina; ASN.1-J. Larmouth; ASTM-Teresa J Cen; ATM Forum; Australia; Austria; Austria2; B. Scott; B. Wood; Belgium; Brazil; Canada; China; Columbia; Czech Republic; Czech Republic2; Czech Republic3; Denmark; ECMA-Isabelle Walc; ETSI-Christian Julien; Finland; Frame Relay Forum; France1; Germany; Greece; Greg Smith; Hoyt Kesterson; Hungary; ICAO-Albert Pelsser; ICAO-Lyse Boisvert; Iceland; IEEE 802-Chair; IEEE-Denise Pribula; IEEE-Robert Pritchar; IETF (PKIX); IETF (PKIX)2; IETF (Routeing); IETF (Routeing)2; IETF (Transport); IETF (Transport)2; INTELSAT-Colin Am; Ireland; ISO/TC68/SC2-Philli; ISOC; Italy1; Italy2; ITTF-Keith Brannon; ITU-T SG 11-TSB; ITU-T SG 16 WP 1; ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack Houldsworth; Jan van den Beld; Japan; Jim Long; Joon-Nyun Kim; KATS; New Zealand; Norway; OIW-Fred Burg; Oliver Dubuisson; Phillipines; Poland1; Poland2; Portugal; Dae-Young Kim; Republic of Korea2; Romania; Russian Federation; S. J. Koh; SC 25-D. Popovic; SC25-Walter von Patt; SC29-Yukiko Ogura; SC31-Maria Schneid; Singapore; SITA; Sweden; Thailand; The Netherlands; UK-Anne Cassidy; UK-John Elwell; UK-Peter Gibbon; Ukraine1; Ukraine2; UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; USA-Geoff Thompso; Yugoslavia Subject: (jtc1sc06.144) Announcement of Document Availability ANNOUNCEMENT OF DOCUMENT AVAILABILITY ========================================= Document Posted : SC6 N11851- N11852 ========================================= The following documents are now available from the JTC1/SC6 web site : http://www.jtc1sc06.org ------------------------------------------ ------------------------------------------ Document Number : 11851 Replaces : Document Type : Summary of Voting/Table of Replies Date Assigned : 2001-02-16 Document Title : Summary of Voting on SC 6 N 11704, Text for FCD Ballot or Comment, ISO/IEC FCD 10589 Due Date : Pages : 2 Source : SC6 Secretariat Project Number : Status : For consideration by the Project Editor and SC 6/WG 7 Action ID : ACT ------------------------------------------- ------------------------------------------- Document Number : 11852 Replaces : Document Type : Meeting Announcement Date Assigned : 2001-02-16 Document Title : Calling Notice from the SC 6/WG 7 ASN.1 Meeting, 5-9 March 2001, Bowdon, UK Due Date : Pages : 1 Source : ASN.1 Rapporteur Project Number : Status : For information Action ID : FYI --------------------------------------------- --------------------------------------------- =============================== Ms. Jooran Lee JTC1/SC6 Secretariat Korean Standards Association Phone: +82 2 369 8308 Fax: +82 2 369 8349 Email: secretariat@jtc1sc06.org http://www.jtc1sc06.org =============================== ------=_NextPart_000_0010_01C09F10.AA634720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: SC6 Secretariat=20 [mailto:secretariat@jtc1sc06.org]
Sent: Friday, February 23, = 2001=20 9:09 PM
To: David Oran
Subject: Re: How can we = access these=20 documents?

Dear Dave Oran,
 
To download the documents = from the SC6=20 website
you need
 
Login ID : = Jtc1sc06
Password : sc06
 
Best wishes,
Jooran Lee
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Ms. Jooran=20 Lee
JTC1/SC6 Secretariat
Korean Standards Association
Phone: = +82 2 369=20 8308
Fax: +82 2 369 8349
Email: secretariat@jtc1sc06.org
= http://www.jtc1sc06.org
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
----- Original = Message -----
From:=20 David = Oran
Sent: = Saturday, February 24, 2001 3:48=20 AM
Subject: How can we access these=20 documents?

We=20 need them for the work of the ISIS working group in = IETF.
 
Any=20 help would be greatly appreciated.
 
Regards,
 
Dave=20 Oran.
Area=20 Director
Routing
Internet Engineering Steering Group
 
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent:= =20 Monday, February 19, 2001 6:02 AM
To: David = Oran
Cc: micah=20 Bartell
Subject: Re: [Isis-wg] FW: (jtc1sc06.144) = Announcement of=20 Document=20 = Availability

Dave,
    =     Is=20 there a way to actually see the SoV document. It seems to want an = authorized=20 = login.

                Mike
At=20 09:21 17/02/2001 -0500, you wrote:
SC6=20 voting on update to ISIS.
 
-----Original Message-----
From: SC6 Secretariat = [mailto:secretariat@jtc1sc06.org]
Sent:=20 Friday, February 16, 2001 5:42 AM
To: Argentina; ASN.1-J.=20 Larmouth; ASTM-Teresa J Cen; ATM Forum; Australia; Austria; = Austria2; B.=20 Scott; B. Wood; Belgium; Brazil; Canada; China; Columbia; Czech = Republic;=20 Czech Republic2; Czech Republic3; Denmark; ECMA-Isabelle Walc;=20 ETSI-Christian Julien; Finland; Frame Relay Forum; France1; Germany; = Greece;=20 Greg Smith; Hoyt Kesterson; Hungary; ICAO-Albert Pelsser; ICAO-Lyse=20 Boisvert; Iceland; IEEE 802-Chair; IEEE-Denise Pribula; IEEE-Robert=20 Pritchar; IETF (PKIX); IETF (PKIX)2; IETF (Routeing); IETF = (Routeing)2; IETF=20 (Transport); IETF (Transport)2; INTELSAT-Colin Am; Ireland;=20 ISO/TC68/SC2-Philli; ISOC; Italy1; Italy2; ITTF-Keith Brannon; ITU-T = SG=20 11-TSB; ITU-T SG 16 WP 1; ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack=20 Houldsworth; Jan van den Beld; Japan; Jim Long; Joon-Nyun Kim; KATS; = New=20 Zealand; Norway; OIW-Fred Burg; Oliver Dubuisson; Phillipines; = Poland1;=20 Poland2; Portugal; Dae-Young Kim; Republic of Korea2; Romania; = Russian=20 Federation; S. J. Koh; SC 25-D. Popovic; SC25-Walter von Patt; = SC29-Yukiko=20 Ogura; SC31-Maria Schneid; Singapore; SITA; Sweden; Thailand; The=20 Netherlands; UK-Anne Cassidy; UK-John Elwell; UK-Peter Gibbon; = Ukraine1;=20 Ukraine2; UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; USA-Geoff = Thompso;=20 Yugoslavia
Subject: (jtc1sc06.144) Announcement of = Document=20 Availability

ANNOUNCEMENT OF DOCUMENT=20 = AVAILABILITY

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= Document=20 Posted : SC6 N11851-=20 = N11852
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The = following=20 documents are now available from the JTC1/SC6 web site :
http://www.jtc1sc06.org

-----= -------------------------------------
 
----------------------= --------------------

Document=20 Number : 11851
Replaces :
Document Type : Summary of = Voting/Table of=20 Replies
Date Assigned : 2001-02-16
Document Title :  = Summary of=20 Voting on SC 6 N 11704,
Text for FCD Ballot or = Comment,=20 ISO/IEC FCD=20 = 10589           =20
Due Date :
Pages : 2
Source : SC6 Secretariat
Project = Number=20 :
Status : For consideration by the Project Editor and SC 6/WG=20 7
Action ID :=20 = ACT

-------------------------------------------

-----------= --------------------------------

Document=20 Number : 11852
Replaces :
Document Type : Meeting = Announcement
Date=20 Assigned : 2001-02-16
Document Title : Calling Notice from the SC = 6/WG 7=20 ASN.1 Meeting,
5-9 March 2001, Bowdon, = UK
Due=20 Date :
Pages : 1
Source : ASN.1 Rapporteur
Project Number=20 :
Status : For information
Action ID :=20 = FYI

---------------------------------------------

---------= ------------------------------------
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Ms. Jooran Lee
JTC1/SC6=20 Secretariat
Korean Standards Association
Phone: +82 2 369 = 8308
Fax:=20 +82 2 369 8349
Email: secretariat@jtc1sc06.org
= http://www.jtc1sc06.org
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------=_NextPart_000_0010_01C09F10.AA634720-- From akyol@pluris.com Tue Feb 27 18:57:36 2001 From: akyol@pluris.com (Bora Akyol) Date: Tue, 27 Feb 2001 10:57:36 -0800 Subject: [Isis-wg] Interest in Supporting PTP Behavior on LAN Media in IS-IS? In-Reply-To: <94B9091E1149D411A45C00508BACEB359CD864@entmail.gnilink.com> References: <94B9091E1149D411A45C00508BACEB359CD864@entmail.gnilink.com> Message-ID: What's wrong with using PPP over Ethernet to achieve what you want without changing anything else? This is why PPPoE was invented. Bora At 1:51 AM -0500 2/25/01, Martin, Christian wrote: >Folks, > >I know that over the years, the idea of supporting NBMA interfaces has been >tossed around the IS-IS community with little interest generated. I assume >that the idea was spurred by the need to support partial-mesh, switched >WANs, such as Frame Relay. The argument aginst this support was that these >media could be made into PTP media through static PVCs, at the expense of >address space. Recently, I have been wondering about the utility of >supporting directed, PTP adjacencies over high-speed LAN interfaces, in an >attempt to provide deterministic, per-adjacency metric state. Since I have >no experience in IS-IS protocol development, I was hoping those who have can >enlighten me on the level of difficulty required to produce such an >implementation, before I embark on authoring or co-authoring a draft. Is >there any interest (outside my own), in supporting per adjacency state >across LAN media? Perhaps an example would help illuminate the need as I >see it. > > >Today's ISP POP architecture is often built using PTP POS trunks between all >core routers in the POP. Edge/Aggregation routers are often redundnatly >uplinked to multiple core routers via POS interfaces as well. In many >cases, POS links may be substituted by ATM PVCs, but this case diminishes as >bandwidth needs rise, and it still looks as if no vendor has any interest in >building OC-48 or higher SARs. Give N core routers and M Edge/Aggregation >routers, such an architecture requires N(N-1) + N(M+N) = 2N^2 + N(M-1) POS >interfcaes per POP. Given the minimum required number of nodes and links >needed for edge and core redundancy, M = N = 2, which results in 10 POS >ports. Since many ISP POPs have N >= 3 and M >= 10, this yields a minimum >45 POS ports per POP. At OC-48/192 speeds for N-N connectivity, and >OC-48/12 speeds for N-M connectivity, this results in N(N-1)*cost> + N(N + M)*routers. > > >A less optimal, but much more cost effective approach would be to use 10GigE >interfaces instead of OC192/48 interfaces, and GigE instead of OC-48/12 >interfaces. By linking each device tigether through a pair of redundant >GigE switches, the number of GigE ports on the routers reduce to 2(N + M), >and the cost reduces to 2N + 2(N+M), >plus 2(N+M) cost of GigE ports on the switches (which is generally an order >of magnitude less than the cost of router ports of the same type when the >switch density is high, utilization-wise). This obviously has significant >advantages cost-wise, but there are glaring disadvantages technology-wise. >In particular, link restoration mechanisms inherent in SONET are not >available, as is end-to-end link management in general, thus requireing >reliance upon proptocol adjacency state to detect remote link trouble. TE >may be more difficult across shared LAN media as well, however, I cannot >substantiate this claim from experience. In particular, though, all routers >adjacent over the same subnetwork share the same metric. This subtle >deficiency is exasperated when routers have different link speeds (and thus) >metrics into the switch fabric. This particular deficiency renders IGP TE >using metrics impossible. > >A potential solution to this problem would be to create Z=[N(N-1) + N(N + >M)]/2 VLANs through the switch fabric, and connect the routers over /30 or >/31 subnetworks. However, this causes the creation Z pseudonodes in the >IS-IS domain. Given an ISP backbone consisting of N = 100 and M =200, this >requires 19950 pseudonodes which has obvious drawbacks, even given the >ability to support more than 255 pseudonodes as recently proposed. > >What would be nice would be one of two things: > >1) Allow an operator to selectively turn LAN-based media into PTP links as >seen by IS-IS. >2) Allow an operator to selectively define neighbors across LAN media and >associate metrics to each neighbor. > >As I see it, both have pros and cons. 1) makes it easier on the operator, >as he/she only needs to set the link type to PTP, and the rest of the >configuration would be akin to real PTP interfaces. However, it requires >the CLNS/IS-IS stack to be able to discover IS-IS (trivial) nodes and direct >IS-IS PDUs at it and only it, which sems non-trivial (this is where I need >assistance from the dvelopers). 2) makes it easier on the developers?, but >harder on the operator, as now the operator has to explicitly define >neighbors. Another pro, however, is that this method conserves address >space, and eliminates the need to create and manage hundreds of VLANs per >switch. Finally, I know of one vendor who has done this with OSPF, although >the IP-ness of OSPF may or may not make this easier, particularly to those >vendors with no interest in supporting a full CLNP stack. > >I suppose that ES-IS could be used to resolve system IDs to MAC addresses in >2), and then IIH hellos could be hacked to use the learned MAC instead of >the standard multicast MAC addressed used in LAN IIHs. But, is this hard to >do development-wise? Is there a workable solution to 1)? Could IS-IS be >made to send IIHs on LAN media without performing DIS election? > >I sincerely hope I am not blowing a bunch of wind, but I am open to any and >all flaming if this idea is completely baseless. If there is any interest, >I'd be very willing to contribute to a draft effort. > >Best Regards, >-chris >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Radia Perlman - Boston Center for Networking Tue Feb 27 22:38:22 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Tue, 27 Feb 2001 17:38:22 -0500 (EST) Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt Message-ID: <200102272238.RAA20025@bcn.East.Sun.COM> I sent minor typos, etc., to the authors, but we had an interesting discussion about the following idea, which is now sufficiently baked to mention to the list. An extension to the problem of quickly detecting a neighbor is down, while perhaps avoiding false declarations of down if the hello process can't be immediately scheduled to sub-second timing... Suppose receipt of data on an adjacency reset the hello timer? Various thoughts on that: You might even avoid sending as many hellos, if you know that you've recently sent data to that adjacency On LANs, where the hello is multicast but data is unicast, the data to the DIS would be the data that counted, not data to some other adjacency on that LAN To allow other information in the Hello to change (area address, etc.) the sender could be required to occasionally send hellos. So, for instance, you'd want to detect him down very very quickly (so perhaps the expiration for that might be subsecond, with either hellos or data resetting that timer), but for changing the information in a hello, this would not need to be so timely...it would be OK to be tens of seconds, so the sender could postpone sending hellos for awhile, but not indefinitely, if he's sending traffic. If the info changed at a router, that router could instantly issue a hello with the new information, but since that might get lost, it's still necessary to occasionally refresh the info in the hello. So to implement this: need an option in the Hello to say "I'm cool with receipt of data messages instead of Hellos". If your neighbor says that, then you don't have to send hellos in a timely way if you're sending traffic. The receiver should reset timer on receipt of either Hello or data. The transmitter still would send Hellos periodically, but not with sub-second requirement if there's traffic. Instead, if the Holding Timer you tell your neighbor is less than, say, 5 seconds, and your neighbor is willing to accept data in lieu of Hellos, then you can postpone sending Hellos, but not longer than, say, 30 seconds. I think 5 and 30 could be architectural constants rather than yet more parameters. Radia From jlearman@cisco.com Tue Feb 27 23:07:40 2001 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 27 Feb 2001 18:07:40 -0500 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt In-Reply-To: <200102272238.RAA20025@bcn.East.Sun.COM> Message-ID: <4.3.2.7.2.20010227175640.0337fe68@dingdong.cisco.com> Perhaps I'm missing something, but ... >So to implement this: need an option in the Hello to say "I'm cool >with receipt of data messages instead of Hellos". If your neighbor >says that, then you don't have to send hellos in a timely way if >you're sending traffic. ... you don't have to send hellos in a timely way if you're sending traffic *via that adjacency*. So you'd need to keep a new timer per adjacency of when you last sent data, and send a Hello (either to that adjacency, or a broadcast) on timeout. [Sorry, I don't remember whether the original proposal indicated whether the hellos were direct or broadcast.] Is that what you mean? Thanks, Jeff From Radia Perlman - Boston Center for Networking Tue Feb 27 23:26:01 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Tue, 27 Feb 2001 18:26:01 -0500 (EST) Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt Message-ID: <200102272326.SAA20260@bcn.East.Sun.COM> I think what you said is what I mean. You would have to be aware of when you last sent something on each such adjacency to know whether you can postpone a hello on that adjacency. If you don't like that, would this be easier on the implementation? Having a nonzero queue of stuff to that adjacency would be sufficient information that you don't need to send a Hello on that adjacency. So, for instance, if the queue is empty, send a Hello...what harm is there since you're not doing anything anyway. But if the queue is nonempty, then you can skip actually transmitting that Hello. Radia X-Sender: jlearman@dingdong.cisco.com To: Radia Perlman - Boston Center for Networking From: Jeff Learman Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt Cc: isis-wg@juniper.net Mime-Version: 1.0 Perhaps I'm missing something, but ... >So to implement this: need an option in the Hello to say "I'm cool >with receipt of data messages instead of Hellos". If your neighbor >says that, then you don't have to send hellos in a timely way if >you're sending traffic. ... you don't have to send hellos in a timely way if you're sending traffic *via that adjacency*. So you'd need to keep a new timer per adjacency of when you last sent data, and send a Hello (either to that adjacency, or a broadcast) on timeout. [Sorry, I don't remember whether the original proposal indicated whether the hellos were direct or broadcast.] Is that what you mean? Thanks, Jeff From oran@cisco.com Tue Feb 27 23:40:32 2001 From: oran@cisco.com (David R. Oran) Date: Tue, 27 Feb 2001 18:40:32 -0500 Subject: FW: [Isis-wg] FW: (jtc1sc06.144) Announcement of Document Availability Message-ID: <001101c0a116$b3450010$5cfeff0a@cisco.com> This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C0A0EC.CA6EF810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: Micah Bartell [mailto:mbartell@cisco.com] Sent: Thursday, February 22, 2001 1:51 PM To: David Oran Subject: Re: [Isis-wg] FW: (jtc1sc06.144) Announcement of Document Availability David, Here is the actual results of the vote. They do not include the US vote with comments. The US voted NO on the document with significant comments. So what is actually happening with it is still unknown. If it did get voted in, that would be a *bad thing*, in which we will need to determine how to get the US and French comments reviewed and integrated. /mpb At 09:21 AM 2/17/2001 -0500, you wrote: >SC6 voting on update to ISIS. > >-----Original Message----- >From: SC6 Secretariat [mailto:secretariat@jtc1sc06.org] >Sent: Friday, February 16, 2001 5:42 AM >To: Argentina; ASN.1-J. Larmouth; ASTM-Teresa J Cen; ATM Forum; >Australia; Austria; Austria2; B. Scott; B. Wood; Belgium; Brazil; Canada; China; Columbia; Czech Republic; Czech Republic2; Czech Republic3; Denmark; ECMA-Isabelle Walc; ETSI-Christian Julien; Finland; Frame Relay Forum; France1; Germany; Greece; Greg Smith; Hoyt Kesterson; Hungary; ICAO-Albert Pelsser; ICAO-Lyse Boisvert; Iceland; IEEE 802-Chair; IEEE-Denise Pribula; IEEE-Robert Pritchar; IETF (PKIX); IETF (PKIX)2; IETF (Routeing); IETF (Routeing)2; IETF (Transport); IETF (Transport)2; INTELSAT-Colin Am; Ireland; ISO/TC68/SC2-Philli; ISOC; Italy1; Italy2; ITTF-Keith Brannon; ITU-T SG 11-TSB; ITU-T SG 16 WP 1; ITU-T SG 16-TSB; ITU-T_Herb Bertine; Jack Houldsworth; Jan van den Beld; Japan; Jim Long; Joon-Nyun Kim; KATS; New Zealand; Norway; OIW-Fred Burg; Oliver Dubuisson; Phillipines; Poland1; Poland2; Portugal; Dae-Young Kim; Republic of Korea2; Romania; Russian Federation; S. J. Koh; SC 25-D. Popovic; SC25-Walter von Patt; SC29-Yukiko Ogura; SC31-Maria Schneid; Singapore; SITA; Sweden; Thailand; The Netherlands; UK-Anne Cassidy; UK-John Elwell; UK-Peter Gibbon; Ukraine1; Ukraine2; UK-Robin Tasker; UK-Tony Jeffree; USA-ANSI; USA-Geoff Thompso; Yugoslavia >Subject: (jtc1sc06.144) Announcement of Document Availability > >ANNOUNCEMENT OF DOCUMENT AVAILABILITY > >========================================= >Document Posted : SC6 N11851- N11852 >========================================= > >The following documents are now available from the JTC1/SC6 web site : >http://www.jtc1sc06.org > >------------------------------------------ > >------------------------------------------ > >Document Number : 11851 >Replaces : >Document Type : Summary of Voting/Table of Replies >Date Assigned : 2001-02-16 >Document Title : Summary of Voting on SC 6 N 11704, >Text for FCD Ballot or Comment, ISO/IEC FCD 10589 >Due Date : >Pages : 2 >Source : SC6 Secretariat >Project Number : >Status : For consideration by the Project Editor and SC 6/WG 7 >Action ID : ACT > >------------------------------------------- > >------------------------------------------- > >Document Number : 11852 >Replaces : >Document Type : Meeting Announcement >Date Assigned : 2001-02-16 >Document Title : Calling Notice from the SC 6/WG 7 ASN.1 Meeting, >5-9 March 2001, Bowdon, UK >Due Date : >Pages : 1 >Source : ASN.1 Rapporteur >Project Number : >Status : For information >Action ID : FYI > >--------------------------------------------- > >--------------------------------------------- > >=============================== >Ms. Jooran Lee >JTC1/SC6 Secretariat >Korean Standards Association >Phone: +82 2 369 8308 >Fax: +82 2 369 8349 >Email: secretariat@jtc1sc06.org >http://www.jtc1sc06.org >=============================== ------=_NextPart_000_0012_01C0A0EC.CA6EF810 Content-Type: application/msword; name="N11851.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="N11851.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAEgAAAAAAAAAA EAAAEwAAAAEAAAD+////AAAAABEAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////c pWgAY+AJBAAAAABlAAAAAAAAgAAAAAAAAwAAqw0AAF8gAAAAAAAAAAAAAAAAAAAAAAAAqwoAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAADoDAAAAHAAAOgMAADofAAAAAAAAOh8A AAAAAAA6HwAAAAAAADofAAAAAAAAOh8AABQAAABOHwAAAAAAAE4fAAAAAAAATh8AAAAAAABOHwAA AAAAAE4fAAAAAAAATh8AAAoAAABYHwAAIgAAAE4fAAAAAAAAfB8AAEEAAAB6HwAAAAAAAHofAAAA AAAAeh8AAAAAAAB6HwAAAAAAAHofAAAAAAAAeh8AAAAAAAB6HwAAAAAAAHofAAAAAAAAeh8AAAIA AAB8HwAAAAAAAHwfAAAAAAAAfB8AAAAAAAB8HwAAAAAAAHwfAAAAAAAAfB8AAAAAAAC9HwAAWAAA ABUgAABKAAAAfB8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAOh8AAAAAAAB6HwAAAAAAAAAACAAJAAEA BQB6HwAAAAAAAHofAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHofAAAAAAAAeh8AAAAAAAB8HwAAAAAA AHofAAAAAAAAOh8AAAAAAAA6HwAAAAAAAHofAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHofAAAAAAAA eh8AAAAAAAB6HwAAAAAAAHofAAAAAAAAeh8AAAAAAAA6HwAAAAAAAHofAAAAAAAAOh8AAAAAAAB6 HwAAAAAAAHofAAAAAAAAAAAAAAAAAACA/RP5AZjAAU4fAAAAAAAATh8AAAAAAAA6HwAAAAAAADof AAAAAAAAOh8AAAAAAAA6HwAAAAAAAHofAAAAAAAAeh8AAAAAAAB6HwAAAAAAAHofAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANVGVsZWNvbW11bmljYXRpb25zIGFuZCBJbmZvcm1h dGlvbiBFeGNoYW5nZSBCZXR3ZWVuIFN5c3RlbXMNDQlJU08vSUVDIEpUQyAxL1NDIDA2IE4xMTg1 MQ0NCURhdGU6CTIwMDEtMDItMTYNDQlSZXBsYWNlczoNDQlEb2N1bWVudCBUeXBlOglTdW1tYXJ5 IG9mIFZvdGluZy9UYWJsZSBvZiBSZXBsaWVzDQ0JRG9jdW1lbnQgVGl0bGU6CVN1bW1hcnkgb2Yg Vm90aW5nIG9uIFNDIDYgTiAxMTcwNCwgVGV4dCBmb3IgRkNEIEJhbGxvdCBvciBDb21tZW50LCBJ U08vSUVDIEZDRCAxMDU4OSAgICAgICAgICAgIA0NCURvY3VtZW50IFNvdXJjZToJU0MgNiBTZWNy ZXRhcmlhdA0NCVByb2plY3QgTnVtYmVyOg0NCURvY3VtZW50IFN0YXR1czoJRm9yIGNvbnNpZGVy YXRpb24gYnkgdGhlIFByb2plY3QgRWRpdG9yIGFuZCBTQyA2L1dHIDcNDQlBY3Rpb24gSUQ6CUFD VA0NCUR1ZSBEYXRlOg0NCU5vLiBvZiBQYWdlczoJMg0NDQlTZWNyZXRhcmlhdCwgSVNPL0lFQyBK VEMgMS9TQzYsIE1zLiBKb29yYW4gTGVlLCBLU0EgKG9uIGJlaGFsZiBvZiBLQVRTKSwgMTMtMzEg WW9pZG8tZG9uZywgWW91bmdkZXVuZ3BvLWd1LCBTZW91bCwgUmVwdWJsaWMgb2YgS29yZWE7IFRl bGVwaG9uZTogIDgyIDIgMzY5IDgzMDg7IEZhY3NpbWlsZTogIDgyIDIgMzY5IDgzNDk7IEVtYWls OiAgc2VjcmV0YXJpYXRAanRjMXNjMDYub3JnDQ0MU3VtbWFyeSBvZiBWb3Rpbmcgb24gU0MgNiBO IDExNzA0IChGQ0QxMDU4OSkNDQ1OYXRpb25hbCBCb2R5DQdBcHByb3ZlB0Rpc2FwcHJvdmUHQWJz dGFpbgdDb21tZW50cwcHQXVzdHJpYQcHBwcHB0JlbGdpdW0HBwcHBwdCcmF6aWwHBwcHBwdDYW5h ZGEHBwcHBwdDaGluYQdYBwcHBwdDemVjaCBSZXB1YmxpYwdYBwcHBwdEZW5tYXJrBwcHWA0oTGFj ayBvZiBFeHBlcnRpc2UpBwcHRmlubGFuZAcHBwcHB0ZyYW5jZQcHWAcHU2VlIEF0dGFjaGVkBwdH ZXJtYW55BwcHWA0oTGFjayBvZiBFeHBlcnRpc2UpBwcHR3JlZWNlBwcHBwcHSmFwYW4HWAcHBwcH UmVwdWJsaWMgb2YgS29yZWEHWAcHBwcHVGhlIE5ldGhlcmxhbmRzBwcHBwcHUnVzc2lhbiBGZWRl cmF0aW9uBwcHBwcHU3dpdHplcmxhbmQHBwdYBwcHVWtyYWluZQcHBwcHB1VuaXRlZCBLaW5nZG9t B1gHBwcHB1VTQQcHBwcHBw0NRnJhbmNlDV9YXyAgCURJU0FQUFJPVkFMIE9GIFRIRSBEUkFGVCBG T1IgUkVBU09OUyBCRUxPVyANDV9YXyAgQWNjZXB0YW5jZSBvZiB0aGVzZSByZWFzb25zIGFuZCBh cHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZSB0ZXh0IHdpbGwgY2hhbmdlIG91ciB2b3RlIHRvIGFw cHJvdmFsDQ1GcmVuY2ggQ29tbWVudHMgb24gSVNPL0lFQyBGQ0QgMTA1ODkNDQ1EUjAzNQ0NRFIw MzUgd2FzIHN1Ym1pdHRlZCBhZ2FpbnN0IHRoZSBmaXJzdCBlZGl0aW9uIG9mIElTTyAxMDU4OS4N DVRoZSBkZWZlY3QgaXMgcmVsYXRlZCB0byB0aGUgZm9yd2FyZGluZyBvZiBlbmNhcHN1bGF0ZWQg TlBEVSBvdmVyIGEgdmlydHVhbCBMMSBwYXRoLiBBIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRo aXMgaXNzdWUgY2FuIGJlIGZvdW5kIGluIGRvY3VtZW50IFNJRi0wMTgtMTk5OCwgcDY3LTcwLiBB cyBhIHN1bW1hcnksIHRoZSBjdXJyZW50IElTTyAxMDU4OSBlZGl0aW9uIGFsbG93cyB0d28gUERJ UyB0byBlc3RhYmxpc2ggYSB2aXJ0dWFsIGxpbmsgYmV0d2VlbiB0aGVtLCBpbiBvcmRlciB0byBy ZXBhaXIgYSBzcGxpdCBhcmVhLCB3aGlsZSB0aGV5IGNhbiBub3QgZXhjaGFuZ2UgZW5jYXBzdWxh dGVkIE5QRFVzIGFjcm9zcyB0aGUgbGV2ZWwgMiBzdWJkb21haW4uDQ1BIHNvbHV0aW9uIHRvIHRo aXMgZGVmZWN0IHJlcG9ydCB3YXMgcHJvcG9zZWQgaW4gZG9jdW1lbnQgNk4gMTA4MDEgKERDT1Ig NikuIFRoZSBwcm9wb3NlZCB0ZXh0IHdhcyBwYXJ0IG9mIHRoZSBwcmV2aW91cyBkcmFmdCBvZiB0 aGUgc2Vjb25kIGVkaXRpb24gb2YgSVNPIDEwNTg5ICh0aGlzIGRyYWZ0IHdhcyByZWplY3RlZCBz b21lIHRpbWUgYWdvKS4NRnJhbmNlIHByb3Bvc2VzIHRvIGludGVncmF0ZSB0aGlzIHRleHQgaW4g dGhlIGN1cnJlbnQgZHJhZnQgb2YgdGhlIHNlY29uZCBlZGl0aW9uIG9mIElTTyAxMDU4OS4NDUNv bXB1dGF0aW9uIG9mIGFyZWEgYWRkcmVzc2VzDQ1TSUYgZG9jdW1lbnQgU0lGLUFSLTk5MDUtMDU2 IGlkZW50aWZpZXMgYW4gaXNzdWUgdGhhdCBvY2N1cnMgYWZ0ZXIgYW4gYXJlYSBoYXMgc3BsaXQ6 IHRoZSBjdXJyZW50IGVkaXRpb24gb2YgSVNPIDEwNTg5IHN0YXRlcyB0aGF0IHRoZSBzZXQgb2Yg YXJlYSBhZGRyZXNzZXMgZm9yIGFuIGFyZWEgaXMgY29tcHV0ZWQgYmFzZWQgb24gYWRkcmVzc2Vz IGFkdmVydGlzZWQgYnkgYWxsIGxldmVsIDEgTFNQcyBmb3VuZCBpbiB0aGUgbG9jYWwgTFNQIGRh dGFiYXNlLiBIb3dldmVyLCBhZnRlciBhbiBhcmVhIGhhcyBzcGxpdCwgTDEgTFNQcyBvcmlnaW5h dGluZyBmcm9tIElTcyB0aGF0IGFyZSBubyBsb25nZXIgcmVhY2hhYmxlIHZpYSBMMSByb3V0aW5n IChhbmQgdGhhdCByZW1haW4gaW4gdGhlIGxvY2FsIGRhdGFiYXNlIHVudGlsIHRoZXkgcmVhY2gg TWF4QWdlKSwgc2hvdWxkIG5vdCBiZSB1c2VkIGZvciBhcmVhIGFkZHJlc3NlcyBjb21wdXRhdGlv bi4NDUZyYW5jZSBwcm9wb3NlcyB0byBpbnRlZ3JhdGUgdGhlIHRleHQgcHJvcG9zZWQgaW4gdGhp cyBTSUYgZG9jdW1lbnQgaW50byB0aGUgY3VycmVudCBkcmFmdCBvZiB0aGUgc2Vjb25kIGVkaXRp b24gb2YgSVNPIDEwNTg5Lg0NDS4NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO4AoQEApNAv peA9pggHpwgHqKAFqaAFqgAAhdT/AgAAAAABgAAAAQBoAXgA/wEAAAAAAwAAAAEAaAF4AP8BAAgA AAMAAAABAGgBeAD/AQAIAAABAAAAAQBoAXgA/wEACAAAAYAAAAEAsAF4AP8BAAgAAAMAAAABAGgB eAD/AQAIAAADAAAAAQBoAXgA/wEACAAAAQAAAAEAaAF4AP8BAAgAAAEAAAABAGgBeAAAAAAAIF8/ Pz9fPz8/PygpKCkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAEDAAA9 AwAAPwMAAFoDAABcAwAAYQMAAGIDAABtAwAAbwMAAHoDAAB7AwAAiQMAAIoDAACuAwAArwMAAL4D AAC/AwAAIAQAACIEAAAyBAAAMwQAAEQEAABGBAAAVgQAAFgEAABoBAAAaQQAAJ8EAAChBAAAqwQA AKwEAACwBAAAsgQAALwEAAC+BAAAywQAAM0EAADOBAAA0QQAAK4FAADdBQAA3wUAABMGAABsBwAA cwcAAKQHAACmBwAACwgAADIIAAA0CAAAOggAADsIAAB3CAAA9gkAAMAKAAAhCwAAPwsAAKkNAACr DQAA8A4AAPz3APIA9wDwAPcA9wDwAPcA8AD3APAA9wD3APAA9wDwAPcA9wDwAO787Ons5QDj8ODe AN4A3gDeAN4A3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACdQEAA2MWAAVVgWMcAANdAAAHVYFeAWMc AAVVgWMYAANjGAADYxIAA10CAAhVgV0CAGMcAAAIVYFdAgBjGAAABVWBYyAAADwAAwAAAQMAAD0D AAA+AwAAWgMAAFsDAABtAwAAbgMAAHkDAAB6AwAArQMAAK4DAAAgBAAAIQQAAEQEAABFBAAAVgQA AFcEAACfBAAAoAQAALAEAACxBAAAvAQAAL0EAADOBAAAzwQAANAEAACuBQAArwUAAN0FAADeBQAA 3wUAAO0FAADuBQAA9gUAAAEGAAAJBgAAEgYAAP0AAAAAAAD3AAAAAAAA9QAAAAAAAPcAAAAAAAD3 AAAAAAAA7gAAAAAAAPUAAAAAAAD3AAAAAAAA9wAAAAAAAO4AAAAAAADuAAAAAAAA5AAAAAAAAPUA AAAAAADuAAAAAAAA9QAAAAAAAPcAAAAAAAD1AAAAAAAA5AAAAAAAAOQAAAAAAADuAAAAAAAA9QAA AAAAAPcAAAAAAAD1AAAAAAAA7gAAAAAAAPUAAAAAAAD1AAAAAAAA3gAAAAAAAP0AAAAAAAD9AAAA AAAA9QAAAAAAAPUAAAAAAADaAAAAAAAA2gAAAAAAANoAAAAAAADaAAAAAAAA2gAAAAAAANoAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAABQEYAQAFAAAPBQABkBUBAAAJAAARIA0T4PIP CAAC4AMgDQAAAAYAAA8IAALgAyANAAAAAQAAAAUAAA8FAAHgAwAAAAIAAAUBJRIGAAATBgAAGwYA ABwGAAAdBgAAHgYAAB8GAAAgBgAAKAYAACkGAAAqBgAAKwYAACwGAAAtBgAANAYAADUGAAA2BgAA NwYAADgGAAA5BgAAQAYAAEEGAABCBgAAQwYAAEQGAABFBgAASwYAAE0GAABOBgAATwYAAFAGAABR BgAAYAYAAGIGAABjBgAAZAYAAGUGAABmBgAAbgYAAG8GAABwBgAA6gAAAAAAAOcAAAAAAADjAAAA AAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA4wAAAAAAAOMAAAAA AADjAAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA6gAAAAAA AOcAAAAAAADjAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA 4wAAAAAAAOMAAAAAAADjAAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA4wAAAAAAAOMAAAAAAADj AAAAAAAA6gAAAAAAAOcAAAAAAADjAAAAAAAA4wAAAAAAAAAAAAAAAAAAAAADAAAFARgBAAIAABgB ABUAABgBGQG4bAC99AG7CQAJAAkACQAJAAkAvg4ABZT/+AdqDVUUQBsrIgAocAYAAHIGAACGBgAA hwYAAIgGAACQBgAAkQYAAJIGAACTBgAAlAYAAJUGAACcBgAAnQYAAJ8GAACgBgAArQYAAK4GAAC2 BgAAtwYAALgGAAC6BgAAzgYAAM8GAADQBgAA1wYAANgGAADZBgAA2gYAANsGAADcBgAA4gYAAOQG AADlBgAA5gYAAOcGAADoBgAA+gYAAPwGAAD9BgAA/gYAAP8GAAD8AAAAAAAA/AAAAAAAAPwAAAAA AADmAAAAAAAA4wAAAAAAAPwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAADmAAAAAAAA4wAAAAAA APwAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAADmAAAAAAAA4wAAAAAAAPwAAAAAAAD8AAAAAAAA /AAAAAAAAPwAAAAAAAD8AAAAAAAA5gAAAAAAAOMAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8 AAAAAAAA5gAAAAAAAOMAAAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAA5gAAAAAAAOMA AAAAAAD8AAAAAAAA/AAAAAAAAPwAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAIAABgBABUAABgBGQG4 bAC99AG7CQAJAAkACQAJAAkAvg4ABZT/+AdqDVUUQBsrIgAAAwAABQEYASj/BgAAAAcAABAHAAAR BwAAEgcAABMHAAAUBwAAFQcAACgHAAApBwAAKgcAACsHAAAsBwAALQcAADkHAAA6BwAAOwcAAD0H AAA+BwAAPwcAAEcHAABIBwAASQcAAEoHAABLBwAATAcAAFsHAABdBwAAXgcAAF8HAABgBwAAYQcA AGUHAABmBwAAZwcAAGgHAABpBwAAagcAAGsHAABsBwAAcwcAAOoAAAAAAADnAAAAAAAA4wAAAAAA AOMAAAAAAADjAAAAAAAA4wAAAAAAAOoAAAAAAADnAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA 4wAAAAAAAOoAAAAAAADnAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA4wAAAAAAAOoAAAAAAADn AAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA4wAAAAAAAOoAAAAAAADnAAAAAAAA4wAAAAAAAOMA AAAAAADjAAAAAAAA4wAAAAAAAOoAAAAAAADnAAAAAAAA4wAAAAAAAOMAAAAAAADjAAAAAAAA4wAA AAAAAOoAAAAAAADhAAAAAAAA4QAAAAAAAOEAAAAAAAAAAAAAAAABAAAAAwAABQEYAQACAAAYAQAV AAAYARkBuGwAvfQBuwkACQAJAAkACQAJAL4OAAWU//gHag1VFEAbKyIAKHMHAAClBwAApgcAAAwI AAANCAAAMggAADMIAAA0CAAAOggAADsIAAB3CAAAeAgAAPUJAAD2CQAAwAoAACALAAAhCwAAPwsA AEALAAAnDQAAKA0AAKcNAACoDQAAqQ0AAKsNAAD+AAAAAAAA/gAAAAAAAPsAAAAAAAD4AAAAAAAA +AAAAAAAAPsAAAAAAAD7AAAAAAAA9QAAAAAAAPsAAAAAAADzAAAAAAAA+wAAAAAAAPsAAAAAAAD7 AAAAAAAA8wAAAAAAAPsAAAAAAAD7AAAAAAAA8QAAAAAAAPsAAAAAAAD7AAAAAAAA+wAAAAAAAPsA AAAAAAD7AAAAAAAA7wAAAAAAAOsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AwAAEdACAAABAAAAAQEAAAERAAACAQAFAwACAAAFAQACAAAFAwABGgAYDgAbAAgAAQBLAA8AAAAA ABoAAEDx/wIAGgAGTm9ybWFsAAIAAAADAGEJBAAiAAFAAQACACIACUhlYWRpbmcgMQAABAABAAgB BQBeAWMcAAAiAAJAAQACACIACUhlYWRpbmcgMgAABAACAAgBBQBVgWMWAAAkAANAAQACACQACUhl YWRpbmcgMwAABAADAAgBBwBVgV4BYxwAACIABEABAAIAIgAJSGVhZGluZyA0AAAEAAQACAEFAFWB YxgAAAAAAAAAAAAAAAAiAEFA8v+hACIAFkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQAAAAAAAAAAAAA ADQAPkABAAIANAAFVGl0bGUAABoADwAFARVIAxbgAQ8OAAQaA6cENAbBBwAAAAAFAFWBYyQAADoA /k8BAAIBOgAGYnVsbGV0ACUAEAAFAxGABBNQ/hQ5/wAAFXgADxEABRoDgASnBDQGwQcAAAAAAAAA AB4AQkABABIBHgAJQm9keSBUZXh0AAACABEAAwBjFgAAKAD+TwEAIgEoAAtBU04uMSBDb250LgAA BwASAAUDEaAFAAUAVYFjEgAAKgD+TwEAMgEqAAZOb3RlIDMAEQATAAUDBwERwgUUOf8AABU8AAAD AGMSAAAwAP5PIQACADAACkhlYWRpbmcgMkEAFwAUAAUDFTkBDw4ABBoDpwQ0BsEHAAAAAAAAADYA /k8BAFIBNgAHTGV2ZWwgMwAAIAAVAAUDFYgADxcAB9ACGANgA/ADpwQ0BsEHAAAAAAAAAAAANAD+ TwEAYgE0AAdMZXZlbCA0AAAaABYABQMVeAAPEQAFGAOEA6cENAbBBwAAAAAAAwBhCQgAOgD+TwEA cgE6AAdMZXZlbCA1AAAgABcABQMR8AMTEPwVeAAPEQAFGgPwA6cENAbBBwAAAAAAAwBhCQgANgAe QAEAggE2AA9Bbm5vdGF0aW9uIFRleHQAABcAGAAFAxWIAA8OAAQaA6cENAbBBwAAAAAAAAAgAP5P AQCSASAAC0JvZHkgVGV4dCAyAAAFABkAEdACAAAAJgD+TwEAogEmAAtCb2R5IFRleHQgMgAACAAa ABHQAhMw/QMAXQIAAAAAAACrCgAAAwAADgAAAQD/////AAMAAPAOAAAIAAADAAASBgAAcAYAAP8G AABzBwAAqw0AAAkACgALAAwADQD/QEEAFRKQAQAAVGltZXMgTmV3IFJvbWFuAAwQkAECAFN5bWJv bAALIpABAABBcmlhbAAPApABAgBXaW5nZGluZ3MAIgAEAAAAgBgA8NACAABoAQAAAACZhFKm04RS pl1dMSYLACEAAACLAQAAzAgAAAEABAAAAAQAgxASAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAAAAA APAQAEoAAAAiU3VtbWFyeSBvZiBWb3Rpbmcgb24gRG9jdW1lbnQgNiBOIAAAAApKb29yYW4gTGVl Ckpvb3JhbiBMZWUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUA AAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAAP7////9////FQAA AP7///8dAAAA/v/////////////////////////////////////////+//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf////////// AQAAAAAJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACA/RP5AZjAARQAAACAAwAAAAAAAFcAbwBy AGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAaAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF8gAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAagAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////8EAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADcAQAAAAAAAAEAAAD+////AwAAAAQAAAAFAAAA BgAAAAcAAAAIAAAACQAAAP7///8LAAAADAAAAA0AAAD+//////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////AQD+/wMKAAD/////AAkCAAAAAADA AAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3Jk LkRvY3VtZW50LjYA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoC AAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACsAQAAEgAAAAEAAACYAAAA AgAAAKAAAAADAAAAzAAAAAQAAADYAAAABQAAAOwAAAAGAAAA+AAAAAcAAAAEAQAACAAAABQBAAAJ AAAAKAEAABIAAAA0AQAACgAAAFwBAAALAAAAaAEAAAwAAAB0AQAADQAAAIABAAAOAAAAjAEAAA8A AACUAQAAEAAAAJwBAAATAAAApAEAAAIAAAC1AwAAHgAAACMAAABTdW1tYXJ5IG9mIFZvdGluZyBv biBEb2N1bWVudCA2IE4gAAAeAAAAAQAAAADaQgAeAAAACwAAAEpvb3JhbiBMZWUAAB4AAAABAAAA AABkAB4AAAABAAAAAP7/AB4AAAAHAAAATm9ybWFsAAAeAAAACwAAAEpvb3JhbiBMZWUAAB4AAAAD AAAAMTEAAB4AAAAeAAAATWljcm9zb2Z0IFdvcmQgZm9yIFcFAEQAbwBjAHUAbQBlAG4AdABTAHUA bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAADgAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////wYJAgAAAAAAwAAA AAAAAEYUAAAATWljcm9zb2Z0IFdvcmQgua68rQAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3Vt ZW50LjgA9DmycQAAAAAAAAAAAAAAAAAADAAAAHQAAAACAAAAtQMAAB4AAAAEAAAAS1NBAAMAAAAS AAAAAwAAAAQAAAALAAAAAAAAAAsAAAAAAAAADBAAAAIAAAAeAAAAIwAAAFN1bW1hcnkgb2YgVm90 aW5nIG9uIERvY3VtZW50IDYgTiAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaW5kb3dzIDk1AAAAQAAAAAAGLJwEAAAAQAAAAADO G/ddPb4BQAAAAAC+l1X6l8ABQAAAAACCyOABmMABAwAAAAEAAAADAAAAiwEAAAMAAADMCAAAAwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAA AAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAACwAAAABwAAAAEAAABAAAAADwAAAEgAAAAF AAAAVAAAAAYAAABcAAAACwAAAGQAAAAQAAAAbAAAAAwAAAB0AAAAAgAAALUDAAAeAAAABAAAAEtT QQADAAAAEgAAAAMAAAAEAAAACwAAAAAAAAALAAAAAAAAAAwQAAACAAAAHgAAACMAAABTdW1tYXJ5 IG9mIFZvdGluZyBvbiBEb2N1bWVudCA2IE4gAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0012_01C0A0EC.CA6EF810 Content-Type: text/plain; name="ATT01250.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01250.txt" -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer Phone: 469.255.1806 SP-Advanced Network Services Cisco Systems, Inc -- The Network Works, No Excuses ------=_NextPart_000_0012_01C0A0EC.CA6EF810-- From ginsberg@pluris.com Wed Feb 28 01:47:19 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Tue, 27 Feb 2001 17:47:19 -0800 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.tx t Message-ID: <17C81AD1F1FED411991E006008F6D1CA055DCA@avalon.pluris.com> The requirements seem to me to actually be more complex than that. Not only do you have to track when you sent/received data, but also presumably the protocol i.e. it has to be the protocol(s) IS-IS is supporting - assuming you still care about CLNP at all. Further, if the IS-IS engine crashes on one end but the forwarding plane keeps working, then the adjacency is maintained until the much slower hello timer expires - which means you don't have fast detection any more. This linkage of control and data plane seems conceptually flawed. It is certainly ugly to implement in a distributed architecture - and not all that wonderful in a non-distributed architecture. There must be better ways to solve this problem than adding this baggage to the forwarding plane. Les > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Tuesday, February 27, 2001 3:08 PM > To: Radia Perlman - Boston Center for Networking > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] comment on > draft-parker-short-isis-hold-times-00.txt > > > > Perhaps I'm missing something, but ... > > >So to implement this: need an option in the Hello to say "I'm cool > >with receipt of data messages instead of Hellos". If your neighbor > >says that, then you don't have to send hellos in a timely way if > >you're sending traffic. > > ... you don't have to send hellos in a timely way if you're sending > traffic *via that adjacency*. So you'd need to > keep a new timer per adjacency of when you last sent data, and send > a Hello (either to that adjacency, or a broadcast) on timeout. > [Sorry, I don't remember whether the original proposal indicated > whether the hellos were direct or broadcast.] > > Is that what you mean? > > Thanks, > Jeff > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From dkatz@juniper.net Wed Feb 28 01:55:04 2001 From: dkatz@juniper.net (Dave Katz) Date: Tue, 27 Feb 2001 17:55:04 -0800 (PST) Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt In-Reply-To: <200102272326.SAA20260@bcn.East.Sun.COM> (message from Radia Perlman - Boston Center for Networking on Tue, 27 Feb 2001 18:26:01 -0500 (EST)) Message-ID: <200102280155.RAA16380@cirrus.juniper.net> All of this is a tad trickier in routers with silicon-based forwarding. Note that this still requires a sufficiently lively scheduler to make sure things happen within tight timeframes, which is the biggest impediment to this subsecond stuff. X-JNPR-Received-From: outside From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Cc: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Es5/WdGPyzDkEWfIBuXoJA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 27 Feb 2001 18:26:01 -0500 (EST) I think what you said is what I mean. You would have to be aware of when you last sent something on each such adjacency to know whether you can postpone a hello on that adjacency. If you don't like that, would this be easier on the implementation? Having a nonzero queue of stuff to that adjacency would be sufficient information that you don't need to send a Hello on that adjacency. So, for instance, if the queue is empty, send a Hello...what harm is there since you're not doing anything anyway. But if the queue is nonempty, then you can skip actually transmitting that Hello. Radia X-Sender: jlearman@dingdong.cisco.com To: Radia Perlman - Boston Center for Networking From: Jeff Learman Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt Cc: isis-wg@juniper.net Mime-Version: 1.0 Perhaps I'm missing something, but ... >So to implement this: need an option in the Hello to say "I'm cool >with receipt of data messages instead of Hellos". If your neighbor >says that, then you don't have to send hellos in a timely way if >you're sending traffic. ... you don't have to send hellos in a timely way if you're sending traffic *via that adjacency*. So you'd need to keep a new timer per adjacency of when you last sent data, and send a Hello (either to that adjacency, or a broadcast) on timeout. [Sorry, I don't remember whether the original proposal indicated whether the hellos were direct or broadcast.] Is that what you mean? Thanks, Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From akyol@pluris.com Wed Feb 28 04:09:08 2001 From: akyol@pluris.com (Bora Akyol) Date: Tue, 27 Feb 2001 20:09:08 -0800 (PST) Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt In-Reply-To: <200102280155.RAA16380@cirrus.juniper.net> Message-ID: I would second Dave here, keeping these timers on a per next hop basis and then generating these interrupts when these timers expire while doing line rate forwarding is a tad tricky. On a SONET link, it is fairly easy to detect that your neighbor has gone down and notify your peers. On an ethernet I do recognize this gets harder, but can we make do with a software based keep-alive mechanism that doesn't involve the forwarding plane? Regards Bora On Tue, 27 Feb 2001, Dave Katz wrote: > All of this is a tad trickier in routers with silicon-based forwarding. > > Note that this still requires a sufficiently lively scheduler to make > sure things happen within tight timeframes, which is the biggest impediment > to this subsecond stuff. > > > X-JNPR-Received-From: outside > From: Radia Perlman - Boston Center for Networking > Reply-To: Radia Perlman - Boston Center for Networking > Cc: isis-wg@juniper.net > MIME-Version: 1.0 > Content-Type: TEXT/plain; charset=us-ascii > Content-MD5: Es5/WdGPyzDkEWfIBuXoJA== > X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Tue, 27 Feb 2001 18:26:01 -0500 (EST) > > I think what you said is what I mean. You would have to be > aware of when you last sent something on each such adjacency to know > whether you can postpone a hello on that adjacency. > > If you don't like that, would this be easier on the implementation? > Having a nonzero queue > of stuff to that adjacency would be sufficient information that > you don't need to send a Hello on that adjacency. So, for instance, > if the queue is empty, send a Hello...what harm is there since you're > not doing anything anyway. But if the queue is nonempty, then you > can skip actually transmitting that Hello. > > Radia > > X-Sender: jlearman@dingdong.cisco.com > To: Radia Perlman - Boston Center for Networking > From: Jeff Learman > Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt > Cc: isis-wg@juniper.net > Mime-Version: 1.0 > > > Perhaps I'm missing something, but ... > > >So to implement this: need an option in the Hello to say "I'm cool > >with receipt of data messages instead of Hellos". If your neighbor > >says that, then you don't have to send hellos in a timely way if > >you're sending traffic. > > ... you don't have to send hellos in a timely way if you're sending > traffic *via that adjacency*. So you'd need to > keep a new timer per adjacency of when you last sent data, and send > a Hello (either to that adjacency, or a broadcast) on timeout. > [Sorry, I don't remember whether the original proposal indicated > whether the hellos were direct or broadcast.] > > Is that what you mean? > > Thanks, > Jeff > > > _______________________________________________ > 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 mshand@cisco.com Wed Feb 28 11:05:48 2001 From: mshand@cisco.com (mike shand) Date: Wed, 28 Feb 2001 11:05:48 +0000 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.tx t In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA055DCA@avalon.pluris.com> Message-ID: <4.3.2.7.2.20010228105857.03384e30@jaws.cisco.com> I agree. This worked very well in DECnet PhaseIV, but it may be somewhat ugly in modern system architectures. However can it be done by accessing the counter which the forwarding plane presumably already keeps for "management" purposes? I guess that depends on whether the counter can be polled every few hundred milliseconds. Mike At 17:47 27/02/2001 -0800, Les Ginsberg wrote: >The requirements seem to me to actually be more complex than that. Not only >do you have to track when you sent/received data, but also presumably the >protocol i.e. it has to be the protocol(s) IS-IS is supporting - assuming >you still care about CLNP at all. Further, if the IS-IS engine crashes on >one end but the forwarding plane keeps working, then the adjacency is >maintained until the much slower hello timer expires - which means you don't >have fast detection any more. > >This linkage of control and data plane seems conceptually flawed. It is >certainly ugly to implement in a distributed architecture - and not all that >wonderful in a non-distributed architecture. > >There must be better ways to solve this problem than adding this baggage to >the forwarding plane. > > Les > > > > > -----Original Message----- > > From: Jeff Learman [mailto:jlearman@cisco.com] > > Sent: Tuesday, February 27, 2001 3:08 PM > > To: Radia Perlman - Boston Center for Networking > > Cc: isis-wg@juniper.net > > Subject: Re: [Isis-wg] comment on > > draft-parker-short-isis-hold-times-00.txt > > > > > > > > Perhaps I'm missing something, but ... > > > > >So to implement this: need an option in the Hello to say "I'm cool > > >with receipt of data messages instead of Hellos". If your neighbor > > >says that, then you don't have to send hellos in a timely way if > > >you're sending traffic. > > > > ... you don't have to send hellos in a timely way if you're sending > > traffic *via that adjacency*. So you'd need to > > keep a new timer per adjacency of when you last sent data, and send > > a Hello (either to that adjacency, or a broadcast) on timeout. > > [Sorry, I don't remember whether the original proposal indicated > > whether the hellos were direct or broadcast.] > > > > Is that what you mean? > > > > Thanks, > > Jeff > > > > _______________________________________________ > > 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 Wed Feb 28 11:55:30 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 28 Feb 2001 06:55:30 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-00.txt Message-ID: <200102281155.GAA02125@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-00.txt Pages : 7 Date : 27-Feb-01 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-00.txt 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-00.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-00.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: <20010227123334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123334.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed Feb 28 13:42:02 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: 28 Feb 2001 05:42:02 -0800 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-00.txt In-Reply-To: Internet-Drafts@ietf.org Message-ID: <200102281155.GAA02125@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-00.txt Pages : 7 Date : 27-Feb-01 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-00.txt 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-00.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-00.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: <20010227123334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123334.I-D@ietf.org> --OtherAccess-- --NextPart-- From jparker@axiowave.com Wed Feb 28 15:06:46 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 28 Feb 2001 10:06:46 -0500 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt Message-ID: > I would second Dave here, keeping these timers on a per next > hop basis and then generating these interrupts when these > timers expire while doing line rate forwarding is a tad tricky. > > On a SONET link, it is fairly easy to detect that your > neighbor has gone down and notify your peers. On an ethernet > I do recognize this gets harder, but can we make do with a > software based keep-alive mechanism that doesn't involve the > forwarding plane? > > Regards > > Bora Bora - While I don't want to conflate Radia's proposal with the draft, the draft tries to be clear in section 8.1 that anytime Level 2 information tells us that a link is down, we should delete any adjacencies on that link. Reacting to Physical Link failures is one of those things that I think everyone agrees is a Good Thing. Van, Cengiz and company have just pointed out that sometimes we forget to implement things that we all know are good. The Hello PDUs act as the software based keep-alive mechanism that you mention. There has been some interest expressed in playing with lower TTLs in this mechanism: this draft is trying to suggest a common format for such experiments. We return now to our regular bashing of the concept that we can meet any schedules with deadlines under 30 seconds. - jeff parker - Entropy ain't what it used to be From akyol@pluris.com Wed Feb 28 17:25:11 2001 From: akyol@pluris.com (Bora Akyol) Date: Wed, 28 Feb 2001 09:25:11 -0800 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt In-Reply-To: References: Message-ID: Following up on this thread, on BGP the recommended behavior is to not use a timer for withdrawals when adjacencies fail, can one utilize a similar behavior and immediately generate and distribute updated LSPs when L2 link is lost? Bora At 10:06 AM -0500 2/28/01, Jeff Parker wrote: > > I would second Dave here, keeping these timers on a per next >> hop basis and then generating these interrupts when these >> timers expire while doing line rate forwarding is a tad tricky. >> >> On a SONET link, it is fairly easy to detect that your >> neighbor has gone down and notify your peers. On an ethernet >> I do recognize this gets harder, but can we make do with a >> software based keep-alive mechanism that doesn't involve the >> forwarding plane? >> >> Regards >> >> Bora > > >Bora - > >While I don't want to conflate Radia's proposal with the draft, >the draft tries to be clear in section 8.1 that anytime Level 2 >information tells us that a link is down, we should delete any >adjacencies on that link. > >Reacting to Physical Link failures is one of those things that >I think everyone agrees is a Good Thing. Van, Cengiz and >company have just pointed out that sometimes we forget to >implement things that we all know are good. > >The Hello PDUs act as the software based keep-alive mechanism >that you mention. There has been some interest expressed >in playing with lower TTLs in this mechanism: this draft is >trying to suggest a common format for such experiments. > >We return now to our regular bashing of the concept that >we can meet any schedules with deadlines under 30 seconds. > >- jeff parker >- Entropy ain't what it used to be From jparker@axiowave.com Wed Feb 28 18:28:35 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 28 Feb 2001 13:28:35 -0500 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt Message-ID: > Following up on this thread, on BGP the recommended behavior is to > not use a timer for withdrawals when adjacencies fail, can one > utilize a similar behavior and immediately generate and distribute > updated LSPs when L2 link is lost? > > Bora Bora - Section 7.3.6 of 10589 describes the minimumLSPGenerationInterval, a hold-down timer on the regeneration of an particular LSP with a default value of 30 seconds. I assume this means that we could generate the first LSP after an Adjacency change at once, though regeneration due to later events would be damped by this value. That is, I read this to say that regeneration could happen right after the first adjacency was lost, recording the time until the next regeneration would be valid. It may be more common to see implementations simply start a timer to schedule regeneration in the future, which may be a bit simpler, and has the nice tendency to group more events into one generation, suffering the problem of increasing the convergence time. Is there any reason why we should not encourage Bora's interpretation for Adjacency Loss? I could defend a distinction between adjacency loss and things like metric change or a change in the DIS, as those do not prevent a packet from reaching its destination. - jparker - axiowave networks - If you want truly to understand something, try to change it. - Kurt Lewin From serge@ivmg.net Wed Feb 28 19:28:59 2001 From: serge@ivmg.net (Serge Maskalik) Date: Wed, 28 Feb 2001 11:28:59 -0800 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-00.txt In-Reply-To: <200102281155.GAA02125@ietf.org>; from Internet-Drafts@ietf.org on Wed, Feb 28, 2001 at 06:55:30AM -0500 References: <200102281155.GAA02125@ietf.org> Message-ID: <20010228112859.C27593@ivmg.net> Tony et al., Outside of the protocol-based VPN (limited amount), the benefits of having multiple parallel IGP topologies is not obvious to me. Even the VPNs are questionable. Can you explain why someone would want a different topology for and in-band management network? Are there NSPs asking for this functionality? - Serge Thus spake Internet-Drafts@ietf.org (Internet-Drafts@ietf.org): > 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-00.txt > Pages : 7 > Date : 27-Feb-01 > > 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-00.txt > > 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-00.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-00.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. From ginsberg@pluris.com Wed Feb 28 19:51:59 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 28 Feb 2001 11:51:59 -0800 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt Message-ID: <17C81AD1F1FED411991E006008F6D1CA055DCF@avalon.pluris.com> If faster convergence is to be achieved and be useful, then clearly all aspects must be addressed - adjacency state change detection, propagation, SPF performance, and forwarding database update. It does no good to detect an adjacency failure in milliseconds if you can't tell anyone about it until 30 seconds later. So clearly minimumLSPGenerationInterval needs to be adjusted as well as the hold down timer on the SPF. All of these issues are mentioned in Cengiz et al draft. I also think that treating adjacency state change as a "special" kind of update is unnecessary. So long as we are not talking about leaking BGP routes into IS-IS, adjacency flapping has to be the primary cause of LSP updates in a network. Les > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Wednesday, February 28, 2001 10:29 AM > To: 'Bora Akyol'; Danny McPherson (E-mail); Cengiz > Alaettinoglu (E-mail) > Cc: isis-wg@juniper.net > Subject: RE: [Isis-wg] comment on > draft-parker-short-isis-hold-times-00.t xt > > > > Following up on this thread, on BGP the recommended behavior is to > > not use a timer for withdrawals when adjacencies fail, can one > > utilize a similar behavior and immediately generate and distribute > > updated LSPs when L2 link is lost? > > > > Bora > > Bora - > > Section 7.3.6 of 10589 describes the minimumLSPGenerationInterval, a > hold-down > timer on the regeneration of an particular LSP with a default > value of 30 > seconds. > I assume this means that we could generate the first LSP > after an Adjacency > change > at once, though regeneration due to later events would be > damped by this > value. > > That is, I read this to say that regeneration could happen right > after the first adjacency was lost, recording the time until the > next regeneration would be valid. > It may be more common to see implementations simply start a timer > to schedule regeneration in the future, which may be a bit simpler, > and has the nice tendency to group more events into one generation, > suffering the problem of increasing the convergence time. > > Is there any reason why we should not encourage Bora's interpretation > for Adjacency Loss? I could defend a distinction between adjacency > loss and things like metric change or a change in the DIS, as those > do not prevent a packet from reaching its destination. > > - jparker > - axiowave networks > - If you want truly to understand something, try to change > it. - Kurt Lewin > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From akyol@pluris.com Wed Feb 28 19:55:06 2001 From: akyol@pluris.com (Bora Akyol) Date: Wed, 28 Feb 2001 11:55:06 -0800 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA055DCF@avalon.pluris.com> References: <17C81AD1F1FED411991E006008F6D1CA055DCF@avalon.pluris.com> Message-ID: As long as you generate LSP updates when the adjacency is dropped quickly and you apply some sort of backoff interval when the adjacency comes back, is there any reason that you can not generate an LSP update immediately when adjacencies are lost (via L2 notification)? Bora At 11:51 AM -0800 2/28/01, Les Ginsberg wrote: >If faster convergence is to be achieved and be useful, then clearly all >aspects must be addressed - adjacency state change detection, >propagation, SPF performance, and forwarding database update. It does no >good to detect an adjacency failure in milliseconds if you can't tell >anyone about it until 30 seconds later. So clearly >minimumLSPGenerationInterval needs to be adjusted as well as the hold >down timer on the SPF. All of these issues are mentioned in Cengiz et al >draft. > >I also think that treating adjacency state change as a "special" kind of >update is unnecessary. So long as we are not talking about leaking BGP >routes into IS-IS, adjacency flapping has to be the primary cause of LSP >updates in a network. > > Les > > >> -----Original Message----- >> From: Jeff Parker [mailto:jparker@axiowave.com] >> Sent: Wednesday, February 28, 2001 10:29 AM >> To: 'Bora Akyol'; Danny McPherson (E-mail); Cengiz >> Alaettinoglu (E-mail) >> Cc: isis-wg@juniper.net >> Subject: RE: [Isis-wg] comment on >> draft-parker-short-isis-hold-times-00.t xt >> >> >> > Following up on this thread, on BGP the recommended behavior is to >> > not use a timer for withdrawals when adjacencies fail, can one >> > utilize a similar behavior and immediately generate and distribute >> > updated LSPs when L2 link is lost? >> > >> > Bora >> >> Bora - >> >> Section 7.3.6 of 10589 describes the minimumLSPGenerationInterval, a >> hold-down >> timer on the regeneration of an particular LSP with a default >> value of 30 >> seconds. >> I assume this means that we could generate the first LSP >> after an Adjacency >> change >> at once, though regeneration due to later events would be >> damped by this >> value. >> >> That is, I read this to say that regeneration could happen right >> after the first adjacency was lost, recording the time until the >> next regeneration would be valid. >> It may be more common to see implementations simply start a timer >> to schedule regeneration in the future, which may be a bit simpler, >> and has the nice tendency to group more events into one generation, >> suffering the problem of increasing the convergence time. >> >> Is there any reason why we should not encourage Bora's interpretation >> for Adjacency Loss? I could defend a distinction between adjacency >> loss and things like metric change or a change in the DIS, as those >> do not prevent a packet from reaching its destination. >> >> - jparker >> - axiowave networks >> - If you want truly to understand something, try to change >> it. - Kurt Lewin >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > From jparker@axiowave.com Wed Feb 28 20:00:40 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 28 Feb 2001 15:00:40 -0500 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt Message-ID: Les - I agree that getting the LSP out quickly is important. I guess I haven't seen where it is written in stone that "hold-down timer" means "don't do something until X seconds elapse" rather than "don't do this more often than once every X seconds." The first is an easy way to implement the second, but not the only way. Given the second interpretation, we could still get rapid convergence while keeping a large minLSPGen time, which is desirable. - jdp > If faster convergence is to be achieved and be useful, then > clearly all > aspects must be addressed - adjacency state change detection, > propagation, > SPF performance, and forwarding database update. It does no > good to detect > an adjacency failure in milliseconds if you can't tell anyone > about it until > 30 seconds later. So clearly minimumLSPGenerationInterval needs to be > adjusted as well as the hold down timer on the SPF. All of > these issues are > mentioned in Cengiz et al draft. > > I also think that treating adjacency state change as a > "special" kind of > update is unnecessary. So long as we are not talking about leaking BGP > routes into IS-IS, adjacency flapping has to be the primary > cause of LSP > updates in a network. > > Les > > > That is, I read this to say that regeneration could happen right > > after the first adjacency was lost, recording the time until the > > next regeneration would be valid. > > It may be more common to see implementations simply start a timer > > to schedule regeneration in the future, which may be a bit simpler, > > and has the nice tendency to group more events into one generation, > > suffering the problem of increasing the convergence time. > > > > - jparker > > - axiowave networks From ginsberg@pluris.com Wed Feb 28 20:15:13 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 28 Feb 2001 12:15:13 -0800 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt Message-ID: <17C81AD1F1FED411991E006008F6D1CA055DD0@avalon.pluris.com> So long as you have a large minLSPgen timer, no matter which implementation method you use, the best you can do is get fast convergence on one adjacency change. If two events occur over a short time span then even the second interpretation would have to wait 30 seconds to propagate the second change. So if you think that minLSPgen needs to be large, then its pretty much a waste of time to do sub-second adjacency timeout. Note that I am not in opposition to the faster convergence concept - just want to be sure all aspects are addressed. Les > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Wednesday, February 28, 2001 12:01 PM > To: 'Les Ginsberg'; Jeff Parker; Bora Akyol; Danny McPherson (E-mail); > Cengiz Alaettinoglu (E-mail) > Cc: isis-wg@juniper.net > Subject: RE: [Isis-wg] comment on > draft-parker-short-isis-hold-times-00.t xt > > > Les - > I agree that getting the LSP out quickly is important. > I guess I haven't seen where it is written in stone that > "hold-down timer" means "don't do something until X seconds elapse" > rather than "don't do this more often than once every X seconds." > The first is an easy way to implement the second, but not the > only way. > Given the second interpretation, we could still get rapid > convergence while keeping a large minLSPGen time, which is > desirable. > > - jdp > > > If faster convergence is to be achieved and be useful, then > > clearly all > > aspects must be addressed - adjacency state change detection, > > propagation, > > SPF performance, and forwarding database update. It does no > > good to detect > > an adjacency failure in milliseconds if you can't tell anyone > > about it until > > 30 seconds later. So clearly minimumLSPGenerationInterval > needs to be > > adjusted as well as the hold down timer on the SPF. All of > > these issues are > > mentioned in Cengiz et al draft. > > > > I also think that treating adjacency state change as a > > "special" kind of > > update is unnecessary. So long as we are not talking about > leaking BGP > > routes into IS-IS, adjacency flapping has to be the primary > > cause of LSP > > updates in a network. > > > > Les > > > > > That is, I read this to say that regeneration could happen right > > > after the first adjacency was lost, recording the time until the > > > next regeneration would be valid. > > > It may be more common to see implementations simply start a timer > > > to schedule regeneration in the future, which may be a > bit simpler, > > > and has the nice tendency to group more events into one > generation, > > > suffering the problem of increasing the convergence time. > > > > > > - jparker > > > - axiowave networks > From jparker@axiowave.com Wed Feb 28 20:40:07 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 28 Feb 2001 15:40:07 -0500 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt Message-ID: > As long as you generate LSP updates when the adjacency is dropped > quickly and you apply some sort of backoff interval when the > adjacency comes back, is there any reason that you can not generate > an LSP update immediately when adjacencies are lost (via L2 > notification)? > > Bora and > So long as you have a large minLSPgen timer, [when] .. > two events occur over a short time span [you]... > would have to wait 30 seconds to propagate the > second change.... > > Note that I am not in opposition to the faster convergence > concept - just want to be sure all aspects are addressed. > > Les Good points both. I see the goals as o Fast Response to change o Stable Networks which starts with a basic tension. The adjacency damping is really there to reduce the number of LSP re-generations. Perhaps it would be better to focus on controling that directly. I think we still want to preserve the notion of "quick loss, slow win", so that losing an adjacency would result in a quick LSP regen, while addition of an adjacency could wait. We also want to preserve some overall rate limiting mechanism on the frequence of LSP regeneration: perhaps an exponential backoff that affects even the fast-twitch Adjacency-loss regen. Perhaps we could take this off-list and come up with a proposal? - jeff parker From Alex Zinin Thu Mar 1 00:58:57 2001 From: Alex Zinin (Alex Zinin) Date: Wed, 28 Feb 2001 16:58:57 -0800 Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt In-Reply-To: References: Message-ID: <2707.010228@cisco.com> A small comment here. While we do want to exponentially (with a considerably wide range of delay values) dampen interfaces and adjacencies, LSP origination should still be paced with a constant max rate even if the starting part of the delay curve goes exponentially. Alex. > Good points both. I see the goals as > o Fast Response to change > o Stable Networks > which starts with a basic tension. > The adjacency damping is really there to reduce the > number of LSP re-generations. Perhaps it would be > better to focus on controling that directly. > I think we still want to preserve the notion of "quick loss, > slow win", so that losing an adjacency would result in a quick > LSP regen, while addition of an adjacency could wait. > We also want to preserve some overall rate limiting mechanism > on the frequence of LSP regeneration: perhaps an exponential > backoff that affects even the fast-twitch Adjacency-loss regen. > Perhaps we could take this off-list and come up with a proposal? > - jeff parker > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From prz@redback.com Thu Mar 1 05:30:10 2001 From: prz@redback.com (Tony Przygienda) Date: Wed, 28 Feb 2001 21:30:10 -0800 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-00.txt References: <200102281155.GAA02125@ietf.org> <20010228112859.C27593@ivmg.net> Message-ID: <3A9DDE62.5F271B14@redback.com> Serge Maskalik wrote: > Tony et al., > > Outside of the protocol-based VPN (limited amount), the > benefits of having multiple parallel IGP topologies is > not obvious to me. Even the VPNs are questionable. Can > you explain why someone would want a different topology > for and in-band management network? Are there NSPs asking > for this functionality? > > - Serge yepp, some of the functionality has been requested by ISPs since a while and the draft is somehow a generalization of the problem. Look @ the section describing different topology numbers and their uses. And as we say "you can run only very limited amount of VPNs" that way ... -- tony From naiming@redback.com Thu Mar 1 08:01:25 2001 From: naiming@redback.com (Naiming Shen) Date: Thu, 01 Mar 2001 00:01:25 -0800 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-00.txt In-Reply-To: Mail from Serge Maskalik dated Wed, 28 Feb 2001 11:28:59 PST <20010228112859.C27593@ivmg.net> Message-ID: <20010301080151.2D910B76787@prattle.redback.com> Serge, ] Outside of the protocol-based VPN (limited amount), the ] benefits of having multiple parallel IGP topologies is ] not obvious to me. Even the VPNs are questionable. Can ] you explain why someone would want a different topology ] for and in-band management network? In the case of applying M-ISIS in in-band management, "different topology" probably means they share the same set of routers in the network, and they may use different set of links each topology. Using a simple example to illustrate this will be all the routers are connected using ATM links; between some pair of routers, there are 1 or 2 VCs dedicated for in-band management use. The "normal" VCs are configured with high BW using UBR, the in-band management VCs are configured with low BW using CBR. One ISIS topology only "sees" the UBR data links, the other only "sees" the CBR links. They use seperate routing tables. The in-band management topology now has more protection from the general routing problems, it can use it's own private address space, it can use different QoS mechanisms and different ACLs on the links with less concern of performance, it can also set different IGP costs on the links independent of data traffic reqirements on other links. In real life, you can replace the above CBR VCs example with dedicated T1s, channelized bandwidths, etc. ]Are there NSPs asking for this functionality? ] ] - Serge - Naiming From Internet-Drafts@ietf.org Mon Mar 5 11:42:39 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 05 Mar 2001 06:42:39 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-02.txt Message-ID: <200103051142.GAA10675@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, B. Rajagopalan, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-02.txt Pages : 12 Date : 02-Mar-01 This document specifies extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (previously known as Multi-Protocol Lambda Switching). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-02.txt 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-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-gmpls-extensions-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: <20010302131607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302131607.I-D@ietf.org> --OtherAccess-- --NextPart-- From mshand@cisco.com Wed Mar 7 13:58:14 2001 From: mshand@cisco.com (mike shand) Date: Wed, 07 Mar 2001 13:58:14 +0000 Subject: [Isis-wg] IS-IS restart Message-ID: <4.3.2.7.2.20010307134635.02e78008@jaws.cisco.com> I've written up some thoughts about doing IS-IS restart (analogous to OSPF). Basically the idea is that we add an "I'm restarting" option to the IIH, which then causes the neighbor to revive its adjacency by setting SRMflags and sending a CSNP WITHOUT bouncing the adjacency. We make this reliable, so we are sure we will get database synchronization, and by looking at the CSNP we can check when we think it has been achieved, and hence run SPF for the first time. Here it is rather more formally in draft format. Comments? Mike Network Working Group M. Shand Internet Draft Cisco Systems Expiration Date: August 2001 February 2001 Restart signaling for ISIS draft-shand-ISIS-restart-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract The IS-IS routing protocol (RFC 1142 [2], ISO/IEC 10589 [3]) is a link state intra-domain routing protocol. Normally, when an IS-IS router is re-started, the neighboring routers detect the restart event and cycle their adjacencies with the restarting router through the down state. This is necessary in order to invoke the protocol mechanisms to ensure correct re-synchronization of the LSP database. However, the cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes temporary disruption of routes passing through the restarting router. In certain scenarios such temporary disruption of the routes is highly undesirable. This draft describes a mechanism for a restarting router to signal that it is restarting to its neighbors, and allow them to re- Shand Expires Aug 2001 [Page 1] INTERNET DRAFT IS-IS restart Feb 2001 establish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. When such a router is restarted, it is highly desirable that it does not re-compute its own routes until it has achieved database synchronization with its neighbors. Re-computing its routes before synchronization is achieved will result in its own routes being temporarily incorrect. This draft additionally describes a mechanism for a restarting router to determine when it has achieved synchronization with its neighbors. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. 3. Overview There are two related problems with the existing specification of IS-IS with regard to re-synchronization of LSP databases when a router is re-started. Firstly, when a routing process restarts, and an adjacency to a neighboring router is re-initialized the neighboring routing process does three things 1. It re-initializes the adjacency and causes its own LSP(s) to be regenerated, thus triggering SPF runs throughout the domain. 2. It sets SRMflags on its own LSP database on the adjacency concerned. 3. In the case of a Point-to-Point link it transmits a (set of) CSNP(s) over the adjacency. In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure re-synchronization of the LSP database. Secondly, whether or not the router is being re-started, it is desirable to be able to determine when the LSP databases of the neighboring routers have been synchronized (so that the overload bit can be cleared in the router's own LSP, for example). This document describes modifications to achieve this. It is assumed that the three-way handshake [5] is being used on Point-to-Point circuits. Shand Expires Aug 2001 [Page 2] INTERNET DRAFT IS-IS restart Feb 2001 4. Approach 4.1 Adjacency re-acquisition Adjacency re-acquisition is the first step in re-initialization. The restarting router explicitly notifies its neighbor that the adjacency is being re-acquired, and hence that it should not re- initialize the adjacency. This is achieved by the inclusion of a new "re-start" option (TLV) in the IIH PDU. The presence of this TLV indicates that the sender supports the new restart capability and it carries flags that are used to convey information during a restart. All IIHs transmitted by a router that supports this capability MUST include this TLV. Type [TBD] Length 1 Value (1 octet) Bit 1 - Restart Request (RR) Bit 2 - Restart Acknowledgment (RA) Bits 3-8 - Reserved On receipt of an IIH with the "re-start" TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then, irrespective of the other contents of the "Intermediate System Neighbors" option (LAN circuits), or the "Point-to-Point Adjacency State" option (Point-to-Point circuits):- a) Refresh the timer on the adjacency and leave the adjacency in state "Up", b) immediately (i.e. without waiting for any currently running timer interval to expire, but with a small random delay of a few 10s of milliseconds on LANs to avoid "storms"), transmit over the corresponding interface an IIH including the "re-start" TLV with the RR bit clear and the RA bit set, having updated the "Point-to- Point Adjacency State" option to reflect any new values received from the re-starting router. (This allows the restarting router to quickly acquire the correct information to place in its hellos.), c) if the corresponding interface is a Point-to-Point interface, or i) if the receiving router is the LAN level n designated router (where n is the level of the IIH), or ii) if the transmitting router is currently (according to the receiving router) the LAN level n designated router (where n is the level of the IIH) and the receiving router would be elected the LAN level n designated router if the transmitting router were ignored (note the actual DR is NOT changed by this process), Shand Expires Aug 2001 [Page 3] INTERNET DRAFT IS-IS restart Feb 2001 initiate the transmission over the corresponding interface of a complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database. Otherwise (i.e. if there was no adjacency to the system ID in question), process the IIH as normal by re-initializing the adjacency, and setting the RA bit in the returned IIH. A router that does not support the re-start capability will ignore the "re-start" TLV and re-initialize the adjacency as normal, returning an IIH without the "re-start" TLV. On starting, a router starts a timer T1 and transmits an IIH containing the "re-start" TLV with the RR bit set. 1. On a LAN circuit the IIH contains an empty "Intermediate Systems Neighbors" TLV. 2. On a Point-to-Point circuit the IIH contains a "Point-to-Point Adjacency State" option with state "Initializing", and with empty "Neighbor System ID" and "Neighbor Extended Local Circuit ID" options. The values of the "LocalCircuitID" and the "Extended Local CircuitID" may, but need not be, the same as those used previously for this circuit. Transmission of "normal" IIHs is inhibited until the conditions described below are met (in order to avoid causing an unnecessary adjacency re-initialization). On expiry of the timer T1, it is restarted and the IIH is retransmitted as above. On receipt of an IIH by the restarting router, a local adjacency is established as usual, and if the IIH contains a "re-start" TLV with the RA bit set, the receipt of the acknowledgement over that interface is noted. Receipt of an IIH not containing the "re-start" option is also treated as an acknowledgement, since it indicates that the neighbor is not re-start capable. In this case the neighbor will have re- initialized the adjacency as normal, which in the case of a Point- to-Point link will guarantee that SRMflags have been set on its database. In the case of LAN interface, the usual operation of the update process will ensure that synchronization is eventually achieved. In the case of a Point-to-Point circuit, the "LocalCircuitID" and "Extended Local Circuit ID" information contained in the IIH can be used immediately to generate an IIH containing the correct 3-way handshake information. The presence of "Neighbor System ID" or "Neighbor Extended Local Circuit ID" information which does not match the values currently in use by the local system is ignored (since the IIH may have been transmitted before the neighbor had received the new values from the re-starting router), but the Shand Expires Aug 2001 [Page 4] INTERNET DRAFT IS-IS restart Feb 2001 adjacency remains in the initializing state until the correct information is received. In the case of a LAN circuit the information in the Intermediate Systems Neighbors option is recorded and used for the generation of subsequent IIHs as normal. When BOTH a complete set of CSNP(s) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Once T1 has been cancelled, subsequent IIHs are transmitted according to the normal algorithms, but including the "re-start" TLV with both RR and RA clear. If a LAN contains a mixture of systems, only some of which support the new algorithm, database synchronization is still guaranteed, but the "old" systems will have re-initialized their adjacencies. If an interface is active, but does not have any neighboring router reachable over that interface the timer T1 would never be cancelled, and according to clause 4.2.1.2 the SPF would never be run. Therefore timer T1 is cancelled after some pre-determined expirations. (By this time any existing adjacency on a remote system would probably have expired anyway.) 4.1.1 State Table The above operations can be summarized by the following state table. Shand Expires Aug 2001 [Page 5] INTERNET DRAFT IS-IS restart Feb 2001 Event | Running | Restarting | Seen RA | Seen CSNP ================================================================== RX RR | Set SRM | Set SRM | Set SRM | Set SRM | Send RA | Send RA | Send RA | Send RA | Send CSNP | Send CSNP | Send CSNP | Send CSNP -------------+------------+------------+------------+------------- RX RA | | Goto Seen | | Cancel T1 | | RA | | Goto Running -------------+------------+------------+------------+------------- RX CSNP | | Goto Seen | Cancel T1 | | | CSNP | Goto | | | | Running | -------------+------------+------------+------------+------------- RX IIH | | Cancel T1 | Cancel T1 | Cancel T1 with no | | Goto | Goto | Goto Reset TLV | | Running | Running | Running -------------+------------+------------+------------+------------- T1 | | Send RR | Send RR | Send RR Expires | | Send CSNP | Send CSNP | Send CSNP | | Start T1 | Start T1 | Start T1 -------------+------------+------------+------------+------------- T1 | | Cancel T1 | Cancel T1 | Cancel T1 Expires | | Goto | Goto | Goto n times | | Running | Running | Running -------------+------------+------------+------------+------------- Router | Set SRM | Set SRM | Set SRM | Set SRM Restarted | Send RR | Send RR | Send RR | Send RR | Send CSNP | Send CSNP | Send CSNP | Send CSNP | Start T1 | Start T1 | Start T1 | Start T1 | Goto | Goto | Goto | Goto | Restarting | Restarting | Restarting | Restarting ================================================================== 4.2 Database synchronization When a router is started or re-started it can expect to receive a (set of) CSNP(s) over each interface. The arrival of the CSNP(s) is now guaranteed, since the "re-start" IIH with the RR bit set will be retransmitted until the CSNP(s) are correctly received. The CSNPs describe the set of LSPs that are currently held by each neighbor. Synchronization will be complete when all these LSPs have been received. On starting, a router starts a timer T2 for each active level. In addition to normal processing of the CSNPs, the set of LSPIDs contained in the first complete set of CSNP(s) received over each interface is recorded. If there are multiple interfaces on the restarting router, the recorded set of LSPIDs is the union of those received over each interface. LSPs with a remaining lifetime of zero are NOT so recorded. Shand Expires Aug 2001 [Page 6] INTERNET DRAFT IS-IS restart Feb 2001 As LSPs are received (by the normal operation of the update process) over any interface, the corresponding LSPID entry is removed (it is also removed if the LSP had arrived before the CSNP containing the reference). When the list of LSPIDs becomes empty, the timer T2 is cancelled. At this point the local database is guaranteed to contain all the LSP(s) (either the same sequence number, or a more recent sequence number) which were present in the neighbors' databases at the time of re-starting. LSPs that arrived in a neighbor's database after the time of re-starting may, or may not, be present, but the normal operation of the update process will guarantee that they will eventually be received. At this point the local database is deemed to be "synchronized". Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime are not recorded, it is unlikely that cancellation of the timer T2 will be prevented by waiting for an LSP which will never arrive. However it is possible that an LSP with a small remaining lifetime was placed in the list. If the re-synchronization process takes longer than 'ZeroAgeLifetime' (default 60 seconds), the corresponding LSP will have been removed from the neighbors' LSP databases and will never arrive. Under these circumstances, the timer T2 may expire, and the databases are deemed to be synchronized. 4.2.1 LSP generation and flooding and SPF computation The operation of a router starting, as opposed to re-starting is somewhat different. These two cases are dealt with separately below. 4.2.1.1. Starting for the first time In the case of a starting router, the router's own zeroth LSP is first transmitted with the overload bit set. This prevents other routers from computing routes through the router until it has reliably acquired the complete set of LSPs. The overload bit remains set in subsequent transmissions of the zeroth LSP (such as will occur if a previous copy of the routers LSP is still present in the network) while the timer T2 is running. When the timer T2 expires, or is cancelled, the own LSP is regenerated with the overload bit clear (assuming the router isn't in fact overloaded), and flooded as normal. Other 'own' LSPs (including pseudonodes) are generated and flooded as normal, irrespective of the timer T2. The SPF is also run as normal and the RIB and FIB updated as routes become available. Shand Expires Aug 2001 [Page 7] INTERNET DRAFT IS-IS restart Feb 2001 4.2.1.2. Re-starting In order to avoid causing unnecessary routing churn in other routers, it is highly desirable that the own LSPs generated by the restarting system are the same as those previously present in the network (assuming no other changes have taken place). It is important therefore not to regenerate and flood the LSPs until all the adjacencies have been re-established and any information required for propagation into the local LSPs is fully available. Ideally, the information should be loaded into the LSPs in a deterministic way, such that the same information occurs in the same place in the same LSP (and hence the LSPs are identical to their previous versions). If this can be achieved, the new versions will not even cause SPF to be run in other systems. However, provided the same information is included in the set of LSPs (albeit in a different order, and possibly different LSPs), the result of running the SPF will be the same and will not cause churn to the forwarding tables. In the case of a re-starting router, none of the router's own non- pseudonode LSPs are transmitted, nor is the SPF run to update the forwarding tables while the timer T2 is running, or while the timer T1 is still running on any of the interfaces. Redistribution of inter-level information must be regenerated before this router's LSP is flooded to other nodes. Therefore the level-n non-pseudonode LSP(s) should not be flooded until the other level's T2 timer has expired and its SPF has been run. This ensures that any inter-level information that should be propagated can be included in the level-n LSP(s). During this period, if one of the router's own (including pseudonodes) LSPs is received, which the local router does not currently have in its own database, it is NOT purged. Under normal operation, such an LSP would be purged, since the LSP clearly should not be present in the global LSP database. However, in the present circumstances, this would be highly undesirable, because it could cause premature removal of an own LSP -- and hence churn in remote routers. Even if the local system has one or more own LSPs (which is has generated, but not yet transmitted) it is still not valid to compare the received LSP against this set, since it may be that as a result of propagation between level 1 and level 2 (or vice versa) a further own LSP will need to be generated when the LSP databases have synchronized. When the timer T2 expires, or is cancelled, the SPF is run to update the RIB and FIB. Once the other level's SPF has run and any inter-level propagation has been resolved, the 'own' LSPs can be generated and flooded. Any 'own' LSPs which were previously ignored, but which are not part of the current set of 'own' LSPs (including pseudonodes) should then be Shand Expires Aug 2001 [Page 8] INTERNET DRAFT IS-IS restart Feb 2001 purged. Note that it is possible that a Designated Router change may have taken place, and consequently the router should purge those pseudonode LSPs which it previously owned, but which are now no longer part of its set of pseudonode LSPs. 5. Security Considerations This memo does not create any new security issues for the IS-IS protocol. Security considerations for the base IS-IS protocol are covered in [2] and [3]. 6. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. 3 ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Katz, D., "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", draft-ietf-isis-3way-03.txt, July 2000 7. Acknowledgments The author would like to acknowledge contributions made by Radia Perlman, Mark Schaefer, Russ White and Rena Yang. 8. Author's Addresses Mike Shand Cisco Systems 4, The Square, Stockley Park, UXBRIDGE, Middlesex UB11 1BN, UK Phone: +44 20 8756 8690 Email: mshand@cisco.com Shand Expires Aug 2001 [Page 9] From Jonathan.Sadler@tellabs.com Wed Mar 7 19:22:49 2001 From: Jonathan.Sadler@tellabs.com (Jonathan Sadler) Date: Wed, 07 Mar 2001 13:22:49 -0600 Subject: [Isis-wg] WG time slot in Minneapolis? Message-ID: <3AA68A89.8A456A1C@tellabs.com> Has a request for a timeslot been made for IS-IS? I don't see it on the current draft agenda... Jonathan Sadler From prz@redback.com Wed Mar 7 19:39:16 2001 From: prz@redback.com (Tony Przygienda) Date: Wed, 07 Mar 2001 11:39:16 -0800 Subject: [Isis-wg] WG time slot in Minneapolis? References: <3AA68A89.8A456A1C@tellabs.com> Message-ID: <3AA68E64.5D548E57@redback.com> Jonathan Sadler wrote: > Has a request for a timeslot been made for IS-IS? I don't see it on the > current draft agenda... and accordingly, there is no workgroup meeting there ... -- tony From mongazon@ms.alcatel.fr Fri Mar 9 10:54:40 2001 From: mongazon@ms.alcatel.fr (Bruno Mongazon) Date: Fri, 09 Mar 2001 11:54:40 +0100 Subject: [Isis-wg] IS-IS restart References: <4.3.2.7.2.20010307134635.02e78008@jaws.cisco.com> Message-ID: <3AA8B670.801636DD@ms.alcatel.fr> mike shand wrote: > > I've written up some thoughts about doing IS-IS restart (analogous to > OSPF). Basically the idea is that we add an "I'm restarting" option to the > IIH, which then causes the neighbor to revive its adjacency by setting > SRMflags and sending a CSNP WITHOUT bouncing the adjacency. We make this > reliable, so we are sure we will get database synchronization, and by > looking at the CSNP we can check when we think it has been achieved, and > hence run SPF for the first time. > > Here it is rather more formally in draft format. > > Comments? > > Mike > Hi Mike, Just to make my mind clear about your proposal, could you check my preliminary wonders/questions below. Point 1 ------- -Does restart signaling is to occur before restart or at restart? -More clearly does a restarting router first announces it is going to restart (while it is up and running) and then restarts? -or does it restarts and then announces it has restarted? Point 2 ------- -Reading the draft, my answer for point 1 would be that restart signaling occurs at restart. In such case, depending on the holding timer, neigbhors might have already moved the restarting adjacency in down state before the restart signal has been received, isn't it? If so, how do you handle such a case in your proposal? If so, how is your proposal compatible/incompatible with the draft(*) which suggests to reduce hold times for faster convergence in isis when routers come up and down? (*) see Thanks in advance. Bruno. From mshand@cisco.com Fri Mar 9 11:22:33 2001 From: mshand@cisco.com (mike shand) Date: Fri, 09 Mar 2001 11:22:33 +0000 Subject: [Isis-wg] IS-IS restart In-Reply-To: <3AA8B670.801636DD@ms.alcatel.fr> References: <4.3.2.7.2.20010307134635.02e78008@jaws.cisco.com> Message-ID: <4.3.2.7.2.20010309110934.00b39b38@jaws.cisco.com> At 11:54 09/03/2001 +0100, Bruno Mongazon wrote: >mike shand wrote: > > > > I've written up some thoughts about doing IS-IS restart (analogous to > > OSPF). Basically the idea is that we add an "I'm restarting" option to the > > IIH, which then causes the neighbor to revive its adjacency by setting > > SRMflags and sending a CSNP WITHOUT bouncing the adjacency. We make this > > reliable, so we are sure we will get database synchronization, and by > > looking at the CSNP we can check when we think it has been achieved, and > > hence run SPF for the first time. > > > > Here it is rather more formally in draft format. > > > > Comments? > > > > Mike > > > >Hi Mike, > >Just to make my mind clear about your proposal, could you check my >preliminary wonders/questions below. > >Point 1 >------- > >-Does restart signaling is to occur before restart or at restart? after >-More clearly does a restarting router first announces it is going to >restart (while it is > up and running) and then restarts? No its not like BGP "I'll be back" >-or does it restarts and then announces it has restarted? The latter > > > >Point 2 >------- > >-Reading the draft, my answer for point 1 would be that restart >signaling occurs at > restart. In such case, depending on the holding timer, neigbhors might >have already moved > the restarting adjacency in down state before the restart signal has >been received, isn't > it? Yes. > If so, how do you handle such a case in your proposal? They come up as usual. i.e the adjacency is reinitialized completely, and of course a new LSP entry generated etc. > If so, how is your proposal compatible/incompatible with the draft(*) >which suggests to > reduce hold times for faster convergence in isis when routers come up >and down? Clearly the re-starting router would have to come back before the neighbor declared the adjacency down (in the sense that it had re-generated its LSP describing it). If the neighbor is detecting physical link failure, the physical link would not fail in the case of a re-starting router which was able to continue forwarding. So that would not be an issue. If the LINK did fail, then the physical failure would cause the desired rapid detection. We assume that failure of the "router" does NOT need to be detected quickly, since it does not disrupt forwarding. Mike > (*) see > > >Thanks in advance. >Bruno. From mshand@cisco.com Fri Mar 9 11:49:43 2001 From: mshand@cisco.com (mike shand) Date: Fri, 09 Mar 2001 11:49:43 +0000 Subject: [Isis-wg] IS-IS restart In-Reply-To: <4.3.2.7.2.20010309110934.00b39b38@jaws.cisco.com> References: <3AA8B670.801636DD@ms.alcatel.fr> <4.3.2.7.2.20010307134635.02e78008@jaws.cisco.com> Message-ID: <4.3.2.7.2.20010309112952.03299948@jaws.cisco.com> Oh I've realized why you might be confused. The restart TLV is always present in the IIH (for a router which supports re-starting). But the "restart-request" bit is ONLY set when you actually re-start. And of course, since you know whether or not you are yourself re-start capable, you can use suitable holding times for your own hellos. Mike At 11:22 09/03/2001 +0000, mike shand wrote: >At 11:54 09/03/2001 +0100, Bruno Mongazon wrote: >>mike shand wrote: >> > >> > I've written up some thoughts about doing IS-IS restart (analogous to >> > OSPF). Basically the idea is that we add an "I'm restarting" option to the >> > IIH, which then causes the neighbor to revive its adjacency by setting >> > SRMflags and sending a CSNP WITHOUT bouncing the adjacency. We make this >> > reliable, so we are sure we will get database synchronization, and by >> > looking at the CSNP we can check when we think it has been achieved, and >> > hence run SPF for the first time. >> > >> > Here it is rather more formally in draft format. >> > >> > Comments? >> > >> > Mike >> > >> >>Hi Mike, >> >>Just to make my mind clear about your proposal, could you check my >>preliminary wonders/questions below. >> >>Point 1 >>------- >> >>-Does restart signaling is to occur before restart or at restart? > >after > > >>-More clearly does a restarting router first announces it is going to >>restart (while it is >> up and running) and then restarts? > >No its not like BGP "I'll be back" > > >>-or does it restarts and then announces it has restarted? > >The latter > >> >> >> >>Point 2 >>------- >> >>-Reading the draft, my answer for point 1 would be that restart >>signaling occurs at >> restart. In such case, depending on the holding timer, neigbhors might >>have already moved >> the restarting adjacency in down state before the restart signal has >>been received, isn't >> it? > >Yes. > > >> If so, how do you handle such a case in your proposal? > >They come up as usual. i.e the adjacency is reinitialized completely, and >of course a new LSP entry generated etc. > > >> If so, how is your proposal compatible/incompatible with the draft(*) >>which suggests to >> reduce hold times for faster convergence in isis when routers come up >>and down? > >Clearly the re-starting router would have to come back before the neighbor >declared the adjacency down (in the sense that it had re-generated its LSP >describing it). > >If the neighbor is detecting physical link failure, the physical link >would not fail in the case of a re-starting router which was able to >continue forwarding. So that would not be an issue. > >If the LINK did fail, then the physical failure would cause the desired >rapid detection. > >We assume that failure of the "router" does NOT need to be detected >quickly, since it does not disrupt forwarding. > > Mike > > > > >> (*) see >> >> >>Thanks in advance. >>Bruno. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mongazon@ms.alcatel.fr Fri Mar 9 14:22:14 2001 From: mongazon@ms.alcatel.fr (Bruno Mongazon) Date: Fri, 09 Mar 2001 15:22:14 +0100 Subject: [Isis-wg] IS-IS restart References: <3AA8B670.801636DD@ms.alcatel.fr> <4.3.2.7.2.20010307134635.02e78008@jaws.cisco.com> <4.3.2.7.2.20010309112952.03299948@jaws.cisco.com> Message-ID: <3AA8E716.D0082056@ms.alcatel.fr> mike shand wrote: > > Oh I've realized why you might be confused. > > The restart TLV is always present in the IIH (for a router which supports > re-starting). > > But the "restart-request" bit is ONLY set when you actually re-start. > > And of course, since you know whether or not you are yourself re-start > capable, you can use suitable holding times for your own hellos. > > Mike > Fine Mike, Then i would like to suggest the following amendments to your proposal: -Modify the proposed restart TLV to include a restart time. Might be encoded on 1 byte in seconds or milliseconds. -Interpret the restart time as follows (only if the restart capability is supported): When a IIH PDU is received with a restart TLV having RR and RA bits reset (means not restarting), then memorize, eventually override (*), the restart time for the adjacency (in addition to the restart capability which i assumed to be memorized in your current proposal). A zero restart time means no restart time. When the holding timer adjacency expires and the adjacency is restartable and the restart timer is non-zero, then wait for restart time seconds/milliseconds before the adjacency is declared down and recycled. Stop the restart timer when an IIH PDU is received with a restart TLV having RR bit set and RA bit not set (means restarting). When restart timer expires, re-initialize the adjacency (as implied by the current proposal). (*) The restart time might be changed while exchanging regular IIH PDU (RR and RA not set. With this suggestion, it is possible to express the restart time independently of the holding time. Otherwise, as you said, you have to choose a 'suitable' value for both holding time and restart time. The choice might be difficult. If you need more time to restart, this will also take more time to detect and propagate failure in routing. If you want early detection aand fast convergence, then you will have less time to restart and less chance for restart to operate. Separating the hold and restart time could solve this issue. Let me know your opinion about this proposal. Bruno. > At 11:22 09/03/2001 +0000, mike shand wrote: > >At 11:54 09/03/2001 +0100, Bruno Mongazon wrote: > >>mike shand wrote: > >> > > >> > I've written up some thoughts about doing IS-IS restart (analogous to > >> > OSPF). Basically the idea is that we add an "I'm restarting" option to the > >> > IIH, which then causes the neighbor to revive its adjacency by setting > >> > SRMflags and sending a CSNP WITHOUT bouncing the adjacency. We make this > >> > reliable, so we are sure we will get database synchronization, and by > >> > looking at the CSNP we can check when we think it has been achieved, and > >> > hence run SPF for the first time. > >> > > >> > Here it is rather more formally in draft format. > >> > > >> > Comments? > >> > > >> > Mike > >> > > >> > >>Hi Mike, > >> > >>Just to make my mind clear about your proposal, could you check my > >>preliminary wonders/questions below. > >> > >>Point 1 > >>------- > >> > >>-Does restart signaling is to occur before restart or at restart? > > > >after > > > > > >>-More clearly does a restarting router first announces it is going to > >>restart (while it is > >> up and running) and then restarts? > > > >No its not like BGP "I'll be back" > > > > > >>-or does it restarts and then announces it has restarted? > > > >The latter > > > >> > >> > >> > >>Point 2 > >>------- > >> > >>-Reading the draft, my answer for point 1 would be that restart > >>signaling occurs at > >> restart. In such case, depending on the holding timer, neigbhors might > >>have already moved > >> the restarting adjacency in down state before the restart signal has > >>been received, isn't > >> it? > > > >Yes. > > > > > >> If so, how do you handle such a case in your proposal? > > > >They come up as usual. i.e the adjacency is reinitialized completely, and > >of course a new LSP entry generated etc. > > > > > >> If so, how is your proposal compatible/incompatible with the draft(*) > >>which suggests to > >> reduce hold times for faster convergence in isis when routers come up > >>and down? > > > >Clearly the re-starting router would have to come back before the neighbor > >declared the adjacency down (in the sense that it had re-generated its LSP > >describing it). > > > >If the neighbor is detecting physical link failure, the physical link > >would not fail in the case of a re-starting router which was able to > >continue forwarding. So that would not be an issue. > > > >If the LINK did fail, then the physical failure would cause the desired > >rapid detection. > > > >We assume that failure of the "router" does NOT need to be detected > >quickly, since it does not disrupt forwarding. > > > > Mike > > > > > > > > > >> (*) see > >> > >> > >>Thanks in advance. > >>Bruno. > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg From mshand@cisco.com Fri Mar 9 14:53:01 2001 From: mshand@cisco.com (mike shand) Date: Fri, 09 Mar 2001 14:53:01 +0000 Subject: [Isis-wg] IS-IS restart In-Reply-To: <3AA8E716.D0082056@ms.alcatel.fr> References: <3AA8B670.801636DD@ms.alcatel.fr> <4.3.2.7.2.20010307134635.02e78008@jaws.cisco.com> <4.3.2.7.2.20010309112952.03299948@jaws.cisco.com> Message-ID: <4.3.2.7.2.20010309144809.032f6718@jaws.cisco.com> I'm afraid I don't see the point of your suggestion. If you are restartable you simply set your holding time to include the time it takes you to re-start. This means that the neighbor will keep its adjacency up for this time (and more importantly keep sending you data). Since you are re-startable you will continue to forward that data more or less correctly (but no less correctly than normal propagation delays would cause). Even if your neighbor DOESN't support restart this is OK, since it will simply re-initialize its adjacency when you come back up. You will cause a netowrk disturbance, but again this is no worse than you would have had without re-startability. Provided you use physical detection of link failure (and why would you not?), then you have lost nothing. Mike At 15:22 09/03/2001 +0100, Bruno Mongazon wrote: >mike shand wrote: > > > > Oh I've realized why you might be confused. > > > > The restart TLV is always present in the IIH (for a router which supports > > re-starting). > > > > But the "restart-request" bit is ONLY set when you actually re-start. > > > > And of course, since you know whether or not you are yourself re-start > > capable, you can use suitable holding times for your own hellos. > > > > Mike > > > >Fine Mike, > >Then i would like to suggest the following amendments to your proposal: > >-Modify the proposed restart TLV to include a restart time. Might be >encoded on 1 byte in > seconds or milliseconds. > >-Interpret the restart time as follows (only if the restart capability >is supported): > > When a IIH PDU is received with a restart TLV having RR and RA bits >reset (means not > restarting), then memorize, eventually override (*), the restart time >for the adjacency > (in addition to the restart capability which i assumed to be memorized >in your current > proposal). A zero restart time means no restart time. > > When the holding timer adjacency expires and the adjacency is >restartable and the > restart timer is non-zero, then wait for restart time >seconds/milliseconds before > the adjacency is declared down and recycled. > > Stop the restart timer when an IIH PDU is received with a restart TLV >having RR bit set > and RA bit not set (means restarting). > > When restart timer expires, re-initialize the adjacency (as implied by >the current > proposal). > >(*) The restart time might be changed while exchanging regular IIH PDU >(RR and RA not > set. > >With this suggestion, it is possible to express the restart time >independently of the holding time. Otherwise, as you said, you have to >choose a 'suitable' value for both holding time and restart time. The >choice might be difficult. If you need more time to restart, this will >also take more time to detect and propagate failure in routing. If you >want early detection aand fast convergence, then you will have less time >to restart and less chance for restart to operate. Separating the hold >and restart time could solve this issue. > >Let me know your opinion about this proposal. > >Bruno. > > > > At 11:22 09/03/2001 +0000, mike shand wrote: > > >At 11:54 09/03/2001 +0100, Bruno Mongazon wrote: > > >>mike shand wrote: > > >> > > > >> > I've written up some thoughts about doing IS-IS restart (analogous to > > >> > OSPF). Basically the idea is that we add an "I'm restarting" > option to the > > >> > IIH, which then causes the neighbor to revive its adjacency by setting > > >> > SRMflags and sending a CSNP WITHOUT bouncing the adjacency. We > make this > > >> > reliable, so we are sure we will get database synchronization, and by > > >> > looking at the CSNP we can check when we think it has been > achieved, and > > >> > hence run SPF for the first time. > > >> > > > >> > Here it is rather more formally in draft format. > > >> > > > >> > Comments? > > >> > > > >> > Mike > > >> > > > >> > > >>Hi Mike, > > >> > > >>Just to make my mind clear about your proposal, could you check my > > >>preliminary wonders/questions below. > > >> > > >>Point 1 > > >>------- > > >> > > >>-Does restart signaling is to occur before restart or at restart? > > > > > >after > > > > > > > > >>-More clearly does a restarting router first announces it is going to > > >>restart (while it is > > >> up and running) and then restarts? > > > > > >No its not like BGP "I'll be back" > > > > > > > > >>-or does it restarts and then announces it has restarted? > > > > > >The latter > > > > > >> > > >> > > >> > > >>Point 2 > > >>------- > > >> > > >>-Reading the draft, my answer for point 1 would be that restart > > >>signaling occurs at > > >> restart. In such case, depending on the holding timer, neigbhors might > > >>have already moved > > >> the restarting adjacency in down state before the restart signal has > > >>been received, isn't > > >> it? > > > > > >Yes. > > > > > > > > >> If so, how do you handle such a case in your proposal? > > > > > >They come up as usual. i.e the adjacency is reinitialized completely, and > > >of course a new LSP entry generated etc. > > > > > > > > >> If so, how is your proposal compatible/incompatible with the draft(*) > > >>which suggests to > > >> reduce hold times for faster convergence in isis when routers come up > > >>and down? > > > > > >Clearly the re-starting router would have to come back before the neighbor > > >declared the adjacency down (in the sense that it had re-generated its LSP > > >describing it). > > > > > >If the neighbor is detecting physical link failure, the physical link > > >would not fail in the case of a re-starting router which was able to > > >continue forwarding. So that would not be an issue. > > > > > >If the LINK did fail, then the physical failure would cause the desired > > >rapid detection. > > > > > >We assume that failure of the "router" does NOT need to be detected > > >quickly, since it does not disrupt forwarding. > > > > > > Mike > > > > > > > > > > > > > > >> (*) see > > >> > > >> > > >>Thanks in advance. > > >>Bruno. > > > > > >_______________________________________________ > > >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 Fri Mar 9 15:30:21 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 9 Mar 2001 10:30:21 -0500 Subject: [Isis-wg] IS-IS restart Message-ID: > -Modify the proposed restart TLV to include a restart time. ... > > When the holding timer adjacency expires and the adjacency is > restartable and the restart timer is non-zero, then wait for > restart time seconds/milliseconds before the adjacency is > declared down and recycled. Doesn't this make it take longer to detect a bad link via hellos? I think Mike's proposal allows the padding you need by making the Hello Hold Time longer than the time required to reboot and restart sending hellos on configured circuits. - jeff parker - axiowave networks From mongazon@ms.alcatel.fr Fri Mar 9 16:56:41 2001 From: mongazon@ms.alcatel.fr (Bruno Mongazon) Date: Fri, 09 Mar 2001 17:56:41 +0100 Subject: [Isis-wg] IS-IS restart References: Message-ID: <3AA90B49.FD8B6883@ms.alcatel.fr> Jeff Parker wrote: > > > > -Modify the proposed restart TLV to include a restart time. ... > > > > When the holding timer adjacency expires and the adjacency is > > restartable and the restart timer is non-zero, then wait for > > restart time seconds/milliseconds before the adjacency is > > declared down and recycled. > > Doesn't this make it take longer to detect a bad link via > hellos? I think Mike's proposal allows the padding you > need by making the Hello Hold Time longer than the time > required to reboot and restart sending hellos on configured > circuits. > Yes, i've got it: The faster (lower) you detect bad links, the faster (lower) you restart! Anyway the restart time will be hidden. It is a part of the holding time. If you want to make this part visible to the peer, my suggestion should be ok? Bruno. > - jeff parker > - axiowave networks > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Fri Mar 9 17:10:11 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 9 Mar 2001 09:10:11 -0800 Subject: [Isis-wg] IS-IS restart In-Reply-To: <3AA90B49.FD8B6883@ms.alcatel.fr> References: <3AA90B49.FD8B6883@ms.alcatel.fr> Message-ID: <14382.010309@cisco.com> Bruno, > Yes, i've got it: > The faster (lower) you detect bad links, the faster (lower) you restart! > Anyway the restart time will be hidden. It is a part of the holding > time. > If you want to make this part visible to the peer, my suggestion should > be ok? What value would it add to the mechanism? Alex. From mongazon@ms.alcatel.fr Fri Mar 9 17:25:25 2001 From: mongazon@ms.alcatel.fr (Bruno Mongazon) Date: Fri, 09 Mar 2001 18:25:25 +0100 Subject: [Isis-wg] IS-IS restart References: <3AA90B49.FD8B6883@ms.alcatel.fr> <14382.010309@cisco.com> Message-ID: <3AA91205.65DC418A@ms.alcatel.fr> Alex Zinin wrote: > > Bruno, > > > Yes, i've got it: > > The faster (lower) you detect bad links, the faster (lower) you restart! > > > Anyway the restart time will be hidden. It is a part of the holding > > time. > > If you want to make this part visible to the peer, my suggestion should > > be ok? > > What value would it add to the mechanism? > > Alex. Not a big value to the mechanism itself but a choice criterion from the peer perspective: The peer can choose to support or not restart for the adjacency depending on the two values (holding time, restart time). If a router says it can detect bad links fast but restarts slowly, then the peer might choose high-speed detection without restart. If everything is hidden in the hold timer, then the peer just ack/nack according to its restart capability. Bruno. From Alex Zinin Fri Mar 9 17:45:38 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 9 Mar 2001 09:45:38 -0800 Subject: [Isis-wg] IS-IS restart In-Reply-To: <3AA91205.65DC418A@ms.alcatel.fr> References: <3AA91205.65DC418A@ms.alcatel.fr> Message-ID: <8406.010309@cisco.com> Bruno, I see your point. However, I think such a choice would make it harder to predict that a graceful restart will actually happen when different implementations make difference choices. I would suggest we make it simple and go with the hold timer. -- Alex Zinin > Alex Zinin wrote: >> >> Bruno, >> >> > Yes, i've got it: >> > The faster (lower) you detect bad links, the faster (lower) you restart! >> >> > Anyway the restart time will be hidden. It is a part of the holding >> > time. >> > If you want to make this part visible to the peer, my suggestion should >> > be ok? >> >> What value would it add to the mechanism? >> >> Alex. > Not a big value to the mechanism itself but a choice criterion from the > peer perspective: > The peer can choose to support or not restart for the adjacency > depending on the two values (holding time, restart time). If a router > says it can detect bad links fast but restarts slowly, then the peer > might choose high-speed detection without restart. > If everything is hidden in the hold timer, then the peer just ack/nack > according to its restart capability. > Bruno. From John.Odak@Marconi.com Fri Mar 9 18:33:43 2001 From: John.Odak@Marconi.com (Odak, John) Date: Fri, 9 Mar 2001 13:33:43 -0500 Subject: [Isis-wg] TE TLVs/Sub-TLVs Message-ID: <39469E08BD83D411A3D900204840EC5519EB42@VIE-MSGUSR-01> TE Authors, Please forgive the lateness of these comments on the TE draft (draft-ietf-isis-traffic-02.txt), but I only recently started looking at it - and ISIS itself for that matter - and I have a few somewhat obvious comments about the TLVs/sub-TLVs that you've specified. Again, please forgive this post if these issues have already been discussed and resolved. Specific comments: - The Extended IP Reachability TLV (type 135) has a one-octet control information field that uses 1 bit to indicate the existence of sub-TLVs. This is not necessary because the enclosing TLV already has a length field that will indicate whether sub-TLVs are present. - The Extended IP Reachability TLV (type 135) has a one-octet control information field that sets aside 6 bits for the IPv4 prefix length when only 5 are required. One of the bits should be freed for possible future or experimental use. - The Extended IP Reachability TLV (type 135) potentially has a one-octet field to indicate the total length of any sub TLVs. This is not necessary because the enclosing TLV already has a length field that will indicate the total length of any sub-TLVs. - The Extended IS Reachability TLV (type 22) has a one-octet field to indicate the total length of any sub TLVs. This is not necessary because the enclosing TLV already has a length field that will indicate the total length of any sub-TLVs. General comments and issues: - The Extended IS Reachability and Extended IP Reachability TLVs are inconsistent in the manner in which they specify the presence of sub-TLVs. Since both definitions are from the same document, and in fact are only one page apart, shouldn't they look a little more like each other? - All of the sub-TLVs have been defined in terms of the Type-Length-Value encoding format, but none has a variable length. This seems to be a real waste of the relatively small 254 bytes of potential value space. - Why are the sub-TLVs referred to as sub? Aren't they just TLVs? It looks like there's still plenty of open space in the main Type range to accommodate them, and many others for that matter. In a future enhancement, will we have sub-sub-TLVs? It would seem that a more general and consistent method for specifying, grouping, and encoding information might be called for - ASN.1/BER comes to mind. I realize that many vendors have already implemented this draft - my company being one of them (I think they'll flog me for this posting), and that some of the comments, while they will not add much functional value, will require rework, and in the case of the general comments, possibly quite a lot of rework. But since the document is still a draft and is introducing sub-TLVs, it might be nice if it also established a framework that could be copied and built upon instead of just something that can be made to work. John Odak john.odak@marconi.com From jparker@axiowave.com Fri Mar 9 19:12:56 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 9 Mar 2001 14:12:56 -0500 Subject: [Isis-wg] TE TLVs/Sub-TLVs Message-ID: > - The Extended IS Reachability TLV (type 22) has a one-octet field to > indicate the total length of any sub TLVs. This is not > necessary because the enclosing TLV already has a length > field that will indicate the total length of any sub-TLVs. You might have multiple instances of this: you need the inner length to split multiple items apart. > - All of the sub-TLVs have been defined in terms of the > Type-Length-Value encoding format, but none has a > variable length. This seems to be a real > waste of the relatively small 254 bytes of potential value space. The strength of the TLV encoding is that you don't need to know anything about the T to decode it. If you mix TLVs and TVs, then an older implementation has now way to deal with a newly defined TV. Since it doesn't know the new Type, it doesn't know the fixed Length to skip. - jeff parker - axiowave networks From satish@pluris.com Fri Mar 9 19:23:33 2001 From: satish@pluris.com (Satish Dattatri) Date: Fri, 9 Mar 2001 11:23:33 -0800 Subject: [Isis-wg] TE TLVs/Sub-TLVs Message-ID: <17C81AD1F1FED411991E006008F6D1CA05A7C5@avalon.pluris.com> Hi, By removing the 'L' in the sub-TLV it would cause headache for implementations (other than cisco for now) not knowing a particular *reserved* sub-TLV's length. An implementation will now have to skip the rest of the data in TLV after hitting a unknown type. This may not be desirable. But by making the length of all sub-TLV types well-known and constant (no more *reserved* types), then the 'L' in the sub-TLVs can be removed and it becomes sub-TV ;-). Multiple values now will be in multiple sub-TV's (for ex. IP V4 interface addresses). Satish -----Original Message----- From: Odak, John [mailto:John.Odak@marconi.com] Sent: Friday, March 09, 2001 10:34 AM To: 'henk@procket.com'; 'isis-wg@external.juniper.net' Subject: [Isis-wg] TE TLVs/Sub-TLVs TE Authors, Please forgive the lateness of these comments on the TE draft (draft-ietf-isis-traffic-02.txt), but I only recently started looking at it - and ISIS itself for that matter - and I have a few somewhat obvious comments about the TLVs/sub-TLVs that you've specified. Again, please forgive this post if these issues have already been discussed and resolved. Specific comments: - The Extended IP Reachability TLV (type 135) has a one-octet control information field that uses 1 bit to indicate the existence of sub-TLVs. This is not necessary because the enclosing TLV already has a length field that will indicate whether sub-TLVs are present. - The Extended IP Reachability TLV (type 135) has a one-octet control information field that sets aside 6 bits for the IPv4 prefix length when only 5 are required. One of the bits should be freed for possible future or experimental use. - The Extended IP Reachability TLV (type 135) potentially has a one-octet field to indicate the total length of any sub TLVs. This is not necessary because the enclosing TLV already has a length field that will indicate the total length of any sub-TLVs. - The Extended IS Reachability TLV (type 22) has a one-octet field to indicate the total length of any sub TLVs. This is not necessary because the enclosing TLV already has a length field that will indicate the total length of any sub-TLVs. General comments and issues: - The Extended IS Reachability and Extended IP Reachability TLVs are inconsistent in the manner in which they specify the presence of sub-TLVs. Since both definitions are from the same document, and in fact are only one page apart, shouldn't they look a little more like each other? - All of the sub-TLVs have been defined in terms of the Type-Length-Value encoding format, but none has a variable length. This seems to be a real waste of the relatively small 254 bytes of potential value space. - Why are the sub-TLVs referred to as sub? Aren't they just TLVs? It looks like there's still plenty of open space in the main Type range to accommodate them, and many others for that matter. In a future enhancement, will we have sub-sub-TLVs? It would seem that a more general and consistent method for specifying, grouping, and encoding information might be called for - ASN.1/BER comes to mind. I realize that many vendors have already implemented this draft - my company being one of them (I think they'll flog me for this posting), and that some of the comments, while they will not add much functional value, will require rework, and in the case of the general comments, possibly quite a lot of rework. But since the document is still a draft and is introducing sub-TLVs, it might be nice if it also established a framework that could be copied and built upon instead of just something that can be made to work. John Odak john.odak@marconi.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Fri Mar 9 19:44:02 2001 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 09 Mar 2001 14:44:02 -0500 Subject: [Isis-wg] TE TLVs/Sub-TLVs In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA05A7C5@avalon.pluris.com> Message-ID: <4.3.2.7.2.20010309144201.01a40bb8@dingdong.cisco.com> I realize this has already been answered, but I think it needs to be stated more emphatically. Implementations are REQUIRED to ignore TLVs they don't recognize. For this reason, the length field is NECESSARY. I assume this is also true for sub-TLVs (is it stated in the draft that unrecognized sub-TLVs are to be ignored?) Jeff At 02:23 PM 3/9/2001, Satish Dattatri wrote: >Hi, > >By removing the 'L' in the sub-TLV it would cause headache for >implementations (other than cisco for now) not knowing a particular >*reserved* sub-TLV's length. An implementation will now have to >skip the rest of the data in TLV after hitting a unknown type. >This may not be desirable. > >But by making the length of all sub-TLV types well-known and >constant (no more *reserved* types), then the 'L' in the sub-TLVs >can be removed and it becomes sub-TV ;-). >Multiple values now will be in multiple sub-TV's (for ex. IP V4 interface >addresses). > >Satish > >-----Original Message----- >From: Odak, John [mailto:John.Odak@marconi.com] >Sent: Friday, March 09, 2001 10:34 AM >To: 'henk@procket.com'; 'isis-wg@external.juniper.net' >Subject: [Isis-wg] TE TLVs/Sub-TLVs > > >TE Authors, > >Please forgive the lateness of these comments on the TE draft >(draft-ietf-isis-traffic-02.txt), but I only recently started looking at it >- and ISIS itself for that matter - and I have a few somewhat obvious >comments about the TLVs/sub-TLVs that you've specified. Again, please >forgive this post if these issues have already been discussed and resolved. > >Specific comments: > >- The Extended IP Reachability TLV (type 135) has a one-octet control >information field that uses 1 bit to indicate the existence of sub-TLVs. >This is not necessary because the enclosing TLV already has a length field >that will indicate whether sub-TLVs are present. > >- The Extended IP Reachability TLV (type 135) has a one-octet control >information field that sets aside 6 bits for the IPv4 prefix length when >only 5 are required. One of the bits should be freed for possible future or >experimental use. > >- The Extended IP Reachability TLV (type 135) potentially has a one-octet >field to indicate the total length of any sub TLVs. This is not necessary >because the enclosing TLV already has a length field that will indicate the >total length of any sub-TLVs. > >- The Extended IS Reachability TLV (type 22) has a one-octet field to >indicate the total length of any sub TLVs. This is not necessary because the >enclosing TLV already has a length field that will indicate the total length >of any sub-TLVs. > >General comments and issues: > >- The Extended IS Reachability and Extended IP Reachability TLVs are >inconsistent in the manner in which they specify the presence of sub-TLVs. >Since both definitions are from the same document, and in fact are only one >page apart, shouldn't they look a little more like each other? > >- All of the sub-TLVs have been defined in terms of the Type-Length-Value >encoding format, but none has a variable length. This seems to be a real >waste of the relatively small 254 bytes of potential value space. > >- Why are the sub-TLVs referred to as sub? Aren't they just TLVs? It looks >like there's still plenty of open space in the main Type range to >accommodate them, and many others for that matter. In a future enhancement, >will we have sub-sub-TLVs? It would seem that a more general and consistent >method for specifying, grouping, and encoding information might be called >for - ASN.1/BER comes to mind. > >I realize that many vendors have already implemented this draft - my company >being one of them (I think they'll flog me for this posting), and that some >of the comments, while they will not add much functional value, will require >rework, and in the case of the general comments, possibly quite a lot of >rework. But since the document is still a draft and is introducing sub-TLVs, >it might be nice if it also established a framework that could be copied and >built upon instead of just something that can be made to work. > >John Odak >john.odak@marconi.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From satish@pluris.com Fri Mar 9 20:08:08 2001 From: satish@pluris.com (Satish Dattatri) Date: Fri, 9 Mar 2001 12:08:08 -0800 Subject: [Isis-wg] TE TLVs/Sub-TLVs Message-ID: <17C81AD1F1FED411991E006008F6D1CA05A7C7@avalon.pluris.com> Hi Jeff, Yes I know that LENGTH field is required in TLVs/sub-TLVs to skip the unknown ones. I was just saying that removing the length in the sub-TLV would not work unless *ALL* sub-TLV types (complete range 0-255) and corresponding length are defined. Since it is not possible to define complete range of TYPE values now, we need the length. satish -----Original Message----- From: Jeff Learman [mailto:jlearman@cisco.com] Sent: Friday, March 09, 2001 11:44 AM To: Satish Dattatri Cc: 'Odak, John'; 'henk@procket.com'; 'isis-wg@external.juniper.net' Subject: RE: [Isis-wg] TE TLVs/Sub-TLVs I realize this has already been answered, but I think it needs to be stated more emphatically. Implementations are REQUIRED to ignore TLVs they don't recognize. For this reason, the length field is NECESSARY. I assume this is also true for sub-TLVs (is it stated in the draft that unrecognized sub-TLVs are to be ignored?) Jeff At 02:23 PM 3/9/2001, Satish Dattatri wrote: >Hi, > >By removing the 'L' in the sub-TLV it would cause headache for >implementations (other than cisco for now) not knowing a particular >*reserved* sub-TLV's length. An implementation will now have to >skip the rest of the data in TLV after hitting a unknown type. >This may not be desirable. > >But by making the length of all sub-TLV types well-known and >constant (no more *reserved* types), then the 'L' in the sub-TLVs >can be removed and it becomes sub-TV ;-). >Multiple values now will be in multiple sub-TV's (for ex. IP V4 interface >addresses). > >Satish > >-----Original Message----- >From: Odak, John [mailto:John.Odak@marconi.com] >Sent: Friday, March 09, 2001 10:34 AM >To: 'henk@procket.com'; 'isis-wg@external.juniper.net' >Subject: [Isis-wg] TE TLVs/Sub-TLVs > > >TE Authors, > >Please forgive the lateness of these comments on the TE draft >(draft-ietf-isis-traffic-02.txt), but I only recently started looking at it >- and ISIS itself for that matter - and I have a few somewhat obvious >comments about the TLVs/sub-TLVs that you've specified. Again, please >forgive this post if these issues have already been discussed and resolved. > >Specific comments: > >- The Extended IP Reachability TLV (type 135) has a one-octet control >information field that uses 1 bit to indicate the existence of sub-TLVs. >This is not necessary because the enclosing TLV already has a length field >that will indicate whether sub-TLVs are present. > >- The Extended IP Reachability TLV (type 135) has a one-octet control >information field that sets aside 6 bits for the IPv4 prefix length when >only 5 are required. One of the bits should be freed for possible future or >experimental use. > >- The Extended IP Reachability TLV (type 135) potentially has a one-octet >field to indicate the total length of any sub TLVs. This is not necessary >because the enclosing TLV already has a length field that will indicate the >total length of any sub-TLVs. > >- The Extended IS Reachability TLV (type 22) has a one-octet field to >indicate the total length of any sub TLVs. This is not necessary because the >enclosing TLV already has a length field that will indicate the total length >of any sub-TLVs. > >General comments and issues: > >- The Extended IS Reachability and Extended IP Reachability TLVs are >inconsistent in the manner in which they specify the presence of sub-TLVs. >Since both definitions are from the same document, and in fact are only one >page apart, shouldn't they look a little more like each other? > >- All of the sub-TLVs have been defined in terms of the Type-Length-Value >encoding format, but none has a variable length. This seems to be a real >waste of the relatively small 254 bytes of potential value space. > >- Why are the sub-TLVs referred to as sub? Aren't they just TLVs? It looks >like there's still plenty of open space in the main Type range to >accommodate them, and many others for that matter. In a future enhancement, >will we have sub-sub-TLVs? It would seem that a more general and consistent >method for specifying, grouping, and encoding information might be called >for - ASN.1/BER comes to mind. > >I realize that many vendors have already implemented this draft - my company >being one of them (I think they'll flog me for this posting), and that some >of the comments, while they will not add much functional value, will require >rework, and in the case of the general comments, possibly quite a lot of >rework. But since the document is still a draft and is introducing sub-TLVs, >it might be nice if it also established a framework that could be copied and >built upon instead of just something that can be made to work. > >John Odak >john.odak@marconi.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From henk@Procket.com Fri Mar 9 21:25:26 2001 From: henk@Procket.com (Henk Smit) Date: Fri, 9 Mar 2001 22:25:26 +0100 (MET) Subject: [Isis-wg] Re: TE TLVs/Sub-TLVs In-Reply-To: <39469E08BD83D411A3D900204840EC5519EB42@VIE-MSGUSR-01> from "Odak, John" at Mar 09, 2001 01:33:43 PM Message-ID: <200103092125.WAA00900@kraak.procket.com> Hello John, > Please forgive the lateness of these comments on the TE draft > (draft-ietf-isis-traffic-02.txt), but I only recently started looking at it > - and ISIS itself for that matter - and I have a few somewhat obvious > comments about the TLVs/sub-TLVs that you've specified. Again, please > forgive this post if these issues have already been discussed and resolved. > > Specific comments: > > - The Extended IP Reachability TLV (type 135) has a one-octet control > information field that uses 1 bit to indicate the existence of sub-TLVs. > This is not necessary because the enclosing TLV already has a length field > that will indicate whether sub-TLVs are present. As others have pointed out, what happens if you put multiple IP prefixes in one TLV135 ? What comes after you have decyphered the first IP prefix ? Some sub-TLVs or the next IP prefix ? > - The Extended IP Reachability TLV (type 135) has a one-octet control > information field that sets aside 6 bits for the IPv4 prefix length when > only 5 are required. One of the bits should be freed for possible future or > experimental use. IP prefixes have a length between (and including) 0 bits (aka the default route) and 32 bits (aka host routes). That are 33 different values. Please enlighten us how to fit 33 values in 5 bits .... ;-) I think you are just of by one. > - The Extended IP Reachability TLV (type 135) potentially has a one-octet > field to indicate the total length of any sub TLVs. This is not necessary > because the enclosing TLV already has a length field that will indicate the > total length of any sub-TLVs. Same thing as above. Don't forget you can put multiple IP prefixes in TLV135, all which might have sub-TLVs. > - The Extended IS Reachability TLV (type 22) has a one-octet field to > indicate the total length of any sub TLVs. This is not necessary because the > enclosing TLV already has a length field that will indicate the total length > of any sub-TLVs. Same thing. > General comments and issues: > > - The Extended IS Reachability and Extended IP Reachability TLVs are > inconsistent in the manner in which they specify the presence of sub-TLVs. > Since both definitions are from the same document, and in fact are only one > page apart, shouldn't they look a little more like each other? This is intentional, and you'll have to blame Tony Li for this. The assumption was that a router can have tens to hunderds of adjacencies. In the worst case maye thousands. But a router might advertise thousands, maybe even hundreds of thousands of IP prefixes. Therefor we think that conserving space in TLV135 is more important than conserving space in TLV22. Another reason is that sub-TLVs in TLV22 are common, while sub-TLVs in TLV135 are hardly seen today. (There are plans for IP prefix coloring, and for multicast tags). > - All of the sub-TLVs have been defined in terms of the Type-Length-Value > encoding format, but none has a variable length. This seems to be a real > waste of the relatively small 254 bytes of potential value space. You don't know what sub-TLVs will exist in the future. So once your code encounters a sub-TLV it doesn't understand, the Length will allow you to skip it. This is a great help in the real world when ISP and enterprises want to migrate to newer version of the protocol without first upgrading all the software on all their routers. > - Why are the sub-TLVs referred to as sub? Aren't they just TLVs? Because sub-TLVs are TLVs inside TLVs. Giving them a different name makes it easier to discuss them in discussions. > It looks > like there's still plenty of open space in the main Type range to > accommodate them, and many others for that matter. In a future enhancement, > will we have sub-sub-TLVs? Maybe. That is up to the authors of new extensions that define new sub-TLVs. If they wanna use TLV encoding inside their sub-TLVs, that is fine with me. I guess those thingies will be called sub-sub-TLVs. > It would seem that a more general and consistent > method for specifying, grouping, and encoding information might be called > for - ASN.1/BER comes to mind. The current encoding is all in the same spirit of the original ISO 10589. Using ASN.1 might be an improvement in itself, but it would also imply a big change in "style" of the protocol. I am not sure everybody likes this. And we wanna keep it simple. Maybe if people come up with a brand new routing protocol. > I realize that many vendors have already implemented this draft - my company > being one of them (I think they'll flog me for this posting), and that some > of the comments, while they will not add much functional value, will require > rework, and in the case of the general comments, possibly quite a lot of > rework. But since the document is still a draft The document is a draft document. That implies we can change the text. That does not necessarily imply that we wanna change the content itself (the protocol). After all, the TE extensions are not just experimental anymore. They are used in the real world. > and is introducing sub-TLVs, > it might be nice if it also established a framework that could be copied and > built upon instead of just something that can be made to work. IMHO the current draft is just that: a framework. It defines how sub-TLVs are used in TLV22 and TLV135. People that wanna experiment with new stuff can add any information they want to link or prefixes. Expanding this framework to other protocols is overkill IMHO, as many protocols have different needs. You might notice that all newer protocols nowadays make use of TLVs. See attributes in BGP for example. Hope this helps, henk. From John.Odak@Marconi.com Fri Mar 9 22:16:40 2001 From: John.Odak@Marconi.com (Odak, John) Date: Fri, 9 Mar 2001 17:16:40 -0500 Subject: [Isis-wg] Re: TE TLVs/Sub-TLVs Message-ID: <39469E08BD83D411A3D900204840EC5519EB43@VIE-MSGUSR-01> Hello Henk, Thanks for the explanations. John -----Original Message----- From: Henk Smit [mailto:henk@procket.com] Sent: Friday, March 09, 2001 4:25 PM To: John.Odak@marconi.com Cc: henk@procket.com; isis-wg@spider.juniper.net Subject: [Isis-wg] Re: TE TLVs/Sub-TLVs Hello John, > Please forgive the lateness of these comments on the TE draft > (draft-ietf-isis-traffic-02.txt), but I only recently started looking at it > - and ISIS itself for that matter - and I have a few somewhat obvious > comments about the TLVs/sub-TLVs that you've specified. Again, please > forgive this post if these issues have already been discussed and resolved. > > Specific comments: > > - The Extended IP Reachability TLV (type 135) has a one-octet control > information field that uses 1 bit to indicate the existence of sub-TLVs. > This is not necessary because the enclosing TLV already has a length field > that will indicate whether sub-TLVs are present. As others have pointed out, what happens if you put multiple IP prefixes in one TLV135 ? What comes after you have decyphered the first IP prefix ? Some sub-TLVs or the next IP prefix ? > - The Extended IP Reachability TLV (type 135) has a one-octet control > information field that sets aside 6 bits for the IPv4 prefix length when > only 5 are required. One of the bits should be freed for possible future or > experimental use. IP prefixes have a length between (and including) 0 bits (aka the default route) and 32 bits (aka host routes). That are 33 different values. Please enlighten us how to fit 33 values in 5 bits .... ;-) I think you are just of by one. > - The Extended IP Reachability TLV (type 135) potentially has a one-octet > field to indicate the total length of any sub TLVs. This is not necessary > because the enclosing TLV already has a length field that will indicate the > total length of any sub-TLVs. Same thing as above. Don't forget you can put multiple IP prefixes in TLV135, all which might have sub-TLVs. > - The Extended IS Reachability TLV (type 22) has a one-octet field to > indicate the total length of any sub TLVs. This is not necessary because the > enclosing TLV already has a length field that will indicate the total length > of any sub-TLVs. Same thing. > General comments and issues: > > - The Extended IS Reachability and Extended IP Reachability TLVs are > inconsistent in the manner in which they specify the presence of sub-TLVs. > Since both definitions are from the same document, and in fact are only one > page apart, shouldn't they look a little more like each other? This is intentional, and you'll have to blame Tony Li for this. The assumption was that a router can have tens to hunderds of adjacencies. In the worst case maye thousands. But a router might advertise thousands, maybe even hundreds of thousands of IP prefixes. Therefor we think that conserving space in TLV135 is more important than conserving space in TLV22. Another reason is that sub-TLVs in TLV22 are common, while sub-TLVs in TLV135 are hardly seen today. (There are plans for IP prefix coloring, and for multicast tags). > - All of the sub-TLVs have been defined in terms of the Type-Length-Value > encoding format, but none has a variable length. This seems to be a real > waste of the relatively small 254 bytes of potential value space. You don't know what sub-TLVs will exist in the future. So once your code encounters a sub-TLV it doesn't understand, the Length will allow you to skip it. This is a great help in the real world when ISP and enterprises want to migrate to newer version of the protocol without first upgrading all the software on all their routers. > - Why are the sub-TLVs referred to as sub? Aren't they just TLVs? Because sub-TLVs are TLVs inside TLVs. Giving them a different name makes it easier to discuss them in discussions. > It looks > like there's still plenty of open space in the main Type range to > accommodate them, and many others for that matter. In a future enhancement, > will we have sub-sub-TLVs? Maybe. That is up to the authors of new extensions that define new sub-TLVs. If they wanna use TLV encoding inside their sub-TLVs, that is fine with me. I guess those thingies will be called sub-sub-TLVs. > It would seem that a more general and consistent > method for specifying, grouping, and encoding information might be called > for - ASN.1/BER comes to mind. The current encoding is all in the same spirit of the original ISO 10589. Using ASN.1 might be an improvement in itself, but it would also imply a big change in "style" of the protocol. I am not sure everybody likes this. And we wanna keep it simple. Maybe if people come up with a brand new routing protocol. > I realize that many vendors have already implemented this draft - my company > being one of them (I think they'll flog me for this posting), and that some > of the comments, while they will not add much functional value, will require > rework, and in the case of the general comments, possibly quite a lot of > rework. But since the document is still a draft The document is a draft document. That implies we can change the text. That does not necessarily imply that we wanna change the content itself (the protocol). After all, the TE extensions are not just experimental anymore. They are used in the real world. > and is introducing sub-TLVs, > it might be nice if it also established a framework that could be copied and > built upon instead of just something that can be made to work. IMHO the current draft is just that: a framework. It defines how sub-TLVs are used in TLV22 and TLV135. People that wanna experiment with new stuff can add any information they want to link or prefixes. Expanding this framework to other protocols is overkill IMHO, as many protocols have different needs. You might notice that all newer protocols nowadays make use of TLVs. See attributes in BGP for example. Hope this helps, henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From mongazon@ms.alcatel.fr Thu Mar 15 09:25:42 2001 From: mongazon@ms.alcatel.fr (Bruno Mongazon) Date: Thu, 15 Mar 2001 10:25:42 +0100 Subject: [Isis-wg] IS-IS restart References: <3AA91205.65DC418A@ms.alcatel.fr> <8406.010309@cisco.com> Message-ID: <3AB08A96.D67F9D1E@ms.alcatel.fr> Alex Zinin wrote: > > Bruno, > > I see your point. > > However, I think such a choice would make it harder > to predict that a graceful restart will actually happen > when different implementations make difference choices. > I would suggest we make it simple and go with the hold timer. > > -- > Alex Zinin > Alex, Mike, Agree, let's make it simple and go with the hold timer. I would just suggest to add a note in the draft indicating that, in order for graceful restart to actually happen, the hold timer of a restarting-capable IS shall be set to the max time the IS is expected to be out (including restart time). Best regards. Bruno. > > Alex Zinin wrote: > >> > >> Bruno, > >> > >> > Yes, i've got it: > >> > The faster (lower) you detect bad links, the faster (lower) you restart! > >> > >> > Anyway the restart time will be hidden. It is a part of the holding > >> > time. > >> > If you want to make this part visible to the peer, my suggestion should > >> > be ok? > >> > >> What value would it add to the mechanism? > >> > >> Alex. > > > Not a big value to the mechanism itself but a choice criterion from the > > peer perspective: > > > The peer can choose to support or not restart for the adjacency > > depending on the two values (holding time, restart time). If a router > > says it can detect bad links fast but restarts slowly, then the peer > > might choose high-speed detection without restart. > > > If everything is hidden in the hold timer, then the peer just ack/nack > > according to its restart capability. > > > Bruno. From mshand@cisco.com Thu Mar 15 09:51:06 2001 From: mshand@cisco.com (mike shand) Date: Thu, 15 Mar 2001 09:51:06 +0000 Subject: [Isis-wg] IS-IS restart In-Reply-To: <3AB08A96.D67F9D1E@ms.alcatel.fr> References: <3AA91205.65DC418A@ms.alcatel.fr> <8406.010309@cisco.com> Message-ID: <4.3.2.7.2.20010315095011.034ee498@jaws.cisco.com> OK. I'll add something to that effect. Mike At 10:25 15/03/2001 +0100, Bruno Mongazon wrote: >Alex Zinin wrote: > > > > Bruno, > > > > I see your point. > > > > However, I think such a choice would make it harder > > to predict that a graceful restart will actually happen > > when different implementations make difference choices. > > I would suggest we make it simple and go with the hold timer. > > > > -- > > Alex Zinin > > > >Alex, Mike, > >Agree, let's make it simple and go with the hold timer. > >I would just suggest to add a note in the draft indicating that, in >order for graceful restart to actually happen, the hold timer of a >restarting-capable IS shall be set to the max time the IS is expected to >be out (including restart time). > >Best regards. >Bruno. > > > > > Alex Zinin wrote: > > >> > > >> Bruno, > > >> > > >> > Yes, i've got it: > > >> > The faster (lower) you detect bad links, the faster (lower) you > restart! > > >> > > >> > Anyway the restart time will be hidden. It is a part of the holding > > >> > time. > > >> > If you want to make this part visible to the peer, my suggestion > should > > >> > be ok? > > >> > > >> What value would it add to the mechanism? > > >> > > >> Alex. > > > > > Not a big value to the mechanism itself but a choice criterion from the > > > peer perspective: > > > > > The peer can choose to support or not restart for the adjacency > > > depending on the two values (holding time, restart time). If a router > > > says it can detect bad links fast but restarts slowly, then the peer > > > might choose high-speed detection without restart. > > > > > If everything is hidden in the hold timer, then the peer just ack/nack > > > according to its restart capability. > > > > > Bruno. From christi@nortelnetworks.com Fri Mar 16 17:34:22 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Fri, 16 Mar 2001 17:34:22 -0000 Subject: [Isis-wg] Comments on IS-IS for IPv6 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_01C0AE3F.567A9260 Content-Type: text/plain First, I noticed that the draft-ietf-isis-ipv6-01.txt appears to have timed out. I think that it is important to have something that says how IPv6 should be routed with IS-IS and so this should be re-submitted. If Christian wants any help with this then I would be pleased to help. I also have some comments on the draft. It says in section 7 "Based on further study, future versions of this draft may specify an optional method for encapsulating IS-IS PDUs in IPv6 packets.". My understanding is that this option has been more or less ruled out for IPv4, and so I guess for IPv6 too. If so then this line could be replaced with something similar to "IS-IS PDUs will continue to be encapsulated using ISO 9542 as per RFC 1195." Also I have a more radical idea. In RFC 1195 it basically says (in my own words) that if any of network layer protocol "X" appears in an IS-IS area, then all routers in that area must support "X", where "X" would be something such as CLNP, IPv4 or IPv6. The risk is that if an IPv6-only router or routers are accidentally connected to an existing IPv4 network, that IS-IS in the IPv4 will see the IPv6 routers as a valid path. If any IPv4 packets are then sent to the IPv6 routers or vice versa then packet loss will occur. This problem could be solved by adding a clause into the IS-IS for IPv6 draft saying something like this:- "An IPv6-only router that uses IS-IS for IPv6 shall check that a neighbouring node supports IPv6 before completing an IS-IS adjacency with that node. It may do this by inspection of the "protocols supported" field of IS-IS Hello PDUs that it receives from the neighbouring node. If IPv6 is not listed in the "protocols supported" field of Hello packets sent by the neighbour then the IPv6-only router will refuse the adjacency." It wouldn't really change the rule in RFC 1195, but it would help to protect against an accidental connection dragging down part of an existing network. Regards, Philip Christian Tel (+44) (0)1279 403184 Fax (+44) (0)1279 402500 e-mail christi@nortelnetworks.com > Registered Company name & Address: > Nortel Networks UK Limited, Maidenhead Office Park, > Westacott Way, Maidenhead, Berkshire SL6 3QH > Company number: 3937799 ------_=_NextPart_001_01C0AE3F.567A9260 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Comments on IS-IS for IPv6

First, I noticed that the = draft-ietf-isis-ipv6-01.txt appears to have timed out.
I think that it is important to have = something that says how IPv6 should be routed with IS-IS and so this = should be re-submitted.

If Christian wants any help with this = then I would be pleased to help.

I also have some comments on the = draft.

It says in section 7 = "Based on = further study, future versions of this draft may specify an optional = method for encapsulating IS-IS PDUs in IPv6 packets.". My = understanding is that this option has been more or less ruled out for = IPv4, and so I guess for IPv6 too. If so then this line could be = replaced with something similar to "IS-IS PDUs will continue to be = encapsulated using ISO 9542 as per RFC 1195."

Also I have a more = radical idea.

In RFC 1195 it = basically says (in my own words) that if any of network layer protocol = "X" appears in an IS-IS area, then all routers in that area = must support "X", where "X" would be something such = as CLNP, IPv4 or IPv6.

The risk is that if = an IPv6-only router or routers are accidentally connected to an = existing IPv4 network, that IS-IS in the IPv4 will see the IPv6 routers = as a valid path. If any IPv4 packets are then sent to the IPv6 routers = or vice versa then packet loss will occur.

This problem could = be solved by adding a clause into the IS-IS for IPv6 draft saying = something like this:-
"An IPv6-only router that uses = IS-IS for IPv6 shall check that a neighbouring node supports IPv6 = before completing an IS-IS adjacency with that node. It may do this by = inspection of the "protocols supported" field of IS-IS Hello = PDUs that it receives from the neighbouring node. If IPv6 is not listed = in the "protocols supported" field of Hello packets sent by = the neighbour then the IPv6-only router will refuse the = adjacency."

It wouldn't really change the rule in = RFC 1195, but it would help to protect against an accidental connection = dragging down part of an existing network.

Regards, Philip Christian

Tel (+44) (0)1279 403184 Fax (+44) = (0)1279 402500
e-mail = christi@nortelnetworks.com
Registered Company name & = Address: 
Nortel Networks UK Limited, = Maidenhead Office Park,
Westacott Way, Maidenhead, Berkshire = SL6 3QH
Company number: 3937799

------_=_NextPart_001_01C0AE3F.567A9260-- From bedwards@juniper.net Sat Mar 17 00:58:15 2001 From: bedwards@juniper.net (Brian Edwards) Date: Fri, 16 Mar 2001 16:58:15 -0800 Subject: [Isis-wg] M-ISIS Message-ID: Instead of specifying reserved MT ID #'s in the M-ISIS draft; why not use the Address Families defined in RFC1700 like MBGP? I mentioned this to Nischal and he thinks it is a good idea, so I am sending it to the working group for comments. -Brian From prz@redback.com Sun Mar 18 01:35:59 2001 From: prz@redback.com (Tony Przygienda) Date: Sat, 17 Mar 2001 17:35:59 -0800 Subject: [Isis-wg] last call for draft-ietf-isis-transient-00.txt Message-ID: <3AB410FF.233CEBFC@redback.com> draft-ietf-isis-transient-00.txt goes last call. Last call finishes in 2 weeks thanks --- tony From prz@redback.com Sun Mar 18 01:50:37 2001 From: prz@redback.com (Tony Przygienda) Date: Sat, 17 Mar 2001 17:50:37 -0800 Subject: [Isis-wg] Comments on IS-IS for IPv6 References: Message-ID: <3AB4146D.A0DEA9C6@redback.com> Philip Christian wrote: > > > First, I noticed that the draft-ietf-isis-ipv6-01.txt appears to have > timed out. Christian's reissuing. It's in ADs hands right now and should go publication anytime soon. > I think that it is important to have something that says how IPv6 > should be routed with IS-IS and so this should be re-submitted. > > If Christian wants any help with this then I would be pleased to help. > > I also have some comments on the draft. > > It says in section 7 "Based on further study, future versions of this > draft may specify an optional method for encapsulating IS-IS PDUs in > IPv6 packets.". My understanding is that this option has been more or > less ruled out for IPv4, and so I guess for IPv6 too. If so then this > line could be replaced with something similar to "IS-IS PDUs will > continue to be encapsulated using ISO 9542 as per RFC 1195." Nothing has been ruled out. The requirement may or may not arise again. The 'may specify' here is fine. But your point is valid in the sense that since notyhing happened we should nuke the sentence completely before it goes RFC. > Also I have a more radical idea. > > In RFC 1195 it basically says (in my own words) that if any of network > layer protocol "X" appears in an IS-IS area, then all routers in that > area must support "X", where "X" would be something such as CLNP, IPv4 > or IPv6. > > The risk is that if an IPv6-only router or routers are accidentally > connected to an existing IPv4 network, that IS-IS in the IPv4 will see > the IPv6 routers as a valid path. If any IPv4 packets are then sent to > the IPv6 routers or vice versa then packet loss will occur. > > This problem could be solved by adding a clause into the IS-IS for > IPv6 draft saying something like this:- > "An IPv6-only router that uses IS-IS for IPv6 shall check that a > neighbouring node supports IPv6 before completing an IS-IS adjacency > with that node. It may do this by inspection of the "protocols > supported" field of IS-IS Hello PDUs that it receives from the > neighbouring node. If IPv6 is not listed in the "protocols supported" > field of Hello packets sent by the neighbour then the IPv6-only router > will refuse the adjacency." hmm, isn't that somewhere in 1195 anywherem too lazy to check now ? You can't build adjacencies unless protocols supported overlap. > It wouldn't really change the rule in RFC 1195, but it would help to > protect against an accidental connection dragging down part of an > existing network. Christian, you want to deal with those comments ? Minor enough to probably not being a MUST but somehow valid. thansk -- tony From chopps@nexthop.com Mon Mar 19 14:12:42 2001 From: chopps@nexthop.com (Christian E . Hopps) Date: Mon, 19 Mar 2001 09:12:42 -0500 Subject: [Isis-wg] Comments on IS-IS for IPv6 In-Reply-To: <3AB4146D.A0DEA9C6@redback.com>; from prz@redback.com on Sat, Mar 17, 2001 at 05:50:37PM -0800 References: <3AB4146D.A0DEA9C6@redback.com> Message-ID: <20010319091242.A26591@nexthop.com> On Sat, Mar 17, 2001 at 05:50:37PM -0800, Tony Przygienda wrote: > Philip Christian wrote: > > It says in section 7 "Based on further study, future versions of this > > draft may specify an optional method for encapsulating IS-IS PDUs in > > IPv6 packets.". My understanding is that this option has been more or > > less ruled out for IPv4, and so I guess for IPv6 too. If so then this > > line could be replaced with something similar to "IS-IS PDUs will > > continue to be encapsulated using ISO 9542 as per RFC 1195." > > Nothing has been ruled out. The requirement may or may not arise again. > The 'may specify' here is fine. But your point is valid in the sense > that since notyhing happened we should nuke the sentence completely > before it goes RFC. I can remove this before I re-submit. > > Also I have a more radical idea. [... don't form adj when nlpid of nbr indicates no ipv6 and router is ipv6 only] > > This problem could be solved by adding a clause into the IS-IS for > > IPv6 draft saying something like this:- > > "An IPv6-only router that uses IS-IS for IPv6 shall check that a > > neighbouring node supports IPv6 before completing an IS-IS adjacency > > with that node. It may do this by inspection of the "protocols > > supported" field of IS-IS Hello PDUs that it receives from the > > neighbouring node. If IPv6 is not listed in the "protocols supported" > > field of Hello packets sent by the neighbour then the IPv6-only router > > will refuse the adjacency." > > hmm, isn't that somewhere in 1195 anywherem too lazy to check now ? You > can't build adjacencies unless protocols supported overlap. > > > It wouldn't really change the rule in RFC 1195, but it would help to > > protect against an accidental connection dragging down part of an > > existing network. > > Christian, you want to deal with those comments ? Minor enough to > probably not being a MUST but somehow valid. I actually coded my implementation this way. The problem is that this doesn't solve all the misconfiguration situations. I think the much more likely "mis"-configuration will be for a router to be v6 only and its neighbors dual v4v6. In this case the adjacency will form but v4 traffic will get dropped by the v6 only router. Further the draft leaves open the above "misconfiguration" state and implementors are free to actually run multiple SPFs paying attention to the NLPID in the LSPs so as to restrict the graph to only supported protocols. This removes the "all routers must support the same protocols in an area" restriction. So, if people feel it is important I think we could add some text indicating that adjacencies should only form when the intersection of the NLPID is non-empty. This will cover the v6 only to v4 only router case, but not restrict the dual v6v4 to v6 only case. Chris. From jlearman@cisco.com Mon Mar 19 16:34:48 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 19 Mar 2001 11:34:48 -0500 Subject: [Isis-wg] Comments on IS-IS for IPv6 In-Reply-To: <20010319091242.A26591@nexthop.com> References: <3AB4146D.A0DEA9C6@redback.com> <3AB4146D.A0DEA9C6@redback.com> Message-ID: <4.3.2.7.2.20010319112244.019a51c8@dingdong.cisco.com> >Further the draft leaves open the above "misconfiguration" state and >implementors are free to actually run multiple SPFs paying attention >to the NLPID in the LSPs so as to restrict the graph to only supported >protocols. This removes the "all routers must support the same protocols >in an area" restriction. This is a great goal -- to permit mixing within a subdomain, unlike the way it currently is for IP+OSI. But is this sufficient? I think it only works if you require all IPV6-capable routers to support IPV4. Otherwise, you'd have an IPV4-only IS assuming that it can relay packets through IPV6-only routers. To make it possible to mix IPV6-only, IPV6+IPV4, and IPV4 only implementations, we'd need to put the IPV6 IS adjacencies in a new TLV. Or are IPV6-only implementations too far in the future for us to carefully consider them? (Or did I get this wrong to start with?) Another problem with "leaving an implementation free" to discriminate or not between protocols seems to me like it could cause routes to be calculated differently by different routers, causing loops or black holes. If we do discriminate, shouldn't we require it of all routers that implement the new RFC? (Perhaps the answer here is that "some new implementations can be mixed in areas, some can't". Is this what we want?) Forgive me if this was already discussed and I missed it, but I would recommend requiring the discrimination when running SPF and see if anyone objects. Regards, Jeff From mbartell@cisco.com Mon Mar 19 18:30:34 2001 From: mbartell@cisco.com (Micah Bartell) Date: Mon, 19 Mar 2001 12:30:34 -0600 Subject: [Isis-wg] M-ISIS In-Reply-To: Message-ID: <4.2.0.58.20010319112742.009f81c0@127.0.0.1> Isn't the idea of this draft to be a generic model for providing multiple topologies in the same AFI? I am also concerned about the AFI grouping that is done within this proposal. We take multiple AFI's and include them in a single TLV....I think it may worthwhile to consider the grouping a bit closer. For example: AFI = IPv4 Sub-AFI = Unicast Sub-AFI = Multicast Sub-AFI = VPN AFI = IPv6 Sub-AFI = Unicast Sub-AFI = Multicast Sub-AFI = VPN AFI = CLNS (Inband Management Network is a member of VPN Sub-AFI) This draft is taking all of the IPvX AFI's and Sub-AFI's and just mixing them all together in a single TLV. IS-IS is an integrated protocol, we do not need to integrate it all at the TLV level again. I would say we have plenty of TLV numbers available to cover about the next 50-75 protocols developed. If we can resolve the number of fragments limitation, we should be fine to carry all of this TE information. (How long before our LSPs are 90% TE info, and 10% routing info?) It makes sense to have the IPv4 TLV (135) and the IPv6 (236) be the primary TLV for their respective AFI, and have Sub-AFI information contained within. This draft does not remove the need for TLV22, but adds another TLV222, which would contain redundant information. The same holds true for TLV135 and TLV235. In fact, how many copies of the same link or prefix would we carry potentiallly? This would cause a fair amount of LSP Bloat, IMHO. If your goal is to create multiple topologies for IPv4 and IPv6, then create them on AFI boundaries. Using the Sub-AFI as the boundary removes the ability to leverage common information across that AFI. But a generic catch-all for all AFI's is not the right method. It can be argued that TLV 135 is going to become too bloated. Maybe TLV 135 should be used primarily to carry TE information, allowing for a separate TLV that is routing specific. Take your TLV 235 for instance. Make this IPv4 specific. Then we have the following sub-tlvs: sub-TLV 1: Unicast Length: 4 Value: Metric sub-TLV 2: Multicast Length: 4 Value: Metric sub-TLV 3: VPN Route Length: 8 Value: VPN ID<4> Metric<4> Now we take TLV 236 and relegate that to TE Information and the standard topology. We create TLV 237 for our IPv6 MT TLV, with the following sub-TLV's. sub-TLV 1: Unicast Length: 4 Value: Metric sub-TLV 2: Multicast Length: 4 Value: Metric sub-TLV 3: VPN Route Length: 8 Value: VPN ID<4> Metric<4> Now we take a look at TLV22. This is going to have to carry our TE information and the default metric. Now let's assume that we wish to carry multiple topologies. So we create TLV 222 and TLV 223. We now have our MT Extended IS Reachability TLV's. One for IPv4 and one for IPv6. Our sub-TLVs would be as follows: sub-TLV 1: Unicast Length: 4 Value: Metric sub-TLV 2: Multicast Length: 4 Value: Metric sub-TLV 3: VPN Route Length: 8 Value: VPN ID<4> Metric<4> If all of the topologies are congruent, you don't need to include a sub-TLV and you just default to the metric in TLV 22. In fact in all of the *new* TLV's mentioned here, the Unicast sub-TLV is optional, because that information is still carried in the main TLV. Obviously the formatting of these TLV's is a bit different, because in the standard TLV's you would not need a sub-TLV for unicast due to the default metric. But since these MT TLVs are in addition to the main TLV, the unicast metric is optional in the MT TLV. More or less this is just off the top of my head, so if this is based off an incorrect understanding about how the MT draft works.... /mpb At 04:58 PM 3/16/2001 -0800, Brian Edwards wrote: >Instead of specifying reserved MT ID #'s in the M-ISIS draft; why not use >the Address Families defined in RFC1700 like MBGP? I mentioned this to >Nischal and he thinks it is a good idea, so I am sending it to the working >group for comments. > >-Brian >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer Phone: 469.255.1806 SP-Advanced Network Services Cisco Systems, Inc -- The Network Works, No Excuses From prz@redback.com Mon Mar 19 21:04:11 2001 From: prz@redback.com (Tony Przygienda) Date: Mon, 19 Mar 2001 13:04:11 -0800 Subject: [Isis-wg] Comments on IS-IS for IPv6 References: <3AB4146D.A0DEA9C6@redback.com> <20010319091242.A26591@nexthop.com> Message-ID: <3AB6744B.A6E037CF@redback.com> > > I actually coded my implementation this way. The problem is that this > doesn't solve all the misconfiguration situations. I think the much > more likely "mis"-configuration will be for a router to be v6 only and > its neighbors dual v4v6. In this case the adjacency will form but v4 > traffic will get dropped by the v6 only router. > > Further the draft leaves open the above "misconfiguration" state and > implementors are free to actually run multiple SPFs paying attention > to the NLPID in the LSPs so as to restrict the graph to only supported > protocols. This removes the "all routers must support the same protocols > in an area" restriction. > > So, if people feel it is important I think we could add some text indicating > that adjacencies should only form when the intersection of the NLPID > is non-empty. This will cover the v6 only to v4 only router case, but > not restrict the dual v6v4 to v6 only case. now, wouldn't you just not advertise any ipv4 prefixes from the ipv6 onliy router. So no ipv4 traffic would even head towards a ipv6-only router ? So if an ipv6+ipv4 router forms adjacency, only traffic crossing it would be ipv6 anyway ? -- tony From prz@redback.com Mon Mar 19 21:05:05 2001 From: prz@redback.com (Tony Przygienda) Date: Mon, 19 Mar 2001 13:05:05 -0800 Subject: [Isis-wg] Comments on IS-IS for IPv6 References: <3AB4146D.A0DEA9C6@redback.com> <20010319091242.A26591@nexthop.com> Message-ID: <3AB67481.FCD645AD@redback.com> > > So, if people feel it is important I think we could add some text indicating > that adjacencies should only form when the intersection of the NLPID > is non-empty. This will cover the v6 only to v4 only router case, but > not restrict the dual v6v4 to v6 only case. I just wrote a stupid e-mail. Ignore it, I forgot the transit case ... silly me -- tony From chopps@nexthop.com Mon Mar 19 23:13:35 2001 From: chopps@nexthop.com (Christian E . Hopps) Date: Mon, 19 Mar 2001 18:13:35 -0500 Subject: [Isis-wg] Comments on IS-IS for IPv6 In-Reply-To: <4.3.2.7.2.20010319112244.019a51c8@dingdong.cisco.com>; from jlearman@cisco.com on Mon, Mar 19, 2001 at 11:34:48AM -0500 References: <3AB4146D.A0DEA9C6@redback.com> <3AB4146D.A0DEA9C6@redback.com> <20010319091242.A26591@nexthop.com> <4.3.2.7.2.20010319112244.019a51c8@dingdong.cisco.com> Message-ID: <20010319181335.A27758@nexthop.com> On Mon, Mar 19, 2001 at 11:34:48AM -0500, Jeff Learman wrote: > > > >Further the draft leaves open the above "misconfiguration" state and > >implementors are free to actually run multiple SPFs paying attention > >to the NLPID in the LSPs so as to restrict the graph to only supported > >protocols. This removes the "all routers must support the same protocols > >in an area" restriction. > > This is a great goal -- to permit mixing within a subdomain, unlike the > way it currently is for IP+OSI. But is this sufficient? I think it > only works if you require all IPV6-capable routers to support IPV4. > Otherwise, you'd have an IPV4-only IS assuming that it can relay packets > through IPV6-only routers. You are correct. I suppose I was only thinking about the "IPv6 is a subset of the IPv4 router set" case. I really don't think we need to overly complicate the extension to support any other configurations. Its worth noting that multiple vendors at this point have implemented this draft, in part I think because it was so easy. :) Chris. From jlearman@cisco.com Mon Mar 19 23:49:24 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 19 Mar 2001 18:49:24 -0500 Subject: [Isis-wg] Comments on IS-IS for IPv6 In-Reply-To: <20010319181335.A27758@nexthop.com> References: <4.3.2.7.2.20010319112244.019a51c8@dingdong.cisco.com> <3AB4146D.A0DEA9C6@redback.com> <3AB4146D.A0DEA9C6@redback.com> <20010319091242.A26591@nexthop.com> <4.3.2.7.2.20010319112244.019a51c8@dingdong.cisco.com> Message-ID: <4.3.2.7.2.20010319181948.01add4b8@dingdong.cisco.com> Chris, >> This is a great goal -- to permit mixing within a subdomain, unlike the >> way it currently is for IP+OSI. But is this sufficient? I think it >> only works if you require all IPV6-capable routers to support IPV4. >> Otherwise, you'd have an IPV4-only IS assuming that it can relay packets >> through IPV6-only routers. > >You are correct. I suppose I was only thinking about the "IPv6 is a >subset of the IPv4 router set" case. I really don't think we need to >overly complicate the extension to support any other configurations. > >Its worth noting that multiple vendors at this point have implemented >this draft, in part I think because it was so easy. :) It may be better than I first thought. True, we won't be able to intermix IPV6-only, dual, and IPV4-only. But we might be able to mix IPV6 with Dual, just as we can now mix Dual with IPV4. If there was a configuration option to enable checking protocols-supported when building both IPV4 FDBs, then we could do this. Initially, the IPV4 option would be disabled, so IPV4 FDBs would match between old and new implementations. As soon as all IPV4-only routers were upgraded (I assume we'll have a few years yet to do that), the options could be enabled, and we could mix Dual and IPV6. Note that I'm assuming that checking the option for IPV6 FDBs is required. Otherwise, I think we get mayhem. A little careful thought now might really reduce headaches later! Jeff From naiming@redback.com Wed Mar 21 08:39:49 2001 From: naiming@redback.com (Naiming Shen) Date: Wed, 21 Mar 2001 00:39:49 -0800 Subject: [Isis-wg] M-ISIS In-Reply-To: Mail from Brian Edwards dated Fri, 16 Mar 2001 16:58:15 PST Message-ID: <20010321084012.2A9C1B7679A@prattle.redback.com> I think M-ISIS is very different from MBGP. This is not meant to "transport" AFI and sub-AFI routes as the case in MBGP. When we proposed the reserved number and labelled them as "IPv6" or "multicast", it does not mean inside those TLVs, we will have IPv6 routes, or 224.x.x.x routes. They are still IPv4 unicast routes. Those routes are just "belong" to the IGP topologies we designate them for the use of IPv6 or of multicast. An example comes to mind will be UUcast, which is a seperate topology from regular IP unicast backbones and of course runs it's own IGP. Even though the purpose of that network is for multicast business, but the IGP is no different from the IGPs running in unicast IP backbones. Besides it uses up two more bytes than the MT ID# scheme, it will also casue confusing since the AFI or sub-AFI don't really have their true meaning. While the other useful things as In-Band management, special QoS networks may not be defined in the rfc1700. I would say just keep the current draft number scheme. thanks. ] ]Instead of specifying reserved MT ID #'s in the M-ISIS draft; why not use ]the Address Families defined in RFC1700 like MBGP? I mentioned this to ]Nischal and he thinks it is a good idea, so I am sending it to the working ]group for comments. ] ]-Brian ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From dino@procket.com Wed Mar 21 17:24:50 2001 From: dino@procket.com (Dino Farinacci) Date: Wed, 21 Mar 2001 09:24:50 -0800 Subject: [Isis-wg] M-ISIS In-Reply-To: <20010321084012.2A9C1B7679A@prattle.redback.com> (message from Naiming Shen on Wed, 21 Mar 2001 00:39:49 -0800) References: <20010321084012.2A9C1B7679A@prattle.redback.com> Message-ID: <200103211724.JAA04063@dino-pc.procket.com> >> I think M-ISIS is very different from MBGP. This is not meant to >> "transport" AFI and sub-AFI routes as the case in MBGP. When we proposed >> the reserved number and labelled them as "IPv6" or "multicast", it does >> not mean inside those TLVs, we will have IPv6 routes, or 224.x.x.x routes. Naiming, you seem to be implying MBGP carries 224.x.x.x routes. This is certainly not true. If that wasn't what you intended, ignore this message. Dino From naiming@redback.com Thu Mar 22 15:19:27 2001 From: naiming@redback.com (Naiming Shen) Date: Thu, 22 Mar 2001 07:19:27 -0800 Subject: [Isis-wg] M-ISIS In-Reply-To: Mail from Dino Farinacci dated Wed, 21 Mar 2001 09:24:50 PST <200103211724.JAA04063@dino-pc.procket.com> Message-ID: <20010322151950.9F3E6B76783@prattle.redback.com> ]>> I think M-ISIS is very different from MBGP. This is not meant to ]>> "transport" AFI and sub-AFI routes as the case in MBGP. When we proposed ]>> the reserved number and labelled them as "IPv6" or "multicast", it does ]>> not mean inside those TLVs, we will have IPv6 routes, or 224.x.x.x routes. ] ] Naiming, you seem to be implying MBGP carries 224.x.x.x routes. This is ] certainly not true. If that wasn't what you intended, ignore this message . Dino. Thanks pointing this out. My mistake. I had a wrong impression that MBGP were able to carry both types of routes. MBGP made it's mistake on this(using the AFIs), that's why so confusing:-) And I still mentain the rest part of my argument. But if we are going to use the AFIs, we probably need a bit to indicate the value is or not from the AFIs of rfc1700, since some of the applications has little to do with address family; or make the AFI when it's 0, the sub-AFI portion is our M-ISIS definition of topologies. Thanks. ] ]Dino ] ] - Naiming From Alex Zinin Wed Mar 28 03:08:10 2001 From: Alex Zinin (Alex Zinin) Date: Tue, 27 Mar 2001 19:08:10 -0800 Subject: [Isis-wg] OSPF WG: Retstart: moving further was: [Re: draft-ietf-ospf-hitless-restart-00.txt, draft-ietf-idr-restart-00.txt] In-Reply-To: <200103272235.PAA13925@tcb.net> References: <200103272235.PAA13925@tcb.net> Message-ID: <9797.010327@cisco.com> Danny: Thanks for your thoughts, the message was a good break in the middle of a battle... see my comments inline, please. > IS-IS: > o "Restart signaling for ISIS" (draft-shand-ISIS-restart-00.txt), > which discusses restart and resync for IS-IS. It must be noted that the discussion there was much more productive. > The IS-IS WG charter is quite dated as well... > OSPF: > o "OSPF Restart Signaling" (draft-ietf-ospf-restart-01.txt), > which was the first of the OSPF proposals and triggered > [unfortunately] competing proposals to provide this > functionality. This work falls into the "We'll accept > anything as a WG item" category". Add draft-ietf-ospf-oob-resync-01.txt here. This is a useful mechanism that is also used in our graceful restart implementation to resync LSDB on restart. > o "Hitless OSPF Restart" (draft-ietf-ospf-hitless-restart-00.txt), > which is John's proposal and falls into the "we'll accept > anything as a WG item" category. I guess this as well is > one of the benefits of having a charter with goals and > milestones as recent as Jun 98. > o I think an overhaul of the OSPF charter is necessary (have I > missed something in this area?). As a message that I sent to the WG today tells, I also think the WG charter should be updated. > I'll not argue the merits of the two proposals (type 9's versus new > bits in existing packets, resync, nsync, fairy dust, etc..), as I > think they've pretty much been beat to death. However, regardless of > what some of the author(s) have said, I feel they could be merged into > a single document and consensus reach in the WG based on the technical > merits of each. We are ready to work towards this. This does require, however, that both sides are willing to negotiate. > Certainly, requirements documents would help to scope this discussion, > as would up to date charters and milestones. After all, I'd hope an > associated requirements document would specify whether the additional > functionality of Alex's proposal is interesting to the community. > IMO, if we're planning to implement any of this, we might as well go > ahead and provide a full set of capabilities (not that any one of them > MUST be enabled in a network, mind you), as well as a common framework > and architecture for NSF/headless routing. I think it's doable and will have merit. In fact, we have started working on something like this with a number of folks... I think we can resume the effort and come up with the requirement and framework documents. Interested parties, please drop me a line. Thanks again! Alex. From hongal@riverstonenet.com Fri Mar 30 17:06:15 2001 From: hongal@riverstonenet.com (Thippanna Hongal) Date: Fri, 30 Mar 2001 10:06:15 -0700 Subject: [Isis-wg] SNMP MIB Message-ID: <3AC4BD07.B9AC0522@riverstonenet.com> hi ISIS-WG I am looking for SNMP Management Information Base for the IS-IS. Is anybody can point me to that document. thanks hongal Thippanna Hongal Riverstone Networks Inc. Santa Clara CA 95054 From jparker@axiowave.com Fri Mar 30 18:56:44 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 30 Mar 2001 13:56:44 -0500 Subject: [Isis-wg] SNMP MIB Message-ID: > hi ISIS-WG > > I am looking for SNMP Management Information Base for the IS-IS. > Is anybody can point me to that document. > > thanks > hongal > > Thippanna Hongal > Riverstone Networks Inc. Santa Clara CA 95054 Thippanna - It has aged off the list. I can send you a copy of the older version, if that would help. - jeff parker From prz@redback.com Fri Mar 30 17:52:08 2001 From: prz@redback.com (Tony Przygienda) Date: Fri, 30 Mar 2001 09:52:08 -0800 Subject: [Isis-wg] SNMP MIB References: Message-ID: <3AC4C7C8.830DE861@redback.com> Jeff Parker wrote: > > hi ISIS-WG > > > > I am looking for SNMP Management Information Base for the IS-IS. > > Is anybody can point me to that document. > > > > thanks > > hongal > > > > Thippanna Hongal > > Riverstone Networks Inc. Santa Clara CA 95054 > > Thippanna - > It has aged off the list. I can send you a > copy of the older version, if that would help. > > - jeff parker jeff, could you resubmit ? Or did the work die ? thanks -- tony From Internet-Drafts@ietf.org Tue Apr 3 12:50:50 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 03 Apr 2001 07:50:50 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ipv6-02.txt Message-ID: <200104031150.HAA26818@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 : Routing IPv6 with IS-IS Author(s) : C. Hopps Filename : draft-ietf-isis-ipv6-02.txt Pages : 6 Date : 02-Apr-01 This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol [0]. The method utilizes the same mechanisms described in RFC 1195 [1]. This is accomplished by adding 2 new TLVs and defining their use. These new TLVs are patterned from the ones described in 'IS-IS extensions for Traffic Engineering' [2]. Just as in RFC 1195 [1] with IPv4 and OSI, this method allows one to route both IPv4 and IPv6 using a single intra-domain routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt 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-ipv6-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-ipv6-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: <20010402124417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ipv6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ipv6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124417.I-D@ietf.org> --OtherAccess-- --NextPart-- From jparker@axiowave.com Fri Apr 6 20:42:39 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 6 Apr 2001 15:42:39 -0400 Subject: [Isis-wg] SNMP MIB Message-ID: I have put the ISIS mib through major changes, as outlined below I have sent the document to a dozen folks who had commented on the recent draft. I have also sent a copy to the reflector, but the file is too large to fit the profile. (Chalk up one win for traffic management.) If you have the interest and the time to review this, I would be happy to send a private copy. I will fold in any comments received and resubmit as version .04 next week. - jeff parker -- Changes this version -- -- Split off counting PDUs into a new table isisPacketCountTable -- responding to several suggestion on WG mail list -- Split off many level-specific circuit parameters into -- Circuit Level Table to allow more than two levels, -- responding to request from Tony Li -- Finished ripping out Authentication, as per request of R. Atkinson -- Striped mention of any metric other than default, as not used -- Compressed Rate Limiting variables -- Defined behavior when setting isisCircLevelHelloTimer at level 2 -- on a p2p link -- Deprecate isisCircIPEncaps OBJECT-TYPE -- -- Many changes suggested by Hans De Vleeschouwer, of Antwerp -- Use isisSysInstance to replace many local copies of same value -- Did the same for isisCircIndex -- Changed many MAX-ACCESS clauses of type read-write to read-create -- Limits on length of fields such as OSINSAddres and SystemID (now 0..6) -- While SystemIDs are all 6 if valid, there are places we need -- to represent a null SystemID, such as the isisCircLevelDesIS -- Fix mismatches of AdminState syntax and OperState descriptions -- Added text to describe isisISAdjNeighSysID for 3-way hello -- Removed IP Dest table, as this is covered by RFC 2096 -- -- Bugs: we are still stuck with L1 and L2 in -- isisSysMinL2LSPGenInt, isisSysOrigL2LSPBuffSize, -- isisSysLSPL2DbaseOloads, isisSysL2toL1Leaking From amudha@future.futsoft.com Fri Apr 13 12:06:49 2001 From: amudha@future.futsoft.com (Amudhavalli Narayanan) Date: Fri, 13 Apr 2001 16:36:49 +0530 Subject: [Isis-wg] Test suites for ISIS Message-ID: <000b01c0c409$d6c728e0$0705a8c0@future.futsoft.com> Hi, I would like to know if there are any publicly available ISIS test suites for protocol conformance Thanks, Amudha From ben.abarbanel@ipoptical.com Tue Apr 17 15:02:58 2001 From: ben.abarbanel@ipoptical.com (Ben Abarbanel) Date: Tue, 17 Apr 2001 10:02:58 -0400 Subject: [Isis-wg] IS-IS Traffic Engineering Extensions Message-ID: Hi guys: I was looking at the draft "IS-IS extensions for Traffic Engineering" . I looked at TLV type 135 (The Extented IP Reachability TLV) section 4.0 it mentions that there would be additional support for subTLVs. I was wondering if there is definition for these SubTLVs. A few big vendors have implemented these subTLVs but I have not seen any public disclosure of them. Any help will be appreciated, Ben From danny@ambernetworks.com Tue Apr 17 15:47:37 2001 From: danny@ambernetworks.com (Danny McPherson) Date: Tue, 17 Apr 2001 08:47:37 -0600 Subject: [Isis-wg] IS-IS Traffic Engineering Extensions Message-ID: <200104171447.IAA08527@tcb.net> Jeff P. proposed some text for the layout of the sub-TLVs a while back, though well after the -02 version of the draft was issued. Perhaps they'll find their way into the *next* version of the draft... Henk? I've included Jeff's message below, you can find it (and the rest of the thread) in the archives. Of course, this doesn't necessarily mean that what you've seen floating around conforms in any way. -danny > Hi guys: > I was looking at the draft "IS-IS extensions for Traffic Engineering" > . > > I looked at TLV type 135 (The Extented IP Reachability TLV) section 4.0 it > mentions that there would be additional support for subTLVs. I was > wondering if > there is definition for these SubTLVs. A few big vendors have implemented > these > subTLVs but I have not seen any public disclosure of them. > > Any help will be appreciated, [snip] From: Jeff Parker To: "'Tony Li'" Cc: "'henk@procket.com'" , "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 3 Jan 2001 09:59:36 -0500 Tony, Henk - This is offered to try to make the draft unambiguous to implement. You do refer to the values as "sub-TLV" throughout. However, there have been enough questions about the need for L in TLV on this and other lists recently that it would be good to remove doubt. This draft is being cited by a number of other drafts, so the effort to make it clear is worthwhile. In section in 4.0 The proposed extended IP reachability TLV contains a new data structure, consisting of: 4 bytes of metric information 1 byte of control information, consisting of 1 bit of up/down information 1 bit indicating the existence of sub-TLVs 6 bits of prefix length 0-4 bytes of IPv4 prefix 0-250 optional octets of sub-TVLs, if present consisting of 1 octet of length of sub-TLVs 0-249 octets of sub-TLVs you could replace the last line with 0-249 octets of sub-TLVs, consisting of a sequence of 1 octet of sub-type 1 octet of length 1-247 octets of value and the phrase in section 5.0 The proposed extended IS reachability TLV contains a new data structure, consisting of 7 octets of system Id and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs could be extended by 0-244 octets of sub-TLVs, consisting of a sequence of 1 octet of sub-type 1 octet of length 1-242 octets of value An example would help: either before section 4.0 or in a final section. For example, the sequence of 41 octets below 0x16 0x27 0xAAAA AAAA AAAA 00 0x00000A 0x06 0x03 0x04 0x01020304 0xBBBB BBBB BBBB 00 0x00000A 0x00 0xCCCC CCCC CCCC 00 0x00000A 0x00 is a TLV which describes three IS-IS neighbors. The first of these has an administrative color, defined by subtype 3, which consists of 4 octets of information. Someone could make the case that this is not prescriptive enough: it simply describes what should be done in a couple of cases. Such a person could argue for a special section describing the rules for a sub-TLV. - - jeff parker > Not doing a TLV is unthinkable, as that would completely > break the spirit > of the IS-IS design. > > If you would like to propose text, that's fine. It's > probably best to give > it to Henk as he has a bit more spare time than I do at present. > > | All of the examples given are fixed length, allowing an unwary > | implementor to imagine that they might be implemented as TV's > | rather than TLVs (that is, one is at risk of imagining that > | the length could be omitted). I can propose text to the list, > | but won't do so if this has been described someplace. > | > | - jeff parker > | - axiowave networks > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------- End of Forwarded Message From jparker@axiowave.com Fri Apr 6 15:29:20 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 6 Apr 2001 10:29:20 -0400 Subject: [Isis-wg] ISIS Mib Update 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_000_01C0BEA5.F7EB2D00 Content-Type: text/plain; charset="iso-8859-1" I have put the ISIS mib through major changes, as outlined below (these notes are also at the head of the file). I am sending this to the list for review before I submit as a draft. At present, my whimpy mib compiler cannot cope with a mib this large, so I will be dismembering it and feeding it into the compiler one part at a time. -- Changes this version -- -- Split off counting PDUs into a new table isisPacketCountTable -- responding to several suggestion on WG mail list -- Split off many level-specific circuit parameters into -- Circuit Level Table to allow more than two levels, -- responding to request from Tony Li -- Striped mention of any metric other than default -- -- Many changes suggested by Hans De Vleeschouwer, of Antwerp -- Use isisSysInstance to replace many local copies of same value -- Did the same for isisCircIndex -- Changed many MAX-ACCESS clauses of type read-write to read-create -- Limits on length of fields such as OSINSAddres and SystemID (now 0..6) -- While SystemIDs are all 6 if valid, there are places where -- we want to represent a null SystemID, such as the DIS -- Fix mismatches of AdminState syntax and OperState descriptions -- Added text to describe isisISAdjNeighSysID for 3-way hello -- Removed IP Dest table, as this is covered by RFC 2096 - jeff parker - axiowave networks - Those are my principles. If you don't like them, I have others. - Groucho Marx ------_=_NextPart_000_01C0BEA5.F7EB2D00 Content-Type: text/plain; name="isismib.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="isismib.txt" -- Changes this version -- -- Split off counting PDUs into a new table isisPacketCountTable=20 -- responding to several suggestion on WG mail list -- Split off many level-specific circuit parameters into=20 -- Circuit Level Table to allow more than two levels, -- responding to request from Tony Li -- Striped mention of any metric other than default -- -- Many changes suggested by Hans De Vleeschouwer, of Antwerp -- Use isisSysInstance to replace many local copies of same value -- Did the same for isisCircIndex -- Changed many MAX-ACCESS clauses of type read-write to read-create -- Limits on length of fields such as OSINSAddres and SystemID (now = 0..6) -- While SystemIDs are all 6 if valid, there are places where -- we want to represent a null SystemID, such as the DIS=20 -- Fix mismatches of AdminState syntax and OperState descriptions -- Added text to describe isisISAdjNeighSysID for 3-way hello -- Removed IP Dest table, as this is covered by RFC 2096 --=09 -- This document defines an experimental portion of the MIB -- containing objects for managing the operation of the IS-IS -- protocol. The objects are mainly derived from the GDMO -- definitions in ISO 10589. -- -- The contents of the MIB are based on a draft revision of an IETF -- MIB dated September 1992 and titled "Integrated IS-IS Management -- Information Base". -- -- Portions of the orignal MIB, such as objects for ES-IS exchange, -- have not been included due to being inapplicable. Additionally, -- corrections and enhancements have been included. -- -- The names of some original items have been left in the text -- as comments, as an indication of missing items. Many of these -- are relevant to routing CLNS traffic -- ISIS-MIB DEFINITIONS ::=3D BEGIN IMPORTS TEXTUAL-CONVENTION, DisplayString, RowStatus, TruthValue, TestAndIncr, DateAndTime FROM SNMPv2-TC MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Integer32, Counter32, IpAddress, experimental FROM SNMPv2-SMI; isis MODULE-IDENTITY LAST-UPDATED "200103121200Z" -- UTC date of the most recent = REVISION. ORGANIZATION "IETF IS-IS for IP Internets Working Group" CONTACT-INFO "Jeff Parker Axiowave Networks 100 Nickerson Rd. Marlborough, MA 01752 jparker@axiowave.com" DESCRIPTION "" ::=3D { experimental 37 } -- OBJECT IDENTIFIER definitions isisSystem OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 1 } isisCirc OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 2 } isisCircLevelValues OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 3 } isisCircPDUCounters OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 4 } isisISAdj OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 5 } isisReachAddr OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 6 } isisIPReachAddr OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 7 } -- Type definitions OSINSAddress ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "OSI Network Service Address, e.g. NSAP, Network Entity = Title" SYNTAX OCTET STRING (SIZE(1..20)) SNPAAddress ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "A MAC Address or DTE Address or other SNPA Address." SYNTAX OCTET STRING (SIZE(0..20)) NSAPPrefix ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "NSAP Prefix. The first octet of the string is used to encode as an unsigned integer the length in bits of the subsequent prefix. This length must be a multiple of 4 bits and may range from 0..160. The second and subsequent octets are used to hold the prefix value. If the last 4 bits of the last octet are not part of the prefix then their value is undefined." SYNTAX OCTET STRING (SIZE(1..21)) SNPAPrefix ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "SNPA Prefix. The first octet of the string is used to encode as an unsigned integer the length in bits of the subsequent prefix. The second and subsequent octets are used to hold the prefix value. Bits in the last octet which are not part of the prefix have undefined value." SYNTAX OCTET STRING (SIZE(1..21)) SystemID ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "A system ID." SYNTAX OCTET STRING (SIZE(0..6)) AdminState ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Type used in enabling and disabling a row." SYNTAX INTEGER { off(1), on(2) } UpTime ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Number of seconds since the object has entered the state = 'up'. If the object is not up, the number of seconds since the circuit was up, or since the system started, if the = circuit has never been up." SYNTAX Integer32 LSPBuffSize ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Integer sub range for LSP size." SYNTAX Integer32 (512..1492) LevelState ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "states of the ISIS protocol." SYNTAX INTEGER { off (1), on (2), waiting (3) } SupportedProtocol ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Types of network protocol supported by Integrated ISIS. The values for ISO8473 and IP are those registered for these protocols in ISO TR9577." SYNTAX INTEGER { iso8473(129), ip(204), ipV6(205) } DefaultMetric ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Integer sub-range for default metric for single hop." SYNTAX Integer32 (1..63) MetricType ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Class of metric at Level 2." SYNTAX INTEGER { internal(1), external(2) } CircuitID ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "ID for a circuit." SYNTAX OCTET STRING (SIZE(2..9)) ISPriority ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Integer sub-range for ISIS priority." SYNTAX Integer32 (1..127) -- Behaviour Definitions -- ResettingTimer behaviour definition -- "This object specifies the interval between certain events in -- the operation of the protocol state machine. If the value of -- this object is set to a new value while the protocol state -- machine is in operation, the implementation shall take the -- necessary steps to ensure that for any time interval which -- was in progress when the value of the corresponding object -- was changed, the next expiration of that interval takes place -- the specified time after the original start of that interval, -- or immediately, whichever is later. The precision with which -- this time shall be implemented shall be the same as that -- associated with the basic operation of the timer object." -- ReplaceOnlyWhileDisabled behaviour definition -- "This object may not be modified while the corresponding=20 -- table row's variable of type AdminState is in state on." -- OperationalState behaviour definition -- "This object controls the enabling and disabling of the -- corresponding table row. Setting this object to the value -- off has the effect of disabling the corresponding row. -- Setting this object to the value on has the effect of -- enabling the corresponding row. Setting the value of this -- object to the same value as its current value has no effect. -- If the table entry also contains an object controlling the -- row status then the object following the operationalState -- behaviour shall not be set to on when the object following -- the Row Status behaviour has value off. An attempt to do -- so is rejected." isisSysTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisSysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of instances of the Integrated IS-IS protocol existing on the system." ::=3D { isisSystem 1 } isisSysEntry OBJECT-TYPE SYNTAX IsisSysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row defines information specific to a single instance of the protocol existing on the system." REFERENCE "{ISIS.poi cLNSISISBasic-P (1)}" INDEX { isisSysInstance } ::=3D { isisSysTable 1 } IsisSysEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisSysVersion DisplayString, isisSysType INTEGER, isisSysID SystemID, isisSysMaxPathSplits Integer32, isisSysMaxLSPGenInt Integer32, isisSysOrigL1LSPBuffSize LSPBuffSize, isisSysMaxAreaAddresses Integer32, isisSysMinL1LSPGenInt =20 Integer32, isisSysMinL2LSPGenInt=20 Integer32, isisSysPollESHelloRate Integer32, isisSysWaitTime Integer32, isisSysAdminState AdminState, isisSysL1State LevelState, isisSysCorrLSPs Counter32, isisSysLSPL1DbaseOloads Counter32, isisSysManAddrDropFromAreas Counter32, isisSysAttmptToExMaxSeqNums Counter32, isisSysSeqNumSkips Counter32, isisSysOwnLSPPurges Counter32, isisSysIDFieldLenMismatches Counter32, isisSysMaxAreaAddrMismatches Counter32, isisSysOrigL2LSPBuffSize LSPBuffSize, isisSysL2State LevelState, isisSysLSPL2DbaseOloads Counter32, isisSysAuthFails Counter32, isisSysLSPIgnoreErrors TruthValue, isisSysLogAdjacencyChanges TruthValue, isisSysPartChanges Counter32, isisSysMaxAreaCheck TruthValue, isisSysNextCircIndex TestAndIncr, isisSysExistState RowStatus, isisSysL2toL1Leaking TruthValue, isisSysSetOverload INTEGER } isisSysInstance OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the Integrated IS-IS instance to which this row corresponds. This object follows the index behaviour." ::=3D { isisSysEntry 1 } isisSysVersion OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the IS-IS protocol to which this instance conforms. This value must be set by the implementation when the row is valid." REFERENCE "{ISIS.aoi version (1)}" ::=3D { isisSysEntry 2 } isisSysType OBJECT-TYPE SYNTAX INTEGER { level1IS (1), level2IS (2), level1l2IS (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of this instance of the Integrated IS-IS protocol. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi iSType (2)}" ::=3D { isisSysEntry 3 } isisSysID OBJECT-TYPE SYNTAX SystemID MAX-ACCESS read-create STATUS current DESCRIPTION "The ID for this instance of the Integrated IS-IS protocol. This value is appended to each of the instance's area addresses to form the Network Entity Titles valid for this instance. The derivation of a value for this object is implementation-specific. Some implementations may assign values and not permit write, others may require the value to be set manually." REFERENCE "{ISIS.aoi systemId (119)}" ::=3D { isisSysEntry 4 } isisSysMaxPathSplits OBJECT-TYPE SYNTAX Integer32 (1..32) MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum number of paths with equal routing metric value which it is permitted to split between. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi maximumPathSplits (3)}" DEFVAL { 2 } ::=3D { isisSysEntry 5 } isisSysMaxLSPGenInt OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum interval, in seconds, between generated LSPs by this instance. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi maximumLSPGenerationInterval (6)}" DEFVAL { 900 } ::=3D { isisSysEntry 6 } isisSysOrigL1LSPBuffSize OBJECT-TYPE SYNTAX LSPBuffSize MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum size of Level 1 LSPs and SNPs originated by this instance. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi originatingL1LSPBufferSize (9)}" DEFVAL { 1492 } ::=3D { isisSysEntry 7 } isisSysMaxAreaAddresses OBJECT-TYPE SYNTAX Integer32 (3..254) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of area addresses to be permitted for the area in which this instance exists. Note that all Intermediate Systems in the same area must have the same value configured for this attribute if correct operation is to be assumed. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi maximumAreaAddresses (4)}" DEFVAL { 3 } ::=3D { isisSysEntry 8 } isisSysMinL1LSPGenInt OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval, in seconds, between successive generatio= n of L1 LSPs with the same LSPID by this instance. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi minimumLSPGenerationInterval (11)}" DEFVAL { 30 } ::=3D { isisSysEntry 9 } isisSysMinL2LSPGenInt OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval, in seconds, between successive = generation of L2 LSPs with the same LSPID by this instance. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi minimumLSPGenerationInterval (11)}" DEFVAL { 30 } ::=3D { isisSysEntry 10 } isisSysPollESHelloRate OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The value, in seconds, to be used for the suggested ES configuration timer in ISH PDUs when soliciting the ES configuration." REFERENCE "{ISIS.aoi pollESHelloRate (13)}" DEFVAL { 50 } ::=3D { isisSysEntry 11 } isisSysWaitTime OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Number of seconds to delay in waiting state before entering on state. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi waitingTime (15)}" DEFVAL { 60 } ::=3D { isisSysEntry 12 } isisSysAdminState OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of this instance of the = Integrated IS-IS protocol. Setting this object to the value on when its current value is off enables operation of this instance of the Integrated IS-IS protocol." DEFVAL { off } ::=3D { isisSysEntry 13 } isisSysL1State OBJECT-TYPE SYNTAX LevelState MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the Level 1 database." REFERENCE "{ISIS.aoi l1State (17)}" ::=3D { isisSysEntry 14 } isisSysCorrLSPs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of corrupted LSPs detected." REFERENCE "{ISIS.aoi corruptedLSPsDetected (19)}" ::=3D { isisSysEntry 15 } isisSysLSPL1DbaseOloads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the LSP L1 database has become overloaded." REFERENCE "{ISIS.aoi lSPL1DatabaseOverloads (20)}" ::=3D { isisSysEntry 16 } isisSysManAddrDropFromAreas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a manual address has been dropped from the area." REFERENCE "{ISIS.aoi manualAddressesDroppedFromArea (21)}" ::=3D { isisSysEntry 17 } isisSysAttmptToExMaxSeqNums OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the IS has attempted to exceed the maximum sequence number." REFERENCE "{ISIS.aoi attemptsToExceedmaximumSequenceNumber (22)}" ::=3D { isisSysEntry 18 } isisSysSeqNumSkips OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a sequence number skip has occurred." REFERENCE "{ISIS.aoi sequenceNumberSkips (23)}" ::=3D { isisSysEntry 19 } isisSysOwnLSPPurges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a zero-aged copy of the system's own LSP is received from some other node." REFERENCE "{ISIS.aoi ownLSPPurges (24)}" ::=3D { isisSysEntry 20 } isisSysIDFieldLenMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a PDU is received with a different value for ID field length to that of the receiving system." REFERENCE "{ISIS.aoi iDFieldLengthMismatches (25)}" ::=3D { isisSysEntry 21 } isisSysMaxAreaAddrMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a PDU is received with a different value for MaximumAreaAddresses from that of the receiving system." REFERENCE "{ISIS.aoi MaximumAreaAddressesMismatches (118)}" ::=3D { isisSysEntry 22 } -- The following objects map those from the cLNSISISLevel2-P -- Package isisSysOrigL2LSPBuffSize OBJECT-TYPE SYNTAX LSPBuffSize MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum size of Level 2 LSPs and SNPs originated by this system. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi originatingL2LSPBufferSize (26)}" DEFVAL { 1492 } ::=3D { isisSysEntry 23 } isisSysL2State OBJECT-TYPE SYNTAX LevelState MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the Level 2 database." REFERENCE "{ISIS.aoi l2State (28)}" ::=3D { isisSysEntry 24 } isisSysLSPL2DbaseOloads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the Level 2 LSP database has become overloaded." REFERENCE "{ISIS.aoi lSPL2DatabaseOverloads (32)}" ::=3D { isisSysEntry 25 } isisSysAuthFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of authentication failures recognized by this instance of the protocol." ::=3D { isisSysEntry 26 } 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 } ::=3D { isisSysEntry 27 } isisSysLogAdjacencyChanges OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, causes IS-IS to generate a log message when an IS-IS adjacency changes state (up or down)." DEFVAL { false } ::=3D { isisSysEntry 28 } isisSysPartChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "partition changes" ::=3D { isisSysEntry 29 } isisSysMaxAreaCheck OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "When on, enables checking of maximum area addresses per IS version of ISO10589." DEFVAL { true } ::=3D { isisSysEntry 30 } isisSysNextCircIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to assign values to isisCircIndex as described in 'Textual Conventions for SNMPv2'. The network manager reads this object, and then writes the value back as the isisCircIndex in a SET that creates=20 a new instance of isisCircEntry. If the SET=20 fails with the code 'inconsistentValue', then=20 the process must be repeated; If the SET succeeds,=20 then the object is incremented, and the new=20 instance is created according to the manager's=20 directions." ::=3D { isisSysEntry 31 } isisSysExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the ISIS router. Turning this off forces the router to forget all current state" DEFVAL { active } ::=3D { isisSysEntry 32 } isisSysL2toL1Leaking OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, allow the router to leak L2 routes into L1." DEFVAL { false } ::=3D { isisSysEntry 33 } isisSysSetOverload OBJECT-TYPE SYNTAX INTEGER { setL1Overload(1), setL2Overload(2), setL1L2Overload(3), overloadClear(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "Administrativly set the overload bit for each level. The overload bit will continue to be set if the implementation runs out of memory, independent of this variable" DEFVAL {overloadClear } ::=3D { isisSysEntry 34 } -- The Level 1 Manual Area Address Table -- contains the set of area addresses manually configured -- for each instance of the Integrated IS-IS protocol. -- At least one row in which the value of -- isisManAreaAddrExistState -- is on must be present for each instance of the protocol -- when isisSysAdminState is also on for that instance. The -- maximum number of rows in this table for each instance of -- the protocol for which the object isisManAreaAddrExistState -- has the value on is the value of isisSysMaxAreaAddresses. -- An Attempt to create a new row such that the number of=20 -- rows with isisManAreaAddrExistState set to on for that=20 -- protocol instance exceeds isisSysMaxAreaAddresses -- is rejected." isisManAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisManAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of manual area addresses configured on this Intermediate System." REFERENCE "{ISIS.aoi manualAreaAddresses (10)}" ::=3D { isisSystem 2 } isisManAreaAddrEntry OBJECT-TYPE SYNTAX IsisManAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address manually configured on this system" INDEX { isisSysInstance, isisManAreaAddr } ::=3D { isisManAreaAddrTable 1 } IsisManAreaAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisManAreaAddr OSINSAddress, isisManAreaAddrExistState RowStatus } isisManAreaAddr OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "A manually configured area address for this system. This object follows the index behaviour. Note: an index for the entry {1, {49.0001} active} in this table would be the ordered pair (1, (0x03 0x49 0x00 0x01)), as the length of an Octet string is part of the OID." ::=3D { isisManAreaAddrEntry 1 } isisManAreaAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the isisManAreaAddrEntry. This object follows the Row Status behaviour. If an attempt is made to set this object to the value off when the corresponding isisManAreaAddrEntry is the only valid entry for this instance and when the corresponding ISIS instance has isisSysAdminState set to On then the attempt is rejected." DEFVAL { active } ::=3D { isisManAreaAddrEntry 2 } -- The Level 1 Area Address Table -- The Level 1 Area Address Table contains the -- union of the sets of area addresses reported in all Level 1 -- LSPs received by this Intermediate System. isisAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The union of the sets of area addresses reported in all Level 1 LSPs received by this instance of the protocol." REFERENCE "{ISIS.aoi areaAddresses (18)}" ::=3D { isisSystem 3 } isisAreaAddrEntry OBJECT-TYPE SYNTAX IsisAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address reported in a Level 1 LSP received by this instance of the protocol." INDEX { isisSysInstance, isisAreaAddr } ::=3D { isisAreaAddrTable 1 } IsisAreaAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisAreaAddr OSINSAddress } isisAreaAddr OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An area address reported in a Level 1 LSP received by this instance of the protocol." ::=3D { isisAreaAddrEntry 1 } -- The System Integrated Group -- The System Integrated Group is present if the system -- supports Integrated ISIS at Level 1. -- The System Protocol Supported Table -- The System Protocol Supported Table contains the manually -- configured set of protocols supported by each -- instance of the Integrated ISIS protocol. -- isisSysProtSuppTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisSysProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the manually configured set of protocols supported by each instance of the Integrated ISIS protocol." ::=3D { isisSystem 4 } isisSysProtSuppEntry OBJECT-TYPE SYNTAX IsisSysProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one protocol supported by an instance of the Integrated ISIS protocol." INDEX { isisSysInstance, isisSysProtSuppProtocol } ::=3D { isisSysProtSuppTable 1 } IsisSysProtSuppEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisSysProtSuppProtocol SupportedProtocol, isisSysProtSuppExistState RowStatus } isisSysProtSuppProtocol OBJECT-TYPE SYNTAX SupportedProtocol MAX-ACCESS not-accessible STATUS current DESCRIPTION "One supported protocol. This object follows the index behaviour." ::=3D { isisSysProtSuppEntry 1 } isisSysProtSuppExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the isisSysProtSuppEntry. This object follows the RowStatus behavior." DEFVAL { active } ::=3D { isisSysProtSuppEntry 2 } -- The Summary Address Table -- The Summary Address Table contains the set of summary -- addresses manually configured for each instance of -- IP Integrated ISIS on the system. isisSummAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisSummAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of IP summary addresses to use in forming the contents of LSPs originated by this Intermediate System." ::=3D { isisSystem 5 } isisSummAddrEntry OBJECT-TYPE SYNTAX IsisSummAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IP summary address." INDEX { isisSysInstance, isisSummAddress, isisSummAddrMask } ::=3D { isisSummAddrTable 1 } IsisSummAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisSummAddress IpAddress, isisSummAddrMask IpAddress, isisSummAddrExistState RowStatus, isisSummAddrAdminState INTEGER, isisSummAddrDefaultMetric DefaultMetric } isisSummAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP Address value for this summary address. This object follows the index behaviour." ::=3D { isisSummAddrEntry 1 } isisSummAddrMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mask value for this summary address. This object follows the index behaviour." ::=3D { isisSummAddrEntry 2 } isisSummAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this summary address. This object follows the row status behaviour." DEFVAL { active } ::=3D { isisSummAddrEntry 3 } isisSummAddrAdminState OBJECT-TYPE SYNTAX INTEGER { summaryl1(1), summaryl2(2), summaryl1l2(3), summaryOff(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of this entry. When the administrative state changes, if the new value would cause the contents of LSPs originated by the system to change, then those new LSPs must be generated and sent as soon as is permitted by the ISIS protocol." DEFVAL { summaryOff } ::=3D { isisSummAddrEntry 4 } isisSummAddrDefaultMetric OBJECT-TYPE SYNTAX DefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The default metric value to announce this summary address with in LSPs generated by this system." DEFVAL { 20 } ::=3D { isisSummAddrEntry 5 } -- The Circuit Group -- The Circuit Group is current -- The Circuit Table -- Each broadcast or point-to-point interface on the system -- corresponds to one entry in the Circuit table. There may be -- many X.25 DA circuit entries in the Circuit table for an -- X.25 interface. isisCircTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisCircEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of circuits used by each instance of Integrated IS-IS on this system." ::=3D { isisCirc 1 } isisCircEntry OBJECT-TYPE SYNTAX IsisCircEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An isisCircEntry exists for each circuit used by Integrated IS-IS on this system." INDEX { isisSysInstance, isisCircIndex } ::=3D { isisCircTable 1 } IsisCircEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisCircIfIndex Integer32, isisCircIfSubIndex Integer32, isisCircLocalID Integer32, isisCircAdminState AdminState, isisCircExistState RowStatus, isisCircType INTEGER, isisCircExtDomain TruthValue, isisCircAdjChanges Counter32, isisCircInitFails Counter32, isisCircRejAdjs Counter32, isisCircOutCtrlPDUs Counter32, isisCircInCtrlPDUs Counter32, isisCircIDFieldLenMismatches Counter32, isisCircLevel INTEGER, isisCircMCAddr INTEGER, isisCircPtToPtCircID CircuitID, isisCircPassiveCircuit TruthValue, isisCircMeshGroupEnabled INTEGER, isisCircMeshGroup Integer32, isisCircSmallHellos AdminState, isisCircIPEncaps TruthValue, isisCircUpTime UpTime } isisCircIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of this circuit, unique within the instance of the protocol. This object follows the index behaviour. This is for SNMP Indexing purposes only and has no relation to any protocol value." ::=3D { isisCircEntry 2 } 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" ::=3D { isisCircEntry 3 } isisCircIfSubIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "A specifier for the part of the interface ifIndex to = which this circuit corresponds, such as a DLCI or VPI/VCI. This object cannot be modified after creation" ::=3D { isisCircEntry 4 } 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=20 not need to be unique. They are only required to differ=20 on LANs where the Intermediate System is the Designated=20 Intermediate System." ::=3D { isisCircEntry 5 } isisCircAdminState OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the circuit. This=20 object follows the AdminState behaviour." DEFVAL { off } ::=3D { isisCircEntry 6 } isisCircExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this circuit. This object follows the Row Status behaviour." DEFVAL { active } ::=3D { isisCircEntry 7 } isisCircType OBJECT-TYPE SYNTAX INTEGER { broadcast(1), ptToPt(2), staticIn(3), staticOut(4), dA(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the circuit. This object follows the replaceOnlyWhileDisabled behaviour. The type specified must be compatible with the type of the interface defined by the value of isisCircIfIndex." REFERENCE "{ISIS.aoi type (33)}" ::=3D { isisCircEntry 8 } isisCircExtDomain OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, suppress normal transmission of and interpretation of Intra-domain ISIS PDUs on this circuit." REFERENCE "{ISIS.aoi externalDomain (46)}" DEFVAL { false } ::=3D { isisCircEntry 9 } isisCircAdjChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an adjacency state change has occurred on this circuit." REFERENCE "{ISIS.aoi changesInAdjacencyState (40)}" ::=3D { isisCircEntry 14 } isisCircInitFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times initialization of this circuit has failed." REFERENCE "{ISIS.aoi initializationFailures (41)}" ::=3D { isisCircEntry 15 } isisCircRejAdjs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an adjacency has been rejected on this circuit." REFERENCE "{ISIS.aoi rejectedAdjacencies (42)}" ::=3D { isisCircEntry 16 } isisCircOutCtrlPDUs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS control PDUs sent on this circuit." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisCircEntry 17 } isisCircInCtrlPDUs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS control PDUs received on this circuit." REFERENCE "{ISIS.aoi controlPDUsReceived (44)}" ::=3D { isisCircEntry 18 } isisCircIDFieldLenMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an IS-IS control PDU with an ID field length different to that for this system has been received." REFERENCE "{ISIS.aoi iDFieldLengthMismatches (25)}" ::=3D { isisCircEntry 19 } isisCircLevel OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), level1l2(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates which type of packets will be sent and accepted on this circuit. The values used will be modified by the settings of isisSysType. This object follows the replaceOnlyWhileDisabled behaviour." DEFVAL { level1l2 } ::=3D { isisCircEntry 20 } isisCircMCAddr OBJECT-TYPE SYNTAX INTEGER{ group (1), functional (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies which type of multicast address will be used for sending HELLO PDUs on this circuit." DEFVAL { group } ::=3D { isisCircEntry 21 } isisCircPtToPtCircID OBJECT-TYPE SYNTAX CircuitID MAX-ACCESS read-create STATUS current DESCRIPTION "The ID of the circuit allocated during initialization. If no value has been negotiated (either because the adjacency is to an End System, or because initialization has not yet successfully completed), this object has the value which would be proposed for this circuit (i.e. the concatenation of the local system ID and the one octet local Circuit ID for this circuit." REFERENCE "{ISIS.aoi ptPtCircuitID (51)}" ::=3D { isisCircEntry 22 } isisCircPassiveCircuit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Should we include this interface in LSPs, even if it is not running the ISIS Protocol?" REFERENCE "{}" DEFVAL { false } ::=3D { isisCircEntry 23 } isisCircMeshGroupEnabled OBJECT-TYPE SYNTAX INTEGER { inactive(1), blocked(2), set(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Is this port a member of a mesh group, or blocked? Circuits in the same mesh group act as a virtual multiaccess network. LSPs seen on one circuit in a mesh group will not be flooded to another circuit in the same mesh group." REFERENCE "{}" DEFVAL { inactive } ::=3D { isisCircEntry 24 } isisCircMeshGroup OBJECT-TYPE SYNTAX Integer32 (1..2000000000) MAX-ACCESS read-create STATUS current DESCRIPTION "Circuits in the same mesh group act as a virtual multiaccess network. LSPs seen on one circuit in a mesh group will not be flooded to another circuit in the same mesh group. If isisCircMeshGroupEnabled is inactive, this value is ignored." REFERENCE "{}" DEFVAL { 1 } ::=3D { isisCircEntry 25 } 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 } ::=3D { isisCircEntry 26 } isisCircIPEncaps OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Should we encapsulate IS-IS in IP packets?" DEFVAL { false } ::=3D { isisCircEntry 27 } isisCircUpTime OBJECT-TYPE SYNTAX UpTime MAX-ACCESS read-only STATUS current DESCRIPTION "If the circuit is up, the amount of time in seconds since this circuit entered state 'up'. If the circuit is not up, the number of seconds since the circuit was up, or since the system started, if the circuit has never been up. Note: This can be implemented as start time less the current time." ::=3D { isisCircEntry 28 } -- The Circuit Level Table -- This table captures level-specific information about a circuit isisCircLevelTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisCircLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Level specific information about circuits used by IS-IS" ::=3D { isisCircLevelValues 1 } isisCircLevelEntry OBJECT-TYPE SYNTAX IsisCircLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An isisCircLevelEntry exists for each level on each circuit used by Integrated IS-IS on this system." INDEX { isisSysInstance, isisCircIndex, isisCircLevelIndex } ::=3D { isisCircLevelTable 1 } IsisCircLevelEntry ::=3D SEQUENCE { isisSysInstance, Integer32, isisCircIndex Integer32, isisCircLevelIndex=20 Integer32, isisCircLevelDefaultMetric DefaultMetric, isisCircLevelISPriority ISPriority, isisCircLevelCircID CircuitID, isisCircLevelDesIS SystemID, isisCircLevelLANDesISChanges=20 Counter32, isisCircLevelHelloMultiplier Integer32, isisCircLevelHelloTimer Integer32, isisCircLevelDRHelloTimer Integer32, isisCircLevelLSPThrottle Integer32, isisCircLevelMinBroadLSPTransInt Integer32, isisCircLevelMinLSPTransInt Integer32, isisCircLevelCSNPInterval Integer32, isisCircLevelPartSNPInterval Integer32 } isisCircLevelIndex OBJECT-TYPE SYNTAX INTEGER { level1IS (1), level2IS (2), } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level that this entry describes." ::=3D { IsisCircLevelEntry 1 } DefaultMetric OBJECT-TYPE SYNTAX DefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The default metric value of this circuit for this level." REFERENCE "{ISIS.aoi l1DefaultMetric (35)}" DEFVAL { 10 } ::=3D { IsisCircLevelEntry 2 } isisCircLevelISPriority OBJECT-TYPE SYNTAX ISPriority MAX-ACCESS read-create STATUS current DESCRIPTION "The priority for becoming LAN Designated Intermediate System at this level." REFERENCE "{ISIS.aoi l2IntermediateSystemPriority (73)}" DEFVAL { 64 } ::=3D { IsisCircLevelEntry 3 } =20 isisCircLevelCircID OBJECT-TYPE SYNTAX CircuitID MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the circuit allocated during initialization. If no value has been negotiated (either because the adjacency is to an End System, or because initialization has not yet successfully completed), this object has the value which would be proposed for this circuit (i.e. the concatenation of the local system ID and the one octet local Circuit ID for this circuit." REFERENCE "{ISIS.aoi ptPtCircuitID (51)}" ::=3D { IsisCircLevelEntry 4 } =20 isisCircLevelDesIS OBJECT-TYPE SYNTAX SystemID 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,=20 this system is not partaking in the relevant=20 Designated Intermediate System election process,=20 then the value returned is the zero length OCTET STRING." REFERENCE "{ISIS.aoi l2DesignatedIntermediateSystem (75)}" ::=3D { IsisCircLevelEntry 5 } isisCircLevelLANDesISChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the LAN Designated Intermediate System has changed at this level." REFERENCE "{ISIS.aoi lanL2DesignatedIntermediateSystemChanges (76)}" ::=3D { IsisCircLevelEntry 6 } 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 } ::=3D { IsisCircLevelEntry 7 } isisCircLevelHelloTimer OBJECT-TYPE SYNTAX Integer32 (10..600000) MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum period, in milliseconds, between IIH PDUs=20 on multiaccess networks at this level for LANs. =20 The value at level 1 is used as the period between=20 Hellos on point to point circuits. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" DEFVAL { 3000 } ::=3D { IsisCircLevelEntry 8 } isisCircLevelDRHelloTimer OBJECT-TYPE SYNTAX Integer32 (10..120000) MAX-ACCESS read-create STATUS current DESCRIPTION "Period, in milliseconds, between Hello PDUs on multiaccess networks when this IS is the Designated Intermediate System. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" DEFVAL { 1000 } ::=3D { IsisCircLevelEntry 9 } isisCircLevelLSPThrottle OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimal interval of time, in milliseconds, between transmissions of LSPs on a point to point interface at this level." REFERENCE "{}" DEFVAL { 10 } ::=3D { IsisCircLevelEntry 10 } isisCircLevelMinBroadLSPTransInt OBJECT-TYPE SYNTAX Integer32 (1..1000) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval, in milliseconds, between transmission of LSPs on a broadcast circuit. This object follows the resettingTimer behaviour. This timer shall be capable of a resolution not coarser than 10 milliseconds." REFERENCE "{ISIS.aoi minimumBroadcastLSPTransmissionInterval = (7)}" DEFVAL { 33 } ::=3D { IsisCircLevelEntry 11 } isisCircLevelMinLSPTransInt OBJECT-TYPE SYNTAX Integer32 (1..300) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval, in seconds, between re-transmission of an LSP at this level. This object follows the = resettingTimer behaviour. Note that isisCircLevelMinBroadLSPTransInt controls how fast we send back to back LSPs. This variable controls how fast we re-send the same LSP." REFERENCE "{ISIS.aoi minimumLSPTransmissionInterval (5)}" DEFVAL { 5 } ::=3D { IsisCircLevelEntry 12 } isisCircLevelCSNPInterval OBJECT-TYPE SYNTAX Integer32 (1..600) MAX-ACCESS read-create STATUS current DESCRIPTION "Interval of time, in seconds, between transmission of CSNPs on multiaccess networks if this router is=20 the designated router at this level." REFERENCE "{}" DEFVAL { 10 } ::=3D { IsisCircLevelEntry 13 } isisCircLevelPartSNPInterval SYNTAX Integer32 (1..120) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval between sending Partial Sequence Number=20 PDUs at this level. This object follows the = resettingTimer=20 behaviour." REFERENCE "{ISIS.aoi partialSNPInterval (14)}" DEFVAL { 2 } ::=3D { IsisCircLevelEntry 14 } -- isisPacketCountTable keeps track of the number of IS-IS -- control packets sent and received at each level isisPacketCountTable OBJECT-TYPE SYNTAX SEQUENCE OF isisPacketCountEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about IS-IS packets sent and received" ::=3D { isisCircPDUCounters 1 } isisPacketCountEntry OBJECT-TYPE SYNTAX isisPacketCountEntry=20 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about IS-IS protocol traffic at one level=20 on one circuit in one direction" INDEX { isisSysInstance, isisCircIndex, isisPacketCountLevel, isisPacketCountDirection } ::=3D { isisPacketCountTable 1 } isisPacketCountEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisPacketCountLevel INTEGER, isisPacketCountDirection=20 INTEGER, isisPacketCountHello Counter32, isisPacketCountLSP Counter32, isisPacketCountCSNP Counter32, isisPacketCountPSNP Counter32 } isisPacketCountLevel OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), } MAX-ACCESS read-create STATUS current DESCRIPTION "The level at which these PDU counts have been collected." ::=3D { isisPacketCountEntry 1 } isisPacketCountDirection OBJECT-TYPE SYNTAX INTEGER { sending(1), receiving(2), } MAX-ACCESS read-create STATUS current DESCRIPTION "Were we sending or receiving these PDUs?" ::=3D { isisPacketCountEntry 2 } isisPacketCountHello OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS Hello PDUs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisPacketCountEntry 3 } isisPacketCountLSP OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS LSPs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisPacketCountEntry 4 } isisPacketCountCSNP OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS CSNPs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisPacketCountEntry 5 } isisPacketCountPSNP OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS PSNPs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisPacketCountEntry 6 } -- The Circuit IS Group -- -- The Circuit IS Group is present if the system supports the -- IS functions of the ISO 9542 protocol. -- The Circuit IS Table -- -- This table is not implemented - jdp -- The IS Adjacency Group -- -- The IS Adjacency Group is current and contains information -- about adjacencies to routers maintained by the Integrated -- IS-IS protocol -- -- The IS Adjacency Table -- -- Each adjacency to an IS corresponds to one entry in this -- table. isisISAdjTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of adjacencies to Intermediate Systems." ::=3D { isisISAdj 1 } isisISAdjEntry OBJECT-TYPE SYNTAX IsisISAdjEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to one adjacency to an Intermediate System on this system." INDEX { isisSysInstance, isisCircIndex, isisISAdjIndex } ::=3D { isisISAdjTable 1 } IsisISAdjEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisISAdjIndex Integer32, isisISAdjState INTEGER, isisISAdjNeighSNPAAddress SNPAAddress, isisISAdjNeighSysType INTEGER, isisISAdjNeighSysID OCTET STRING, isisISAdjUsage INTEGER, isisISAdjHoldTimer Integer32, isisISAdjNeighPriority ISPriority, isisISAdjUpTime UpTime } isisISAdjIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value identifying the IS adjacency from all other such adjacencies on this circuit. This value is assigned by the system when the adjacency is created automatically." ::=3D { isisISAdjEntry 1 } isisISAdjState OBJECT-TYPE SYNTAX INTEGER { initializing (1), up (2), failed (3), down (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the adjacency" REFERENCE "{ISIS.aoi adjacencyState (78)}" ::=3D { isisISAdjEntry 2 } isisISAdjNeighSNPAAddress OBJECT-TYPE SYNTAX SNPAAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The SNPA address of the neighboring system." REFERENCE "{ISIS.aoi neighbourSNPAAddress (79)}" ::=3D { isisISAdjEntry 3 } isisISAdjNeighSysType OBJECT-TYPE SYNTAX INTEGER { l1IntermediateSystem(1), l2IntermediateSystem(2), l1l2IntermediateSystem(3), unknown(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the neighboring system." REFERENCE "{ISIS.aoi neighbourSystemType (80)}" ::=3D { isisISAdjEntry 4 } isisISAdjNeighSysID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..12)) MAX-ACCESS read-only STATUS current DESCRIPTION "The system ID and 4 byte circuit ID of the=20 neighboring Intermediate System set from=20 the source ID field of the Three-Way-Handshake information from the neighbor's IIH PDUs." REFERENCE "{ISIS.aoi neighbourSystemIds (83)}" ::=3D { isisISAdjEntry 5 } isisISAdjUsage OBJECT-TYPE SYNTAX INTEGER { undefined(1), level1(2), level2(3), level1and2(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "An adjacency of type level1 is used for level 1 traffic only. An adjacency of type level2 is used for level 2 traffic only. An adjacency of type level1and2 is used for both level 1 and level 2 traffic. There may be two adjacencies (of types level1 and level2) between the same pair of Intermediate Systems." REFERENCE "{ISIS.aoi adjacencyUsage (82)}" ::=3D { isisISAdjEntry 6 } isisISAdjHoldTimer OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The holding time for this adjacency updated from received IIH PDUs." REFERENCE "{ISIS.aoi holdingTimer (85)}" ::=3D { isisISAdjEntry 7 } isisISAdjNeighPriority OBJECT-TYPE SYNTAX ISPriority MAX-ACCESS read-only STATUS current DESCRIPTION "Priority of the neighboring Intermediate System for becoming the LAN Level 1 Designated Intermediate System if the value of isisISAdjNeighSysType is L1IntermediateSystem or LAN Level 2 Designated Intermediate System if the value of isisISAdjNeighSysType is L2IntermediateSystem." REFERENCE "{ISIS.aoi lANPriority (86)}" ::=3D { isisISAdjEntry 8 } isisISAdjUpTime OBJECT-TYPE SYNTAX UpTime MAX-ACCESS read-only STATUS current DESCRIPTION "If the adjacency is up, the amount of time in seconds since this adjacency entered state 'up'. If the adjacency is not up, the number of seconds since the adjacency was up, or since the system started, if the adjacency has never been up. Note: This can be implemented as start time less the current time." ::=3D { isisISAdjEntry 9 } -- The IS Adjacency Area Address Table -- The IS Adjacency Area Address Table contains the set of -- Area Addresses of neighboring -- Intermediate Systems as reported in IIH PDUs. isisISAdjAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of Area Addresses of neighboring Intermediate Systems as reported in received IIH PDUs." REFERENCE "{ISIS.aoi areaAddressesOfNeighbour (84)}" ::=3D { isisISAdj 2 } isisISAdjAreaAddrEntry OBJECT-TYPE SYNTAX IsisISAdjAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one Area Address reported by a neighboring Intermediate System in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjAreaAddrAdjIndex, isisISAdjAreaAddress } ::=3D { isisISAdjAreaAddrTable 1 } IsisISAdjAreaAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisISAdjAreaAddrAdjIndex Integer32, isisISAdjAreaAddress OSINSAddress } isisISAdjAreaAddrAdjIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of the IS adjacency to which this entry belongs." ::=3D { isisISAdjAreaAddrEntry 1 } isisISAdjAreaAddress OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "One Area Address as reported in IIH PDUs received from the neighbor." ::=3D { isisISAdjAreaAddrEntry 2 } -- The IS Adjacency IP Group -- The IS Adjacency IP Group is present if the system supports -- IP Integrated IS-IS -- The IS Adjacency IP Address Table -- The IS Adjacency IP Address Table contains the -- set of IP Addresses of neighboring Intermediate Systems -- as reported in received IIH PDUs. 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." ::=3D { 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, isisISAdjIPAddrAdjIndex } ::=3D { isisISAdjIPAddrTable 1 } IsisISAdjIPAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisISAdjIPAddrAdjIndex Integer32, isisISAdjIPAddress IpAddress } isisISAdjIPAddrAdjIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of the IS adjacency to which this entry belongs." ::=3D { isisISAdjIPAddrEntry 1 } isisISAdjIPAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "One IP Address as reported in IIH PDUs received from the neighbor." ::=3D { isisISAdjIPAddrEntry 2 } -- The IS Adjacency Integrated Group -- -- The IS Adjacency Integrated Group is present if the system -- supports Integrated ISIS. -- -- -- The IS Adjacency Protocol Supported Table -- -- The IS Adjacency Protocol Supported Table contains the set of -- protocols supported by neighboring -- Intermediate Systems as reported in received IIH PDUs. -- isisISAdjProtSuppTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of protocols supported by neighboring Intermediate Systems as reported in received IIH PDUs." ::=3D { isisISAdj 4 } isisISAdjProtSuppEntry OBJECT-TYPE SYNTAX IsisISAdjProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one protocol supported by a neighboring Intermediate System as reported in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjProtSuppAdjIndex, isisISAdjProtSuppProtocol } ::=3D { isisISAdjProtSuppTable 1 } IsisISAdjProtSuppEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisISAdjProtSuppAdjIndex Integer32, isisISAdjProtSuppProtocol SupportedProtocol } isisISAdjProtSuppAdjIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier the IS adjacency to which this entry corresponds." ::=3D { isisISAdjProtSuppEntry 1 } isisISAdjProtSuppProtocol OBJECT-TYPE SYNTAX SupportedProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "One supported protocol as reported in IIH PDUs received from the neighbor." ::=3D { isisISAdjProtSuppEntry 2 } -- -- -- The ES Adjacency Group -- -- The ES Adjacency Group is present if the system supports -- reception of ES Hellos -- The ES Adjacency Table -- -- Not supported - jdp -- -- -- The Reachable Address Group -- -- The Reachable Address Group is optional. -- The Reachable Address Table -- Each entry records information about a reachable address -- (NSAP or address prefix) manually configured on the system -- or learned through another protocol. isisRATable OBJECT-TYPE SYNTAX SEQUENCE OF IsisRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of Reachable Addresses to NSAPs or Address Prefixes." ::=3D { isisReachAddr 1 } isisRAEntry OBJECT-TYPE SYNTAX IsisRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines a Reachable Address to a NSAP or Address Prefix." INDEX { isisSysInstance, isisCircIndex, isisRAIndex } ::=3D { isisRATable 1 } IsisRAEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisRAIndex Integer32, isisRAExistState RowStatus, isisRAAdminState AdminState, isisRAAddrPrefix NSAPPrefix, isisRAMapType INTEGER, isisRADefMetric DefaultMetric, isisRADefMetricType MetricType, isisRASNPAAddress SNPAAddress, isisRASNPAMask SNPAPrefix, isisRASNPAPrefix SNPAPrefix, isisRAType INTEGER } isisRAIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier for this isisRAEntry. This value must be unique amongst all Reachable Addresses on the same parent Circuit. This object follows the index and manualOrAutomatic behaviours." ::=3D { isisRAEntry 1 } isisRAExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this Reachable Address. This object follows the Row Status behaviours." DEFVAL { active } ::=3D { isisRAEntry 2 } isisRAAdminState OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the Reachable Address. This object follows the AdminState and manualOrAutomatic behaviours." DEFVAL { off } ::=3D { isisRAEntry 3 } isisRAAddrPrefix OBJECT-TYPE SYNTAX NSAPPrefix MAX-ACCESS read-create STATUS current DESCRIPTION "The destination of this Reachable Address. This is an Address Prefix. This object follows the replaceOnlyWhileDisabled and manualOrAutomatic behaviours." REFERENCE "{ISIS.aoi addressPrefix (98)}" ::=3D { isisRAEntry 4 } isisRAMapType OBJECT-TYPE SYNTAX INTEGER { none (1), explicit (2), extractIDI (3), extractDSP (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of mapping to be employed to ascertain the SNPA Address which should be used in forwarding PDUs for this Reachable Address prefix. This object follows the manualOrAutomatic behaviour. The following values of mapping type are defined: none: The mapping is null because the neighbor SNPA is implicit by nature of the subnetwork (e.g. a point-to-point linkage). explicit: The subnetwork addresses in the object isisRASNPAAddress is to be used. extractIDI: The SNPA is embedded in the IDI of the destination NSAP Address. The mapping algorithm extracts the SNPA to be used according to the format and encoding rules of ISO8473/Add2. This SNPA extraction algorithm can be used in conjunction with Reachable Address prefixes from the X.121, F.69, E.163 and E.164 addressing subdomains. extractDSP: All, or a suffix, of the SNPA is embedded in the DSP of the destination address. This SNPA extraction algorithm extracts the embedded subnetwork addressing information by performing a logical AND of the isisRASNPAMask object value with the destination address. The part of the SNPA extracted from the destination NSAP is appended to the isisRASNPAPrefix object value to form the next hop subnetwork addressing information." REFERENCE "{ISO10589-ISIS.aoi mappingType (107)}" ::=3D { isisRAEntry 5 } isisRADefMetric OBJECT-TYPE SYNTAX DefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The default metric value for reaching the specified prefix over this circuit. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi defaultMetric (99)}" DEFVAL { 20 } ::=3D { isisRAEntry 6 } isisRADefMetricType OBJECT-TYPE SYNTAX MetricType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the default metric is internal or external. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi defaultMetricType (103)}" DEFVAL { internal } ::=3D { isisRAEntry 7 } isisRASNPAAddress OBJECT-TYPE SYNTAX SNPAAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The SNPA Address to which a PDU may be forwarded in order to reach a destination which matches the address prefix of the Reachable Address. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi sNPAAddresses (109)}" -- note only one address may be specified per Reachable Address -- in the MIB DEFVAL { ''H } ::=3D { isisRAEntry 8 } isisRASNPAMask OBJECT-TYPE SYNTAX SNPAPrefix MAX-ACCESS read-create STATUS current DESCRIPTION "A bit mask with 1 bits indicating the positions in the effective destination address from which embedded SNPA information is to be extracted. For the extraction the first octet of the isisRASNPAMask object value is aligned with the first octet (AFI) of the NSAP Address. If the isisRASNPAMask object value and NSAP Address are of different lengths, the shorter of the two is logically padded with zeros before performing the extraction. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi sNPAMask (122)}" DEFVAL { '00'H } ::=3D { isisRAEntry 9 } isisRASNPAPrefix OBJECT-TYPE SYNTAX SNPAPrefix MAX-ACCESS read-create STATUS current DESCRIPTION "A fixed SNPA prefix for use when the isisRAMapType is extractDSP. The SNPA Address to use is formed by concatenating the fixed SNPA prefix with a variable SNPA part that is extracted from the effective destination address. For Reachable Address prefixes in which the entire SNPA is embedded in the DSP the SNPA Prefix shall be null. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi sNPAPrefix (123)}" DEFVAL { '00'H } ::=3D { isisRAEntry 10 } isisRAType OBJECT-TYPE SYNTAX INTEGER { manual (1), automatic (2) } MAX-ACCESS read-create STATUS current DESCRIPTION " The type of Reachable address. Those of type manual are created by the network manager. Those of type automatic are created through propogation of routing information from another routing protocol (eg. IDRP). " DEFVAL {manual} ::=3D {isisRAEntry 11 } -- The IP Reachable Address Group -- The IP Reachable Address Group is optional. -- The IP Reachable Address Table -- Each entry records information about one IP reachable -- address manually configured on this system or learned from -- another protocol. isisIPRATable OBJECT-TYPE SYNTAX SEQUENCE OF IsisIPRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of IP Reachable Addresses to networks, subnetworks or hosts either manually configured or learned from another protocol." ::=3D { isisIPReachAddr 1 } isisIPRAEntry OBJECT-TYPE SYNTAX IsisIPRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines an IP Reachable Address to a network, subnetwork or host." INDEX { isisSysInstance, isisCircIndex, isisIPRAType, isisIPRAIndex } ::=3D { isisIPRATable 1 } IsisIPRAEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisIPRAIndex Integer32, isisIPRAType INTEGER, isisIPRADest IpAddress, isisIPRAMask IpAddress, isisIPRAExistState RowStatus, isisIPRAAdminState AdminState, isisIPRADefMetric DefaultMetric, isisIPRADefMetricType MetricType, isisIPRASNPAAddress SNPAAddress } isisIPRAIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier for this isisIPRAEntry. This value must be unique amongst all IP Reachable Addresses on the same parent Circuit. This object follows the index and manualOrAutomatic behaviours." ::=3D { isisIPRAEntry 1 } isisIPRAType OBJECT-TYPE SYNTAX INTEGER { manual (1), automatic (2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of this IP Reachable Address. Those of type manual are created by the network manager. Those of type automatic are created through propagation of routing information from another routing protocol." ::=3D { isisIPRAEntry 2 } isisIPRADest OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The destination of this IP Reachable Address. This is either a network address, subnetwork address or host address. This object follows the manualOrAutomatic behaviour." ::=3D { isisIPRAEntry 3 } isisIPRAMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The network mask for the IP Address in the isisIPRADest object. This object follows the manualOrAutomatic behaviour." ::=3D { isisIPRAEntry 4 } isisIPRAExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of this IP Reachable Address. This object follows the ExistenceState and manualOrAutomatic behaviours." DEFVAL { active } ::=3D { isisIPRAEntry 5 } isisIPRAAdminState OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the IP Reachable Address. = This object follows the AdminState and manualOrAutomatic behaviours." DEFVAL { off } ::=3D { isisIPRAEntry 6 } isisIPRADefMetric OBJECT-TYPE SYNTAX DefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The default metric value for reaching the specified destination over this circuit. This object follows the manualOrAutomatic behaviour." DEFVAL { 20 } ::=3D { isisIPRAEntry 7 } isisIPRADefMetricType OBJECT-TYPE SYNTAX MetricType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the default metric is internal or external. This object follows the manualOrAutomatic behaviour." DEFVAL { internal } ::=3D { isisIPRAEntry 8 } isisIPRASNPAAddress OBJECT-TYPE SYNTAX SNPAAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The SNPA Address to which a PDU may be forwarded in order to reach a destination which matches this IP Reachable Address. This object follows the manualOrAutomatic behaviour." DEFVAL { ''H } ::=3D { isisIPRAEntry 9 } -- The Circuit CLNS Group -- -- The Circuit CLNS Table contains objects controlling the -- operation of the IS functions of the CLNS protocol -- -- Removed - jdp -- -- The IP Destination Group -- The IP Destination Group is present if the system forwards -- IP packets. -- The IP Destination Table -- The IP Destination Table records information about each -- destination known to the Intermediate System -- Removed: overlaps RFC 2096 END -- End of Object Definitions ------_=_NextPart_000_01C0BEA5.F7EB2D00-- From abirjandi@yahoo.com Thu Apr 19 17:39:59 2001 From: abirjandi@yahoo.com (Amir Birjandi) Date: Thu, 19 Apr 2001 09:39:59 -0700 (PDT) Subject: [Isis-wg] Multilevel verses multi instance Message-ID: <20010419163959.74749.qmail@web14104.mail.yahoo.com> Hi, I have a basic question. What are the pros and cons of Multi instance verses Multi level ISIS? I apologize if this has already been addressed. I tried the mailing list up to mid 2000, but i couldn't find anything. Regards A. __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From vamsik@future.futsoft.com Tue Apr 24 10:57:10 2001 From: vamsik@future.futsoft.com (Vamsi K) Date: Tue, 24 Apr 2001 15:27:10 +0530 Subject: [Isis-wg] help needed Message-ID: <000501c0cca4$eeb33a40$1c06140a@future.futsoft.com> Hi , I need small clarification regarding the IS-IS routing protocol functinalities. Here i have small set up | L2 IS(A)|<-------------------->|L1IS(B)|<-------------------------->|L2IS(C)| In the above configuration whether the L2IS A exchanges the L2 link state PDUs with L2IS at C. Assumption there is no direct link between these two. The Intermediate Systems both A and C act as L1 and as well as L2. Here my doubt is whether L2 PDUS can be traversed through L1IS B to reach the L2IS C. Could anybody can help me in this regard. Thanks & Regards vamsi.P From jparker@axiowave.com Tue Apr 24 21:42:36 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 24 Apr 2001 16:42:36 -0400 Subject: [Isis-wg] help needed 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_01C0CCFF.185081F0 Content-Type: text/plain; charset="iso-8859-1" > Here i have small set up > > L1L2 IS(A)<-------->L1 IS(B)<------->L1L2 IS(C) > > Assumption there is no direct link between (A and C) > > The Intermediate Systems both A and C act as L1 and as well as L2. > > Here my doubt is whether L2 PDUS can be traversed through > L1IS B to reach the L2IS C. > > vamsi.P You are right to have doubts. The L2 domain is split. There are provisions in the spec to replair broken L1 areas, but not to patch split L2. - jeff parker - axiowave networks - I think, therefore I am. I think. ------_=_NextPart_001_01C0CCFF.185081F0 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] help needed

> Here i have small set up
>   
> L1L2 IS(A)<-------->L1 IS(B)<------->L1L2 IS(C)
>
> Assumption there is no direct link between (A and C)
>
> The Intermediate Systems both  A and C act as L1 and as well as L2.
>
> Here my doubt is whether L2 PDUS can be traversed through
> L1IS B to reach the L2IS C.
>
> vamsi.P

You are right to have doubts.  The L2 domain is split. 
There are provisions in the spec to replair broken L1
areas, but not to patch split L2. 

- jeff parker
- axiowave networks
- I think, therefore I am. I think.

------_=_NextPart_001_01C0CCFF.185081F0-- From mbartell@cisco.com Tue Apr 24 21:47:16 2001 From: mbartell@cisco.com (Micah Bartell) Date: Tue, 24 Apr 2001 15:47:16 -0500 Subject: [Isis-wg] help needed In-Reply-To: <000501c0cca4$eeb33a40$1c06140a@future.futsoft.com> Message-ID: <4.3.2.7.2.20010424154356.01c42ee8@ce-nfs-1.cisco.com> Assuming that RTRB is an L1 Only IS, no, it will not act as a transit for L2 LSPs. L2 IS's must be contiguous. This is because the ADJ between RTRA and RTRB would be L1 only, and so RTRA would not flood an L2 LSP over and L1 Only ADJ. Same goes for the RTRB and RTRC ADJ. /mpb At 15:27 04/24/2001 +0530, Vamsi K wrote: > Hi , > I need small clarification regarding the IS-IS routing protocol >functinalities. > > >Here i have small set up > > > > | L2 >IS(A)|<-------------------->|L1IS(B)|<-------------------------->|L2IS(C)| > > > >In the above configuration whether the L2IS A exchanges the L2 link state >PDUs with L2IS at C. >Assumption there is no direct link between these two. > >The Intermediate Systems both A and C act as L1 and as well as L2. > >Here my doubt is whether L2 PDUS can be traversed through L1IS B to reach >the L2IS C. > > >Could anybody can help me in this regard. > > >Thanks & Regards >vamsi.P > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From ben.abarbanel@ipoptical.com Tue Apr 24 22:13:07 2001 From: ben.abarbanel@ipoptical.com (Ben Abarbanel) Date: Tue, 24 Apr 2001 17:13:07 -0400 Subject: [Isis-wg] help needed Message-ID: Vamsi: A level 1 router will flood to all its neighbors except the originating Level 1 router its L1 LSP. A Level 2 router will do the same. Thus B must speak both Level 1 and Level 2 to flood IS(A) LSP-Level-1 to IS(C) and vice versa. You should assume,that Level 1 routers will reach all Level 1 routers in the cloud if there is Level 1 reachability. Same goes with Level 2. The other way to get Level-1 routes to Level-2 routers is to Leak the routes inside the LSP to the other Level and hence flood them inside the other Level-n LSP. I hope this helped more than confused you. Regards, Ben -----Original Message----- From: Vamsi K [mailto:vamsik@future.futsoft.com] Sent: Tuesday, April 24, 2001 5:57 AM To: isis-wg@juniper.net Subject: [Isis-wg] help needed Hi , I need small clarification regarding the IS-IS routing protocol functinalities. Here i have small set up | L2 IS(A)|<-------------------->|L1IS(B)|<-------------------------->|L2IS(C)| In the above configuration whether the L2IS A exchanges the L2 link state PDUs with L2IS at C. Assumption there is no direct link between these two. The Intermediate Systems both A and C act as L1 and as well as L2. Here my doubt is whether L2 PDUS can be traversed through L1IS B to reach the L2IS C. Could anybody can help me in this regard. Thanks & Regards vamsi.P _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From navaneeth@www.com Wed Apr 25 06:41:44 2001 From: navaneeth@www.com (Navaneeth Krishnan) Date: Tue, 24 Apr 2001 22:41:44 -0700 Subject: [Isis-wg] ISIS References.. Message-ID: <200104250541.WAA23767@mail16.bigmailbox.com> Hi, Can anybody suggest some good references/drafts/links for implementing ISIS over IP Unnumbered interfaces, ISIS Multiple Instance support and redistirbution of routes into ISIS? This will be greatly helpful. Regards Navaneeth. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From mongazon@ms.alcatel.fr Wed Apr 25 10:21:22 2001 From: mongazon@ms.alcatel.fr (Bruno Mongazon) Date: Wed, 25 Apr 2001 11:21:22 +0200 Subject: [Isis-wg] IS-IS restart (more comments) Message-ID: <3AE69712.A97FBC7D@ms.alcatel.fr> Hi Mike, Here are some more comments about your IS-IS restart draft. 1. Simultaneous restart of peers The draft does not explicitely indicate if simultaneous restart of peers is possible/supported. My current understanding is that it is not possible for peers to restart simultaneously mainly because the restart mechanism implies a peer to help the restarting router. If my understanding is correct, it could be fine to indicate explicitely in the draft that simultaneous restart is not possible. If my understanding is not correct, can you give a few explanation of what happens in the case of simultaneous restart of peers. 2. State table Could be fine to split the state table in two state tables: -state table of the restarting IS-IS -state table of a peer IS-IS which helps a peer to restart My motivations are the followings: -make the state table more readable and understandable as it is currently -distinguish two behaviors: engine restart and engine restart assistance 3. Forwarding activity during restart I understand the draft as useful _only_ if the forwarding activity is not discontinued when ISIS is restarting. This might be stated explicitely in the draft because it implies a control/forwarding separation in the router. If forwarding is not discontinued during restart, it might however be temporarily out-of-date until restart completes (engine is back to Running state) if routing has changed in the meantime. Since being out-of-date during restart might have impacts on network users, i guess this should be stated explicitely in the draft. In particular excessive restart times definitely have impacts on routing. 4. Typo's Page 8: <= ...(which is has generated, but not yet transmitted)... => ...(which it has generated, but not yet transmitted)... Thanks in advance for your reply. Bruno. From mshand@cisco.com Wed Apr 25 11:15:34 2001 From: mshand@cisco.com (mike shand) Date: Wed, 25 Apr 2001 11:15:34 +0100 Subject: [Isis-wg] IS-IS restart (more comments) In-Reply-To: <3AE69712.A97FBC7D@ms.alcatel.fr> Message-ID: <4.3.2.7.2.20010425103727.00b92f30@jaws.cisco.com> At 11:21 25/04/2001 +0200, Bruno Mongazon wrote: >Hi Mike, > >Here are some more comments about your IS-IS restart draft. > >1. Simultaneous restart of peers > >The draft does not explicitely indicate if simultaneous restart of peers >is possible/supported. My current understanding is that it is not >possible for peers to restart simultaneously mainly because the restart >mechanism implies a peer to help the restarting router. > >If my understanding is correct, it could be fine to indicate explicitely >in the draft that simultaneous restart is not possible. If my >understanding is not correct, can you give a few explanation of what >happens in the case of simultaneous restart of peers. It depends what you mean by supported. I think it has to be supported in the sense that if neighbors do restart simultaneously nothing bad happens. Although the draft doesn't state this explicitly, both neighbors can operate the restart algorithms with each other (as well as their non-restarted neighbors). So both would set RR and both would expect RA and note the LSP IDs from the received CSNPs. In the case where both neighbors were restarting the initial CSNPs over those interfaces would not reference very much and so those two neighbors would not add very much to the set of LSPs which must be acquired before synchronization is declared complete. But presumably other interfaces would contribute the full set of LSP IDs so the synchronization would not terminate prematurely. Obviously if one of the routers in question were ONLY connected to the other restarting router, then it may be fooled into thinking that it was synchronized prematurely. This would negate the "restart" capability but would be equivalent to what would have happened with a standard implementation. So nothing "bad" happens. >2. State table > >Could be fine to split the state table in two state tables: > >-state table of the restarting IS-IS >-state table of a peer IS-IS which helps a peer to restart > >My motivations are the followings: > >-make the state table more readable and understandable as it is >currently >-distinguish two behaviors: engine restart and engine restart assistance I'll look into that. >3. Forwarding activity during restart > >I understand the draft as useful _only_ if the forwarding activity is >not discontinued when ISIS is restarting. This might be stated >explicitely in the draft because it implies a control/forwarding >separation in the router. OK >If forwarding is not discontinued during restart, it might however be >temporarily out-of-date until restart completes (engine is back to >Running state) if routing has changed in the meantime. Since being >out-of-date during restart might have impacts on network users, i guess >this should be stated explicitely in the draft. In particular excessive >restart times definitely have impacts on routing. Sure. I would only expect it to be used where restart times were of the order of a few seconds. One possibility is to abort the restart when the neighbor detects a topology change. Ideally this would only be a topology change which affects routes passing through the restarting router. i.e. if the neighbor thinks that the restarting router's forwarding table may be wrong, it treats the adjacency as down and routes around it (if possible). But if we wanted to do that we would need an indication from the neighbor that it had now re-run its SPF, and hence the adjacency is trustworthy. This could either be explicitly signalled by another bit in the hello restart TLV, or perhaps we could notice that the neighbor had re-issued its own LSP. >4. Typo's > >Page 8: ><= ...(which is has generated, but not yet transmitted)... >=> ...(which it has generated, but not yet transmitted)... Noted. >Thanks in advance for your reply. >Bruno. Thanks for your comments. BTW, in case people hadn't noticed, the draft is now available from the usual places e.g. ftp://ftp.ietf.org/internet-drafts/draft-shand-isis-restart-00.txt Mike >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mongazon@ms.alcatel.fr Wed Apr 25 14:15:21 2001 From: mongazon@ms.alcatel.fr (Bruno Mongazon) Date: Wed, 25 Apr 2001 15:15:21 +0200 Subject: [Isis-wg] IS-IS restart (more comments) References: <4.3.2.7.2.20010425103727.00b92f30@jaws.cisco.com> Message-ID: <3AE6CDE9.34829CA1@ms.alcatel.fr> mike shand wrote: > > At 11:21 25/04/2001 +0200, Bruno Mongazon wrote: > >Hi Mike, > > > >Here are some more comments about your IS-IS restart draft. > > > >1. Simultaneous restart of peers > > > >The draft does not explicitely indicate if simultaneous restart of peers > >is possible/supported. My current understanding is that it is not > >possible for peers to restart simultaneously mainly because the restart > >mechanism implies a peer to help the restarting router. > > > >If my understanding is correct, it could be fine to indicate explicitely > >in the draft that simultaneous restart is not possible. If my > >understanding is not correct, can you give a few explanation of what > >happens in the case of simultaneous restart of peers. > > It depends what you mean by supported. I think it has to be supported in > the sense that if neighbors do restart simultaneously nothing bad happens. > Although the draft doesn't state this explicitly, both neighbors can > operate the restart algorithms with each other (as well as their > non-restarted neighbors). So both would set RR and both would expect RA and > note the LSP IDs from the received CSNPs. In the case where both neighbors > were restarting the initial CSNPs over those interfaces would not reference > very much and so those two neighbors would not add very much to the set of > LSPs which must be acquired before synchronization is declared complete. > But presumably other interfaces would contribute the full set of LSP IDs so > the synchronization would not terminate prematurely. > > Obviously if one of the routers in question were ONLY connected to the > other restarting router, then it may be fooled into thinking that it was > synchronized prematurely. This would negate the "restart" capability but > would be equivalent to what would have happened with a standard > implementation. So nothing "bad" happens. > Fine, you designed the mechanism in a way that nothing bad should happen in case of simultaneous restarts. Then you might or not state it explicitely in the draft. Note that this question came to my mind while checking the state table for such a case. In particular could you please clarify my following wonders: When the state table specifies an Action such as the one depicted hereafter, State: Running Event: Router Restarted Action: Set SRM Send RR Send CSNP Start T1 Next state: Restarting Do you assume that all PDUs transmission performed as part of an action are done before a PDU reception (more generally an event) can be handled by the state machine ? More clearly, given the previous action, do you assume it is not possible for a RA PDU to enter the state machine after RR has been sent and while CSNP is not yet sent ? > >2. State table > > > >Could be fine to split the state table in two state tables: > > > >-state table of the restarting IS-IS > >-state table of a peer IS-IS which helps a peer to restart > > > >My motivations are the followings: > > > >-make the state table more readable and understandable as it is > >currently > >-distinguish two behaviors: engine restart and engine restart assistance > > I'll look into that. > > >3. Forwarding activity during restart > > > >I understand the draft as useful _only_ if the forwarding activity is > >not discontinued when ISIS is restarting. This might be stated > >explicitely in the draft because it implies a control/forwarding > >separation in the router. > > OK > > >If forwarding is not discontinued during restart, it might however be > >temporarily out-of-date until restart completes (engine is back to > >Running state) if routing has changed in the meantime. Since being > >out-of-date during restart might have impacts on network users, i guess > >this should be stated explicitely in the draft. In particular excessive > >restart times definitely have impacts on routing. > > Sure. I would only expect it to be used where restart times were of the > order of a few seconds. One possibility is to abort the restart when the > neighbor detects a topology change. Ideally this would only be a topology > change which affects routes passing through the restarting router. i.e. if > the neighbor thinks that the restarting router's forwarding table may be > wrong, it treats the adjacency as down and routes around it (if possible). > But if we wanted to do that we would need an indication from the neighbor > that it had now re-run its SPF, and hence the adjacency is trustworthy. > This could either be explicitly signalled by another bit in the hello > restart TLV, or perhaps we could notice that the neighbor had re-issued its > own LSP. > Interesting proposal? If there is an additional bit in the restart TLV indicating that the neighbor has or not re-run its SPF, then the restarting router might use the bit to re-run or not its SPF. If there is no additional bit, i guess the restarting router will have to always re-run its SPF after restart. Is the additional bit interesting? Bruno. > >4. Typo's > > > >Page 8: > ><= ...(which is has generated, but not yet transmitted)... > >=> ...(which it has generated, but not yet transmitted)... > > Noted. > > >Thanks in advance for your reply. > >Bruno. > > Thanks for your comments. > > BTW, in case people hadn't noticed, the draft is now available from the > usual places > > e.g. ftp://ftp.ietf.org/internet-drafts/draft-shand-isis-restart-00.txt > > Mike > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_200142531637361717226057 Content-Type: text/plain; charset=us-ascii Hi all, With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned that Area Address option shall be present only in an LSP with LSP number zero. If there are more area addreeses than will fit in a single instance of the Area Addresses option field, then the IS shall place L2 area addresses in each instance of the field except the last. What is the L2 area address and how is it different from area address of a particular area. thanks and regards Sivakumar Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_200142531637361717226057 Content-Type: text/html; charset=us-ascii

Hi all,

With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned that Area Address option shall be present only in an LSP with LSP number zero. If there are more area addreeses than will fit in a single instance of the Area Addresses option field, then the IS shall place L2 area addresses in each instance of the field except the last.

What is the L2 area address and how is it different from area address of a particular area.

thanks and regards

Sivakumar

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_200142531637361717226057-- From vamsik@future.futsoft.com Wed Apr 25 12:10:58 2001 From: vamsik@future.futsoft.com (Vamsi K) Date: Wed, 25 Apr 2001 16:40:58 +0530 Subject: [Isis-wg] Help needed Message-ID: <000b01c0cd78$68545220$1c06140a@future.futsoft.com> Hi , In the ISO/IEC 10589: 1992(E) document, the section 7.3.4.4 is a bit confusing. Here i am quoting the exact words. Once a particular adjacency has been assigned to a particular LSP number, it is desirable that it not be moved to another LSP number. This is because moving an adjacency from one LSP to another can cause temporary loss of connectivity to that system. This can occur if the new version of the LSP which orginally contained information about the adjacency (which now doesnot contain information) is propagated before the new version of the other LSP ( which now contains the information about the adjacency). Here my doubt is what is the need for attaching the specific LSP number (not the sequence number) for a particular adjacency. The field "Intermediate system Neighbours" in the LSP PDU contains the neighbour id field which indicates the particular adjacency, the information is pertaining to. Can anybody clear my doubt regarding this. Thanks in advance vamsi.P From Ravindra.Sunkad@marconi.com Wed Apr 25 19:24:05 2001 From: Ravindra.Sunkad@marconi.com (Sunkad, Ravindra) Date: Wed, 25 Apr 2001 14:24:05 -0400 Subject: [Isis-wg] Is L1 and L2 address same in an area? Message-ID: <39469E08BD83D411A3D900204840EC5531DBF4@vie-msgusr-01.dc.fore.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_01C0CDB4.E8D58A90 Content-Type: text/plain; charset="iso-8859-1" Sivakumar, That is "twelve" not L2. Ravi -----Original Message----- From: Sivakumar A [mailto:sivaa@indiatimes.com] Sent: Wednesday, April 25, 2001 7:08 AM To: isis-wg@juniper.net Subject: [Isis-wg] Is L1 and L2 address same in an area? Hi all, With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned that Area Address option shall be present only in an LSP with LSP number zero. If there are more area addreeses than will fit in a single instance of the Area Addresses option field, then the IS shall place L2 area addresses in each instance of the field except the last. What is the L2 area address and how is it different from area address of a particular area. thanks and regards Sivakumar _____ Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com ------_=_NextPart_001_01C0CDB4.E8D58A90 Content-Type: text/html; charset="iso-8859-1"
Sivakumar,
 
That is "twelve" not L2.
 
Ravi
-----Original Message-----
From: Sivakumar A [mailto:sivaa@indiatimes.com]
Sent: Wednesday, April 25, 2001 7:08 AM
To: isis-wg@juniper.net
Subject: [Isis-wg] Is L1 and L2 address same in an area?

Hi all,

With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned that Area Address option shall be present only in an LSP with LSP number zero. If there are more area addreeses than will fit in a single instance of the Area Addresses option field, then the IS shall place L2 area addresses in each instance of the field except the last.

What is the L2 area address and how is it different from area address of a particular area.

thanks and regards

Sivakumar

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
------_=_NextPart_001_01C0CDB4.E8D58A90-- From truskows@cisco.com Wed Apr 25 19:30:38 2001 From: truskows@cisco.com (Mike Truskowski) Date: Wed, 25 Apr 2001 11:30:38 PDT Subject: [Isis-wg] Is L1 and L2 address same in an area? In-Reply-To: <39469E08BD83D411A3D900204840EC5531DBF4@vie-msgusr-01.dc.fore.com>; from "Sunkad, Ravindra" at Apr 25, 101 11:28 am Message-ID: <200104251830.LAA26168@diablo.cisco.com> Looked like L2 to me also... mwt > > 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_01C0CDB4.E8D58A90 > Content-Type: text/plain; > charset="iso-8859-1" > > Sivakumar, > > That is "twelve" not L2. > > Ravi > > -----Original Message----- > From: Sivakumar A [mailto:sivaa@indiatimes.com] > Sent: Wednesday, April 25, 2001 7:08 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Is L1 and L2 address same in an area? > > > > Hi all, > > With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned > that Area Address option shall be present only in an LSP with LSP number > zero. If there are more area addreeses than will fit in a single instance of > the Area Addresses option field, then the IS shall place L2 area addresses > in each instance of the field except the last. > > What is the L2 area address and how is it different from area address of a > particular area. > > thanks and regards > > Sivakumar > > _____ > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > > > > ------_=_NextPart_001_01C0CDB4.E8D58A90 > Content-Type: text/html; > charset="iso-8859-1" > > > > > > > > >
class=643502018-25042001>Sivakumar,
>
class=643502018-25042001> 
>
That > is "twelve" not L2.
>
class=643502018-25042001> 
>
class=643502018-25042001>Ravi
>
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"> >
size=2>-----Original Message-----
From: Sivakumar A > [mailto:sivaa@indiatimes.com]
Sent: Wednesday, April 25, 2001 7:08 > AM
To: isis-wg@juniper.net
Subject: [Isis-wg] Is L1 and L2 > address same in an area?

>

Hi all,

>

With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned > that Area Address option shall be present only in an LSP with LSP number zero. > If there are more area addreeses than will fit in a single instance of the > Area Addresses option field, then the IS shall place L2 area addresses in each > instance of the field except the last.

>

What is the L2 area address and how is it different from area address of a > particular area.

>

thanks and regards

>

Sivakumar

>
> Get Your Private, Free E-mail from Indiatimes at href="http://email.indiatimes.com">http://email.indiatimes.com >
> > ------_=_NextPart_001_01C0CDB4.E8D58A90-- > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mbartell@cisco.com Wed Apr 25 19:34:35 2001 From: mbartell@cisco.com (Micah Bartell) Date: Wed, 25 Apr 2001 13:34:35 -0500 Subject: [Isis-wg] Help needed In-Reply-To: <000b01c0cd78$68545220$1c06140a@future.futsoft.com> Message-ID: <4.3.2.7.2.20010425132608.031c9ef0@ce-nfs-1.cisco.com> If for instance you have LSPA-FRAG3 that contains adjacency Z. A whole bunch of circuits are restored, and the LSPA-FRAG3 contains these new adjacencies and adjacency Z gets moved to LSPA-FRAG4. When LSPA-FRAG3 is flooded, other IS's will receive this and see that adjacency Z is no longer there. So they remove it for their SPF. However, shortly after, LSPA-FRAG4 would arrive with adjacency Z and it would be restored. This could cause the temporary loss of connectivity. When a link goes down, you don't repack everything as densely as possible, the recommendation is that the number of LSPs generated be within 10% of the optimal number of LSPs if they were densely packed. When new adjacencies come up, you add them into the lowest LSP with available space, which will optimize the number of LSPs vs amount of information being sent. /mpb Full Quote of 7.3.4.4 & Note and Footnote: 7.3.4.4 Once a particular adjacency has been assigned to a particular LSP Number, it is desirable that it not be moved to another LSP Number. This is because moving an adjacency from one LSP to another can cause temporary loss of connectivity to that system. This can occur if the new version of the LSP which originally contained information about the adjacency (which now does not contain that information) is propagated before the new version of the other LSP (which now contains the information about the adjacency). NOTE 25 An implementation is recommended to ensure that the number of LSPs generated for a particular system is within approximately 10% of the optimal number which would be required if all LSPs were densely packed with neighbour options. Where possible this should be accomplished by re-using space in LSPs with a lower LSP Number for new adjacencies. If it is necessary to move an adjacency from one LSP to another, the SRMflags (see 7.3.15) for the two new LSPs shall be set as an atomic action.1) 1) If the two SRMflags are not set atomically, a race condition will exist in which one of the two LSPs may be propagated quickly, while the other waits for an entire propagation cycle. If this occurs, adjacencies will be falsely eliminated from the topology and routes may become unstable for periods of time potentially as large as maximumLSPGenerationInterval. At 16:40 04/25/2001 +0530, Vamsi K wrote: >Hi , > In the ISO/IEC 10589: 1992(E) document, the section 7.3.4.4 is a bit >confusing. Here i am quoting the exact words. > > >Once a particular adjacency has been assigned to a particular LSP number, it >is desirable that it not be moved to another LSP number. >This is because moving an adjacency from one LSP to another can cause >temporary loss of connectivity to that system. This can occur if the >new version of the LSP which orginally contained information about the >adjacency (which now doesnot contain information) is propagated before the >new version of the other LSP ( which now contains the information about the >adjacency). > > > > > >Here my doubt is what is the need for attaching the specific LSP number >(not the sequence number) for a particular adjacency. The field >"Intermediate system Neighbours" in the LSP PDU contains the neighbour id >field which indicates the particular adjacency, the information is >pertaining to. > > >Can anybody clear my doubt regarding this. > > >Thanks in advance >vamsi.P > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Wed Apr 25 19:58:58 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 25 Apr 2001 14:58:58 -0400 Subject: [Isis-wg] Help needed In-Reply-To: <000b01c0cd78$68545220$1c06140a@future.futsoft.com> Message-ID: <4.3.2.7.2.20010425143803.049d0f00@dingdong.cisco.com> Vamsi, >Here my doubt is what is the need for attaching the specific LSP number >(not the sequence number) for a particular adjacency. For example, let's say adjacency A is currently in LSP segment 2, and is moved to LSP segement 3. Both LSP segments' (independent) sequence numbers get incremented, and both segments get transmitted. Now, if segment 3 gets dropped due to noise on an Ethernet, segment 2 gets flooded first. All the routers that get segment 2 and not segment 3 will assume that there is no adjacency A. Note that this could also happen if the segments simply arrive in the obvious order (2 first, then 3), if the receiving implementation has a hold-down timer on running SPF. If it weren't for the "don't move" rule, we wouldn't be able to have hold-down timers on running SPF, which can be useful especially in embedded systems like SONET NEs, where routing is not the system's principal concern. Regards, Jeff At 07:10 AM 4/25/2001, Vamsi K wrote: >Hi , > In the ISO/IEC 10589: 1992(E) document, the section 7.3.4.4 is a bit >confusing. Here i am quoting the exact words. > > >Once a particular adjacency has been assigned to a particular LSP number, it >is desirable that it not be moved to another LSP number. >This is because moving an adjacency from one LSP to another can cause >temporary loss of connectivity to that system. This can occur if the >new version of the LSP which orginally contained information about the >adjacency (which now doesnot contain information) is propagated before the >new version of the other LSP ( which now contains the information about the >adjacency). > > > > > >Here my doubt is what is the need for attaching the specific LSP number >(not the sequence number) for a particular adjacency. The field >"Intermediate system Neighbours" in the LSP PDU contains the neighbour id >field which indicates the particular adjacency, the information is >pertaining to. > > >Can anybody clear my doubt regarding this. > > >Thanks in advance >vamsi.P > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Internet-Drafts@ietf.org Mon Apr 30 12:05:05 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 30 Apr 2001 07:05:05 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-04.txt Message-ID: <200104301105.HAA04362@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-04.txt Pages : 60 Date : 27-Apr-01 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 [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-04.txt 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-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-wg-mib-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: <20010427152439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010427152439.I-D@ietf.org> --OtherAccess-- --NextPart-- From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_20014264957392008532428 Content-Type: text/plain; charset=us-ascii Hi all, a)What is downsteam path? b) In clause 7.2.6.4 of ISO/IEC 10589 : 1992 (E) If an IS is a L1 intermediate system which supports all four metrics, and additionally computes downstream paths, it would execute the algorith 4 * (number of neighbours +1) times. Can any one clarify this?? thanks and regards Sivakumar Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20014264957392008532428 Content-Type: text/html; charset=us-ascii

Hi all,

a)What is downsteam path?

b) In clause 7.2.6.4 of ISO/IEC 10589 : 1992 (E)

If an IS is a L1 intermediate system which supports all four metrics, and additionally computes downstream paths, it would execute the algorith 4 * (number of neighbours +1) times. Can any one clarify this??

thanks and regards

Sivakumar

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20014264957392008532428-- From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_2001428695423126107205 Content-Type: text/plain; charset=us-ascii Hi, a)What is downsteam path? b) In clause 7.2.6.4 of ISO/IEC 10589 : 1992 (E) If an IS is a L1 intermediate system which supports all four metrics, and additionally computes downstream paths, it would execute the algorith 4 * (number of neighbours +1) times. Can any one clarify this?? thanks and regards Sivakumar Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_2001428695423126107205 Content-Type: text/html; charset=us-ascii

Hi,

a)What is downsteam path?

b) In clause 7.2.6.4 of ISO/IEC 10589 : 1992 (E)

If an IS is a L1 intermediate system which supports all four metrics, and additionally computes downstream paths, it would execute the algorith 4 * (number of neighbours +1) times. Can any one clarify this??

thanks and regards

Sivakumar

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_2001428695423126107205-- From jparker@axiowave.com Mon Apr 30 19:38:58 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 30 Apr 2001 14:38:58 -0400 Subject: [Isis-wg] downstream paths? 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_01C0D1A4.D190E6B0 Content-Type: text/plain; charset="iso-8859-1" > a)What is downsteam path? Something closer to the "ocean" - a nearby L2 router with a better sense of direction. Take a look at section 7.2.6.2 7.2.6.2 A system executes the SPF algorithm to find a set of legal paths to a destination system in the routeing domain. The set may consist of a) a single path of minimum metric sum: these are termed minimum cost paths; b) a set of paths of equal minimum metric sum: these are termed equal minimum cost paths; or c) a set of paths which will get a PDU closer to its destination than the local system: these are called downstream paths. - jeff parker - axiowave networks - A child of five could understand this. Fetch me a child of five. ------_=_NextPart_001_01C0D1A4.D190E6B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] downstream paths?

> a)What is downsteam path?

Something closer to the "ocean" - a nearby = L2 router with a better
sense of direction.  Take a look at section = 7.2.6.2

7.2.6.2 A system executes the SPF algorithm to find a = set of legal
paths to a destination system in the routeing = domain. The set may consist of

a)      a single path of = minimum metric sum: these are termed minimum cost paths;

b)      a set of paths of = equal minimum metric sum: these are termed equal minimum cost paths; = or

c)      a set of paths which = will get a PDU closer to its destination than
        the local = system: these are called downstream paths.

- jeff parker
- axiowave networks
- A child of five could understand this.  Fetch = me a child of five.

------_=_NextPart_001_01C0D1A4.D190E6B0-- From Radia Perlman - Boston Center for Networking Mon Apr 30 20:38:38 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Mon, 30 Apr 2001 15:38:38 -0400 (EDT) Subject: [Isis-wg] downstream paths? Message-ID: <200104301938.PAA11826@bcn.East.Sun.COM> OK. Reading Jeff Parker's reply I now understand, but perhaps it's worth having a 2nd person explain it. I didn't remember this from IS-IS at all (I assume it got put in by ISO and wasn't in the original DECnet Phase V routing algorithm), but apparently (based on the section quoted by Jeff) you're allowed to forward a packet destined to D to neighbor N even if N isn't on a minimal path from you to D, but instead neighbor N is closer to D than you are. In other words, you have a path through neighbor N1 to D that is of cost 50, and that's your best path. Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. If you forward through N your path will be 53, clearly worse than your path through N1, but since N is closer to D than you (N is 48 away, you're 50 away), you're allowed to forward to N. A neighbor closer to D than you is "downstream". So N (as well as N1) would be downstream. The normal Dijkstra calculation wouldn't tell you all neighbors closer to D than you. The only way to get this is to calculate Dijkstra from the point of view of each neighbor. That's why, if you have k neighbors, you'd have to calculate Dijkstra from your own point of view, plus from the point of view of each neighbor (to find out, for each destination, which of your neighbors is closer to the destination than you are). And with multiple metrics, you'd have to multiply the number of Dijkstra calculations by the number of metrics (I never did like the multiple metric thing, especially the way ISO specified it...that you leave out links that don't advertise that metric so you're calculating an "optimal" path based on a subset of the links!). So that explains why the section you quoted says if there are 4 metrics, and you want to "calculate downstream paths) i.e., find out which neighbors are closer than you for each destination), you "would execute the algorithm 4 * (number of neighbours +1) times" I always thought the multiple metrics were not worth the extra calculation and configuration (and were actually quite dangerous given how ISO specified it since it's very nonintuitive why you might get really horrible routes if you use any metric that isn't universally supported on every link). I'd think this "calculating downstream paths" would also not be worth the extra computation and storage. Does any IS-IS implementation bother with this "downstream paths" thing? Radia From jlearman@cisco.com Mon Apr 30 23:31:26 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 30 Apr 2001 18:31:26 -0400 Subject: [Isis-wg] downstream paths? In-Reply-To: <200104301938.PAA11826@bcn.East.Sun.COM> Message-ID: <4.3.2.7.2.20010430182119.019c0548@dingdong.cisco.com> Radia, Thanks for the clarification. Your interpretation matches the only interpretation I have ever been able to glean from the spec. I am at a loss for why anyone would bother to do more work to get less optimal routes, other than to be able to do load balancing in more circumstances. (Whether that kind of LB would actually be a good idea is another question.) I can't answer whether this is implemented in any integrated IS-IS implementations, but I will be surprised if it is. If it was, it could not be used in conjunction with reverse path filtering, of course. Regards, Jeff At 03:38 PM 4/30/2001, Radia Perlman - Boston Center for Networking wrote: >OK. Reading Jeff Parker's reply I now understand, but perhaps >it's worth having a 2nd person explain it. > >I didn't remember this from IS-IS at all (I assume >it got put in by ISO and wasn't in the original DECnet >Phase V routing algorithm), but apparently (based on >the section quoted by Jeff) you're >allowed to forward a packet destined to D to neighbor N even if >N isn't on a minimal path from you to D, but instead neighbor N >is closer to D than you are. In other words, you have a path through >neighbor N1 to D that is of cost 50, and that's your best path. >Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. >If you forward through N your path will be 53, clearly worse than >your path through N1, but since N is closer to D than you (N is >48 away, you're 50 away), you're allowed to forward to N. > >A neighbor closer to D than you is "downstream". So N (as well as N1) >would be downstream. > >The normal Dijkstra calculation wouldn't tell you all neighbors closer >to D than you. The only way to get this is to calculate Dijkstra >from the point of view of each neighbor. That's why, if you have k >neighbors, you'd have to calculate Dijkstra from your own point of >view, plus from the point of view of each neighbor (to find out, for >each destination, which of your neighbors is closer to the destination >than you are). > >And with multiple metrics, you'd have to multiply the number of Dijkstra >calculations by the number of metrics (I never did like the multiple >metric thing, especially the way ISO specified it...that you leave out >links that don't advertise that metric so you're calculating an "optimal" >path based on a subset of the links!). > >So that explains why the section you quoted says if there are 4 >metrics, and you want to "calculate downstream paths) i.e., find out >which neighbors are closer than you for each destination), you >"would execute the algorithm 4 * (number of neighbours +1) times" > >I always thought the multiple metrics were not worth the extra >calculation and configuration (and were actually quite dangerous >given how ISO specified it since it's very nonintuitive why you >might get really horrible routes if you use any metric that isn't >universally supported on every link). I'd think this "calculating >downstream paths" would also not be worth the extra computation >and storage. Does any IS-IS implementation bother with this >"downstream paths" thing? > >Radia > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From dima@krioukov.net Tue May 1 01:53:56 2001 From: dima@krioukov.net (Dmitri Krioukov) Date: Mon, 30 Apr 2001 20:53:56 -0400 Subject: [Isis-wg] downstream paths? In-Reply-To: <200104301938.PAA11826@bcn.East.Sun.COM> Message-ID: It's worth to note that any non-ECMP proposal (ISIS-OMP, for example) would require this. -- dima. > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Radia Perlman - > Boston Center for Networking > Sent: Monday, April 30, 2001 3:39 PM > To: isis-wg@juniper.net; sivaa@indiatimes.com > Subject: Re: [Isis-wg] downstream paths? > > > OK. Reading Jeff Parker's reply I now understand, but perhaps > it's worth having a 2nd person explain it. > > I didn't remember this from IS-IS at all (I assume > it got put in by ISO and wasn't in the original DECnet > Phase V routing algorithm), but apparently (based on > the section quoted by Jeff) you're > allowed to forward a packet destined to D to neighbor N even if > N isn't on a minimal path from you to D, but instead neighbor N > is closer to D than you are. In other words, you have a path through > neighbor N1 to D that is of cost 50, and that's your best path. > Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > If you forward through N your path will be 53, clearly worse than > your path through N1, but since N is closer to D than you (N is > 48 away, you're 50 away), you're allowed to forward to N. > > A neighbor closer to D than you is "downstream". So N (as well as N1) > would be downstream. > > The normal Dijkstra calculation wouldn't tell you all neighbors closer > to D than you. The only way to get this is to calculate Dijkstra > from the point of view of each neighbor. That's why, if you have k > neighbors, you'd have to calculate Dijkstra from your own point of > view, plus from the point of view of each neighbor (to find out, for > each destination, which of your neighbors is closer to the destination > than you are). > > And with multiple metrics, you'd have to multiply the number of Dijkstra > calculations by the number of metrics (I never did like the multiple > metric thing, especially the way ISO specified it...that you leave out > links that don't advertise that metric so you're calculating an "optimal" > path based on a subset of the links!). > > So that explains why the section you quoted says if there are 4 > metrics, and you want to "calculate downstream paths) i.e., find out > which neighbors are closer than you for each destination), you > "would execute the algorithm 4 * (number of neighbours +1) times" > > I always thought the multiple metrics were not worth the extra > calculation and configuration (and were actually quite dangerous > given how ISO specified it since it's very nonintuitive why you > might get really horrible routes if you use any metric that isn't > universally supported on every link). I'd think this "calculating > downstream paths" would also not be worth the extra computation > and storage. Does any IS-IS implementation bother with this > "downstream paths" thing? > > Radia > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From mshand@cisco.com Tue May 1 09:36:24 2001 From: mshand@cisco.com (mike shand) Date: Tue, 01 May 2001 09:36:24 +0100 Subject: [Isis-wg] downstream paths? In-Reply-To: <4.3.2.7.2.20010430182119.019c0548@dingdong.cisco.com> References: <200104301938.PAA11826@bcn.East.Sun.COM> Message-ID: <4.3.2.7.2.20010501092926.0356f298@jaws.cisco.com> This was another of those things which it was easier to allow to be put in there than it was to argue against it. As I recall it was a guy called Mikel Silvest (I may have the spelling wrong) who wanted this. We had already had to remove the description of the SPF algorithm from the normative text into a non-normative appendix (since from an interoperability point of view it doesn't matter WHAT the algorithm is, it only matters that it gives the same results). Dave might remember more. As far as I am aware, nobody has ever attempted to implement this. Yes, the idea I think was to be able to do better load balancing, but I was never convinced it was a good idea. At 18:31 30/04/2001 -0400, Jeff Learman wrote: >Radia, > >Thanks for the clarification. > >Your interpretation matches the only interpretation I have ever >been able to glean from the spec. I am at a loss for why anyone >would bother to do more work to get less optimal routes, other >than to be able to do load balancing in more circumstances. >(Whether that kind of LB would actually be a good idea is another >question.) > >I can't answer whether this is implemented in any integrated IS-IS >implementations, but I will be surprised if it is. If it was, it >could not be used in conjunction with reverse path filtering, >of course. > >Regards, >Jeff > >At 03:38 PM 4/30/2001, Radia Perlman - Boston Center for Networking wrote: > >OK. Reading Jeff Parker's reply I now understand, but perhaps > >it's worth having a 2nd person explain it. > > > >I didn't remember this from IS-IS at all (I assume > >it got put in by ISO and wasn't in the original DECnet > >Phase V routing algorithm), but apparently (based on > >the section quoted by Jeff) you're > >allowed to forward a packet destined to D to neighbor N even if > >N isn't on a minimal path from you to D, but instead neighbor N > >is closer to D than you are. In other words, you have a path through > >neighbor N1 to D that is of cost 50, and that's your best path. > >Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > >If you forward through N your path will be 53, clearly worse than > >your path through N1, but since N is closer to D than you (N is > >48 away, you're 50 away), you're allowed to forward to N. > > > >A neighbor closer to D than you is "downstream". So N (as well as N1) > >would be downstream. > > > >The normal Dijkstra calculation wouldn't tell you all neighbors closer > >to D than you. The only way to get this is to calculate Dijkstra > >from the point of view of each neighbor. That's why, if you have k > >neighbors, you'd have to calculate Dijkstra from your own point of > >view, plus from the point of view of each neighbor (to find out, for > >each destination, which of your neighbors is closer to the destination > >than you are). > > > >And with multiple metrics, you'd have to multiply the number of Dijkstra > >calculations by the number of metrics (I never did like the multiple > >metric thing, especially the way ISO specified it...that you leave out > >links that don't advertise that metric so you're calculating an "optimal" > >path based on a subset of the links!). > > > >So that explains why the section you quoted says if there are 4 > >metrics, and you want to "calculate downstream paths) i.e., find out > >which neighbors are closer than you for each destination), you > >"would execute the algorithm 4 * (number of neighbours +1) times" > > > >I always thought the multiple metrics were not worth the extra > >calculation and configuration (and were actually quite dangerous > >given how ISO specified it since it's very nonintuitive why you > >might get really horrible routes if you use any metric that isn't > >universally supported on every link). I'd think this "calculating > >downstream paths" would also not be worth the extra computation > >and storage. Does any IS-IS implementation bother with this > >"downstream paths" thing? > > > >Radia > > > >_______________________________________________ > >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 Tue May 1 15:30:51 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 1 May 2001 10:30:51 -0400 Subject: [Isis-wg] draft-ietf-isis-wg-mib-04.txt 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_01C0D24B.523AA890 Content-Type: text/plain; charset="iso-8859-1" A copy of the source to the isis mib suitable for feeding to a mib compiler should now be accessible at ftp.axiowave.com. This DNS name should resolve to 209.6.34.3. The URL for the draft, with words, page numbers, etc. is on the IETF site at http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-04.txt Please let me know about any questions or issues. The changes in this version are described at the top of the mib file, and a visible in either version. - jeff parker - axiowave networks ------_=_NextPart_001_01C0D24B.523AA890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-isis-wg-mib-04.txt

A copy of the source to the isis mib suitable for = feeding to a mib compiler should
now be accessible at ftp.axiowave.com.  This = DNS name should resolve to 209.6.34.3. 

The URL for the draft, with words, page numbers, etc. = is on the IETF site at
        =         http://www.ietf.org/internet-drafts/draft-ietf-isis-wg= -mib-04.txt

Please let me know about any questions or = issues.  The changes in this version
are described at the top of the mib file, and a = visible in either version. 

- jeff parker
- axiowave networks

------_=_NextPart_001_01C0D24B.523AA890-- From dkatz@juniper.net Tue May 1 18:42:34 2001 From: dkatz@juniper.net (Dave Katz) Date: Tue, 1 May 2001 10:42:34 -0700 (PDT) Subject: [Isis-wg] downstream paths? In-Reply-To: <4.3.2.7.2.20010501092926.0356f298@jaws.cisco.com> (message from mike shand on Tue, 01 May 2001 09:36:24 +0100) Message-ID: <200105011742.KAA20373@cirrus.juniper.net> In theory I suppose this could be used to provide potentially feasible "standby" routes that could be quickly plugged in when link failure is detected locally, thus reducing the black hole period by some nominal amount, at the cost of additional background calculation. This kind of scheme is used in EIGRP to determine feasible successors prior to the failure of the primary path, in order to avoid entering Active state. It can also be used for unequal cost load balancing, as mentioned. It makes a lot more sense in EIGRP's case, since it takes no more computation to determine the feasible successors (the neighbors are already telling you their path cost), and since the cost of having to find a new path from scratch is relatively high. --Dave X-JNPR-Received-From: outside X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 From: mike shand Cc: Radia Perlman , isis-wg@juniper.net, sivaa@indiatimes.com References: <200104301938.PAA11826@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 01 May 2001 09:36:24 +0100 This was another of those things which it was easier to allow to be put in there than it was to argue against it. As I recall it was a guy called Mikel Silvest (I may have the spelling wrong) who wanted this. We had already had to remove the description of the SPF algorithm from the normative text into a non-normative appendix (since from an interoperability point of view it doesn't matter WHAT the algorithm is, it only matters that it gives the same results). Dave might remember more. As far as I am aware, nobody has ever attempted to implement this. Yes, the idea I think was to be able to do better load balancing, but I was never convinced it was a good idea. At 18:31 30/04/2001 -0400, Jeff Learman wrote: >Radia, > >Thanks for the clarification. > >Your interpretation matches the only interpretation I have ever >been able to glean from the spec. I am at a loss for why anyone >would bother to do more work to get less optimal routes, other >than to be able to do load balancing in more circumstances. >(Whether that kind of LB would actually be a good idea is another >question.) > >I can't answer whether this is implemented in any integrated IS-IS >implementations, but I will be surprised if it is. If it was, it >could not be used in conjunction with reverse path filtering, >of course. > >Regards, >Jeff > >At 03:38 PM 4/30/2001, Radia Perlman - Boston Center for Networking wrote: > >OK. Reading Jeff Parker's reply I now understand, but perhaps > >it's worth having a 2nd person explain it. > > > >I didn't remember this from IS-IS at all (I assume > >it got put in by ISO and wasn't in the original DECnet > >Phase V routing algorithm), but apparently (based on > >the section quoted by Jeff) you're > >allowed to forward a packet destined to D to neighbor N even if > >N isn't on a minimal path from you to D, but instead neighbor N > >is closer to D than you are. In other words, you have a path through > >neighbor N1 to D that is of cost 50, and that's your best path. > >Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > >If you forward through N your path will be 53, clearly worse than > >your path through N1, but since N is closer to D than you (N is > >48 away, you're 50 away), you're allowed to forward to N. > > > >A neighbor closer to D than you is "downstream". So N (as well as N1) > >would be downstream. > > > >The normal Dijkstra calculation wouldn't tell you all neighbors closer > >to D than you. The only way to get this is to calculate Dijkstra > >from the point of view of each neighbor. That's why, if you have k > >neighbors, you'd have to calculate Dijkstra from your own point of > >view, plus from the point of view of each neighbor (to find out, for > >each destination, which of your neighbors is closer to the destination > >than you are). > > > >And with multiple metrics, you'd have to multiply the number of Dijkstra > >calculations by the number of metrics (I never did like the multiple > >metric thing, especially the way ISO specified it...that you leave out > >links that don't advertise that metric so you're calculating an "optimal" > >path based on a subset of the links!). > > > >So that explains why the section you quoted says if there are 4 > >metrics, and you want to "calculate downstream paths) i.e., find out > >which neighbors are closer than you for each destination), you > >"would execute the algorithm 4 * (number of neighbours +1) times" > > > >I always thought the multiple metrics were not worth the extra > >calculation and configuration (and were actually quite dangerous > >given how ISO specified it since it's very nonintuitive why you > >might get really horrible routes if you use any metric that isn't > >universally supported on every link). I'd think this "calculating > >downstream paths" would also not be worth the extra computation > >and storage. Does any IS-IS implementation bother with this > >"downstream paths" thing? > > > >Radia > > > >_______________________________________________ > >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 dima@krioukov.net Wed May 2 00:10:03 2001 From: dima@krioukov.net (Dmitri Krioukov) Date: Tue, 1 May 2001 19:10:03 -0400 Subject: [Isis-wg] downstream paths? In-Reply-To: <200105011742.KAA20373@cirrus.juniper.net> Message-ID: Was this idea (of "standby" routes) in anyone's mind when this text was put in, though? -- dima. > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Dave Katz > Sent: Tuesday, May 01, 2001 1:43 PM > To: mshand@cisco.com > Cc: jlearman@cisco.com; oran@cisco.com; Radia.Perlman@Sun.COM; > isis-wg@juniper.net; sivaa@indiatimes.com > Subject: Re: [Isis-wg] downstream paths? > > > In theory I suppose this could be used to provide potentially feasible > "standby" routes that could be quickly plugged in when link failure is > detected locally, thus reducing the black hole period by some nominal > amount, at the cost of additional background calculation. > > This kind of scheme is used in EIGRP to determine feasible successors > prior to the failure of the primary path, in order to avoid entering > Active state. It can also be used for unequal cost load balancing, as > mentioned. It makes a lot more sense in EIGRP's case, since it takes > no more computation to determine the feasible successors (the > neighbors are already telling you their path cost), and since the cost > of having to find a new path from scratch is relatively high. > > --Dave > > X-JNPR-Received-From: outside > X-Sender: mshand@jaws.cisco.com > X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 > From: mike shand > Cc: Radia Perlman , isis-wg@juniper.net, > sivaa@indiatimes.com > References: <200104301938.PAA11826@bcn.East.Sun.COM> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: > , > > List-Archive: > Date: Tue, 01 May 2001 09:36:24 +0100 > > This was another of those things which it was easier to allow > to be put in > there than it was to argue against it. As I recall it was a guy called > Mikel Silvest (I may have the spelling wrong) who wanted this. We had > already had to remove the description of the SPF algorithm from the > normative text into a non-normative appendix (since from an > interoperability point of view it doesn't matter WHAT the > algorithm is, it > only matters that it gives the same results). > > Dave might remember more. > > As far as I am aware, nobody has ever attempted to implement this. > > Yes, the idea I think was to be able to do better load > balancing, but I was > never convinced it was a good idea. > > > At 18:31 30/04/2001 -0400, Jeff Learman wrote: > > >Radia, > > > >Thanks for the clarification. > > > >Your interpretation matches the only interpretation I have ever > >been able to glean from the spec. I am at a loss for why anyone > >would bother to do more work to get less optimal routes, other > >than to be able to do load balancing in more circumstances. > >(Whether that kind of LB would actually be a good idea is another > >question.) > > > >I can't answer whether this is implemented in any integrated IS-IS > >implementations, but I will be surprised if it is. If it was, it > >could not be used in conjunction with reverse path filtering, > >of course. > > > >Regards, > >Jeff > > > >At 03:38 PM 4/30/2001, Radia Perlman - Boston Center for > Networking wrote: > > >OK. Reading Jeff Parker's reply I now understand, but perhaps > > >it's worth having a 2nd person explain it. > > > > > >I didn't remember this from IS-IS at all (I assume > > >it got put in by ISO and wasn't in the original DECnet > > >Phase V routing algorithm), but apparently (based on > > >the section quoted by Jeff) you're > > >allowed to forward a packet destined to D to neighbor N even if > > >N isn't on a minimal path from you to D, but instead neighbor N > > >is closer to D than you are. In other words, you have a path through > > >neighbor N1 to D that is of cost 50, and that's your best path. > > >Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > > >If you forward through N your path will be 53, clearly worse than > > >your path through N1, but since N is closer to D than you (N is > > >48 away, you're 50 away), you're allowed to forward to N. > > > > > >A neighbor closer to D than you is "downstream". So N (as > well as N1) > > >would be downstream. > > > > > >The normal Dijkstra calculation wouldn't tell you all > neighbors closer > > >to D than you. The only way to get this is to calculate Dijkstra > > >from the point of view of each neighbor. That's why, if you have k > > >neighbors, you'd have to calculate Dijkstra from your own point of > > >view, plus from the point of view of each neighbor (to find out, for > > >each destination, which of your neighbors is closer to the > destination > > >than you are). > > > > > >And with multiple metrics, you'd have to multiply the > number of Dijkstra > > >calculations by the number of metrics (I never did like the multiple > > >metric thing, especially the way ISO specified it...that > you leave out > > >links that don't advertise that metric so you're > calculating an "optimal" > > >path based on a subset of the links!). > > > > > >So that explains why the section you quoted says if there are 4 > > >metrics, and you want to "calculate downstream paths) i.e., find out > > >which neighbors are closer than you for each destination), you > > >"would execute the algorithm 4 * (number of neighbours +1) times" > > > > > >I always thought the multiple metrics were not worth the extra > > >calculation and configuration (and were actually quite dangerous > > >given how ISO specified it since it's very nonintuitive why you > > >might get really horrible routes if you use any metric that isn't > > >universally supported on every link). I'd think this "calculating > > >downstream paths" would also not be worth the extra computation > > >and storage. Does any IS-IS implementation bother with this > > >"downstream paths" thing? > > > > > >Radia > > > > > >_______________________________________________ > > >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 Talmon_Reiss@KereniX.com Wed May 2 12:57:06 2001 From: Talmon_Reiss@KereniX.com (Talmon_Reiss) Date: Wed, 2 May 2001 14:57:06 +0300 Subject: [Isis-wg] Operation of P-toP links Message-ID: <2B15221907365C468941FDFC02C8776932391B@EXCHANGE.kerenix.com> Hi I have some questions regarding the operation of P-to-P links in IS-IS: After the establishment of a P-to-P adjacency what exactly happens wrt to LSP transmission ? Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)? What is the purpose of the partialSNPInterval timer? When is it used? What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link? Also did ISO ever update 10589 to fix the errors/omissions in the 1st edition dated 30/4/92 (eg to incl the stuff in the Defect Report 10589/001 from July 92 and / or other errors)? TIA Talmon From mshand@cisco.com Wed May 2 13:25:12 2001 From: mshand@cisco.com (mike shand) Date: Wed, 02 May 2001 13:25:12 +0100 Subject: [Isis-wg] Operation of P-toP links In-Reply-To: <2B15221907365C468941FDFC02C8776932391B@EXCHANGE.kerenix.co m> Message-ID: <4.3.2.7.2.20010502131827.00b50d98@jaws.cisco.com> At 14:57 02/05/2001 +0300, Talmon_Reiss wrote: >Hi > >I have some questions regarding the operation of P-to-P links in IS-IS: >After the establishment of a P-to-P adjacency what exactly happens wrt to >LSP transmission ? >Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)? Its an optimization (only). Receipt of a CSNP from the neighbor specifying which LSPs the neighbor has allows you to clear SRMflags for those LSPs and hence avoid transmitting them. Clearly if the link is to a neighbor which has just come up (as opposed to a link just coming up to a neighbor which has a full LSP database), then there will be no optimization. But I stress, it is ONLY an optimization. i.e. loss of the CSNP will still result in correct synchronization. Its just that it may require the unnecessary transmission of some or all the LSPs. >What is the purpose of the partialSNPInterval timer? When is it used? The idea is to batch up the acknowledgements. The only requirement is that the ack is received before the re-transmit happens. SO by delaying the sending of the PSNP it is likely that multiple LSPs can be acknowledged in the same PSNP. >What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link? You always send them to acknowledge every LSPs. i.e. SRMflags for an LSP is NOT cleared until either a PSNP has been received or an LSP with equal or newer sequence number. >Also did ISO ever update 10589 to fix the errors/omissions in the 1st >edition dated 30/4/92 (eg to incl the stuff in the Defect Report 10589/001 >from July 92 and / or other errors)? There is a version 2 currently being progressed by ISO. Note DO NOT confuse this with an earlier V2 draft which was circulating a couple of years ago which contained MANY errors. >TIA >Talmon > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Talmon_Reiss@KereniX.com Wed May 2 14:19:11 2001 From: Talmon_Reiss@KereniX.com (Talmon_Reiss) Date: Wed, 2 May 2001 16:19:11 +0300 Subject: [Isis-wg] Operation of P-toP links Message-ID: <2B15221907365C468941FDFC02C8776932391D@EXCHANGE.kerenix.com> Hi again - thanks for replying So if I understand you correctly: On a P-to-P link, FIRST, a CSNP is sent, thus maybe saving the transmission of some LSPs from the neighbour. Then each sends his LSPs, which you acknowledge when the partialSNPInterval timer fires. Then basically this previous sentence is repeated when an IS receives new LSPs to propagate. Is my understanding correct? Another question: Say hypothetically, that a IS with a P-to-P adjacency "lost" an LSP from its database. Apart from waiting for a retransmission of this LSP from its neighbour (after maximumLSPGenerationInterval seconds), is there any other way to get this LSP sooner? Thanks Talmon -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Wednesday, May 02, 2001 3:25 PM To: Talmon_Reiss Cc: IS-IS Mailing List (E-mail) Subject: Re: [Isis-wg] Operation of P-toP links At 14:57 02/05/2001 +0300, Talmon_Reiss wrote: >Hi > >I have some questions regarding the operation of P-to-P links in IS-IS: >After the establishment of a P-to-P adjacency what exactly happens wrt to >LSP transmission ? >Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)? Its an optimization (only). Receipt of a CSNP from the neighbor specifying which LSPs the neighbor has allows you to clear SRMflags for those LSPs and hence avoid transmitting them. Clearly if the link is to a neighbor which has just come up (as opposed to a link just coming up to a neighbor which has a full LSP database), then there will be no optimization. But I stress, it is ONLY an optimization. i.e. loss of the CSNP will still result in correct synchronization. Its just that it may require the unnecessary transmission of some or all the LSPs. >What is the purpose of the partialSNPInterval timer? When is it used? The idea is to batch up the acknowledgements. The only requirement is that the ack is received before the re-transmit happens. SO by delaying the sending of the PSNP it is likely that multiple LSPs can be acknowledged in the same PSNP. >What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link? You always send them to acknowledge every LSPs. i.e. SRMflags for an LSP is NOT cleared until either a PSNP has been received or an LSP with equal or newer sequence number. >Also did ISO ever update 10589 to fix the errors/omissions in the 1st >edition dated 30/4/92 (eg to incl the stuff in the Defect Report 10589/001 >from July 92 and / or other errors)? There is a version 2 currently being progressed by ISO. Note DO NOT confuse this with an earlier V2 draft which was circulating a couple of years ago which contained MANY errors. >TIA >Talmon > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mshand@cisco.com Wed May 2 14:33:09 2001 From: mshand@cisco.com (mike shand) Date: Wed, 02 May 2001 14:33:09 +0100 Subject: [Isis-wg] Operation of P-toP links In-Reply-To: <2B15221907365C468941FDFC02C8776932391D@EXCHANGE.kerenix.co m> Message-ID: <4.3.2.7.2.20010502142905.03490060@jaws.cisco.com> At 16:19 02/05/2001 +0300, Talmon_Reiss wrote: >Hi again - thanks for replying > >So if I understand you correctly: >On a P-to-P link, FIRST, a CSNP is sent, thus maybe saving the transmission >of some LSPs from the neighbour. Then each sends his LSPs, which you >acknowledge when the partialSNPInterval timer fires. Then basically this >previous sentence is repeated when an IS receives new LSPs to propagate. Is >my understanding correct? Yes, if I understand you correctly. >Another question: >Say hypothetically, that a IS with a P-to-P adjacency "lost" an LSP from its >database. Apart from waiting for a retransmission of this LSP from its >neighbour (after maximumLSPGenerationInterval seconds), is there any other >way to get this LSP sooner? Well, it better hadn't arbitrarily loose LSPs!!! If it detects that an LSP it holds is corrupt (bad checksum in memory), then it can treat it as expired and hence get a new one. Alternatively if it KNOWS that it has "lost" the LSP it could adopt various strategies to try to get it back, but none of this is covered by the normal protocol. As I said, once a router has acknowledged an LSP it is its responsibility to preserve it in its memory. If it doesn't it should probably crash! Mike >Thanks >Talmon > >-----Original Message----- >From: mike shand [mailto:mshand@cisco.com] >Sent: Wednesday, May 02, 2001 3:25 PM >To: Talmon_Reiss >Cc: IS-IS Mailing List (E-mail) >Subject: Re: [Isis-wg] Operation of P-toP links > > >At 14:57 02/05/2001 +0300, Talmon_Reiss wrote: > >Hi > > > >I have some questions regarding the operation of P-to-P links in IS-IS: > >After the establishment of a P-to-P adjacency what exactly happens wrt to > >LSP transmission ? > >Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)? > >Its an optimization (only). Receipt of a CSNP from the neighbor specifying >which LSPs the neighbor has allows you to clear SRMflags for those LSPs and >hence avoid transmitting them. Clearly if the link is to a neighbor which >has just come up (as opposed to a link just coming up to a neighbor which >has a full LSP database), then there will be no optimization. > >But I stress, it is ONLY an optimization. i.e. loss of the CSNP will still >result in correct synchronization. Its just that it may require the >unnecessary transmission of some or all the LSPs. > > >What is the purpose of the partialSNPInterval timer? When is it used? > >The idea is to batch up the acknowledgements. The only requirement is that >the ack is received before the re-transmit happens. SO by delaying the >sending of the PSNP it is likely that multiple LSPs can be acknowledged in >the same PSNP. > > >What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link? > >You always send them to acknowledge every LSPs. i.e. SRMflags for an LSP is >NOT cleared until either a PSNP has been received or an LSP with equal or >newer sequence number. > > > >Also did ISO ever update 10589 to fix the errors/omissions in the 1st > >edition dated 30/4/92 (eg to incl the stuff in the Defect Report 10589/001 > >from July 92 and / or other errors)? > >There is a version 2 currently being progressed by ISO. Note DO NOT confuse >this with an earlier V2 draft which was circulating a couple of years ago >which contained MANY errors. > > >TIA > >Talmon > > > > > > > > > > > >_______________________________________________ > >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 cast@allegronetworks.com Wed May 2 18:35:25 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Wed, 2 May 2001 10:35:25 -0700 Subject: [Isis-wg] Operation of P-toP links Message-ID: > If it detects that an LSP it holds is corrupt (bad checksum > in memory), > then it can treat it as expired and hence get a new one. Treating corrupt LSPs as if they had expired causes a network wide purge of them. I could imagine a faulty router (maybe one with bad memory or bad software) frequently purging many LSPs and so cause network wide disruption. One way to "safely" recover is to reacquire the LSP database. You need a mechanism to cause the routers on the other side of WAN links to reinitialize them, and so cause the LSP database to be synchronized again. (This mechanism does not exist in 10589). We added a state machine to the WAN hello processing that allowed one side to notify the other that it was reinitializing the link, in NLSP, an ISIS knock-off. Among other things, this allowed NLSP to recover from corrupt LSPs. Recovering worked fine in the lab. After corrupting an LSP by hand in the database, the router would find the bad LSP during periodic LSP database verification. The router then released the entire contents of the database and reinitialized all the WAN links, thereby causing the LSPs to be reacquired. However, while it seems like a great idea to recover from corrupt LSPs, how does the router know the extent of the damage? It could be that other data structures are now in an inconsistent state, some of which could cause network wide disruption. This is why the (simple) idea of "crashing the router" makes a lot of sense. It can help to isolate the problem to a single node in the network (of course, it's best to prevent as many of these problems as practical in the first place!). > As I said, once a router has acknowledged an LSP it is its > responsibility > to preserve it in its memory. If it doesn't it should probably crash! > > Mike --Neal From prz@redback.com Wed May 2 19:42:29 2001 From: prz@redback.com (Tony Przygienda) Date: Wed, 02 May 2001 11:42:29 -0700 Subject: [Isis-wg] Operation of P-toP links References: Message-ID: <3AF054FA.55665265@redback.com> Neal Castagnoli wrote: > > If it detects that an LSP it holds is corrupt (bad checksum > > in memory), > > then it can treat it as expired and hence get a new one. > > Treating corrupt LSPs as if they had expired causes a network wide purge of > them. I could imagine a faulty router (maybe one with bad memory or bad > software) frequently purging many LSPs and so cause network wide disruption. any decent implementation does only flush its own LSPs these days. Flushing other people LSPs has proven to be a bad idea. > We added a state machine to the WAN hello processing that allowed one side > to notify the other that it was reinitializing the link, in NLSP, an ISIS > knock-off. Among other things, this allowed NLSP to recover from corrupt > LSPs. > > Recovering worked fine in the lab. After corrupting an LSP by hand in the > database, the router would find the bad LSP during periodic LSP database > verification. The router then released the entire contents of the database > and reinitialized all the WAN links, thereby causing the LSPs to be > reacquired. even simpler solutions to the problem exist given some cooperation from your neighbor -- tony From cast@allegronetworks.com Wed May 2 22:50:23 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Wed, 2 May 2001 14:50:23 -0700 Subject: [Isis-wg] Operation of P-toP links Message-ID: > any decent implementation does only flush its own LSPs these > days. Flushing > other people LSPs has proven to be a bad idea. Right. In NLSP we eliminated the "bad checksum purge" when receiving corrupted LSPs, because a corrupting link (or misbehaving router on the other end of the link) could bring down a network. We discarded the bad ones, and alerted the administrator. The other instance of a network wide purge is receipt of an LSP that has the same "newness" (same sequence number, same lspid, both non-zero lifetime), but different checksums. In this case, we included checksum as a part of the "newer" calculation. LSPs with higher checksums were "newer." This prevented routers from purging others LSPs, and in the case of two routers battling over a system ID, it allowed the LSPs to flow back and forth between the battling routers (both routers complain). Is this being done with ISIS implementations? If so, it seems all routers need to have the same algorithm (what is it?). If not, what is being done to prevent the purge? >> > even simpler solutions to the problem exist given some > cooperation from your > neighbor > Do you know what the simpler solutions are? Care to describe them? (which begs the question of whether it is even right to try to recover!). > -- tony > --Neal From prz@redback.com Wed May 2 23:32:11 2001 From: prz@redback.com (Tony Przygienda) Date: Wed, 02 May 2001 15:32:11 -0700 Subject: [Isis-wg] Operation of P-toP links References: Message-ID: <3AF08ACD.8DD72EE9@redback.com> Neal Castagnoli wrote: > >> > > even simpler solutions to the problem exist given some > > cooperation from your > > neighbor > > > > Do you know what the simpler solutions are? Care to describe them? > > (which begs the question of whether it is even right to try to recover!). think sending SNPs when the spec doesn't call for it. Most implementation will do the right thing then. Whether it is right to recover depends on many things, one of them your marketing departement and overall architecture of the box ;-) 'nuff said -=-= tony From mshand@cisco.com Thu May 3 08:20:21 2001 From: mshand@cisco.com (mike shand) Date: Thu, 03 May 2001 08:20:21 +0100 Subject: [Isis-wg] Operation of P-toP links In-Reply-To: Message-ID: <4.3.2.7.2.20010503080613.03471fb0@jaws.cisco.com> At 14:50 02/05/2001 -0700, Neal Castagnoli wrote: > > any decent implementation does only flush its own LSPs these > > days. Flushing > > other people LSPs has proven to be a bad idea. Absolutely. I wasn't really advocating purging the bad checksum in memory case. My main concern was to emphasis that you shouldn't arbitrarily loose LSPs! >Right. In NLSP we eliminated the "bad checksum purge" when receiving >corrupted LSPs, because a corrupting link (or misbehaving router on the >other end of the link) could bring down a network. We discarded the bad >ones, and alerted the administrator. This is exactly what IS-IS does now. (There's a TC on ISO/IEC 10589 which says this). >The other instance of a network wide purge is receipt of an LSP that has the >same "newness" (same sequence number, same lspid, both non-zero lifetime), >but different checksums. In this case, we included checksum as a part of >the "newer" calculation. LSPs with higher checksums were "newer." This >prevented routers from purging others LSPs, and in the case of two routers >battling over a system ID, it allowed the LSPs to flow back and forth >between the battling routers (both routers complain). > >Is this being done with ISIS implementations? If so, it seems all routers >need to have the same algorithm (what is it?). I know of implementations which do this, but there is nothing which says which is the "right" way to do it (higher or lower checksum). As you say it is critical that all implementations choose the same algorithm. (Well, in fact it is safe for this to co-exist with the "standard" purging). But I'm not sure that this issue is particularly important (as opposed to the bad checksum in a received LSP, which is important, as we have real world evidence to show ) > If not, what is being done >to prevent the purge? > > >> > > even simpler solutions to the problem exist given some > > cooperation from your > > neighbor > > > >Do you know what the simpler solutions are? Care to describe them? Well, something along the lines of draft-shand-isis-restart-00.txt springs to mind! But as Tony says, you can do interesting things with SNPs. >(which begs the question of whether it is even right to try to recover!). > > > -- tony > > > > --Neal From Talmon_Reiss@KereniX.com Thu May 3 16:53:54 2001 From: Talmon_Reiss@KereniX.com (Talmon_Reiss) Date: Thu, 3 May 2001 18:53:54 +0300 Subject: [Isis-wg] Receiving CSNPs in IS-IS Message-ID: <2B15221907365C468941FDFC02C87769323927@EXCHANGE.kerenix.com> Hi If an IS receives an CSNP and there are LESS LSPs listed in it than it has in its own database, is this IS required to send the missing LSPs back on the same circuit? If so, according to what timer? Or is it immediate? Talmon From mbartell@cisco.com Thu May 3 17:30:30 2001 From: mbartell@cisco.com (Micah Bartell) Date: Thu, 03 May 2001 11:30:30 -0500 Subject: [Isis-wg] Receiving CSNPs in IS-IS In-Reply-To: <2B15221907365C468941FDFC02C87769323927@EXCHANGE.kerenix.co m> Message-ID: <4.3.2.7.2.20010503112938.03cbe008@ce-nfs-1.cisco.com> You would set the SRM flags for those LSPs that are missing from the CSNP. The flooding would be when your flooding routine goes through and floods the LSPs with the SRMflag set. /mpb At 18:53 05/03/2001 +0300, Talmon_Reiss wrote: >Hi > >If an IS receives an CSNP and there are LESS LSPs listed in it than it has >in its own database, is this IS required to send the missing LSPs back on >the same circuit? If so, according to what timer? Or is it immediate? > >Talmon > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mongazon@ms.alcatel.fr Thu May 3 17:30:31 2001 From: mongazon@ms.alcatel.fr (Bruno Mongazon) Date: Thu, 03 May 2001 18:30:31 +0200 Subject: [Isis-wg] Receiving CSNPs in IS-IS References: <2B15221907365C468941FDFC02C87769323927@EXCHANGE.kerenix.com> Message-ID: <3AF187A7.FBE10F51@ms.alcatel.fr> Talmon_Reiss wrote: > > Hi > > If an IS receives an CSNP and there are LESS LSPs listed in it than it has > in its own database, is this IS required to send the missing LSPs back on > the same circuit? If so, according to what timer? Or is it immediate? > > Talmon > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg Hi Talmon, I think it works as follows: A CSNP contains the START LSP ID and END LSP ID fields in addition to LSP entries. When an IS receives a CSNP it should scan its database within the range [START LSP ID, END LSP ID]. If no LSP entry is found in the CSNP for an LSP ID in that range, the IS should send the missing LSP back to the transmitter. My understanding is that the transmission of missing LSPs is immediate. My 2 cents. Bruno. From mshand@cisco.com Fri May 4 08:01:04 2001 From: mshand@cisco.com (mike shand) Date: Fri, 04 May 2001 08:01:04 +0100 Subject: [Isis-wg] Receiving CSNPs in IS-IS In-Reply-To: <3AF187A7.FBE10F51@ms.alcatel.fr> References: <2B15221907365C468941FDFC02C87769323927@EXCHANGE.kerenix.com> Message-ID: <4.3.2.7.2.20010504075845.019733f8@jaws.cisco.com> At 18:30 03/05/2001 +0200, Bruno Mongazon wrote: >Talmon_Reiss wrote: > > > > Hi > > > > If an IS receives an CSNP and there are LESS LSPs listed in it than it has > > in its own database, is this IS required to send the missing LSPs back on > > the same circuit? If so, according to what timer? Or is it immediate? > > > > Talmon > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > >Hi Talmon, > >I think it works as follows: > >A CSNP contains the START LSP ID and END LSP ID fields in addition to >LSP entries. >When an IS receives a CSNP it should scan its database within the range >[START LSP ID, END LSP ID]. If no LSP entry is found in the CSNP for an >LSP ID in that range, the IS should send the missing LSP back to the >transmitter. > >My understanding is that the transmission of missing LSPs is immediate. Mihah's description is slightly more accurate. You set SRMflags immediately, but the actual transmission takes place according to the usual transmission rules, including pacing and randomization where appropriate. In particular, if its a LAN and you hear the LSP in question transmitted by someone else before you have actually transmitted it, this would cause your SRMflag for that LSP to be cleared, so you wouldn't transmit it. Mike >My 2 cents. >Bruno. >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From dougm@ieee.org Mon Apr 30 23:44:52 2001 From: dougm@ieee.org (Doug Montgomery) Date: Mon, 30 Apr 2001 18:44:52 -0400 Subject: [Isis-wg] downstream paths? References: <200104301938.PAA11826@bcn.East.Sun.COM> Message-ID: <3AEDEAE4.115750CB@ieee.org> Radia, Of course Dave Oran could do a better job of providing the history, but you have the basic idea. Run Dijkstra routed at each of your immediate neighbors and store forwarding adjacencies for any of them that are closer to the destination than yourself. Provides very aggressive load splitting. A researcher from Denmark (? I can see the fellow's face, his name escapes me) proposed this in the early days of ISO standardization. The rationale at the time involved scenarios in which one was highly BW constrained and needed to get every drop of load splitting possible. I don't think many people other than the author saw the burning need, but on the other hand, after some analysis, it seemed well specified and workable and was added as a second algorithm. I have never seen an implementation of it. dougm Radia Perlman - Boston Center for Networking wrote: > > OK. Reading Jeff Parker's reply I now understand, but perhaps > it's worth having a 2nd person explain it. > > I didn't remember this from IS-IS at all (I assume > it got put in by ISO and wasn't in the original DECnet > Phase V routing algorithm), but apparently (based on > the section quoted by Jeff) you're > allowed to forward a packet destined to D to neighbor N even if > N isn't on a minimal path from you to D, but instead neighbor N > is closer to D than you are. In other words, you have a path through > neighbor N1 to D that is of cost 50, and that's your best path. > Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > If you forward through N your path will be 53, clearly worse than > your path through N1, but since N is closer to D than you (N is > 48 away, you're 50 away), you're allowed to forward to N. > > A neighbor closer to D than you is "downstream". So N (as well as N1) > would be downstream. > > The normal Dijkstra calculation wouldn't tell you all neighbors closer > to D than you. The only way to get this is to calculate Dijkstra > from the point of view of each neighbor. That's why, if you have k > neighbors, you'd have to calculate Dijkstra from your own point of > view, plus from the point of view of each neighbor (to find out, for > each destination, which of your neighbors is closer to the destination > than you are). > > And with multiple metrics, you'd have to multiply the number of Dijkstra > calculations by the number of metrics (I never did like the multiple > metric thing, especially the way ISO specified it...that you leave out > links that don't advertise that metric so you're calculating an "optimal" > path based on a subset of the links!). > > So that explains why the section you quoted says if there are 4 > metrics, and you want to "calculate downstream paths) i.e., find out > which neighbors are closer than you for each destination), you > "would execute the algorithm 4 * (number of neighbours +1) times" > > I always thought the multiple metrics were not worth the extra > calculation and configuration (and were actually quite dangerous > given how ISO specified it since it's very nonintuitive why you > might get really horrible routes if you use any metric that isn't > universally supported on every link). I'd think this "calculating > downstream paths" would also not be worth the extra computation > and storage. Does any IS-IS implementation bother with this > "downstream paths" thing? > > Radia > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- +-----------------------------------------------------------------------------+ | Doug Montgomery Manager, Internetworking Technologies Group | | National Institute of Standards and Technology Email: dougm@nist.gov | | Building 820, Room 457 Voice: +1-301-975-3630 | | 820 West Diamond Avenue Fax: +1-301-590-0932 | | Gaithersburg, MD 20899 USA WWW: http://www.antd.nist.gov/itg/ | +-----------------------------------------------------------------------------+ From Talmon_Reiss@KereniX.com Wed May 9 13:30:09 2001 From: Talmon_Reiss@KereniX.com (Talmon_Reiss) Date: Wed, 9 May 2001 15:30:09 +0300 Subject: [Isis-wg] Adjacencies and LSP Numbers Message-ID: <2B15221907365C468941FDFC02C87769323941@EXCHANGE.kerenix.com> Hi In 10589, 7.3.4.4, it says "Once a particular adjacency has been assigned to a particular LSP Number, it is desirable that it not be moved to another LSP Number." As I understood it, the LSP Number was supposd to be used when a LS PDU was too large to fit in a single LSP (the LSP Number 0 then has a special significance wrt to the DB overload bit etc). Could someone please clarify this concept of the link between an an adjacency and a LSP Number? Thanks Talmon From mshand@cisco.com Wed May 9 13:47:46 2001 From: mshand@cisco.com (mike shand) Date: Wed, 09 May 2001 13:47:46 +0100 Subject: [Isis-wg] Adjacencies and LSP Numbers In-Reply-To: <2B15221907365C468941FDFC02C87769323941@EXCHANGE.kerenix.co m> Message-ID: <4.3.2.7.2.20010509134442.01e571b8@jaws.cisco.com> At 15:30 09/05/2001 +0300, Talmon_Reiss wrote: >Hi > >In 10589, 7.3.4.4, it says "Once a particular adjacency has been assigned to >a particular LSP Number, it is desirable that it not be moved to another LSP >Number." > >As I understood it, the LSP Number was supposd to be used when a LS PDU was >too large to fit in a single LSP (the LSP Number 0 then has a special >significance wrt to the DB overload bit etc). Correct >Could someone please clarify this concept of the link between an an >adjacency and a LSP Number? The point is that if you move an adjacency between one LSP and another, there are race conditions which can result in momentary loss of information. SO, for example if the new LSP without the adjacency propagates before the new LSP with the adjacency, then SPF may run and compute the topology without the link, then an SPF hold-down prevents SPF from being run again, so the new LSP doesn't get taken account of. So it is DESIRABLE not to arbitrarily move a link from one LSP to another. Mike >Thanks >Talmon > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Wed May 9 14:32:57 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 09 May 2001 09:32:57 -0400 Subject: [Isis-wg] Adjacencies and LSP Numbers In-Reply-To: <2B15221907365C468941FDFC02C87769323941@EXCHANGE.kerenix.co m> Message-ID: <4.3.2.7.2.20010509092915.04ceb130@dingdong.cisco.com> At 08:30 AM 5/9/2001, Talmon_Reiss wrote: >Hi > >In 10589, 7.3.4.4, it says "Once a particular adjacency has been assigned to >a particular LSP Number, it is desirable that it not be moved to another LSP >Number." > >As I understood it, the LSP Number was supposd to be used when a LS PDU was >too large to fit in a single LSP (the LSP Number 0 then has a special >significance wrt to the DB overload bit etc). You are correct. However, once an adjacency is assigned to an LSP fragment, it is "polite" to try to leave it in that same fragment. This avoids route flaps that can happen just because a link moved from one fragment to another, and a router receiving these LSPs gets the new LSP fragment without the link first and runs SPF -- only to receive the next new fragment where the link is up. >Could someone please clarify this concept of the link between an an >adjacency and a LSP Number? > >Thanks >Talmon > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Yu.Ju@marconi.com Thu May 10 15:52:03 2001 From: Yu.Ju@marconi.com (Ju, Yu) Date: Thu, 10 May 2001 10:52:03 -0400 Subject: [Isis-wg] IP reachability information and IP interface address Message-ID: <39469E08BD83D411A3D900204840EC5537DCA7@vie-msgusr-01.dc.fore.com> Hi, I have the following question regarding rfc1195.txt. 1). Suppose L1 A and L1 B are directly connected as the following. x and y are IP interface addresses on A and B respectively. -------- x y --------- | A |-----------------------------| B | --------- -------- x will be in the IP interface address field of A's L1 LSP. y will be in IP interface address field of B's L1 LSP. These information is enough for other IS in the area to calculate route to x and y. Then does A have to put y in the IP internal reachability information field of its L1 LSP? The same question for B. 2) Why L1 LSP can not have IP external reachability information? Thanks, Yu From jlearman@cisco.com Thu May 10 16:19:15 2001 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 10 May 2001 11:19:15 -0400 Subject: [Isis-wg] IP reachability information and IP interface address In-Reply-To: <39469E08BD83D411A3D900204840EC5537DCA7@vie-msgusr-01.dc.fo re.com> Message-ID: <4.3.2.7.2.20010510111123.01a1ef20@dingdong.cisco.com> At 10:52 AM 5/10/2001, Ju, Yu wrote: >Hi, > >I have the following question regarding rfc1195.txt. > >1). Suppose L1 A and L1 B are directly connected as the following. x and y >are IP interface addresses on A and B respectively. > > > -------- x y --------- > | A |-----------------------------| B | > --------- -------- > > x will be in the IP interface address field of A's L1 LSP. y will be >in IP interface address field of B's L1 LSP. These information is enough for >other IS in the area to calculate route to x and y. Then does A have to put >y in the IP internal reachability information field of its L1 LSP? The same >question for B. This is enough information to calculate the routes ONLY if these routers are actually connected. There are too many situations where these routers might not actually be connected (e.g., switch failure). Routes must be known to be available by IIH handshake in order to use them for transit routing. >2) Why L1 LSP can not have IP external reachability information? IS-IS is a hierarchical system to reduce the amount of information that an L1 router needs to know to do its job. If the rules were changed to permit L1 routers to perform L2 functions (i.e., forwarding L2 traffic anywhere but to the nearest L2 router), this would obliterate the hierarchical distinction and would be a fairly radical change to IS-IS. >Thanks, > >Yu > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Ravindra.Sunkad@marconi.com Thu May 10 16:26:40 2001 From: Ravindra.Sunkad@marconi.com (Sunkad, Ravindra) Date: Thu, 10 May 2001 11:26:40 -0400 Subject: [Isis-wg] IP reachability information and IP interface addres s Message-ID: <39469E08BD83D411A3D900204840EC5531DC8E@vie-msgusr-01.dc.fore.com> > >2) Why L1 LSP can not have IP external reachability information? > > IS-IS is a hierarchical system to reduce the amount of information > that an L1 router needs to know to do its job. If the rules were > changed to permit L1 routers to perform L2 functions (i.e., forwarding > L2 traffic anywhere but to the nearest L2 router), this would > obliterate the hierarchical distinction and would be a fairly > radical change to IS-IS. > First paragraph in section 2.2 of RFC-2966 removes this restriction. Ravi From myeung@procket.com Tue May 15 03:37:48 2001 From: myeung@procket.com (Derek Yeung) Date: Mon, 14 May 2001 19:37:48 -0700 Subject: [Isis-wg] Optional Checksum in ISIS Message-ID: <3B00967C.4AD71D4@procket.com> Hi, What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. Thanks, - Derek From amudha@future.futsoft.com Tue May 15 10:56:28 2001 From: amudha@future.futsoft.com (Amudhavalli Narayanan) Date: Tue, 15 May 2001 15:26:28 +0530 Subject: [Isis-wg] Regarding Area address option in non-pseudo LSPs Message-ID: <000001c0dd25$502a6ce0$0705a8c0@future.futsoft.com> Hi, In section 7.3.5 of ISIS standard it is staes that: The Level 1 Link State PDU not generated on behalf of a pseudonode contains the following information in its variable length fields. - In the Area Addresses option – the set of manualAreaAd-dresses for this Intermediate System. In section 9.7 it states that: For non-pseudonode LSPs this option (Area addresses) shall always be pre- sent in the LSP with LSP number zero, and shall never be present in an LSP with non-zero LSP number. This option shall never be present in pseudonode LSPs. Aren't these statements contradictory or is my understanding wrong? Can anyone please help me out? Thanks and Regards, Amudha From henk@Procket.com Tue May 15 15:06:48 2001 From: henk@Procket.com (Henk Smit) Date: Tue, 15 May 2001 07:06:48 -0700 (PDT) Subject: [Isis-wg] Regarding Area address option in non-pseudo LSPs In-Reply-To: <000001c0dd25$502a6ce0$0705a8c0@future.futsoft.com> from "Amudhavalli Narayanan" at May 15, 2001 03:26:28 PM Message-ID: <200105151406.HAA02691@redcs4.procket.com> > In section 7.3.5 of ISIS standard it is staes that: > > The Level 1 Link State PDU not generated on behalf of a pseudonode "L1 LSP *not* generated on behalf of a pseudonode". So this is clearly about "non-pseudonode LSPs". > contains the following information in its variable length fields. > - In the Area Addresses option – the set of manualAreaAd-dresses > for this Intermediate System. Point made is "non-pseudonode LSPs can hold area-addresses" > In section 9.7 it states that: > For non-pseudonode LSPs this option (Area addresses) shall always be pre- > sent in the LSP with LSP number zero, and shall never be present in an LSP > with non-zero LSP number. Clearly about "non-pseudonode LSPs". Point made is "non-pseudonode LSPs can hold area-addresses" > This option shall never be present in pseudonode LSPs. Clearly about "pseudonode LSPs". Point made is "pseudonode LSPs can *not* hold area-addresses" > Aren't these statements contradictory or is my understanding wrong? Can > anyone please help me out? Mmmm, I see no contradiction ? henk. From larmer@commsense.net Tue May 15 18:16:28 2001 From: larmer@commsense.net (Larmer) Date: Tue, 15 May 2001 13:16:28 -0400 Subject: [Isis-wg] Host addresses in the L2 LSP IP Internal Reachability Information TLV Message-ID: Hi, I was wondering if anyone knows why Cisco includes the neighbour's IP interface address (host address) for a Point-to-Point interface in its L2 LSP IP Internal Reachability Information TLV? Cheers, Ken Larmer CommSense Networks www.commsense.net From sluong@cisco.com Tue May 15 19:08:36 2001 From: sluong@cisco.com (Steven Luong) Date: Tue, 15 May 2001 11:08:36 -0700 Subject: [Isis-wg] Host addresses in the L2 LSP IP Internal Reachability Information TLV References: Message-ID: <3B0170A4.CC899E69@cisco.com> That is called redistribution, from level-1 into level-2, which is automatic. Larmer wrote: > Hi, > > I was wondering if anyone knows why Cisco includes > the neighbour's IP interface address (host address) for a > Point-to-Point interface in its L2 LSP IP Internal > Reachability Information TLV? > > Cheers, > > Ken Larmer > CommSense Networks > www.commsense.net > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- Steven Luong From larmer@commsense.net Tue May 15 19:26:49 2001 From: larmer@commsense.net (Larmer) Date: Tue, 15 May 2001 14:26:49 -0400 Subject: [Isis-wg] Host addresses in the L2 LSP IP Internal Reachability Information TLV In-Reply-To: <3B0170A4.CC899E69@cisco.com> Message-ID: Hi, Thanks Steve, though I don't understand? This IP (host) address does not show up in Level-1 LSPs? Only in L2 LSPs. Besides, we are advertising the IP subnet already, why do we need to advertise the host specific address? And why only on Point-to-Point interfaces? Cheers, Ken -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Steven Luong Sent: Tuesday, May 15, 2001 2:09 PM To: Larmer Cc: Isis-Wg@Juniper. Net Subject: Re: [Isis-wg] Host addresses in the L2 LSP IP Internal Reachability Information TLV That is called redistribution, from level-1 into level-2, which is automatic. Larmer wrote: > Hi, > > I was wondering if anyone knows why Cisco includes > the neighbour's IP interface address (host address) for a > Point-to-Point interface in its L2 LSP IP Internal > Reachability Information TLV? > > Cheers, > > Ken Larmer > CommSense Networks > www.commsense.net > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- Steven Luong _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From Ravindra.Sunkad@marconi.com Tue May 15 23:47:04 2001 From: Ravindra.Sunkad@marconi.com (Sunkad, Ravindra) Date: Tue, 15 May 2001 18:47:04 -0400 Subject: [Isis-wg] Three-way Handshake question Message-ID: <39469E08BD83D411A3D900204840EC5531DCC3@vie-msgusr-01.dc.fore.com> Hi, I have a question related to the Three-Way handshake operation. In the "Point-to-Point Adjacency State" TLV definition of draft-ietf-isis-3way-03, length is defined to be between 5 to 17 octets. However, I have noticed that some implementations have only the "Adjacency State" included in this TLV. i.e. "Extended Local Circuit ID" is not included. What is the expected behavior on receipt of such a IIH PDU? Thanks, Ravi From premal@riverstonenet.com Tue May 15 23:03:02 2001 From: premal@riverstonenet.com (Premal Ashar) Date: Tue, 15 May 2001 15:03:02 -0700 Subject: [Isis-wg] Three-way Handshake question In-Reply-To: <39469E08BD83D411A3D900204840EC5531DCC3@vie-msgusr-01.dc.fore.com> Message-ID: Hi Ravi, I believe that draft-ietf-isis-3way-02 did not have the "Extended Local Circuit ID" support while draft-ietf-isis-3way-03 does have. Hence the implementations based on 02 will not have "Extended Local Circuit ID" support. draft-ietf-isis-3way-03 is backward compatible with draft-ietf-isis-3way-02, so the behavior should not matter. -- Premal Ashar Member of Technical Staff Email: premal@riverstonenet.com Riverstone Networks Tel: (408)878-6515 5200 Great America Parkway FAX: (408)878-6501 Santa Clara, CA 95054 http://www.riverstonenet.com -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Sunkad, Ravindra Sent: Tuesday, May 15, 2001 3:47 PM To: Isis-Wg@Juniper. Net Subject: [Isis-wg] Three-way Handshake question Hi, I have a question related to the Three-Way handshake operation. In the "Point-to-Point Adjacency State" TLV definition of draft-ietf-isis-3way-03, length is defined to be between 5 to 17 octets. However, I have noticed that some implementations have only the "Adjacency State" included in this TLV. i.e. "Extended Local Circuit ID" is not included. What is the expected behavior on receipt of such a IIH PDU? Thanks, Ravi _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From henk@Procket.com Wed May 16 00:24:18 2001 From: henk@Procket.com (Henk Smit) Date: Tue, 15 May 2001 16:24:18 -0700 (PDT) Subject: [Isis-wg] Three-way Handshake question In-Reply-To: <39469E08BD83D411A3D900204840EC5531DCC3@vie-msgusr-01.dc.fore.com> from "Sunkad, Ravindra" at May 15, 2001 06:47:04 PM Message-ID: <200105152324.QAA01998@redcs4.procket.com> > > Hi, > > I have a question related to the Three-Way handshake operation. > > In the "Point-to-Point Adjacency State" TLV definition of > draft-ietf-isis-3way-03, length is defined to be between 5 to 17 octets. > However, I have noticed that some implementations have only the "Adjacency > State" included in this TLV. i.e. "Extended Local Circuit ID" is not > included. > > What is the expected behavior on receipt of such a IIH PDU? Be strict in what you send, be liberal in what you accept. The first version of the 3-way handshake used to have only the "Adjacency State" included. Many years after this had been implemented, the need for more information in the TLV arose. There are still a zillion routers out there that only send and understand the first byte of the TLV. The dominant implementation of those days luckily will ignore any extra bytes in the TLV. So IMHO if you know about this, you should build your implementation in such a way that it will be able to interoperate with these older boxes. Your customers will appreciate it. hope this helps, henk. > Thanks, > Ravi > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From rsaluja@nortelnetworks.com Wed May 16 00:50:28 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Tue, 15 May 2001 19:50:28 -0400 Subject: [Isis-wg] Three-way Handshake question References: Message-ID: <3B01C0C4.F7567185@nortelnetworks.com> This is a multi-part message in MIME format. --------------855F676E1993D3F3671E4929 Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: quoted-printable Ravi, Premal, Extended Local circuit Id has been there in all versions of 3way handshak= e draft. The draft is backward compatible with=A0 the implementation contai= ning only "adjacency state" in the TLV. Thanks, Rajesh =A0 =A0 Premal Ashar wrote: > Hi Ravi, > > I believe that draft-ietf-isis-3way-02 did not have the "Extended Local= > Circuit ID" support while draft-ietf-isis-3way-03 does have. Hence the > implementations based on 02 will not have "Extended Local Circuit ID" > support. draft-ietf-isis-3way-03 is backward compatible with > draft-ietf-isis-3way-02, so the behavior should not matter. > > -- > Premal Ashar > Member of Technical Staff=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Ema= il: premal@riverstonenet.com > Riverstone Networks=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Tel: (408)878-6515 > 5200 Great America Parkway=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: = (408)878-6501 > Santa Clara, CA 95054=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 http://www.riverstonenet.com > > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Sunkad, Ravindra > Sent: Tuesday, May 15, 2001 3:47 PM > To: Isis-Wg@Juniper. Net > Subject: [Isis-wg] Three-way Handshake question > > Hi, > > I have a question related to the Three-Way handshake operation. > > In the "Point-to-Point Adjacency State" TLV definition of > draft-ietf-isis-3way-03, length is defined to be between 5 to 17 octets= =2E > However, I have noticed that some implementations have only the "Adjace= ncy > State" included in this TLV. i.e. "Extended Local Circuit ID" is not > included. > > What is the expected behavior on receipt of such a IIH PDU? > > Thanks, > Ravi > _______________________________________________ > Isis-wg mailing list=A0 -=A0 Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list=A0 -=A0 Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg --------------855F676E1993D3F3671E4929 Content-Type: text/x-vcard; charset=x-user-defined; name="rsaluja~vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Saluja, Rajesh [BL60:424:EXCH] Content-Disposition: attachment; filename="rsaluja~vcf" begin:vcard n:Saluja;Rajesh tel;fax:978 288 4837 tel;work:978 288 7791 x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:rsaluja@baynetworks.com fn:Rajesh Saluja end:vcard --------------855F676E1993D3F3671E4929-- From ginsberg@pluris.com Wed May 16 01:02:22 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Tue, 15 May 2001 17:02:22 -0700 Subject: [Isis-wg] Three-way Handshake question Message-ID: <17C81AD1F1FED411991E006008F6D1CA055F95@avalon.pluris.com> All very true. Which is why it would be "nice" if the current 3way draft were updated to indicate that the TLV has an acceptable form that includes only the adjacency state and that the len could be "1-17" rather than "5-17". Given that the old form of handshake is still in widespread use this is more than a historical issue. Les > > > > > > Hi, > > > > I have a question related to the Three-Way handshake operation. > > > > In the "Point-to-Point Adjacency State" TLV definition of > > draft-ietf-isis-3way-03, length is defined to be between 5 > to 17 octets. > > However, I have noticed that some implementations have only > the "Adjacency > > State" included in this TLV. i.e. "Extended Local Circuit ID" is not > > included. > > > > What is the expected behavior on receipt of such a IIH PDU? > > Be strict in what you send, be liberal in what you accept. > > The first version of the 3-way handshake used to have only > the "Adjacency > State" included. Many years after this had been implemented, > the need for > more information in the TLV arose. There are still a zillion > routers out > there that only send and understand the first byte of the > TLV. The dominant > implementation of those days luckily will ignore any extra > bytes in the TLV. > > So IMHO if you know about this, you should build your > implementation in > such a way that it will be able to interoperate with these > older boxes. > Your customers will appreciate it. > > hope this helps, > > henk. > > > > Thanks, > > Ravi > > _______________________________________________ > > 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 prz@redback.com Wed May 16 07:06:39 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 15 May 2001 23:06:39 -0700 Subject: [Isis-wg] Optional Checksum in ISIS References: <3B00967C.4AD71D4@procket.com> Message-ID: <3B0218EF.A8739945@redback.com> Derek Yeung wrote: > Hi, > What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? > The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. > > Thanks, > - Derek > ________________________________ passed last call and was forwarded to ADs a nice while ago with couple other drafts. There was some serious feet-dragging there and change of ADs just happened as well. I hope to see the RFC out anytime soon ... If you need the draft, I'm sure enough private copies swirl around. Less than ideal, I know. thanks -- tony From Radia Perlman - Boston Center for Networking Tue May 15 16:34:54 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Tue, 15 May 2001 11:34:54 -0400 (EDT) Subject: [Isis-wg] Regarding Area address option in non-pseudo LSPs Message-ID: <200105151534.LAA22318@bcn.East.Sun.COM> Amudha asked: Hi, In section 7.3.5 of ISIS standard it is staes that: The Level 1 Link State PDU not generated on behalf of a pseudonode contains the following information in its variable length fields. - In the Area Addresses option – the set of manualAreaAd-dresses for this Intermediate System. In section 9.7 it states that: For non-pseudonode LSPs this option (Area addresses) shall always be pre- sent in the LSP with LSP number zero, and shall never be present in an LSP with non-zero LSP number. This option shall never be present in pseudonode LSPs. Aren't these statements contradictory or is my understanding wrong? Can anyone please help me out? Thanks and Regards, Amudha Henk replied, and his reply was correct, but I think I can offer a more tutorial explanation. "Pseudonodes" are a way of making a LAN look like a node to the routing algorithm, which makes the database and computation scale better than the alternative, which would be considering all the nodes connected to the LAN to be fully connected, and each reporting links to all the others. So the DR "names" the LAN, and each node on that LAN just reports a single neighbor (that LAN, i.e., the pseudonode). The DR, in addition to the LSP it generates on behalf of itself (the "non-pseudonode LSP), generates an LSP on behalf of the LAN (the "pseudonode LSP"). Sending manual area addresses around in LSPs is a way to ensure that all the routers in the area agree on what the area addresses for that area are. All the routers need to find out what area addresses have been configured into other routers in that area. If area addresses were reported in ALL LSPs (pseudonode and non-pseudonode), then that would just be duplicative info, since the DR would report the same set in both its non-pseudonode LSP and its pseudonode LSP. So the spec says to ONLY report it in non-pseudonode LSPs. Radia From myeung@procket.com Thu May 17 00:03:40 2001 From: myeung@procket.com (Derek Yeung) Date: Wed, 16 May 2001 16:03:40 -0700 Subject: [Isis-wg] Optional Checksum in ISIS References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> Message-ID: <3B03074C.98CB85F3@procket.com> Tony Przygienda wrote: > > Derek Yeung wrote: > > > Hi, > > What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? > > The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. > > > > Thanks, > > - Derek > > ________________________________ > > passed last call and was forwarded to ADs a nice while ago with couple other drafts. > There was some serious feet-dragging there and change of ADs just happened > as well. I hope to see the RFC out anytime soon ... > > If you need the draft, I'm sure enough private copies swirl around. Less than ideal, I know. Any big change between the 01 draft and the final RFC ? If there is no important change, my copy would be good enough. BTW, I have a few questions about the 01 draft. The draft said one cannot rely on authentication as checksum mechanism. Does the draft refer to simple cleartext authentication in particular or any authentication scheme ? IMHO, MD5 authentication alone should be able to detect packet corruption. For example, in OSPF, checksum is not calculated when MD5 authentication is used. The only problem I see is that one cannot tell whether error is due to packet corruption or real authentication failure, but it is probably not a big deal. The draft also said that an implemenation that implements optional checksum MUST accept PDUs which do not contain optional checksum. Given that a checksumed PDU could be corrupted in a way that it appear to contain no optional checksum. Then wouldn't the rule permit corrupted packet to go undetected and defeat the purpose to do checksum in the first place ? Thanks, - Derek > > thanks > > -- tony From prz@redback.com Thu May 17 01:17:26 2001 From: prz@redback.com (Tony Przygienda) Date: Wed, 16 May 2001 17:17:26 -0700 Subject: [Isis-wg] Optional Checksum in ISIS References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> <3B03074C.98CB85F3@procket.com> Message-ID: <3B03187A.D475065E@redback.com> Derek Yeung wrote: > Tony Przygienda wrote: > > > > Derek Yeung wrote: > > > > > Hi, > > > What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? > > > The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. > > > > > > Thanks, > > > - Derek > > > ________________________________ > > > > passed last call and was forwarded to ADs a nice while ago with couple other drafts. > > There was some serious feet-dragging there and change of ADs just happened > > as well. I hope to see the RFC out anytime soon ... > > > > If you need the draft, I'm sure enough private copies swirl around. Less than ideal, I know. > > Any big change between the 01 draft and the final RFC ? If there is no important > change, my copy would be good enough. don't remember what 01 was but the only change that pretty much ever came up was the issue of whehter you calculate csum first or authentication. Nischal caught that when implementing. > BTW, I have a few questions about the 01 draft. > > The draft said one cannot rely on authentication as checksum mechanism. > Does the draft refer to simple cleartext authentication in particular or any authentication > scheme ? IMHO, MD5 authentication alone should be able to detect packet corruption. For example, > in OSPF, checksum is not calculated when MD5 authentication is used. The only problem > I see is that one cannot tell whether error is due to packet corruption or > real authentication failure, but it is probably not a big deal. well, source authentication should imply integrity in security so it's kind of true what you're saying. However, this clear text password is a glaring hole here (it's basically not authentication ;-) So having said that, we could add a sentence or so to the draft saying that if it's clear that authentication verifies integrity of the packet, checksum can be omitted. Read on ... > The draft also said that an implemenation that implements optional checksum MUST > accept PDUs which do not contain optional checksum. Given that a checksumed PDU could > be corrupted in a way that it appear to contain no optional checksum. Then wouldn't the rule > permit corrupted packet to go undetected and defeat the purpose to do checksum in the first place ? very brain-twisted but to a certain extent you're right. However, IMHO it's kind of much more important to not make the assumption that someone MUST put optional checksums on packets (equivalent to saying that you MUST NOT or MAY only accept packets without optional checksums). That would render piles of existing deployment problematic and lead to nasty effects when boxes are misconfigured. Also, that would introduce even more dependencies with the previous point you brought up since you'd have to say e.g. "must accept pdus which do not contain optional checksum if md5 is present". then of course think about the case where the checksum tlv got corrupted so it's not present anymore AND md5 got corrupted to deliver correct verification for that corrupted packet. Worst of all I think saying that "you must not accept packets without optional checksum when you expect it" would prevent in future boxes from being shipped with optional checksums enabled as default which I'd like to see ideally. All that doesn't end and has a 0.00001% of a chance to show up in real networks ;-) To summarize, I'd like to keep MD5 and checksums decoupled for simplicity reasons and only resolve the dependency which one's to be computed/verified first when received so I'd resist either change you brought up. - -tony From rja@inet.org Thu May 17 01:04:09 2001 From: rja@inet.org (RJ Atkinson) Date: Wed, 16 May 2001 20:04:09 -0400 Subject: [Isis-wg] Optional Checksum in ISIS In-Reply-To: <3B03074C.98CB85F3@procket.com> References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> Message-ID: <5.1.0.14.2.20010516200305.00a1dec0@10.30.15.2> At 19:03 16/05/01, Derek Yeung wrote: >IMHO, MD5 authentication alone should be able to detect packet corruption. For example, in OSPF, checksum is not calculated >when MD5 authentication is used. Quite right on both counts. >The only problem I see is that one cannot tell whether error >is due to packet corruption or real authentication failure, >but it is probably not a big deal. Agree. Ran From amudha@future.futsoft.com Thu May 17 08:36:53 2001 From: amudha@future.futsoft.com (Amudhavalli Narayanan) Date: Thu, 17 May 2001 13:06:53 +0530 Subject: [Isis-wg] Regarding manual area address Message-ID: <000401c0dea4$24f9d710$0705a8c0@future.futsoft.com> Hi, Can some one help me in understanding the attached flag? Will it be set for this setup? R1 - L1L2 router in manually configured area a1 R2 - L1L2 router in manually configured areas a1, a2. Will R1 set the attached flag as it can reach a2 via R2? Thanks, Amudha From premal@riverstonenet.com Thu May 17 09:07:16 2001 From: premal@riverstonenet.com (Premal Ashar) Date: Thu, 17 May 2001 01:07:16 -0700 Subject: [Isis-wg] Regarding manual area address In-Reply-To: <000401c0dea4$24f9d710$0705a8c0@future.futsoft.com> Message-ID: Hi Amudha, When ever a L1 router knows about a L2 router it will set the attached flag for it's L1 LSP according to 7.2.9.1 of the 10589 -- Premal Ashar Member of Technical Staff Email: premal@riverstonenet.com Riverstone Networks Tel: (408)878-6515 5200 Great America Parkway FAX: (408)878-6501 Santa Clara, CA 95054 http://www.riverstonenet.com -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Amudhavalli Narayanan Sent: Thursday, May 17, 2001 12:37 AM To: isis-wg@juniper.net Subject: [Isis-wg] Regarding manual area address Hi, Can some one help me in understanding the attached flag? Will it be set for this setup? R1 - L1L2 router in manually configured area a1 R2 - L1L2 router in manually configured areas a1, a2. Will R1 set the attached flag as it can reach a2 via R2? Thanks, Amudha _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From mshand@cisco.com Thu May 17 10:27:59 2001 From: mshand@cisco.com (mike shand) Date: Thu, 17 May 2001 10:27:59 +0100 Subject: [Isis-wg] Regarding manual area address In-Reply-To: References: <000401c0dea4$24f9d710$0705a8c0@future.futsoft.com> Message-ID: <4.3.2.7.2.20010517094333.03555a70@jaws.cisco.com> At 01:07 17/05/2001 -0700, Premal Ashar wrote: >Hi Amudha, > >When ever a L1 router knows about a L2 router it will set the attached flag >for it's L1 LSP according to 7.2.9.1 of the 10589 Errr... not quite. The attached flag is set by a level 2 router in its level 1 LSP to indicate that it can reach other areas. A level 1 (only) router shouldn't be setting the attached bit, and nothing should be setting it just because it "knows about" an L2 router. The critical thing is that it can reach other areas. There are various ways it could know about this involving manual routes, but typically it is because when it runs its L2 SPF calculation it can "reach" one or more areas other than its own. And in the context of the original question, this really does mean other areas, not just other area addresses within the same area. 7.2.9.1 isn't saying anything about this. It is describing what an L1 router does with the attached bit information it sees in LSPs from other L1 routers in the area. It finds the (set of) L2 routers (within the area) which have the attached bit set, and chooses the set (possibly only one) with minimal cost. It then uses this as a "default route" for forwarding any data which is unreachable according to its L1 database. (In the CLNS case, that is if and only if the area address portion of the destination NSAP address does not match any of the local area addresses.) Mike >-- >Premal Ashar >Member of Technical Staff Email: premal@riverstonenet.com >Riverstone Networks Tel: (408)878-6515 >5200 Great America Parkway FAX: (408)878-6501 >Santa Clara, CA 95054 http://www.riverstonenet.com > >-----Original Message----- >From: isis-wg-admin@spider.juniper.net >[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Amudhavalli >Narayanan >Sent: Thursday, May 17, 2001 12:37 AM >To: isis-wg@juniper.net >Subject: [Isis-wg] Regarding manual area address > > >Hi, > >Can some one help me in understanding the attached flag? > >Will it be set for this setup? > >R1 - L1L2 router in manually configured area a1 >R2 - L1L2 router in manually configured areas a1, a2. > >Will R1 set the attached flag as it can reach a2 via R2? > >Thanks, >Amudha > > > > >_______________________________________________ >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 May 17 14:22:00 2001 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 17 May 2001 09:22:00 -0400 Subject: [Isis-wg] Regarding manual area address In-Reply-To: <000401c0dea4$24f9d710$0705a8c0@future.futsoft.com> Message-ID: <4.3.2.7.2.20010517091642.06408ef8@dingdong.cisco.com> Amudha, In your example, you have configured two area addresses for one area. Therefore the attached flag would not be set. Setting multiple area addresses does not place a L2 router in multiple areas, it causes multiple area addresses to be configured for the area. According to the spec, and as far as can be observed by looking at packets, no L2 router is ever in multiple areas. While there may be implementations where one can run the same router in multiple areas, these routers must make it appear to other routers as though it is a collection of routers, each in a different area. Regards, Jeff At 03:36 AM 5/17/2001, Amudhavalli Narayanan wrote: >Hi, > >Can some one help me in understanding the attached flag? > >Will it be set for this setup? > >R1 - L1L2 router in manually configured area a1 >R2 - L1L2 router in manually configured areas a1, a2. > >Will R1 set the attached flag as it can reach a2 via R2? > >Thanks, >Amudha > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From larmer@commsense.net Thu May 17 14:43:34 2001 From: larmer@commsense.net (Larmer) Date: Thu, 17 May 2001 09:43:34 -0400 Subject: [Isis-wg] Regarding manual area address In-Reply-To: <4.3.2.7.2.20010517094333.03555a70@jaws.cisco.com> Message-ID: Hi, There is one other situation, which is not described by ISO-10589 where the attached bit "may" be set, depending upon the implementation. When a vendor implements multiple level-1 IS-IS instances on one IS and you want to get from one instance to another, should you set the attached bit? Well, if you set it, you can indeed get between the instances. Though, this may create problems? As long as you keep the L2 area contiguous, you should still be able to reach all other L1 areas. However, there are situations where you may take an extra hop or two to get to another area. This will happen if the L2 process does not have a direct connection to another L2 area as depicted below? _________________________________ |L2 |L2 ------------ ------------ ------ | | | | | | |L1 L1 L1| |L1 L2|-----------|L2 | ------------ ------------ ------ | | _____|_______|____ | ------- | L1 | ------- Mike??? Cheers, Ken -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of mike shand Sent: Thursday, May 17, 2001 5:28 AM To: premal@riverstonenet.com Cc: amudha@future.futsoft.com; isis-wg@juniper.net Subject: RE: [Isis-wg] Regarding manual area address At 01:07 17/05/2001 -0700, Premal Ashar wrote: >Hi Amudha, > >When ever a L1 router knows about a L2 router it will set the attached flag >for it's L1 LSP according to 7.2.9.1 of the 10589 Errr... not quite. The attached flag is set by a level 2 router in its level 1 LSP to indicate that it can reach other areas. A level 1 (only) router shouldn't be setting the attached bit, and nothing should be setting it just because it "knows about" an L2 router. The critical thing is that it can reach other areas. There are various ways it could know about this involving manual routes, but typically it is because when it runs its L2 SPF calculation it can "reach" one or more areas other than its own. And in the context of the original question, this really does mean other areas, not just other area addresses within the same area. 7.2.9.1 isn't saying anything about this. It is describing what an L1 router does with the attached bit information it sees in LSPs from other L1 routers in the area. It finds the (set of) L2 routers (within the area) which have the attached bit set, and chooses the set (possibly only one) with minimal cost. It then uses this as a "default route" for forwarding any data which is unreachable according to its L1 database. (In the CLNS case, that is if and only if the area address portion of the destination NSAP address does not match any of the local area addresses.) Mike >-- >Premal Ashar >Member of Technical Staff Email: premal@riverstonenet.com >Riverstone Networks Tel: (408)878-6515 >5200 Great America Parkway FAX: (408)878-6501 >Santa Clara, CA 95054 http://www.riverstonenet.com > >-----Original Message----- >From: isis-wg-admin@spider.juniper.net >[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Amudhavalli >Narayanan >Sent: Thursday, May 17, 2001 12:37 AM >To: isis-wg@juniper.net >Subject: [Isis-wg] Regarding manual area address > > >Hi, > >Can some one help me in understanding the attached flag? > >Will it be set for this setup? > >R1 - L1L2 router in manually configured area a1 >R2 - L1L2 router in manually configured areas a1, a2. > >Will R1 set the attached flag as it can reach a2 via R2? > >Thanks, >Amudha > > > > >_______________________________________________ >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 mshand@cisco.com Thu May 17 15:06:26 2001 From: mshand@cisco.com (mike shand) Date: Thu, 17 May 2001 15:06:26 +0100 Subject: [Isis-wg] Regarding manual area address In-Reply-To: References: <4.3.2.7.2.20010517094333.03555a70@jaws.cisco.com> Message-ID: <4.3.2.7.2.20010517145927.035e0c78@jaws.cisco.com> Ken, The attached bit mechanism is actually a very crude indication. The original idea was that your L2 domain should be "well connected", but when it broke you could end up with L2 routers which were isolated from the "core". You didn't want to choose one of these as your "nearest" L2 router, when there might be an "attached" router further away. But there are all sorts of scenarios which are not as black and white as this. Where the domain gets partitioned into a "big" bit and a "small" bit. How do you choose the "big" bit? Count the number of areas you can see? Propagate summary routes of the bits you can see and have multiple "nearest" L2 routers depending on which route contains the destination? etc. etc. Any attempt to solve complex problems with the existing single bit is pretty much doomed to failure. Most implementations have a combination of heuristics and manual settings which let you squeeze a bit more mileage out of this, but you can always come up with a case you can't deal with. Mike At 09:43 17/05/2001 -0400, Larmer wrote: >Hi, > > There is one other situation, which is not described >by ISO-10589 where the attached bit "may" be set, depending >upon the implementation. When a vendor implements multiple >level-1 IS-IS instances on one IS and you want to get from >one instance to another, should you set the attached bit? >Well, if you set it, you can indeed get between the instances. > > Though, this may create problems? As long as you keep >the L2 area contiguous, you should still be able to reach >all other L1 areas. However, there are situations where you >may take an extra hop or two to get to another area. This will >happen if the L2 process does not have a direct connection to >another L2 area as depicted below? > > _________________________________ > |L2 |L2 > ------------ ------------ ------ > | | | | | | > |L1 L1 L1| |L1 L2|-----------|L2 | > ------------ ------------ ------ > | | > _____|_______|____ > | > ------- > | L1 | > ------- > > > Mike??? > >Cheers, >Ken > > > > >-----Original Message----- >From: isis-wg-admin@external.juniper.net >[mailto:isis-wg-admin@external.juniper.net]On Behalf Of mike shand >Sent: Thursday, May 17, 2001 5:28 AM >To: premal@riverstonenet.com >Cc: amudha@future.futsoft.com; isis-wg@juniper.net >Subject: RE: [Isis-wg] Regarding manual area address > > >At 01:07 17/05/2001 -0700, Premal Ashar wrote: > >Hi Amudha, > > > >When ever a L1 router knows about a L2 router it will set the attached flag > >for it's L1 LSP according to 7.2.9.1 of the 10589 > > >Errr... not quite. The attached flag is set by a level 2 router in its >level 1 LSP to indicate that it can reach other areas. A level 1 (only) >router shouldn't be setting the attached bit, and nothing should be setting >it just because it "knows about" an L2 router. The critical thing is that >it can reach other areas. There are various ways it could know about this >involving manual routes, but typically it is because when it runs its L2 >SPF calculation it can "reach" one or more areas other than its own. And in >the context of the original question, this really does mean other areas, >not just other area addresses within the same area. > >7.2.9.1 isn't saying anything about this. It is describing what an L1 >router does with the attached bit information it sees in LSPs from other L1 >routers in the area. It finds the (set of) L2 routers (within the area) >which have the attached bit set, and chooses the set (possibly only one) >with minimal cost. It then uses this as a "default route" for forwarding >any data which is unreachable according to its L1 database. (In the CLNS >case, that is if and only if the area address portion of the destination >NSAP address does not match any of the local area addresses.) > > Mike > > > > >-- > >Premal Ashar > >Member of Technical Staff Email: premal@riverstonenet.com > >Riverstone Networks Tel: (408)878-6515 > >5200 Great America Parkway FAX: (408)878-6501 > >Santa Clara, CA 95054 http://www.riverstonenet.com > > > >-----Original Message----- > >From: isis-wg-admin@spider.juniper.net > >[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Amudhavalli > >Narayanan > >Sent: Thursday, May 17, 2001 12:37 AM > >To: isis-wg@juniper.net > >Subject: [Isis-wg] Regarding manual area address > > > > > >Hi, > > > >Can some one help me in understanding the attached flag? > > > >Will it be set for this setup? > > > >R1 - L1L2 router in manually configured area a1 > >R2 - L1L2 router in manually configured areas a1, a2. > > > >Will R1 set the attached flag as it can reach a2 via R2? > > > >Thanks, > >Amudha > > > > > > > > > >_______________________________________________ > >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 selvarajr@www.com Thu May 17 10:17:52 2001 From: selvarajr@www.com (R Selvaraj) Date: Thu, 17 May 2001 02:17:52 -0700 Subject: [Isis-wg] ISIS over tunnel Message-ID: <200105170917.CAA20009@mail16.bigmailbox.com> Hi, It will be helpful if any of u could let me know any Standards/RFC/Drafts for ISIS over tunnel. I think some ISIS implementation sends PPP IIH over tunnel. So, shall ISIS over tunnel be considered same as ISIS over PPP. Or do have any special consideration ? Pls let me know. Thanks, Selva. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From chopps@nexthop.com Fri May 18 01:15:15 2001 From: chopps@nexthop.com (Christian E . Hopps) Date: Thu, 17 May 2001 20:15:15 -0400 Subject: [Isis-wg] ISIS over tunnel In-Reply-To: <200105170917.CAA20009@mail16.bigmailbox.com>; from selvarajr@www.com on Thu, May 17, 2001 at 02:17:52AM -0700 References: <200105170917.CAA20009@mail16.bigmailbox.com> Message-ID: <20010517201515.V3146@nexthop.com> On Thu, May 17, 2001 at 02:17:52AM -0700, R Selvaraj wrote: > Hi, > It will be helpful if any of u could let me know any Standards/RFC/Drafts for ISIS over tunnel. I think some ISIS implementation sends PPP IIH over tunnel. So, shall ISIS over tunnel be considered same as ISIS over PPP. Or do have any special consideration ? > Pls let me know. You can use EON (ISO in IP) tunnels. I'm not sure if they are standardized anywhere, but I modified NetBSD's gif tunnels to support EON encapsulation if you want a code reference. The code interoperates with at least one popular (:) router vendor. Chris. From myeung@procket.com Fri May 18 06:46:58 2001 From: myeung@procket.com (Derek Yeung) Date: Thu, 17 May 2001 22:46:58 -0700 Subject: [Isis-wg] Optional Checksum in ISIS References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> <3B03074C.98CB85F3@procket.com> <3B03187A.D475065E@redback.com> Message-ID: <3B04B752.3C88F133@procket.com> Tony Przygienda wrote: > > Derek Yeung wrote: > > > Tony Przygienda wrote: > > > > > > Derek Yeung wrote: > > > > > > > Hi, > > > > What's the status of draft-ietf-isis-wg-snp-checksum-01.txt ? > > > > The copy I have expired Oct 2000 and I cannot find a newer version on the IETF web. > > > > > > > > Thanks, > > > > - Derek > > > > ________________________________ > > > > > > passed last call and was forwarded to ADs a nice while ago with couple other drafts. > > > There was some serious feet-dragging there and change of ADs just happened > > > as well. I hope to see the RFC out anytime soon ... > > > > > > If you need the draft, I'm sure enough private copies swirl around. Less than ideal, I know. > > > > Any big change between the 01 draft and the final RFC ? If there is no important > > change, my copy would be good enough. > > don't remember what 01 was but the only change that pretty much ever came up was the issue > of whehter you calculate csum first or authentication. Nischal caught that when implementing. > > > BTW, I have a few questions about the 01 draft. > > > > The draft said one cannot rely on authentication as checksum mechanism. > > Does the draft refer to simple cleartext authentication in particular or any authentication > > scheme ? IMHO, MD5 authentication alone should be able to detect packet corruption. For example, > > in OSPF, checksum is not calculated when MD5 authentication is used. The only problem > > I see is that one cannot tell whether error is due to packet corruption or > > real authentication failure, but it is probably not a big deal. > > well, source authentication should imply integrity in security so it's kind of true what you're > saying. > However, this clear text password is a glaring hole here (it's basically not authentication ;-) > So having said that, we could add a sentence or so to the draft saying that if it's clear that > authentication verifies integrity of the packet, checksum can be omitted. Read on ... > > > The draft also said that an implemenation that implements optional checksum MUST > > accept PDUs which do not contain optional checksum. Given that a checksumed PDU could > > be corrupted in a way that it appear to contain no optional checksum. Then wouldn't the rule > > permit corrupted packet to go undetected and defeat the purpose to do checksum in the first place ? > > very brain-twisted but to a certain extent you're right. However, IMHO it's kind of much more > important to not Not brain-twisted at all, I found it pretty obvious ;-) > make the assumption that someone MUST put optional checksums on packets (equivalent to > saying that you MUST NOT or MAY only accept packets without optional checksums). That > would render piles of existing deployment problematic and lead to nasty effects when > boxes are misconfigured. Also, that would introduce even more dependencies with the previous point > you brought up since you'd have to say > e.g. "must accept pdus which do not contain optional checksum if md5 is present". then of course > think about the case where the checksum tlv got corrupted so it's not present anymore AND > md5 got corrupted to deliver correct verification for that corrupted packet. Worst of all I think > saying that "you must not accept packets without optional checksum when you expect it" would > prevent in future boxes from being shipped with optional checksums enabled as default which I'd like > to see ideally. All that doesn't end and has a 0.00001% of a chance > to show up in real networks ;-) IHMO, "you must not accept packets without optional checksum when you expect it" is the right thing to do. Just a different opinion, no big deal. > > To summarize, I'd like to keep MD5 and checksums decoupled for simplicity reasons > and only resolve the dependency which > one's to be computed/verified first when received so I'd resist either change you brought up. > > - -tony I am not proposing to couple MD5 and checksum in the same draft. My point is just that if MD5 authentication has been implemented already, there is no significant technical reason to implement optional checksum too. Thanks, - Derek From selvarajr@www.com Fri May 18 06:59:02 2001 From: selvarajr@www.com (R Selvaraj) Date: Thu, 17 May 2001 22:59:02 -0700 Subject: [Isis-wg] ISIS over tunnel Message-ID: <200105180559.WAA15044@mail4.bigmailbox.com> Hi, I would like to know the procedure for implementing ISIS over GRE tunnel. I'm basically looking for some document/URL in that regard. Pls let me know. Thanks, Selva. >From: "Christian E . Hopps" >To: R Selvaraj >Cc: isis-wg@juniper.net >SUBJECTDate: Thu, 17 May 2001 20:15:15 -0400 > >On Thu, May 17, 2001 at 02:17:52AM -0700, R Selvaraj wrote: >> Hi, >> It will be helpful if any of u could let me know any Standards/RFC/Drafts for ISIS over tunnel. I think some ISIS implementation sends PPP IIH over tunnel. So, shall ISIS over tunnel be considered same as ISIS over PPP. Or do have any special consideration ? >> Pls let me know. > >You can use EON (ISO in IP) tunnels. I'm not sure if they are standardized >anywhere, but I modified NetBSD's gif tunnels to support EON encapsulation >if you want a code reference. The code interoperates with at least one >popular (:) router vendor. > >Chris. >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From prz@redback.com Sat May 19 06:39:57 2001 From: prz@redback.com (Tony Przygienda) Date: Fri, 18 May 2001 22:39:57 -0700 Subject: [Isis-wg] Optional Checksum in ISIS References: <3B00967C.4AD71D4@procket.com> <3B0218EF.A8739945@redback.com> <3B03074C.98CB85F3@procket.com> <3B03187A.D475065E@redback.com> <3B04B752.3C88F133@procket.com> Message-ID: <3B06072D.4B67F874@redback.com> Derek Yeung wrote: > > > The draft also said that an implemenation that implements optional checksum MUST > > > accept PDUs which do not contain optional checksum. Given that a checksumed PDU could > > > be corrupted in a way that it appear to contain no optional checksum. Then wouldn't the rule > > > permit corrupted packet to go undetected and defeat the purpose to do checksum in the first place ? > > > > very brain-twisted but to a certain extent you're right. However, IMHO it's kind of much more > > important to not > > Not brain-twisted at all, I found it pretty obvious ;-) ok > > prevent in future boxes from being shipped with optional checksums enabled as default which I'd like > > to see ideally. All that doesn't end and has a 0.00001% of a chance > > to show up in real networks ;-) > > IHMO, "you must not accept packets without optional checksum when you expect it" is the > right thing to do. Just a different opinion, no big deal. ok, agreed to disagree here .... maybe more people will comment. > > and only resolve the dependency which > > one's to be computed/verified first when received so I'd resist either change you brought up. > I am not proposing to couple MD5 and checksum in the same draft. well, if we start to put in the draft all kind of sentences as of what to do conditionally if either MD5 is present or not, we'll end up coupling those issues together. > My point is just that > if MD5 authentication has been implemented already, there is no significant technical reason > to implement optional checksum too. agree technically, observe that with the way the draft is stated you are free to ignore CSUMs if MD5 is configured and omit them in your packets. Things will still work. So in a sense there is no need to specifically state that you HAVE TO omit them. thanks -=-= tony From selvarajr@www.com Mon May 21 09:36:12 2001 From: selvarajr@www.com (R Selvaraj) Date: Mon, 21 May 2001 01:36:12 -0700 Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV Message-ID: <200105210836.BAA30169@mail11.bigmailbox.com> Hi, Section 5.3.4 of RFC 1195 states that IP addresses within the routing domain reachable directly via one or more interfaces on the router should be encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, do we need to consider circuit level also. I mean, a L12 router while encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all of its L1 circit's IP address and should not consider its L2 circuit's IP address at all. I found some implementation, for L12 router, not encodeing L2 circuit's IP address in its L1 LSP's IP Internal Reach TLV. It'll be helpful if I get clarified. Thanks, Selva. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From amir@cwnt.com Mon May 21 16:34:27 2001 From: amir@cwnt.com (Amir H.) Date: Mon, 21 May 2001 18:34:27 +0300 Subject: [Isis-wg] draft-hermelin-ext-lsp-frags-01.txt Message-ID: <059c01c0e20b$857c5710$6102a8c0@cwnt.com> This is a multi-part message in MIME format. ------=_NextPart_000_0599_01C0E224.AA9ED590 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Hi, a new version of the LSP fragments draft has been submitted. Please take a moment to examine it, and reply with your thoughts. Editorial comments should be sent to me, please. General comments to the list. Main things that were changed were editorial and clarifications. Thanks, Amir Hermelin mailto:amir@cwnt.com Charlotte's Web Networks LTD. http://www.cwnt.com Abstract This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. The document describes behaviors that are backwards compatible with ISIS implementations that do not support this feature. These behaviors are specified in a way that allows previous implementations to correctly process the extended fragment information. ------=_NextPart_000_0599_01C0E224.AA9ED590 Content-Type: text/plain; name="draft-hermelin-ext-lsp-frags-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-hermelin-ext-lsp-frags-01.txt" Network Working Group Amir Hermelin Internet Draft Charlotte's Web Networks, Inc. Expiration Date: November 2001 Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit draft-hermelin-ext-lsp-frags-01.txt Status 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. Abstract This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. The document describes behaviors that are backwards compatible with ISIS implementations that do not support this feature. These behaviors are specified in a way that allows previous implementations to correctly process the extended fragment information. A. Hermelin Expires November 2001 [Page 1] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 1. Introduction In the IS-IS protocol, a system floods its link-state information in Link State Protocol Data Units, or LSPs for short. These logical LSPs can become quite large, therefore the protocol specifies a means of fragmenting this information into multiple LSP fragments. The number of fragments a system can generate is limited by ISO 10589 [1] to 256 fragments, where each fragment's size is also limited. Hence, there is a limit on the amount of link-state information a system can generate. A number of factors can contribute to exceeding this limit: - Introduction of new TLVs and sub-TLVs to be included in LSPs. - The use of LSPs to propagate various types of information (such as traffic-engineering information). - The growing size of route tables and AS topologies. This document describes a mechanism to relax the limit on the number of LSP fragments, while providing behavior that would allow previous implementations to correctly process fragments exceeding this limit. 1.1 Definitions of Commonly Used Terms This section provides definitions for terms that are used throughout the text. Originating System A router running the IS-IS protocol. Original system-id The system-id of an originating system. Extended system-id An additional system-id that is assigned by the network administrator. Each extended system-id allows generation of 256 additional, or extended, LSP fragments. The extended system-id, like the original system-id, must be unique throughout the routing domain. Virtual System The system, identified by an extended system-id, advertised as originating the extended LSP fragments. These fragments specify the extended system-id in their LSP IDs. Original LSP An LSP using the original system-id in its LSP ID. A. Hermelin Expires November 2001 [Page 2] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 Extended LSP An LSP using an extended system-id in its LSP ID. LSP set A group of LSP fragments constituting a logical LSP. These share a specific system-id and pseudonode number, and differ only in their LSP (or fragment) Number. Extended LSP set A group of LSP fragments using an extended system-id, and originated by the originating system. These fragments appear to other routers as having been originated by the virtual system identified by an extended system-id. 1.2 Overview Using additional system-ids assigned to the originating system, that system can advertise the excess link-state information in extended LSPs under these extended system-ids. It would do so as if other routers, or "virtual systems", were advertising this information. These extended LSPs will also have the specified limit on their LSP fragments; however, the originating system may generate extended LSPs under numerous virtual systems. The originating system will not advertise its extended system-ids to any of its neighbors; it will always use its original system-id in IS Hellos [3] and IS-IS Hellos. As a result, no adjacencies will be formed with other systems using extended system-ids, and the originating system would be the only one advertising adjacencies to its extended system-ids, as described below. The originating system must include connectivity information in its original LSPs (the LSPs with the original system-id in their LSP ID) to all virtual systems for which extended LSPs are generated by it. This is to ensure other routers correctly process the extra information in their SPF calculation. The metric for these connections should be zero, since the cost of reaching a virtual system is the same as the cost of reaching its originating system. To other routers, virtual systems would appear reachable only through their originating system, hence loss of connectivity to the originating system means loss of connectivity to all of its information, including that advertised in its extended LSPs. Furthermore, the cost of reaching information advertised in non- extended LSPs is the same as the cost of reaching information advertised in the new extended LSPs, with an additional hop. A. Hermelin Expires November 2001 [Page 3] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 +---------------------------------------------+ | Originating System | | system-id =3D S | | ( extended system-ids =3D S', S'' ) | +---------------------------------------------+ | /\ | /\ cost=3D0 | |cost=3Dmax cost=3D0 | |cost=3Dmax | | | | \/ | \/ | +------------------+ +------------------+ | Virtual System | | Virtual System | | system-id =3D S' | | system-id =3D S'' | +------------------+ +------------------+ Figure 1. Advertising connections to virtual systems The generation of extended LSPs is discussed in section 2. Not all link-state information that can be advertised in the original LSPs can be advertised in extended LSPs; this is discussed in further detail in section 3. However, most "leaf" information, i.e. information that serves only as leaves in a shortest path tree, can be advertised in extended LSPs. Other routers exhibit the same behavior for this information as for information advertised in the original LSPs, with a few minor exceptions noted in section 5. Extended LSPs can be purged, in the same manner as original LSPs. This is discussed in section 4. 2. Generating Extended LSP Fragments When new extended LSP fragments are generated, these fragments should be generated as specified in ISO 10589 [1]. Furthermore, a system will treat its extended LSPs the same as it treats its original LSPs, with the exceptions noted in section 3. Specifically, creating, flooding, renewing, purging and all other operations are similar for both original and extended LSPs, unless stated otherwise. The extended LSPs will use one of the extended system-ids configured for the router, in their LSP ID. An extended LSP Number zero should be generated for every extended LSP set, to allow a router's SPF calculation to consider those fragments in that set. Additionally, when an extended LSP belonging to extended system-id S' is first created, the original LSP must specify S' as a neighbor, with metric set to zero. This is to ensure other routers will consider the extended LSP in their SPF A. Hermelin Expires November 2001 [Page 4] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 calculations, as well as consider the cost of reaching the virtual system S' the same as the cost of reaching its originating system. Furthermore, the extended LSP must specify the original system-id as a neighbor, with metric set to MaxLinkMetric. Where relevant, this adjacency should be considered as point-to-point. Note, that the restriction specified in ISO 10589 section 7.2.5 holds: if an LSP Number zero of the originating system is not present, none of that system's neighbor entries would be processed during SPF, hence none of its extended LSPs would be processed as well. Extended LSPs with number zero will be regarded in the same special manner as specified in 10589 for LSPs with number zero, and will include the same type of extra information as specified in 10589 and RFC 1195 [2]. So, for example, when a system reissues its LSP Number zero due to an area address change, it should reissue all extended LSPs with number zero as well. 3. Exceptions when Encoding Extended LSP Fragments 3.1 The LSP Header The LSP header of an extended LSP fragment should include the same settings as for non-extended LSP fragments with the exceptions noted below: 3.1.1 The Pseudonode ID The Pseudonode ID, which is part of the LSP ID, should be set to zero on all extended LSP fragments. 3.1.2 The Attached Bits The Attached (ATT) bits should be set to zero for all four metric types, on all extended LSPs. This is for two main reasons: - If a virtual system is reachable, so is its originating system. It is preferable, then, that an L1 IS chooses the originating system and not the virtual system as its nearest L2 exit point, as connectivity to the virtual system has a higher probability of being lost (a result of the extended LSP no longer being advertised). This could cause unnecessary processing on some implementations. - Some implementations which support weighted multipath, might set A. Hermelin Expires November 2001 [Page 5] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 multipath weights according to the number of ISs that can be reached via each path. So, for example, if there are two nearest L2 ISs to a particular L1-only system, each reachable via different interfaces, and one is generating an extended LSP, then the L1 system might forward more traffic towards that destination (i.e. give it a stronger weight), as it would think it is forwarding traffic towards two L2 ISs. 3.1.3 The Partition Repair Bit The Partition Repair (P) bit should be set to zero on all extended LSPs. This is for the same reasons as for the Attached bits. 3.2 TLVs Extended LSPs can contain any TLVs that original LSPs can contain, with the exceptions noted below. 3.2.1 IS Neighbors TLV An Extended LSP must specify only the originating system as a neighbor, with the metric set to MaxLinkMetric. No other neighbors may be specified in an Extended LSP, as this would not satisfy the bi-directionality check in the SPF calculation. Where relevant, this adjacency should be considered as point-to-point. 3.2.2 ES Neighbors TLV ISO 10589 [1] section 7.3.7 specifies inserting an ES Neighbor TLV in L1 LSPs, with the system ID of the router. RFC 1195 [2] relieves IP- only routers of this requirement. However, for routers that do insert this ESN TLV in L1 LSPs (whether IP-only or OSI-capable), then in an extended LSP, the relevant extended system-id should be used. Furthermore, OSI-capable routers should accept packets destined for this extended system-id. 4. Purging Extended LSP Fragments ISO 10589 [1] section 7.3.4.4 note 21 suggests that an implementation keeps the number of LSP fragments within a certain limit based on the optimal (minimal) number of fragments needed. Section 7.3.4.6 also recommends that an IS purge its empty LSPs to conserve resources. A. Hermelin Expires November 2001 [Page 6] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 These recommendations hold for the extended LSP fragments as well. However, an extended LSP Number zero should not be purged until all of the fragments in its set (i.e. belonging to a particular virtual system-id), are empty as well. This is to ensure implementations consider the fragments in their SPF calculations, as specified in section 7.2.5. When all the extended LSP fragments of a particular extended system- id S' have been purged, the originating system should remove the adjacency information to S' from its original LSPs. 5. Compatibility Issues Previous implementations will interpret TLVs in extended LSPs in the same manner that they interpret TLVs in original LSPs, due to the zero metric adjacencies from the originating system to its virtual systems. However, applications that take hop count into consideration, will misinterpret the destinations appearing in extended LSPs as being one hop further than they really are. This is due to the extra neighbor hop needed to reach these LSPs. There are two solutions to this problem: - Add extra information to specify that an adjacency should not be considered for any purpose of hop counting. - Restrict information that might be subject to hop counting, such as traffic engineering information, to appear only in the original LSPs. These restrictions should be applied with care, as too many of them could re-introduce the problem of limited LSP fragments. 6. Security Considerations This document raises no new security issues for IS-IS. 7. Acknowledgments The author would like to thank Tony Li, Radia Perlman, and Mike Shand for helpful ideas and suggestions on the subject. 8. References [1] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the A. Hermelin Expires November 2001 [Page 7] =0C Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 Protocol for Providing the Connectionless-mode Network Service (ISO 8473)" [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 [3] ISO 9542, "End System to Intermediate System Routeing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service (ISO 8473)", March 1988 9. Author's Address Amir Hermelin Charlotte's Web Networks, Inc. 2 Hamada St. Yokneam Moshava, 26000 ISRAEL Email: amir@cwnt.com Phone: +972 4 9592203 Fax: +972 4 9593325 A. Hermelin Expires November 2001 [Page 8] =0C ------=_NextPart_000_0599_01C0E224.AA9ED590-- From sluong@cisco.com Tue May 22 20:59:18 2001 From: sluong@cisco.com (Steven Luong) Date: Tue, 22 May 2001 12:59:18 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac References: <200102272326.SAA20260@bcn.East.Sun.COM> Message-ID: <3B0AC516.FC7F6250@cisco.com> What is the latest status of the subject draft? I can't find it anymore in the ietf web site. From prz@redback.com Tue May 22 20:59:02 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 22 May 2001 12:59:02 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac References: <200102272326.SAA20260@bcn.East.Sun.COM> <3B0AC516.FC7F6250@cisco.com> Message-ID: <3B0AC4E9.BE988B06@redback.com> Steven Luong wrote: > What is the latest status of the subject draft? I can't find it anymore in the ietf web > site. check with rja, pls. Last time we talked he was supposed to update it and put it out thanks -- tony From selvarajr@www.com Wed May 23 08:43:04 2001 From: selvarajr@www.com (R Selvaraj) Date: Wed, 23 May 2001 00:43:04 -0700 Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV Message-ID: <200105230743.AAA20691@mail14.bigmailbox.com> Hi, Let me resend my last doubt. Actually, I would like to know wheather a L12 router shall include its local L2 circits IP adress in its L1 LSP's Internal Reach TLV and vice versa for its L2 LSP. Thanks, Selva. >From: "R Selvaraj" >To: isis-wg@juniper.net >SUBJECTDate: Mon, 21 May 2001 01:36:12 -0700 > >Hi, >Section 5.3.4 of RFC 1195 states that IP addresses within the routing domain reachable directly via one or more interfaces on the router should be encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, do we need to consider circuit level also. I mean, a L12 router while encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all of its L1 circit's IP address and should not consider its L2 circuit's IP address at all. > >I found some implementation, for L12 router, not encodeing L2 circuit's IP address in its L1 LSP's IP Internal Reach TLV. > >It'll be helpful if I get clarified. > >Thanks, >Selva. > > > > >------------------------------------------------------------ >WWW.COM - Where the Web Begins! http://www.www.com >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From Larmer@CommSense.Net Wed May 23 14:53:19 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Wed, 23 May 2001 09:53:19 -0400 Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV In-Reply-To: <200105230743.AAA20691@mail14.bigmailbox.com> Message-ID: Hi Selva, My inclination would be to only place L1 routes into L1 LSPs and L2 routes into L2 LSPs. However, I just conducted some testing on a well-known platform and the results are a bit puzzling? If I have 2 circuits, both set to circuit-type L1/L2, one circuit has adjacencyUsage = L1/L2 (matching area) and the other with adjacencyUsage = L2-Only (no matching area), I get the following results: L1 LSP IP Internal Reachability Information = IP subnets from both circuits L2 LSP IP Internal Reachability Information = IP subnets from both circuits When I change the circuit which does not have a matching area to "circuit-type = L2-Only", so that I now have two circuits with adjacencyUsage = L1/L2 (matching area) and adjacencyUsage = L2-Only (non-matching area and circuit-type = L2-Only), I get the following results: L1 LSP IP Internal Reachability Information = IP subnet from circuit with adjacencyUsage = L1/L2 L2 LSP IP Internal Reachability Information = IP subnets from both circuits ???? Cheers, Ken -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of R Selvaraj Sent: Wednesday, May 23, 2001 3:43 AM To: isis-wg@juniper.net Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV Hi, Let me resend my last doubt. Actually, I would like to know wheather a L12 router shall include its local L2 circits IP adress in its L1 LSP's Internal Reach TLV and vice versa for its L2 LSP. Thanks, Selva. >From: "R Selvaraj" >To: isis-wg@juniper.net >SUBJECTDate: Mon, 21 May 2001 01:36:12 -0700 > >Hi, >Section 5.3.4 of RFC 1195 states that IP addresses within the routing domain reachable directly via one or more interfaces on the router should be encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, do we need to consider circuit level also. I mean, a L12 router while encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all of its L1 circit's IP address and should not consider its L2 circuit's IP address at all. > >I found some implementation, for L12 router, not encodeing L2 circuit's IP address in its L1 LSP's IP Internal Reach TLV. > >It'll be helpful if I get clarified. > >Thanks, >Selva. > > > > >------------------------------------------------------------ >WWW.COM - Where the Web Begins! http://www.www.com >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From henk@Procket.com Wed May 23 19:09:10 2001 From: henk@Procket.com (Henk Smit) Date: Wed, 23 May 2001 11:09:10 -0700 (PDT) Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV In-Reply-To: <200105230743.AAA20691@mail14.bigmailbox.com> from "R Selvaraj" at May 23, 2001 12:43:04 AM Message-ID: <200105231809.f4NI9A416273@redd3174.procket.com> I haven't checked rfc1195, but the following has always been my understanding. > Let me resend my last doubt. > Actually, I would like to know wheather a L12 router shall include its > local L2 circits IP adress in its L1 LSP's Internal Reach TLV No. Routers inside an area should only know about "things" that are living inside that area. "Things" include routers, adjacencies, IP prefixes. If a L1L2 router has prefix-X configured on a L2-only circuit, then IMHO that prefix-X is not part of the L1 area, and thus the L1L2 router should not advertise prefix-X in its L1 LSP. Prefix-X will be reachable because the L1L2 router has the "attached bit" set in its L1 LSP. (Unless this router can not reach other areas, then it doesn't set the attached-bit, and L1-only routers can not reach prefix-X. Too bad, such is life). If a L1L2 router implements the extensions from RFC2966, then a L1L2 router is allowed to advertise all or any of the IP prefixes it has learned via L2 router. This includes directly connected prefixes configured on L2-only circuits. > and vice versa for its L2 LSP. A L1L2 router is responsable for reachability from the L2 backbone to all IP prefixes that live inside its L1 area. Therefor a L1L2 router must advertise all IP prefixes that live in its L1 area, inside its L2 LSP. IMHO this includes all IP prefixes configured on directly connected L1-only circuits. Of course when you configure summary-addresses, individual L1 prefixes might not be advertised in the L2 LSP, because they are covered by the summary address. So the "problem" that you see is that a L1L2 router advertises the IP prefixes configured on L2-only circuits in its L1 LSP ? Well, IMHO that would not be necessary. But it wouldn't hurt eiter. (Except for the fact that the L1 LSP would be a little bigger. No big deal). The benefit of doing this would be the case I pointed out above. If the L1L2 router looses contact to other areas, it will unset the attached bit in its L1 LSP. Then L1-only routers would not be able to reach the IP prefixes configured on the L2-only circuits of the L1L2 router. If a router always advertises the prefixes configured on its L2-only circuits in its L1 LSP, then this problem will not occur. Hope this helps, henk. > Thanks, > Selva. > > > >From: "R Selvaraj" > >To: isis-wg@juniper.net > >SUBJECTDate: Mon, 21 May 2001 01:36:12 -0700 > > > >Hi, > >Section 5.3.4 of RFC 1195 states that IP addresses within the routing domain reachable directly via one or more interfaces on the router should be encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, do we need to consider circuit level also. I mean, a L12 router while encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all of its L1 circit's IP address and should not consider its L2 circuit's IP address at all. > > > >I found some implementation, for L12 router, not encodeing L2 circuit's IP address in its L1 LSP's IP Internal Reach TLV. > > > >It'll be helpful if I get clarified. > > > >Thanks, > >Selva. > > > > > > > > > >------------------------------------------------------------ > >WWW.COM - Where the Web Begins! http://www.www.com > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > ------------------------------------------------------------ > WWW.COM - Where the Web Begins! http://www.www.com > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Omer Sali" Message-ID: <033101c0e41b$e9f26240$6302a8c0@cwnt.com> Hi Ken, The IP Internal Reachability Information includes all the subnets ISIS knows from all the interfaces it runs on. The RFC says nothing about a condition like: "advertise only IP's of interfaces you have an adjacency over them". For example, in section 1.3 of RFC 1195 you can find: "Specifically, zero or more [IP address, subnet mask, metric] combinations may be included in each Link State Packet. Each level 1 router is manually configured with the [IP address, subnet mask, metric] combinations which are reachable on each interface. " So, in the first case you have discribed you had ISIS running on the interface at level 1 so you saw the IP address advertised in the L1 LSP (although you had no adjacency on L1). In the second case ISIS did not ran on L1 so the router did not advertise it in its L1 LSPs. By the way, most implementations allow you to run ISIS on an interface in "passive mode" saying: "don't exchange packets (don't raise adjacencies) but advertise the IP of the interface as IP Internal Reachability". Hope it helps, Omer ----- Original Message ----- From: "Ken Larmer" To: ; "R Selvaraj" Cc: "Ken Larmer" Sent: Wednesday, May 23, 2001 4:53 PM Subject: RE: [Isis-wg] Doubt regarding IP Internal Reach TLV > Hi Selva, > > My inclination would be to only place L1 routes into L1 LSPs and L2 routes > into L2 LSPs. > > However, I just conducted some testing on a well-known platform and the > results are a bit puzzling? If I have 2 circuits, both set to circuit-type > L1/L2, one circuit has adjacencyUsage = L1/L2 (matching area) and the other > with adjacencyUsage = L2-Only (no matching area), I get the following > results: > > L1 LSP IP Internal Reachability Information = IP subnets from both circuits > L2 LSP IP Internal Reachability Information = IP subnets from both circuits > > When I change the circuit which does not have a matching area to > "circuit-type = L2-Only", so that I now have two circuits with > adjacencyUsage = L1/L2 (matching area) and adjacencyUsage = L2-Only > (non-matching area and circuit-type = L2-Only), I get the following results: > > L1 LSP IP Internal Reachability Information = IP subnet from circuit with > adjacencyUsage = L1/L2 > L2 LSP IP Internal Reachability Information = IP subnets from both circuits > > ???? > > Cheers, > Ken > > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of R Selvaraj > Sent: Wednesday, May 23, 2001 3:43 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV > > Hi, > Let me resend my last doubt. Actually, I would like to know wheather a L12 > router shall include its local L2 circits IP adress in its L1 LSP's Internal > Reach TLV and vice versa for its L2 LSP. > > Thanks, > Selva. > > > >From: "R Selvaraj" > >To: isis-wg@juniper.net > >SUBJECTDate: Mon, 21 May 2001 01:36:12 -0700 > > > >Hi, > >Section 5.3.4 of RFC 1195 states that IP addresses within the routing > domain reachable directly via one or more interfaces on the router should be > encoded in the L1 LSP's IP Internal reachability TLV. reachability . Here, > do we need to consider circuit level also. I mean, a L12 router while > encoding its L1 LSP's IP Inernal Reachability TLV should it encode only all > of its L1 circit's IP address and should not consider its L2 circuit's IP > address at all. > > > >I found some implementation, for L12 router, not encodeing L2 circuit's IP > address in its L1 LSP's IP Internal Reach TLV. > > > >It'll be helpful if I get clarified. > > > >Thanks, > >Selva. > > > > > > > > > >------------------------------------------------------------ > >WWW.COM - Where the Web Begins! http://www.www.com > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > ------------------------------------------------------------ > WWW.COM - Where the Web Begins! http://www.www.com > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From jparker@axiowave.com Thu May 24 14:57:20 2001 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 24 May 2001 09:57:20 -0400 Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV 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_01C0E459.7325E720 Content-Type: text/plain; charset="iso-8859-1" > By the way, most implementations allow you to run ISIS on an > interface in "passive mode" saying: "don't exchange packets > (don't raise adjacencies) but advertise the IP of the > interface as IP Internal Reachability". > > Omer > > > I would like to know wheather a L12 > > router shall include its local L2 circits IP adress in its L1 LSP's > > Internal Reach TLV and vice versa for its L2 LSP. > > > > Selva. I thought the issue was that there was no point in advertising that you can reach a network if you have no evidence that you can, in fact, reach the network. Just because you are configured and you have carrier doesn't mean that you can get there from here. The existence of an IS-IS Adjacency on a link proves that there is at least one other router under the delusion that it can reach the net in question. Implementations use "passive" to bring in networks that do not have other IS-IS routers on it: the assumption is that the administrator has performed extra due-diligence on the link, much as he would with a static configuration. - jeff parker - axiowave networks ------_=_NextPart_001_01C0E459.7325E720 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Doubt regarding IP Internal Reach TLV

> By the way, most implementations allow you to run ISIS on an
> interface in "passive mode" saying: "don't exchange packets
> (don't raise adjacencies) but advertise the IP of the
> interface as IP Internal Reachability".
>
> Omer
>
> > I would like to know wheather a L12
> > router shall include its local L2 circits IP adress in its L1 LSP's
> > Internal Reach TLV and vice versa for its L2 LSP.
> >
> > Selva.

I thought the issue was that there was no point in advertising
that you can reach a network if you have no evidence that you
can, in fact, reach the network.  Just because you are configured
and you have carrier doesn't mean that you can get there from
here. 

The existence of an IS-IS Adjacency on a link proves that
there is at least one other router under the delusion that
it can reach the net in question.  Implementations use
"passive" to bring in networks that do not have other IS-IS
routers on it: the assumption is that the administrator
has performed extra due-diligence on the link, much as he
would with a static configuration.  

- jeff parker
- axiowave networks

------_=_NextPart_001_01C0E459.7325E720-- From selvarajr@www.com Thu May 24 17:59:02 2001 From: selvarajr@www.com (R Selvaraj) Date: Thu, 24 May 2001 09:59:02 -0700 Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV Message-ID: <200105241659.JAA09802@mail20.bigmailbox.com> >I thought the issue was that there was no point in advertising >that you can reach a network if you have no evidence that you >can, in fact, reach the network. Just because you are configured >and you have carrier doesn't mean that you can get there from >here. >The existence of an IS-IS Adjacency on a link proves that >there is at least one other router under the delusion that >it can reach the net in question. --Jeff Parker Do u mean that unless an ISIS have an ajacency on the circuit it should not include the circit IP addres ? But, even if there is no adjacency on the circuit it can still route data packtets to that net. I feel an ISIS need not bother about adjacency for advertising Internal reachability information. Neighhbour TLV can do that. Selva. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From jlearman@cisco.com Thu May 24 18:36:24 2001 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 24 May 2001 13:36:24 -0400 Subject: [Isis-wg] Doubt regarding IP Internal Reach TLV In-Reply-To: <200105241659.JAA09802@mail20.bigmailbox.com> Message-ID: <4.3.2.7.2.20010524133406.019745e0@dingdong.cisco.com> At 12:59 PM 5/24/2001, R Selvaraj wrote: >>I thought the issue was that there was no point in advertising >>that you can reach a network if you have no evidence that you >>can, in fact, reach the network. Just because you are configured >>and you have carrier doesn't mean that you can get there from >>here. > >>The existence of an IS-IS Adjacency on a link proves that >>there is at least one other router under the delusion that >>it can reach the net in question. >--Jeff Parker I assume you mean "router or host", not just router, and are including adjacencies created by ARP as well as IS adjacencies. Otherwise, how would we ever get a route to a subnet with only one router? Jeff From Russ White Mon May 21 00:49:48 2001 From: Russ White (Russ White) Date: Sun, 20 May 2001 19:49:48 -0400 (EDT) Subject: [Isis-wg] Optional Checksum in ISIS In-Reply-To: <3B06072D.4B67F874@redback.com> Message-ID: > > My point is just that if MD5 authentication has been > > implemented already, there is no significant technical reason > > to implement optional checksum too. > > agree technically, observe that with the way the draft is > stated you are free to ignore CSUMs if MD5 is configured and > omit them in your packets. Things will still work. So in a > sense there is no need to specifically state that you HAVE TO > omit them. I'll agree with Tony here, and say we should leave it optional. Of course, I'd expect implementations to ignore the checksum if md5 is enabled, just as a matter of efficiency. It won't matter if anyone actually sends them if everyone ignores them when md5 is enabled, so we'll all end up not sending them either, most likely. :-) Russ _____________ riw@cisco.com From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_20015244172131176911340 Content-Type: text/plain; charset=us-ascii Hello all, Do we need to have seperate TLVs for each virtual adjacency as there is only one virtual flag in a IS neighbour TLV. Thanks in advance sivakumar Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015244172131176911340 Content-Type: text/html; charset=us-ascii

Hello all,

Do we need to have seperate TLVs for each virtual adjacency as there is only one virtual flag in a IS neighbour TLV.

 

Thanks in advance

sivakumar

 

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015244172131176911340-- From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_20015244165452993967637 Content-Type: text/plain; charset=us-ascii Hi all, In an LSP why should all Intermediate System Neighbour options always precede the End System Neighbour options.(As per the ISO/IEC 10589:1992(E) Section 9.8 page No. 55. Thanks and regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015244165452993967637 Content-Type: text/html; charset=us-ascii

Hi all,

In an LSP why should all Intermediate System Neighbour options always precede the End System Neighbour options.(As per the ISO/IEC 10589:1992(E) Section 9.8 page No. 55.

Thanks and regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015244165452993967637-- From mshand@cisco.com Fri May 25 09:48:43 2001 From: mshand@cisco.com (mike shand) Date: Fri, 25 May 2001 09:48:43 +0100 Subject: [Isis-wg] Virtual adjacencies In-Reply-To: <200105241139.RAA04569@WS0005.indiatimes.com> Message-ID: <4.3.2.7.2.20010525094713.01e00f38@jaws.cisco.com> At 17:02 24/05/2001 +0530, Sivakumar A wrote:

Hello all,

Do we need to have seperate TLVs for each virtual adjacency as there is only one virtual flag in a IS neighbour TLV.

No, you can put multiple virtual adjacencies within the same TLV. You just have to have separate TLVs for virtual and non-virtual.

But you are not seriously considering implementing partition repair are you?

        Mike


 

Thanks in advance

sivakumar

 

 
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
From mshand@cisco.com Fri May 25 10:00:28 2001 From: mshand@cisco.com (mike shand) Date: Fri, 25 May 2001 10:00:28 +0100 Subject: [Isis-wg] ES/IS options in an LSP In-Reply-To: <200105241132.RAA04348@WS0005.indiatimes.com> Message-ID: <4.3.2.7.2.20010525095133.01e00960@jaws.cisco.com> At 16:54 24/05/2001 +0530, Sivakumar A wrote: >Hi all, > >In an LSP why should all Intermediate System Neighbour options always >precede the End System Neighbour options.(As per the ISO/IEC 10589:1992(E) >Section 9.8 page No. 55. Didn't we just discuss this? Its an attempt to avoid having to move options from one LSP to another. So the idea was to keep the (more stable) IS information together and leave the ES information to flap around at the end. Some implementations put the IS information in LSPs starting at zero and working up, and ES information starting at 255 and working down. It doesn't really buy you all that much. See also 7.3.4.4 Mike >Thanks and regards > >Sivakumar A > >---------- >Get Your Private, Free E-mail from Indiatimes at >http://email.indiatimes.com From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_200152811738161034949299 Content-Type: text/plain; charset=us-ascii Hello all, all IS adjacencies should preceed ES adjacencies according to ISO 10589. if an LSP with LSP no. 5 containing all ES adjacencies is received and later LSP no. 8 with IS adjacencies is received, should an implementation discard this LSP(no. 8) or the Complete set of LSP's received by this source (i.e LSP no.0, 5, 8 ). any help regarding this is appretiated Thanks in advance sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_200152811738161034949299 Content-Type: text/html; charset=us-ascii

Hello all,

all IS adjacencies should preceed ES adjacencies according to ISO 10589. if  an LSP with LSP no. 5 containing all ES adjacencies is received and later  LSP no. 8 with IS adjacencies is received, should an implementation discard this LSP(no. 8) or the Complete set of LSP's received by this source (i.e LSP no.0, 5, 8 ). any help regarding this is appretiated

Thanks in advance

sivakumar A

 

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_200152811738161034949299-- From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_20015292114239846811127 Content-Type: text/plain; charset=us-ascii Hello all, Is it possible to have seperate LSP 0 for pseudonode and non- pseudonode? For Example: If LSP0,1,2,3,4,5 are present for non-pseudonode. Can there be LSP0 for a pseudonode? Please give your valuable comments. Thanks and regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015292114239846811127 Content-Type: text/html; charset=us-ascii

Hello all,

Is it possible to have seperate LSP 0 for pseudonode and non- pseudonode?

For Example:

If LSP0,1,2,3,4,5 are present for non-pseudonode. Can there be LSP0 for a pseudonode?

Please give your valuable comments.

Thanks and regards

Sivakumar A     

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015292114239846811127-- From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_20015292145334350322227 Content-Type: text/plain; charset=us-ascii Hello all, Why is Pt-to-Pt Circuit ID is calculated and where it is used? Any help regarding this is appretiated. Thanks in advance Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015292145334350322227 Content-Type: text/html; charset=us-ascii

Hello all,

Why is Pt-to-Pt Circuit ID is calculated and where it is used? Any help regarding this is appretiated.

Thanks in advance

Regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015292145334350322227-- From appalla@rediffmail.com Tue May 29 18:22:04 2001 From: appalla@rediffmail.com (A Rama suryanarayana) Date: 29 May 2001 17:22:04 -0000 Subject: [Isis-wg] querry regarding draft-ietf-isis-wg-mib-04.txt Message-ID: <20010529172204.2850.qmail@mailweb5.rediffmail.com> Hello, When i was going through the MIB for implementing Integrated IS-IS, I could not find the configurable object IP Interface address. The IP interface address should go with the Hellos, LSPs according to RFC 1195. can any one tell me How IP interface address are configured. any help regarding this is appriatiated. Thanks in advance Warm Regards suryanarayana _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com From jparker@axiowave.com Tue May 29 19:56:54 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 29 May 2001 14:56:54 -0400 Subject: [Isis-wg] RE: querry regarding draft-ietf-isis-wg-mib-04.txt 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_01C0E871.20DD81F0 Content-Type: text/plain; charset="iso-8859-1" > Hello, > When i was going through the MIB for implementing > Integrated IS-IS, I could not find the configurable object IP > Interface address. The IP interface address should go with > the Hellos, LSPs according to RFC 1195. can any one tell me > How IP interface address are configured. any help regarding > this is appriatiated. > > Thanks in advance > > Warm Regards > suryanarayana I would think that RFC 1213, or whatever has replaced it, would be the place to go for this funcitonality. - jeff parker ------_=_NextPart_001_01C0E871.20DD81F0 Content-Type: text/html; charset="iso-8859-1" RE: querry regarding draft-ietf-isis-wg-mib-04.txt

> Hello,
>   When i was going through the MIB for implementing
> Integrated IS-IS, I could not find the configurable object IP
> Interface address. The IP interface address should go with
> the Hellos, LSPs according to RFC 1195. can any one tell me
> How IP interface address are configured. any help regarding
> this is appriatiated.
>
> Thanks in advance
>
> Warm Regards
> suryanarayana

I would think that RFC 1213, or whatever has replaced it,
would be the place to go for this funcitonality.  

- jeff parker

------_=_NextPart_001_01C0E871.20DD81F0-- From henk@Procket.com Tue May 29 20:00:02 2001 From: henk@Procket.com (Henk Smit) Date: Tue, 29 May 2001 12:00:02 -0700 (PDT) Subject: [Isis-wg] improper LSP no. Sequence In-Reply-To: <200105281201.RAA05630@WS0005.indiatimes.com> from "Sivakumar A" at May 28, 2001 05:38:16 PM Message-ID: <200105291900.f4TJ02U12006@redd3174.procket.com> > all IS adjacencies should preceed ES adjacencies according to ISO 10589. if an LSP with LSP no. 5 containing all ES adjacencies is received and later LSP no. 8 with IS adjacencies is received, should an implementation discard this LSP(no. 8) or the Complete set of LSP's received by this source (i.e LSP no.0, 5, 8 ). any help regarding this is appretiated This is an IETF WG. The most important rule in IETF protocols has always been: "Be strict in what you send, be liberal in what you accept". So, *IMHO*, you should never drop an LSP because it does the ordering of TLVs in the wrong way. As Mike Shand has explained, the ordering of IS TLVs at the beginning of an LSP (or set of LSP fragments), and ES TLVs at the end of an LSP (or set of LSP fragments), is a way to optimize and prevent unnecessary fragment changes. This is an optimization to try to minimize the amount of LSP fragments being flooded. There are no substantial reasons why you shouldn't accept those LSP fragments. Nothing in the routing will break if you do. So *IMHO* you should build your implementation in such a way that it will accept those LSPs, even if they don't have the TLVs in the right order. Hope this helps, henk. From henk@Procket.com Tue May 29 20:01:36 2001 From: henk@Procket.com (Henk Smit) Date: Tue, 29 May 2001 12:01:36 -0700 (PDT) Subject: [Isis-wg] LSP 0 In-Reply-To: <200105290620.LAA29831@WS0005.indiatimes.com> from "Sivakumar A" at May 29, 2001 11:42:39 AM Message-ID: <200105291901.f4TJ1aS12029@redd3174.procket.com> > Is it possible to have seperate LSP 0 for pseudonode and non- pseudonode? > > For Example: > > If LSP0,1,2,3,4,5 are present for non-pseudonode. Can there be LSP0 for a pseudonode? Yes. In fact, each pseudonode LSP, as well as each non-pseudonode LSP, is required to have an LSP fragment number zero. henk. From jparker@axiowave.com Tue May 29 20:15:46 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 29 May 2001 15:15:46 -0400 Subject: [Isis-wg] Usage of Pt-to-Pt Circuit Id 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_01C0E873.C3458490 Content-Type: text/plain; charset="iso-8859-1" > Why is Pt-to-Pt Circuit ID is calculated and where it is used? One place this is used is in the three-way handshake describe by Katz and Saluja in "Three-Way Handshake for IS-IS Point-to- Point Adjacencies" which seems to have aged off the workgroup page. It is used there to detect that the remote side has heard your hellos. It's a form of active listening, repeating what you have just heard, and allows you to detect some anomalous one-way connected situations. - jeff parker - axiowave networks ------_=_NextPart_001_01C0E873.C3458490 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Usage of Pt-to-Pt Circuit Id

> Why is Pt-to-Pt Circuit ID is calculated and where it is used? 

One place this is used is in the three-way handshake describe
by Katz and Saluja in "Three-Way Handshake for IS-IS Point-to-
Point Adjacencies" which seems to have aged off the workgroup
page. 

It is used there to detect that the remote side has heard your
hellos.  It's a form of active listening, repeating what you
have just heard, and allows you to detect some anomalous one-way
connected situations. 

- jeff parker
- axiowave networks

------_=_NextPart_001_01C0E873.C3458490-- From mshand@cisco.com Wed May 30 08:42:25 2001 From: mshand@cisco.com (mike shand) Date: Wed, 30 May 2001 08:42:25 +0100 Subject: [Isis-wg] improper LSP no. Sequence In-Reply-To: <200105291900.f4TJ02U12006@redd3174.procket.com> References: <200105281201.RAA05630@WS0005.indiatimes.com> Message-ID: <4.3.2.7.2.20010530083948.01a74d98@jaws.cisco.com> At 12:00 29/05/2001 -0700, Henk Smit wrote: > > all IS adjacencies should preceed ES adjacencies according to ISO > 10589. if an LSP with LSP no. 5 containing all ES adjacencies is > received and later LSP no. 8 with IS adjacencies is received, should an > implementation discard this LSP(no. 8) or the Complete set of LSP's > received by this source (i.e LSP no.0, 5, 8 ). any help regarding this is > appretiated > > This is an IETF WG. The most important rule in IETF protocols has > always been: > > "Be strict in what you send, be liberal in what you accept". > > So, *IMHO*, you should never drop an LSP because it does the ordering > of TLVs in the wrong way. As Mike Shand has explained, the ordering > of IS TLVs at the beginning of an LSP (or set of LSP fragments), and > ES TLVs at the end of an LSP (or set of LSP fragments), is a way to > optimize and prevent unnecessary fragment changes. This is an optimization > to try to minimize the amount of LSP fragments being flooded. There > are no substantial reasons why you shouldn't accept those LSP fragments. > Nothing in the routing will break if you do. So *IMHO* you should > build your implementation in such a way that it will accept those > LSPs, even if they don't have the TLVs in the right order. No need to be humble about it Henk :-) You should definitely accept those LSPs. Mike > Hope this helps, > > henk. > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From dhudek@ma.ultranet.com Wed May 30 03:19:45 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Tue, 29 May 2001 19:19:45 -0700 Subject: [Isis-wg] History of the External Metric Type? Message-ID: <3B1458C1.B37EC7A2@ma.ultranet.com> Hi all, Before embarking on an ISIS implementation, I've been perusing the wg mail archives, and I want to make sure I understand the current status of the (effectively deprecated?) "external metric type" indication (or perhaps more clearly, the non-comparable metric type indication). The following is my current understanding... please let me know if it's correct or if I've gone delusional ;-) (and if the latter, what the real situation is, thanks :-) ) When the spec was first defined, it was thought that users might want to inject routes into ISIS from other sources, and those other routes might come in two flavors: a) those using metrics which are directly comparable with the metrics used by ISIS, and b) those using metrics which are NOT comparable with the metrics used by ISIS. The "metric type" indication was defined as a mechanism for distinguishing between these two types, with the comparable metrics being identified as "internal metric type", and the non-comparable metrics being identified as "external metric type" Only the internal metric type was valid for IP Internal Reachability information. Either internal or external metric type would be valid for IP External Reachability information. IP External Reachability info using internal metric type would be treated similarly to Internal Reachability info, but IP External Reachability info would be less preferred if it used external metric type instead. Then, the RealWorld(TM) intervened :-) In the dominant early implementation (presumably cisco's), the internal/external metric type field was accidentally ignored, and all IP Reachability was treated as having internal metric type. No one complained. It is presumed (known??) that this is because customers never actually made use of the external metric type capability, rather than because they did try to use it but then never noticed odd but still workable routes chosen because of comparing what were intended to be incomparable metrics. As long as every interworking implementation calculated things in the same manner, loops were avoided, and things worked out in a manner satisfactory to the customers. Subsequent implementations by others either also ignored the external metric type, or provided a configurable knob to turn its recognition on/off for compatibility purposes and everyone was(is) just turning it off. So far there has apparently not been any hue and cry for the restoration of the capability, and as a practical matter everyone is fine with only using comparable metrics. Given that IP External Reachability with internal metrics is treated similarly to IP Internal Reachability, and that IP External Reachability with external metrics is not actually used in practice, there no longer appears to be any significant difference between IP Internal/External Reachability, and so no longer any need for separate TLVs. Given all that, and being practical folks, as new enhancements were proposed, they were(are) no longer explicitly including the capability of distinguishing between internal/external metric type. For instance, (if I'm reading it correctly) the ISIS extensions for TE draft-rfc intentionally leaves out any internal/external metric type, as well as lumping together all IP Reachability into one (extended) type. Going forward, the net effect seems to be a deprecation of the comparable/noncomparable metric idea, in favor of all IP reachability info using a single comparable metric type. There exists the possibility for subTLVs in the IP Extended Reachability, but so far no-one has publicly defined any subTLVs to revive the internal/external (comparable/noncomparable) metric type distinction. The above is my best guess as to the current state of affairs, treating what had been implied in some earlier emails as explicitly true. How far off am I ? :-) Assuming that the above isn't too far off the mark, assuming that implementations will not properly interwork if they calculate routes differently (and that they will calculate routes differently if one recognizes external metrics and treats them differently from internal, while another does not recognize external metrics or does but still treats them the same as internal), would it be reasonable for the external metric type to be "officially" deprecated and implementers strongly encouraged to ignore the external metric type if encountered (a "send yours as internal only, and ignore theirs" sort of deal), treating all as internal metric type ? adTHANKSvance, dave h From purush_isis@rediffmail.com Wed May 30 13:42:40 2001 From: purush_isis@rediffmail.com (Purushothaman NandaKumaran) Date: 30 May 2001 12:42:40 -0000 Subject: [Isis-wg] Reachability information passing Message-ID: <20010530124240.22798.qmail@mailweb32.rediffmail.com> Hi, I have some doubts regarding the following: 1) Whether the internal reachability information in the Level 2 LSP (about level 2 subdomain)can be passed on to the level 1 area through level1 LSP's? 2) Whether the external reachability information (e.g learnt thru BGP) can be passed to the routers in level 1 area thru level 1 LSP's? Please clarify my doubts Thanks and Regards, Purush _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com From selvarajr@rediffmail.com Wed May 30 15:34:32 2001 From: selvarajr@rediffmail.com (R selvaraj) Date: 30 May 2001 14:34:32 -0000 Subject: [Isis-wg] LSP 0 Message-ID: <20010530143432.11945.qmail@mailweb18.rediffmail.com> Pseudonode LSPs are generated behalf of pseudonode, a virtial node. So, always think pseudonode as a seperate node. Also it has it own unique soure ID(7 bytes). Although the same router(physically) is originating both Pseudonode as well as non-pseudonode LSPs both are considered to be from two different sources. Since each source should start LSP generation from LSP 0 , obviously the same router should generate LSP 0 for pseudonode as well as non-pseudonode. If suppose the router has 10 broadcast interfaces and if all the 10 interfaces are DR then the router will be having 11 LSPs with LSP number 0(10 Pseudonode LSP + 1 non-pseudonode LSP). Selva. ------------- Original Message -------------- "Sivakumar A" wrote: To:"isis" From:"Sivakumar A" Date:Tue, 29 May 2001 11:42:39 +0530 Subject:[Isis-wg] LSP 0 Hello all, Is it possible to have seperate LSP 0 for pseudonode and non- pseudonode? For Example: If LSP0,1,2,3,4,5 are present for non-pseudonode. Can there be LSP0 for a pseudonode? Please give your valuable comments. Thanks and regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com From henk@Procket.com Wed May 30 19:18:09 2001 From: henk@Procket.com (Henk Smit) Date: Wed, 30 May 2001 11:18:09 -0700 (PDT) Subject: [Isis-wg] Reachability information passing In-Reply-To: <20010530124240.22798.qmail@mailweb32.rediffmail.com> from "Purushothaman NandaKumaran" at May 30, 2001 12:42:40 PM Message-ID: <200105301818.f4UIIAT13983@redd3174.procket.com> > Hi, > I have some doubts regarding the following: > 1) Whether the internal reachability information in the Level 2 LSP > (about level 2 subdomain)can be passed on to the level 1 > area through level1 LSP's? In the original ISIS for IP specification (RFC 1195), there was no way to do that. Network operators have asked for this feature later, and it has been implemented, and has been documented in RFC 2966. > 2) Whether the external reachability information (e.g learnt thru BGP) > can be passed to the routers in level 1 area thru level 1 LSP's? In RFC 1195 that wasn't allowed either. However, some vendors implemented redistribution into L1 anyway. This was documented later in rfc2966 as well. http://www.ietf.org/rfc/rfc2966.txt henk. > Please clarify my doubts > Thanks and Regards, > Purush From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_20015314957572083149517 Content-Type: text/plain; charset=us-ascii Hello all, Can you pls. suggest me a reasonable value for routes per second a router need to support. Thanks in advance Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015314957572083149517 Content-Type: text/html; charset=us-ascii

Hello all,

Can you pls. suggest me a reasonable value for routes per second a router need to support.

Thanks in advance

Regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20015314957572083149517-- From dhudek@ma.ultranet.com Tue Jun 5 22:38:45 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Tue, 05 Jun 2001 14:38:45 -0700 Subject: [Isis-wg] [Fwd: Question/Comment on draft-ietf-isis-wg-mib-04.txt] Message-ID: <3B1D5164.913F20C6@ma.ultranet.com> This is a multi-part message in MIME format. --------------B6D8409BDBD74229EA97F680 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I originally sent the following note to Jeff, and he asked me to resend it to the wg email list. Comments/clarifications/corrections/further discussion welcomed. Thanks, dave h David Hudek wrote: > > Hi Jeff... > > I'm not sure if these sorts of questions/comments > should go on the ISIS working group email list or > be sent directly to the author... I'm just > opting for the latter as a default :-) > > I've started looking at draft-ietf-isis-wg-mib-04.txt (believe > this is the latest?) and had a couple minor > questions/comments concerning the IsisSummAddrEntry stuff... > > a) Why two "type" entries, one for address and > one for mask... are they not required to agree? > (e.g., if the address is ipv4 type, then doesn't > the associated mask also have to be ipv4 type?) > > My first thought was that only one is needed, > with extra error handling now required if we > allow two and they accidentally differ... > but perhaps a heterogeneous combination > makes sense and I just didn't see it? > > > b) Assuming the summary addresses are for the > purpose of prefix summarization when leaking > routes up or down the levels (with leaking down > now allowed via rfc 2966) (?)... > > Can there be a little more verbiage describing > exactly what the isisSummAddrAdminState > (which can take on values indicating L1, L2, > L1L2, and off) is supposed to indicate? > Perhaps something to indicate which end of the > leaking is contemplated (e.g., "into" vs. "out of")... > For instance, if it's "summaryl1", does that mean the > summarization is supposed to be applied when leaking > out of L1, or when leaking into L1? Basically, > in which direction is the filter applied? > I'm assuming "out of" is meant, but you know > what happens when one assumes :-) > > Also, is an L1L2 entry functionally the same > as an L1 entry and a separate L2 entry with > identical addr/mask? > (is it just there to save on an extra config step > or does it mean something different)? > If it's the same as a L1 and a L2, I'd personally > rather see the L1L2 removed and the two summaries > be made explicit, so they can be treated independently. > Else, if it was L1L2, and user decided they just > wanted L1, then they'd have to turn off L1L2 > and then quickly add it back as L1, possibly causing > unnecessary churn in the LSPs as the summarization > state bounced. (of course, one could change the order, add the L1 and then turn off the L1L2, but still... the semantics are a little unclear, as mentioned next) > And you could get complaints about the treatment of > the same addr/mask in overlapping types if one was > turned off and the other on... which one wins? > For instance, if the user turned off L1L2 intending > that they both not summarize that addr/mask, but > they also had that addr/mask as an L1, then what > happens? I'm assuming that the L1 summarization > occurs (L1 on trumps L1L2 off) > but perhaps others would assume differently. > > (and a really *minor* nit... if there's not > a MIB convention that prohibits it, when naming > items with L and 1 next to each other, > could the capital L be used instead of lower case? > "l1" looks an awful lot like "11", while > "L1" is easily distinguished... personal opinion, > I think that summaryL1 looks just spiffy, while > summaryl1l2 at first glance looks like the > many-level-ISIS effort has gone on steroids > with over 1000 levels :-) ) > > Thanks, > dave h > dhudek@ma.ultranet.com --------------B6D8409BDBD74229EA97F680 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3B1C50B2.C6A8A2AF@ma.ultranet.com> Date: Mon, 04 Jun 2001 20:23:30 -0700 From: David Hudek X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jparker@axiowave.com Subject: Question/Comment on draft-ietf-isis-wg-mib-04.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jeff... I'm not sure if these sorts of questions/comments should go on the ISIS working group email list or be sent directly to the author... I'm just opting for the latter as a default :-) I've started looking at draft-ietf-isis-wg-mib-04.txt (believe this is the latest?) and had a couple minor questions/comments concerning the IsisSummAddrEntry stuff... a) Why two "type" entries, one for address and one for mask... are they not required to agree? (e.g., if the address is ipv4 type, then doesn't the associated mask also have to be ipv4 type?) My first thought was that only one is needed, with extra error handling now required if we allow two and they accidentally differ... but perhaps a heterogeneous combination makes sense and I just didn't see it? b) Assuming the summary addresses are for the purpose of prefix summarization when leaking routes up or down the levels (with leaking down now allowed via rfc 2966) (?)... Can there be a little more verbiage describing exactly what the isisSummAddrAdminState (which can take on values indicating L1, L2, L1L2, and off) is supposed to indicate? Perhaps something to indicate which end of the leaking is contemplated (e.g., "into" vs. "out of")... For instance, if it's "summaryl1", does that mean the summarization is supposed to be applied when leaking out of L1, or when leaking into L1? Basically, in which direction is the filter applied? I'm assuming "out of" is meant, but you know what happens when one assumes :-) Also, is an L1L2 entry functionally the same as an L1 entry and a separate L2 entry with identical addr/mask? (is it just there to save on an extra config step or does it mean something different)? If it's the same as a L1 and a L2, I'd personally rather see the L1L2 removed and the two summaries be made explicit, so they can be treated independently. Else, if it was L1L2, and user decided they just wanted L1, then they'd have to turn off L1L2 and then quickly add it back as L1, possibly causing unnecessary churn in the LSPs as the summarization state bounced. And you could get complaints about the treatment of the same addr/mask in overlapping types if one was turned off and the other on... which one wins? For instance, if the user turned off L1L2 intending that they both not summarize that addr/mask, but they also had that addr/mask as an L1, then what happens? I'm assuming that the L1 summarization occurs (L1 on trumps L1L2 off) but perhaps others would assume differently. (and a really *minor* nit... if there's not a MIB convention that prohibits it, when naming items with L and 1 next to each other, could the capital L be used instead of lower case? "l1" looks an awful lot like "11", while "L1" is easily distinguished... personal opinion, I think that summaryL1 looks just spiffy, while summaryl1l2 at first glance looks like the many-level-ISIS effort has gone on steroids with over 1000 levels :-) ) Thanks, dave h dhudek@ma.ultranet.com --------------B6D8409BDBD74229EA97F680-- From jparker@axiowave.com Tue Jun 5 21:04:31 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 5 Jun 2001 16:04:31 -0400 Subject: [Isis-wg] [Fwd: Question/Comment on draft-ietf-isis-wg-mib-04 .txt] 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_01C0EDFA.BBE4B9F0 Content-Type: text/plain; charset="iso-8859-1" > > ...[is] draft-ietf-isis-wg-mib-04.txt ... the latest? Yup. > > a) Why two "type" entries, one for address and > > one for mask... are they not required to agree? > > (e.g., if the address is ipv4 type, then doesn't > > the associated mask also have to be ipv4 type?) This is an issue with RFC 2851's InetAddress object. This has been addressed in a recent draft that Juergen Schoenwaelder pointed out, draft-ietf-ops-rfc2851-update-00.txt, which includes provisions for a triple (Type, Address, MaskLen). I will use this in version 05. > > > > b) Assuming the summary addresses are for the > > purpose of prefix summarization when leaking > > routes up or down the levels (with leaking down > > now allowed via rfc 2966) (?)... Point taken. The original anticipated summarizing L1 routes into L2. I was trying to support the ability to summarize L1 routes into L1 as well, which some vendors support. If you are importing routes from another protocol into IS-IS, you might wish to summarize before announcing. Any comments from the list about the relevance of summaries from {L1, L2} into {L1, L2}? (That is, which of the four possibilities make sense) Does it make sense to summarize L2 into L1? > > Also, is an L1L2 entry functionally the same > > as an L1 entry and a separate L2 entry with > > identical addr/mask? You raise a good point about controlling these. The question of what we should/should not support remains. > > could the capital L be used instead of lower case? > > "l1" looks an awful lot like "11", while > > "L1" is easily distinguished... > > > > dhudek@ma.ultranet.com Many of these are easy to fix. I think there is a requirement that the first character of an enumerated type be lower case (as below). I suppose these could be spelled out as "level1..." and "level2...". Would that be any better? - jeff parker - axiowave networks isisISAdjNeighSysType OBJECT-TYPE SYNTAX INTEGER { l1IntermediateSystem(1), l2IntermediateSystem(2), l1l2IntermediateSystem(3), unknown(4) } ------_=_NextPart_001_01C0EDFA.BBE4B9F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] [Fwd: Question/Comment on = draft-ietf-isis-wg-mib-04.txt]

> > ...[is] draft-ietf-isis-wg-mib-04.txt ... = the latest?

Yup.

> >     a) Why two = "type" entries, one for address and
> >        = one for mask... are they not required to agree?
> >        = (e.g., if the address is ipv4 type, then doesn't
> = >         the associated = mask also have to be ipv4 type?)

This is an issue with RFC 2851's InetAddress = object.  This has
been addressed in a recent draft that Juergen = Schoenwaelder
pointed out, draft-ietf-ops-rfc2851-update-00.txt, = which includes
provisions for a triple (Type, Address, = MaskLen).
I will use this in version 05. 

> >
> >     b) Assuming the = summary addresses are for the
> >        = purpose of prefix summarization when leaking
> >        = routes up or down the levels (with leaking down
> >        = now allowed via rfc 2966) (?)...

Point taken.  The original anticipated = summarizing L1
routes into L2.  I was trying to support the = ability
to summarize L1 routes into L1 as well, which = some
vendors support.  If you are importing routes = from
another protocol into IS-IS, you might wish to = summarize
before announcing.

Any comments from the list about the relevance
of summaries from {L1, L2} into {L1, L2}?  =
(That is, which of the four possibilities make = sense)
Does it make sense to summarize L2 into L1?  =

> >        = Also, is an L1L2 entry functionally the same
> >        = as an L1 entry and a separate L2 entry with
> >        = identical addr/mask?

You raise a good point about controlling these.  = The
question of what we should/should not support = remains. 

> = >         could the capital = L be used instead of lower case?
> = >         "l1" = looks an awful lot like "11", while
> = >         "L1" is = easily distinguished...
> >
> > dhudek@ma.ultranet.com

Many of these are easy to fix. 
I think there is a requirement that the first = character
of  an enumerated type be lower case (as = below).  I
suppose these could be spelled out as = "level1..."
and "level2...".  Would that be any = better?

- jeff parker
- axiowave networks

     isisISAdjNeighSysType = OBJECT-TYPE
         = SYNTAX INTEGER {
          &nb= sp;  l1IntermediateSystem(1),
          &nb= sp;  l2IntermediateSystem(2),
          &nb= sp;  l1l2IntermediateSystem(3),
          &nb= sp;  unknown(4)
          &nb= sp;  }

------_=_NextPart_001_01C0EDFA.BBE4B9F0-- From dhudek@ma.ultranet.com Wed Jun 6 03:17:48 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Tue, 05 Jun 2001 19:17:48 -0700 Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt Message-ID: <3B1D92CC.9E0DC03@ma.ultranet.com> Hi all, The latest ISIS TE draft I could find is the one mentioned in the subject. Assuming that's the latest, or that a later one has similar treatment (non-treatment) of external metric type, I'd like to offer the following comments/suggestions. First, let me say I'm no big fan of the external metric type, and it wouldn't bother me if it were to just fade away. It simplifies things nicely if all metrics are comparable. [Since no one has told me nay, I'm assuming that the previous "History of the External Metric Type?" email is at least reasonably close to the actual state of affairs? If not, please let me know and perhaps the rest of this comment will be filed under Rosanne Rosannadana ("nevermind..." ;-))] However, I'm more concerned with implementations' interoperability, and so if it is going away, I'd like to see it do so in an orderly manner. If it's not going away, I'd like to see it defined in the relevant message. It's troubling to read of some folks just picking undocumented random bits in the message to indicate metric type, while others do nothing and ignore it, and some talk of using an unspecified subTLV. As I understand it, the draft rfc has an Extended IP Reachability TLV, which is intended to replace two of the original IP TLVs... IP Internal Reachability (Type 128) and IP External Reachability (Type 130) [the only really significant difference between the two being that ExtReach could potentially use external non-comparable type metrics, while IntReach could not... and all reachability using internal metric type, from either TLV, is treated similarly... so the only distinguishing factor boils down to the external metric type or not] Besides other nice stuff, the new Extended TLV uses a wider metric. To my knowledge, no official subTLVs have been defined for it, and it intentionally makes no mention of the metric type. The rationale mentioned so far for this omission is that no one is using the non-comparable "external" metric type, and implementers could just assume that info supplied via the Extended IP Reachability TLV should be treated as though it had comparable "internal" metrics. However, that sort of advice has only been given via the mailing list and is not part of the (draft) rfc itself, where a future implementer could readily find it. Also, it is not clear that the rationale is correct, since at least one person posted to the list in the past that they intended to make use of some otherwise unused bit to indicate the external metric type in their implementation. Others have mentioned using an undocumented subTLV type. Can we decide if external metric type is *actually required* (seems to be some disagreement?), and either: a) explicitly deprecate it in the TE spec. Some verbiage to the effect that the external metric type is no longer supported, and any metrics received via the Extended IP Reachability TLV MUST be treated as having comparable ("internal") metrics (is there anyone on the list who would strongly oppose such a thing?) OR b) explicitly specify a subTLV in which to convey the metric type. For a stake in the ground, how about something like the following (using least sig bit in the value as internal/external type, other bits sent as zero and ignored upon receipt), and since we only need one bit and it seems so wasteful to spend 3 octets to convey one bit's worth of data, possibly generalize the new subTLV into an "Extended Control Info" type for future general use of the other bits if needed? : Extended Control Type SubTLV Sub-TLV Type: 1 Sub-TLV Length: 1 Sub-TLV Values: 0 if metric is comparable (internal type) 1 if metric is non-comparable (external type) If someone really really demanded symmetry with the old TLVs, one could use the second least sig bit to indicate internal or external reachability, but it's not clear that buys you anything?... (but for completeness, could use these values instead, with the upper 6 bits reserved, zeroed on send, ignored on receipt) 00 - metric is internal reach/comparable metric type 01 - metric is internal reach/non-comparable metric type (illegal?) 10 - metric is external reach/comparable metric type 11 - metric is external reach/non-comparable metric type) If it's true that there's no real justification for external metric type, then I'd favor (a). If there are valid reasons for having it, then I'd favor something along the lines of (b) with things at least nailed down sufficiently for an implementation. If this has been resolved after draft ver 02 or elsewhere, oops... my bad! and can you point me to it? Thanks, dave h From purush_isis@rediffmail.com Wed Jun 6 08:42:46 2001 From: purush_isis@rediffmail.com (Purushothaman NandaKumaran) Date: 6 Jun 2001 07:42:46 -0000 Subject: [Isis-wg] Summary Address Message-ID: <20010606074246.16361.qmail@mailweb25.rediffmail.com> Hi, I have some doubts in advertising summary routes. 1) Whether the configured summary address will go as IP internal or external reachability information in the generated LSP's? 2) If some redistributed routes fall under the summary route (redistributed routes will be sent as IP external reachability information) and if some level 1 routes also fall under the same summary route (level 1 to level 2 which should go as IP internal reachability information) then how should we advertise that summary route? Please clarify my doubts. thanks in advance, Purush _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com From jparker@axiowave.com Wed Jun 6 14:46:59 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 6 Jun 2001 09:46:59 -0400 Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt 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_01C0EE8F.28642680 Content-Type: text/plain; charset="iso-8859-1" > ...two of the original IP TLVs... > IP Internal Reachability (Type 128) and IP External Reachability > (Type 130) [the only really significant difference between > the two being that ExtReach could potentially use external > non-comparable type metrics, > while IntReach could not... and all reachability using > internal metric type, from either TLV, is treated similarly... > so the only distinguishing factor boils down to the > external metric type or not] Just to be clear about this, these metrics are quite different. The worst metric for an internal reachability is preferred over the best metric in external. This could be visualized as an extra 9th bit that is set for external and cleared for internal. This would allow the two metrics to be mapped into a new consistent value. Any route learned from another protocol (BGP, Static, RIP) gets an external: any route learned via the IGP gets an internalReach. Of course, implementations have been known to import external routes as Internal Reachability, but that was not the original intention. There is an argument to be made that local policy should define how metrics are mapped, and that since IS-IS is an IGP, we only need to worry about local policy. However, I like to have some guidelines on interoperation between metric types. It is bad enough that we need to compare two types, with the 2 extra bits, without adding an incomperable 3rd metric. - jeff parker ------_=_NextPart_001_01C0EE8F.28642680 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt

 > ...two of the original IP TLVs...
> IP Internal Reachability (Type 128) and IP External Reachability
> (Type 130) [the only really significant difference between
> the two being that ExtReach could potentially use external
> non-comparable type metrics,
> while IntReach could not... and all reachability using
> internal metric type, from either TLV, is treated similarly...
> so the only distinguishing factor boils down to the
> external metric type or not]

Just to be clear about this, these metrics are quite different.
The worst metric for an internal reachability is preferred over
the best metric in external.  This could be visualized as an
extra 9th bit that is set for external and cleared for internal.
This would allow the two metrics to be mapped into a new
consistent value. 

Any route learned from another protocol (BGP, Static, RIP) gets
an external: any route learned via the IGP gets an internalReach.
Of course, implementations have been known to import external
routes as Internal Reachability, but that was not the original
intention. 

There is an argument to be made that local policy should define
how metrics are mapped, and that since IS-IS is an IGP, we only
need to worry about local policy.  However, I like to have some
guidelines on interoperation between metric types.  It is bad
enough that we need to compare two types, with the 2 extra bits,
without adding an incomperable 3rd metric. 

- jeff parker

------_=_NextPart_001_01C0EE8F.28642680-- From jparker@axiowave.com Wed Jun 6 14:54:49 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 6 Jun 2001 09:54:49 -0400 Subject: [Isis-wg] Summary Address 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_01C0EE90.409B6140 Content-Type: text/plain; charset="iso-8859-1" > 1) Whether the configured summary address will go as IP > internal or external reachability information in the generated LSP's? > > 2) If some redistributed routes fall under the summary route > (redistributed routes will be sent as IP external > reachability information) and if some level 1 routes also > fall under the same summary route (level 1 to level 2 which > should go as IP internal reachability information) > then how should we advertise that summary route? > > Please clarify my doubts. > thanks in advance, > Purush As to point 2, if you have an internal route to a destination, there is no need to advertise an external route. Even if you did, no one would use it until you withdrew the InternalReach route. As to point 1, I would assume that routes preserve 'type', but I can't cite chapter and verse to defend this. - jeff parker - axiowave networks ------_=_NextPart_001_01C0EE90.409B6140 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Summary Address

> 1) Whether the configured summary address will go as IP
> internal or external reachability information in the generated LSP's?
>
> 2) If some redistributed routes fall under the summary route
> (redistributed routes will be sent as IP external
> reachability information) and if some level 1 routes also
> fall under the same summary route (level 1 to level 2 which
> should go as IP internal reachability information)
> then how should we advertise that summary route?
>
> Please clarify my doubts.
> thanks in advance,
> Purush

As to point 2, if you have an internal route to a destination,
there is no need to advertise an external route.  Even if you
did, no one would use it until you withdrew the InternalReach
route. 

As to point 1, I would assume that routes preserve 'type',
but I can't cite chapter and verse to defend this. 

- jeff parker
- axiowave networks

------_=_NextPart_001_01C0EE90.409B6140-- From dhudek@ma.ultranet.com Wed Jun 6 22:24:03 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Wed, 06 Jun 2001 14:24:03 -0700 Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt References: Message-ID: <3B1E9F72.3FFE0CB1@ma.ultranet.com> Hi Jeff, I think we probably agree? ...but just want to drill down to the detail to make sure. I'm beginning implementation soon and want to ensure I've got a reasonably accurate understanding of the issues first (much easier to change what you haven't coded yet ;-) ) > Jeff Parker wrote: > > > ...two of the original IP TLVs... > > IP Internal Reachability (Type 128) and IP External Reachability > > (Type 130) [the only really significant difference between > > the two being that ExtReach could potentially use external > > non-comparable type metrics, > > while IntReach could not... and all reachability using > > internal metric type, from either TLV, is treated similarly... > > so the only distinguishing factor boils down to the > > external metric type or not] > > Just to be clear about this, these metrics are quite different. > The worst metric for an internal reachability is preferred over > the best metric in external. This could be visualized as an > extra 9th bit that is set for external and cleared for internal. > This would allow the two metrics to be mapped into a new > consistent value. I agree that the metrics (*if distinguished by a different metric type*) are quite different, but I also believe they are not different only based on which TLV they arrive on, and if they have the same metric type, then it doesn't matter if they're internalReach or externalReach... at least, that's my current understanding based on rfc1195 and some prior emails on this list. Could we agree on one of the prior sentences if it were changed to say: The worst metric for an internal reachability is preferred over the best metric in external . and, "External Reachability with internal metric type has the same preference as Internal Reachability." I believe that the worst metric for an internal reachability would not be preferred over a better metric in an external reachability if that external reachability metric was of internal type (?) I'm basing that on my reading of the NOTE on page 29 of rfc1195, where it says, if I'm interpreting it correctly :-), that internal routes from Internal Reachability (presumably with internal metric type since external metric type is illegal there) and external routes from External Reachability with metric type internal, are treated identically for the purpose of the order of preference of routes, and the Dijkstra calc. The terminology of all this can get quite confusing, with the terms external and internal applying to both reachability as well as the metric type. Looking back, I wish they could have used a different term for the metric type :-) > Any route learned from another protocol (BGP, Static, RIP) gets > an external: any route learned via the IGP gets an internalReach. > Of course, implementations have been known to import external > routes as Internal Reachability, but that was not the original > intention. Just curious... does anyone know why the original intent was to separate routes into different reachability types like that (if it is indeed true that the only practical difference from a route calc point of view is the metric type, not the reachability type) ? Was it an aid to network managers in wading through a bunch of show database output... help them pick out which routes were from another protocol, based on the reachability type? > There is an argument to be made that local policy should define > how metrics are mapped, and that since IS-IS is an IGP, we only > need to worry about local policy. However, I like to have some > guidelines on interoperation between metric types. It is bad > enough that we need to compare two types, with the 2 extra bits, > without adding an incomperable 3rd metric. I'm not quite sure I understand the last part about 3rd metric? As I understand it, today we have two reachability types and two metric types (internal reach, external reach, internal metric, external metric). With the new TE draft we now have a new unnamed extended reachability type and no explicit metric type... is that the third metric? And that's where some potential incompatabilities come in... if everyone agrees to treat the new extended one similarly to how they would treat the old internal reach with internal metrics, then we're fine, but if some folks continue with the external metric concept, encoding it in undocumented ways, then we'll have some interworking problems. My motivation was just to nail it down one way or the other... deprecate external metric type, or continue with it but document how to encode it inside the new extended reachability TLV so implementations will interwork. Thanks, dave h From jparker@axiowave.com Wed Jun 6 21:33:48 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 6 Jun 2001 16:33:48 -0400 Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt 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_01C0EEC7.FD536EE0 Content-Type: text/plain; charset="iso-8859-1" > I believe that the worst metric for an internal reachability would > not be preferred over a better metric in an external reachability > if that external reachability metric was of internal type (?) I'm > basing that on my reading of the NOTE on page 29 of rfc1195, > where it says, if I'm interpreting it correctly :-), that > internal routes from Internal Reachability (presumably with internal > metric type since external metric type is illegal there) and external > routes from External Reachability with metric type internal, > are treated identically for the purpose of the order of preference > of routes, and the Dijkstra calc. > > The terminology of all this can get quite confusing, with > the terms external and internal applying to both reachability > as well as the metric type. Looking back, I wish they > could have used a different term for the metric type :-) David - Have you had a chance to look over RFC 2966? This is probably the clearest discussion of the various combinations of infernal and extortion around. http://ietf.org/rfc/rfc2966.txt - jeff parker ------_=_NextPart_001_01C0EEC7.FD536EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt

 
> I believe that the worst metric for an internal = reachability would
> not be preferred over a better metric in an = external reachability
> if that external reachability metric was of = internal type (?)  I'm
> basing that on my reading of the NOTE on page = 29 of rfc1195,
> where it says, if I'm interpreting it correctly = :-), that
> internal routes from Internal Reachability = (presumably with internal
> metric type since external metric type is = illegal there) and external
> routes from External Reachability with metric = type internal,
> are treated identically for the purpose of the = order of preference
> of routes, and the Dijkstra calc.
>
> The terminology of all this can get quite = confusing, with
> the terms external and internal applying to = both reachability
> as well as the metric type. Looking back, I = wish they
> could have used a different term for the metric = type :-)

David -
        Have you = had a chance to look over RFC 2966?
This is probably the clearest discussion of the = various
combinations of infernal and extortion around.  =

        http://ietf.org/rfc/rfc2966.txt

- jeff parker

------_=_NextPart_001_01C0EEC7.FD536EE0-- From henk@Procket.com Wed Jun 6 23:15:49 2001 From: henk@Procket.com (Henk Smit) Date: Wed, 6 Jun 2001 15:15:49 -0700 (PDT) Subject: [Isis-wg] History of the External Metric Type? In-Reply-To: <3B1458C1.B37EC7A2@ma.ultranet.com> from "David Hudek" at May 29, 2001 07:19:45 PM Message-ID: <200106062215.f56MFnS00779@redd3174.procket.com> Hello Dave, > Before embarking on an ISIS implementation, I've been perusing > the wg mail archives, and I want to make sure I understand the > current status of the (effectively deprecated?) > "external metric type" indication (or perhaps more clearly, > the non-comparable metric type indication). I don't think the internal/external metric-type has been totally deprecated. It is still in the spec. And in fact, I tried to clarify it a little in rfc2966. > The following is my current understanding... please > let me know if it's correct or if I've gone delusional ;-) > (and if the latter, what the real situation is, thanks :-) ) > > When the spec was first defined, it was thought that > users might want to inject routes into ISIS from > other sources, and those other routes might come in > two flavors: > a) those using metrics which are directly comparable > with the metrics used by ISIS, and > b) those using metrics which are NOT comparable > with the metrics used by ISIS. > The "metric type" indication was defined as a mechanism > for distinguishing between these two types, with > the comparable metrics being identified as > "internal metric type", and the non-comparable metrics > being identified as "external metric type" > > Only the internal metric type was valid for IP Internal > Reachability information. Either internal or external > metric type would be valid for IP External Reachability > information. IP External Reachability info using > internal metric type would be treated similarly > to Internal Reachability info, but IP External Reachability > info would be less preferred if it used external > metric type instead. Correct. > Then, the RealWorld(TM) intervened :-) > > In the dominant early implementation (presumably cisco's), > the internal/external metric type field was accidentally ignored, > and all IP Reachability was treated as having internal > metric type. Yes. But there were in fact three things wrong: 1) older IOS ignored the internal/external-metric bit on receipt 2) older IOS would not mask out the first two bits (reserved and I/E bit), so during SPF, it would just use the 8-bit value. 3) when setting the I/E bit (doable via route-maps), it would set the wrong bit: it would set bit 8, in stead of bit 7. The result would be that if you would manually set the I/E bit, the metric would be increased by 128 (2^7). And when the receiving routers do their SPF computation, they would handle the prefix as if it had a way larger metric. By accident, the results would be pretty similar to what you would have gotten if you would have just given those prefixes lower preference because of the I/E bit. Lucky. Maybe if anyone is interested, cisco people can explain the current behaviour. > No one complained. > > It is presumed (known??) that this is because customers never > actually made use of the external metric type capability, rather > than because they did try to use it but then never noticed odd > but still workable routes chosen because of comparing what were > intended to be incomparable metrics. IMHO relying on redistribution and detailled redistribution features in particular, often points towards a bad network design. (Again, this is just my opinion). Leaking all specific routes is often not necessary. And if it is, it should be *reachability* information, not necessarily *routing* information. Using typical redistribution would cause all traffic to go to the closest redistribution-points. If you make metrics be advertised between routing domains to force some "further-exit routing" behaviour, you are making life more complex than probably necessary. Also, leaking metrics between routing domains will make it more likely that routing instability in one domain will cause instability in the other domain. Plus ISPs (the typical users of Integrated IS-IS), often carry as much information in BGP as they can. So if you *have* to redistribute something from outside your network, they rather redistribute it into BGP, in stead of their IGP. > As long as every interworking implementation calculated things > in the same manner, loops were avoided, and things worked out > in a manner satisfactory to the customers. > > Subsequent implementations by others either also ignored the > external metric type, or provided a configurable knob to turn > its recognition on/off for compatibility purposes and everyone > was(is) just turning it off. So far there has apparently not been > any hue and cry for the restoration of the capability, and > as a practical matter everyone is fine with only using > comparable metrics. FYI, about 2 years ago, there was one cisco customer that wanted the I/E metric bit to work. (Both for IP and CLNS routing). A knob was added to turn on the correct behaviour. (My excuses to the list for this vendor specific information). > Given that IP External Reachability with internal metrics > is treated similarly to IP Internal Reachability, and that > IP External Reachability with external metrics is not actually used > in practice, there no longer appears to be any significant difference > between IP Internal/External Reachability, and so no longer > any need for separate TLVs. Exactly. I have never really understood the need for both TLV128 and TLV130. This was also one of the reasons why we decided to not carry the I/E metric bit semantics forward into TLV135 (the new IP prefix TLV defined in the IS-IS TE extensions draft). (The most important reason was of course the fact that we had no bits left, and did not want to spend another byte per prefix). > Given all that, and being practical folks, as new enhancements > were proposed, they were(are) no longer explicitly including the > capability of distinguishing between internal/external metric type. > For instance, (if I'm reading it correctly) > the ISIS extensions for TE draft-rfc intentionally > leaves out any internal/external metric type, as well as > lumping together all IP Reachability into one (extended) type. > Going forward, the net effect seems to be a deprecation of the > comparable/noncomparable metric idea, in favor of all IP reachability > info using a single comparable metric type. Correct. It remains to be seen how long the old TLV128/TLV130 will stay around. My guess is it will be a long time ..... > There exists the possibility for subTLVs in the IP Extended > Reachability, > but so far no-one has publicly defined any subTLVs to revive the > internal/external (comparable/noncomparable) metric type distinction. > > The above is my best guess as to the current state of > affairs, treating what had been implied in some earlier emails > as explicitly true. How far off am I ? :-) You are correct. > Assuming that the above isn't too far off the mark, > assuming that implementations will not properly interwork if > they calculate routes differently (and that they will calculate > routes differently if one recognizes external metrics and > treats them differently from internal, while another does not > recognize external metrics or does but still treats them the same > as internal), See my explication about how interpreting the metric field as a simple 8-bit value in many cases gives a similar result as interpreting the I/E bit in the correct way. > would it be reasonable for the external > metric type to be "officially" deprecated and implementers > strongly encouraged to ignore the external metric type if > encountered (a "send yours as internal only, and ignore theirs" > sort of deal), treating all as internal metric type ? I have no opinion on that. And by judging the (lack of) responses to your email, nobody else on this list seems to care in particular for one way or another. I'm afaid you'll have to implement the I/E bit semantics, even though none of your customers will use it. Sorry. :-) henk. From henk@Procket.com Wed Jun 6 23:25:42 2001 From: henk@Procket.com (Henk Smit) Date: Wed, 6 Jun 2001 15:25:42 -0700 (PDT) Subject: [Isis-wg] Summary Address In-Reply-To: <20010606074246.16361.qmail@mailweb25.rediffmail.com> from "Purushothaman NandaKumaran" at Jun 06, 2001 07:42:46 AM Message-ID: <200106062225.f56MPgn00796@redd3174.procket.com> > I have some doubts in advertising summary routes. > > 1) Whether the configured summary address will go as IP internal or > external reachability information in the generated LSP's? Not defined anywhere, AFAIK. > 2) If some redistributed routes fall under the summary route > (redistributed routes will be sent as IP external reachability > information) and if some level 1 routes also > fall under the same > summary route (level 1 to level 2 which should go as IP internal > reachability information) > then how should we advertise that summary > route? Not defined anywhere, AFAIK. > Please clarify my doubts. See RFC1195. We quote the relevant section in rfc2966. RFC 1195 states this quite clearly in the note in paragraph 3.10.2, item 2c). This document does not alter this rule of preference. NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field), and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation. So for route computation, it doesn't matter if you advertise your summaries as TVL128 or TVL130. So if it doesn't create routing loops, doesn't create suboptimal routing, and doesn't create interoperability problems, this problem is non-relevant. Some routers can advertise their summaries in TVL128, some might advertise summaries in TVL130. No problem. Pick whatever you like best ..... Hope this helps. henk. From henk@Procket.com Wed Jun 6 23:32:40 2001 From: henk@Procket.com (Henk Smit) Date: Wed, 6 Jun 2001 15:32:40 -0700 (PDT) Subject: [Isis-wg] Summary Address In-Reply-To: from "Jeff Parker" at Jun 06, 2001 09:54:49 AM Message-ID: <200106062232.f56MWeU00814@redd3174.procket.com> > As to point 1, I would assume that routes preserve 'type', > but I can't cite chapter and verse to defend this. Would be nice if you do this, but only for administrative purposes, like debugging. No need to bother if all you care about is preventing routing loops and interoperability. Come to think of it, the subject of summaries might become a little more tricky once you have to deal with L2->L1 leaked routes. henk. From jparker@axiowave.com Wed Jun 6 23:52:25 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 6 Jun 2001 18:52:25 -0400 Subject: [Isis-wg] Summary Address 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_01C0EEDB.5B175C40 Content-Type: text/plain; charset="iso-8859-1" > Come to think of it, the subject of summaries might become > a little more tricky once you have to deal with L2->L1 leaked > routes. > > henk. I would assume we should prohibit a L2->L1 route from being summarized in L1. - jdp ------_=_NextPart_001_01C0EEDB.5B175C40 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Summary Address

>   Come to think of it, the subject of summaries might become
>  a little more tricky once you have to deal with L2->L1 leaked
>  routes.
>
>      henk.

I would assume we should prohibit a L2->L1 route from being
summarized in L1. 

- jdp

------_=_NextPart_001_01C0EEDB.5B175C40-- From henk@Procket.com Thu Jun 7 00:21:11 2001 From: henk@Procket.com (Henk Smit) Date: Wed, 6 Jun 2001 16:21:11 -0700 (PDT) Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt In-Reply-To: <3B1D92CC.9E0DC03@ma.ultranet.com> from "David Hudek" at Jun 05, 2001 07:17:48 PM Message-ID: <200106062321.f56NLBe01001@redd3174.procket.com> > The latest ISIS TE draft I could find is the one mentioned in the > subject. Assuming that's the latest, or that a later one has > similar treatment (non-treatment) of external metric type, I'd like > to offer the following comments/suggestions. Yes, version 02 is the lastest. I have been planning on releasing a 03 version for a long time. It will only have marginal changes (wording, not really semantics). RealSoonNow (sorry for the delay ....). > First, let me say I'm no big fan of the external metric type, and > it wouldn't bother me if it were to just fade away. If the whole world moves to TLV22 and TVL135, the old TLVs TLV128 and TLV130 might go away. But I don't see that happening. So whatever we decide to do in the future, the fact will always remain that you will have to implement the old behaviour from RFC1195, for backwards compatability. No matter what. > However, I'm more concerned with implementations' interoperability, > and so if it is going away, I'd like to see it do so in an orderly > manner. If it's not going away, I'd like to see it defined in the > relevant message. RFC1195 defines behaviour. I tried to clarify all route and metric types, and their preferences in RFC2966. I assume you read RFC2966. If not, please read it and tell us what parts you think are not clear. (I'm sorry if I messed up and blew the chance we had to clarify it). > It's troubling to read of some folks just picking undocumented random > bits in the message to indicate metric type, > while others do nothing and ignore it, Are you refering to the old cisco behaviour of picking bit-8 as the I/E bit, in stead of bit-7 ? That is clearly a bug, not picking random undocumented bits. > and some talk of using an unspecified subTLV. This has been suggested to people who wanted I/E metric-type semantics in TLV135. That doesn't meant they implemented it, or their customers deployed it. I would assume that if anyone would implent something like this, they would try to document it before letting their customers deploy it on a grand scale. > Besides other nice stuff, the new Extended TLV uses a wider metric. > To my knowledge, no official subTLVs have been defined for it, Correct. > and it intentionally makes no mention of the metric type. The rationale > mentioned so far for this omission is that no one is using the > non-comparable "external" metric type, Correct. Plus we didn't have a spare bit. Plus we (the draft authors) didn't like to add complexity with little gain. So far no one has been able to convince the working group that we absolutely need I/E metric-type. > and implementers could just > assume that info supplied via the Extended IP Reachability TLV > should be treated as though it had comparable "internal" metrics. No sure what you mean here ? TLV128/TLV130 are to be seen totally disjunct from TLV135. Networks should not be combining them. (Maybe they can be flooded in parallel while a network migrates from the old to the new TLVs, but you should *never* have some routers use the old metrics during SPF, and some other routers the new metrics). > However, that sort of advice has only been given via the mailing list > and is not part of the (draft) rfc itself, where a future implementer > could readily find it. I tried to clarify all route-types and metric-types from RFC1195, plus "route leaking" in RFC2966. The TE-extensions TLVs are totally disjunct from that. > Also, it is not clear that the rationale is > correct, since at least one person posted to the list in the past that > they intended to make use of some otherwise unused bit to indicate the > external metric type in their implementation. Others have mentioned > using an undocumented subTLV type. As long as they don't post a draft, and don't pass the requirements to turn the draft into an RFC (even an experimental rfc), they can not go tell their customers anything else but that they have implemented a proprietary extension. Nothing wrong with proprietary extensions, but customers might decide not to bother with the hassle. > Can we decide if external metric type is *actually required* > (seems to be some disagreement?), and either: > > a) explicitly deprecate it in the TE spec. > Some verbiage to the effect that the external metric > type is no longer supported, and any metrics > received via the Extended IP Reachability TLV > MUST be treated as having comparable ("internal") > metrics (is there anyone on the list who would > strongly oppose such a thing?) > > OR > > b) explicitly specify a subTLV in which to convey the > metric type. For a stake in the ground, how about > something like the following (using least sig bit > in the value as internal/external type, other bits > sent as zero and ignored upon receipt), and since > we only need one bit and it seems so wasteful to > spend 3 octets to convey one bit's worth of data, > possibly generalize the new subTLV into an > "Extended Control Info" type for future general use > of the other bits if needed? : > > Extended Control Type SubTLV > Sub-TLV Type: 1 > Sub-TLV Length: 1 > Sub-TLV Values: 0 if metric is comparable (internal type) > 1 if metric is non-comparable (external > type) > > If someone really really demanded symmetry with the > old TLVs, one could use the second least sig bit > to indicate internal or external reachability, > but it's not clear that buys you anything?... > (but for completeness, could use these values instead, > with the upper 6 bits reserved, zeroed on send, ignored on > receipt) > 00 - metric is internal reach/comparable metric type > 01 - metric is internal reach/non-comparable metric type > (illegal?) > 10 - metric is external reach/comparable metric type > 11 - metric is external reach/non-comparable metric type) > > > If it's true that there's no real justification for external metric > type, > then I'd favor (a). If there are valid reasons for having it, then I'd > favor something along the lines of (b) with things at least nailed down > sufficiently for an implementation. When you write an ISIS implementation that is supposed to be compatible with RFC1195 and RFC2966, you better implement external metric. Sorry. When you implement the extensions from the te-draft, you can forget about I/E metrics. If you wanna be compatible with both, you better implement both algorithms. Not really rocket-science, IMHO, just a small matter of coding. :-) Hope this helps, henk. From dhudek@ma.ultranet.com Thu Jun 7 06:03:08 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Wed, 06 Jun 2001 22:03:08 -0700 Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt Message-ID: <3B1F0B0C.36CA2B5B@ma.ultranet.com> Hi Henk, Thanks for the info. Regarding the metric types, as a new reader of the draft, I interpreted the new Extended Reach as the successor to the old 128/130 and assumed (always dangerous! :-)) that the old semantics applied to the new TLV unless otherwise noted (and then wondered where the darn metric type info had hidden :-)). I wonder, since there is already some text about how the new Extended Reachability differs from the old TLVs (e.g., wider metric, upDown bit, different prefix encoding), and given that there have been a few folks asking about the metric type, could perhaps a simple sentence about no differing metric type support be added? No biggie since I now understand the intent, but it might help in the future. >> and implementers could just >> assume that info supplied via the Extended IP Reachability TLV >> should be treated as though it had comparable "internal" metrics. > > No sure what you mean here ? > TLV128/TLV130 are to be seen totally disjunct from TLV135. > Networks should not be combining them. (Maybe they can be flooded > in parallel while a network migrates from the old to the new TLVs, > but you should *never* have some routers use the old metrics during > SPF, and some other routers the new metrics). What I was trying to get at here is the question of what the preference rules should be in an environment where there is no longer such a thing as a metric type (since the existing rules take the metric type into account, but the new Extended Reach has no metric type information). What I think was suggested was to take the old preference rules, throw out those that keyed off of external metric type, and use those rules that only depended on internal metric type as though the metric in the Extended Reach is comparable (as though internal type). If I've read RFC2966 properly, it appears that the only key pieces of information in the preference rules are the LSP Level, the UpDown bit, and the metric type (other info, such as TLV type boils away)... yielding something like the following: Pref 1: L1 IntMet UD0 (128 or 130 a dont-care) Pref 2: L2 IntMet UD0 (128 or 130 a dont-care) Pref 3: L1 IntMet UD1 (128 or 130 a dont-care) Pref 4: L1 ExtMet UD0 Pref 5: L2 ExtMet UD0 Pref 6: L1 ExtMet UD1 where UD# is updown status 0 or 1, IntMet/ExtMet are internal/external metric type. Is it envisioned that the preference rules after switching to the Extended Reach will be like the first three, so something like Pref 1: L1 UD0 Pref 2: L2 UD0 Pref 3: L1 UD1 or is something different planned? Is there any documentation that discusses what the preference rules should be when running with the new Extended Metric TLV? Thanks, dave h From henk@Procket.com Thu Jun 7 05:25:41 2001 From: henk@Procket.com (Henk Smit) Date: Wed, 6 Jun 2001 21:25:41 -0700 (PDT) Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt In-Reply-To: <3B1F0B0C.36CA2B5B@ma.ultranet.com> from "David Hudek" at Jun 06, 2001 10:03:08 PM Message-ID: <200106070425.f574PgZ01488@redd3174.procket.com> > I wonder, since there is already some > text about how the new Extended Reachability differs > from the old TLVs (e.g., wider metric, upDown bit, > different prefix encoding), and given that there have > been a few folks asking about the metric type, could > perhaps a simple sentence about no differing metric type > support be added? No biggie since I now understand the > intent, but it might help in the future. OK, will do. > What I was trying to get at here is the question of what > the preference rules should be in an environment where there > is no longer such a thing as a metric type (since the existing > rules take the metric type into account, but the new Extended Reach > has no metric type information). What I think was suggested > was to take the old preference rules, throw out > those that keyed off of external metric type, and > use those rules that only depended on internal metric type > as though the metric in the Extended Reach is > comparable (as though internal type). Yes. Everything the same order, just simplified by having less types of routes. > If I've read RFC2966 properly, it appears that the only > key pieces of information in the preference rules are > the LSP Level, the UpDown bit, and the metric type > (other info, such as TLV type boils away)... yielding > something like the following: > > Pref 1: L1 IntMet UD0 (128 or 130 a dont-care) > Pref 2: L2 IntMet UD0 (128 or 130 a dont-care) > Pref 3: L1 IntMet UD1 (128 or 130 a dont-care) > Pref 4: L1 ExtMet UD0 > Pref 5: L2 ExtMet UD0 > Pref 6: L1 ExtMet UD1 > > where UD# is updown status 0 or 1, IntMet/ExtMet are > internal/external metric type. I think RFC2966 is very precise on that. See paragraph 3.2, called Order of preference for all types of IP routes in IS-IS. --snip---- Based on these assumptions, this document defines the following route preferences. 1) L1 intra-area routes with internal metric L1 external routes with internal metric 2) L2 intra-area routes with internal metric L2 external routes with internal metric L1->L2 inter-area routes with internal metric L1->L2 inter-area external routes with internal metric 3) L2->L1 inter-area routes with internal metric L2->L1 inter-area external routes with internal metric 4) L1 external routes with external metric 5) L2 external routes with external metric L1->L2 inter-area external routes with external metric 6) L2->L1 inter-area external routes with external metric --snip---- So that is very similar to what you describe. > Is it envisioned that the preference rules after > switching to the Extended Reach will be like the > first three, so something like > Pref 1: L1 UD0 > Pref 2: L2 UD0 > Pref 3: L1 UD1 Correct. Otherwise you get routing loops. > or is something different planned? > Is there any documentation that discusses > what the preference rules should be when running > with the new Extended Metric TLV? I had thought it was clear. I will add some text in the upcoming version of the draft. henk. From purush_isis@rediffmail.com Thu Jun 7 05:32:37 2001 From: purush_isis@rediffmail.com (Purushothaman NandaKumaran) Date: 7 Jun 2001 04:32:37 -0000 Subject: [Isis-wg] Summary Address Message-ID: <20010607043237.16049.qmail@mailweb4.rediffmail.com> Hi all, Thanks for replying. My doubt got extended. What happens if some external route with external metric falls on that summary route? Can we make metric and metric type configurable in the summary address table of the mib and leave the problem to the administrator? thanks with best regards, Purush ------------- Original Message -------------- Henk Smit wrote: To:purush_isis@rediffmail.com (Purushothaman NandaKumaran) From:Henk Smit Date:Wed, 6 Jun 2001 15:25:42 -0700 (PDT) CC:isis-wg@spider.juniper.net (isis-wg@external.juniper.net) Subject:Re: [Isis-wg] Summary Address > I have some doubts in advertising summary routes. > > 1) Whether the configured summary address will go as IP internal or > external reachability information in the generated LSP's? Not defined anywhere, AFAIK. > 2) If some redistributed routes fall under the summary route > (redistributed routes will be sent as IP external reachability > information) and if some level 1 routes also > fall under the same > summary route (level 1 to level 2 which should go as IP internal > reachability information) > then how should we advertise that summary > route? Not defined anywhere, AFAIK. > Please clarify my doubts. See RFC1195. We quote the relevant section in rfc2966. RFC 1195 states this quite clearly in the note in paragraph 3.10.2, item 2c). This document does not alter this rule of preference. NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field), and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation. So for route computation, it doesn't matter if you advertise your summaries as TVL128 or TVL130. So if it doesn't create routing loops, doesn't create suboptimal routing, and doesn't create interoperability problems, this problem is non-relevant. Some routers can advertise their summaries in TVL128, some might advertise summaries in TVL130. No problem. Pick whatever you like best ..... Hope this helps. henk. _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com From henk@Procket.com Thu Jun 7 05:40:17 2001 From: henk@Procket.com (Henk Smit) Date: Wed, 6 Jun 2001 21:40:17 -0700 (PDT) Subject: [Isis-wg] Summary Address In-Reply-To: <20010607043237.16049.qmail@mailweb4.rediffmail.com> from "Purushothaman NandaKumaran" at Jun 07, 2001 04:32:37 AM Message-ID: <200106070440.f574eHJ01545@redd3174.procket.com> > What happens if some external route with external metric falls on > that summary route? Summary-addresses are advertised in combination with a metric. If you have 10 routes that are more specific to that summary-address, each route with a different metric, what metric will you choose to be advertised for the summary ? Answer is simple: you take the lowest metric of all metrics associated with all the more specifics. Apply that rule to the internal/external metric-type situation ..... You can view internal metrics as metrics that are always lower (better) than any external metrics. So if you apply the rule above to the internal/external metric-type situation, it is easy to see that if a summary has some specifics with internal metric and some specifics with external metric, the logic forces you to advertise the summary with an internal metric. > Can we make metric and metric type configurable in the summary > address table of the mib and leave the problem to the administrator? Ugh. A very cowardly solution. :-) ;-) As I explain above, there is no need to leave this unsolved. henk. From dhudek@ma.ultranet.com Thu Jun 7 21:53:36 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Thu, 07 Jun 2001 13:53:36 -0700 Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-02.txt References: <200106070425.f574PgZ01488@redd3174.procket.com> Message-ID: <3B1FE9D0.4DE63A00@ma.ultranet.com> Henk Smit wrote: > > Is it envisioned that the preference rules after > > switching to the Extended Reach will be like the > > first three, so something like > > Pref 1: L1 UD0 > > Pref 2: L2 UD0 > > Pref 3: L1 UD1 > > Correct. Otherwise you get routing loops. > > > or is something different planned? > > Is there any documentation that discusses > > what the preference rules should be when running > > with the new Extended Metric TLV? > > I had thought it was clear. I will add some text in the upcoming > version of the draft. Great, thanks... It certainly is the reasonable pref order, and is implied in several places, but I think that making it crystal clear with an explicit statement would be a GoodThing Either stating them for the new Extended Reachability universe, or a simple statement that the preference rules in rfc2966 will apply using the interpretation that routes learned via the Extended Reach must be treated as though they had an internal metric type for the purpose of preference calculations ? Otherwise, someone could argue that the preference order is unspecified, since none of the rules mentioned earlier --snip---- Based on these assumptions, this document defines the following route preferences. 1) L1 intra-area routes with internal metric L1 external routes with internal metric 2) L2 intra-area routes with internal metric L2 external routes with internal metric L1->L2 inter-area routes with internal metric L1->L2 inter-area external routes with internal metric 3) L2->L1 inter-area routes with internal metric L2->L1 inter-area external routes with internal metric 4) L1 external routes with external metric 5) L2 external routes with external metric L1->L2 inter-area external routes with external metric 6) L2->L1 inter-area external routes with external metric --snip---- actually apply, since none of them match an unspecified metric type (all require either internal or external for a match), and the Extended Reach currently has an unspecified metric type. The ordering for Extended Reach is strongly implied by the first and fourth assumptions in the paragraph prior to the above rule set, but after painful experiences with some other protocols where things were assumed or implied but not specified, I suppose I've become paranoid :-) Thanks, dave h From ginsberg@pluris.com Fri Jun 8 01:50:25 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Thu, 7 Jun 2001 17:50:25 -0700 Subject: [Isis-wg] TLV Assignment Conflict Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A412@avalon.pluris.com> > 2. Optional checksums goes last call, no comments since a while, > implementation works from all I heard. > Sorry for the VERY belated response here, but I just noticed this issue on a recent review of the revised second edition draft of ISO 10589. There is a TLV assignment conflict between the TLV assigned in TLV Type = 12 and the new TLVs introduced by the SIF work on mismatched LSPBufferSize which were assigned TLV Type 12 - originatingL1LSPBufferSize TLV Type 13 - originatingL2LSPBufferSize As a matter of history, the SIF proposal was published in 1998 both within SIF and to this group. The new TLVs are now part of the revised Second Edition draft of ISO 10589 which is pretty much in its final form and winding its way through the ISO approval process. I would not begin to speculate on the number of implementations affected by a change to one or the other - but clearly some folks are going to be affected by whichever TLV is reassigned. Given that no entity/person has taken responsibility for assigning TLV codes, I suppose this was inevitable - and I am not sure how this gets resolved - but clearly it needs to be resolved. It is unfortunate that no one, including myself, ever noticed this before, but... Les From dhudek@ma.ultranet.com Fri Jun 8 21:41:57 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Fri, 08 Jun 2001 13:41:57 -0700 Subject: [Isis-wg] [Fwd: Question/Comment on draft-ietf-isis-wg-mib-04.txt] References: Message-ID: <3B213895.F816FAAF@ma.ultranet.com> > Jeff Parker wrote: > Any comments from the list about the relevance > of summaries from {L1, L2} into {L1, L2}? > (That is, which of the four possibilities make sense) > Does it make sense to summarize L2 into L1? I'll take a stab at this... Of the possible combinations {L1,L2} into {L1,L2}, I believe that L1->L2 and L2->L1 are already specified (in rfc1195 and rfc2966) I'm not sure L1->L1 or L2->L2 makes sense? At least, I can't find any specification for L1->L1 or L2->L2 summarization in the ISIS rfcs. As far as I know, only two of the four combinations are "legal" That brings up the question of other combinations, though, which as far as I know, have been implementation dependent? Would it be a good or bad idea to standardize them a bit and possibly include them in the ISIS MIB? Such as summarizing other protocols' routes when injecting/redistributing them into a particular level of ISIS. Say, one wanted to inject BGP routes into L2 ISIS, but was willing to sacrifice some accuracy for better scalability by summarizing those routes first. I don't see a mechanism in the MIB for doing that? One might have four summarization types: L1ToL2, L2ToL1, OtherProtToL1, OtherProtToL2. But that opens a can of worms... what if one wanted different rules for different "other" protocols... would there need to be separate types for each and every other protocol to L1 and L2 ISIS... or would just one type which applied to all other protocols be satisfactory? Thanks, dave h From dhudek@ma.ultranet.com Fri Jun 8 22:10:43 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Fri, 08 Jun 2001 14:10:43 -0700 Subject: [Isis-wg] [Fwd: Question/Comment on draft-ietf-isis-wg-mib-04.txt] References: Message-ID: <3B213F53.3585C578@ma.ultranet.com> There was discussion on another thread ("Summary Address") that might affect the MIB as well... In discussing how one ought to advertise a summary address, a suggestion was made (paraphrasing here...) to advertise the summary address using the lowest metric from among those routes that matched the summary. My understanding from rfc1195 (section 3.2) was that one should instead advertise the summary using a set metric which was manually configured (and the draft MIB has such a field... the isisSummAddrDefaultMetric) Actually, 1195 does use the word "may" in there somewhere :-) so there's a fair amount of leeway in how folks implement it. I was wondering if it might not be a good idea to make it explicit how one was summarizing, and perhaps add to the MIB either a control knob (telling ISIS how to summarize: a)use configured metric as specified in the isisSummAddrTable, b)ignore it and aggressively use the smallest metric from among the routes which match, or c)ignore it and conservatively use the largest metric from among the routes which match), or alternatively a read-only value in which the ISIS implementation just tells which scheme it is using but cannot be told to act differently. I think a network administrator might be confused/upset if they set the metric value in the table, assuming it would be used, but then the implementations do something different. If neither the control knob nor the information field seem appropriate, perhaps the text surrounding the metric field in the summary table should be modified to say that this is only a suggested metric and that implementations may do something different? Thanks, dave h From dhudek@ma.ultranet.com Mon Jun 11 04:00:36 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Sun, 10 Jun 2001 20:00:36 -0700 Subject: [Isis-wg] Other than 6 octet ID ? Message-ID: <3B243454.482C3C41@ma.ultranet.com> Hi all, As I understand it, the ISIS specification allows the ID field of a NET to vary from between 1 to 8 octets, with the constraint that everyone within a routing domain must use the same ID size. Is anyone anywhere actually using an ID size other than 6 octets? Would it be correct to say that as a practical matter the ID is fixed at 6 octets? Or are alternate ID sizes commonly deployed in real networks? adTHANKSvance, dave h From mshand@cisco.com Mon Jun 11 13:49:44 2001 From: mshand@cisco.com (mike shand) Date: Mon, 11 Jun 2001 13:49:44 +0100 Subject: [Isis-wg] Other than 6 octet ID ? In-Reply-To: <3B243454.482C3C41@ma.ultranet.com> Message-ID: <4.3.2.7.2.20010611134855.03469d70@jaws.cisco.com> At 20:00 10/06/2001 -0700, David Hudek wrote: >Hi all, > >As I understand it, the ISIS specification allows the ID field >of a NET to vary from between 1 to 8 octets, with the constraint >that everyone within a routing domain must use the same ID size. > >Is anyone anywhere actually using an ID size other than 6 octets? >Would it be correct to say that as a practical matter the >ID is fixed at 6 octets? I believe that is the case, unless someone can prove me wrong. Mike > Or are alternate ID sizes commonly >deployed in real networks? > >adTHANKSvance, >dave h >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Larmer@CommSense.Net Tue Jun 12 17:12:04 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Tue, 12 Jun 2001 12:12:04 -0400 Subject: [Isis-wg] L2 LSP Area Address TLV Message-ID: Hi, I am in doubt about the use of the L2 LSP Area Address TLV? ISO-10589-06n1704 states the following: 7.3.9 Generation of level 2 LSPs (non-pseudonode) - In the Area Addresses option — the set of partitionAreaAddresses for this intermediate system as described in 7.2.10.3 7.2.10.3 Computation of partition area addresses For systems which do not implement partition repair, the value of partitionAreaAddresses is identical to the value computed for areaAddresses as described in 7.2.11. 7.2.11 Computation of area addresses A Level 1 or Level 2 Intermediate System shall compute the values of areaAddresses (the set of area addresses for this Level 1 area), by forming the union of the sets of manualAreaAddresses reported in the Area Addresses field of all Level 1 LSPs with LSP number zero in the local Intermediate system’s link state database. NOTES 18 This includes all source systems, whether currently reachable or not. It also includes the local Intermediate system’s own Level 1 LSP with LSP number zero. 7.1.5 Manual area addresses ...Each level 1 IS distributes its manualAreaAddresses in its Level 1 LSP’s Area Addresses field, thus allowing level 2 ISs to create a composite list of all area addresses in use within a given area. Level 2 ISs in turn advertise the composite list throughout the level 2 subdomain by including it in their Level 2 LSP’s Area Addresses field, thus distributing information on all the area addresses associated with the entire routeing domain. ... 7.2.9.2 Setting the attached flag in level 2 intermediate systems When executing the level 2 decision process for each supported metric, level 2 IS shall ascertain whether or not it can reach any destinations outside its area using that metric. The IS considers itself attached if either: a) it can reach at least one other area using the coresponding routeing metric, or b) it has at least one enabled reachable address prefix with the corresponding metric defined. Otherwise the IS considers itself not attached. END OF ISO-10589 REFERENCES: What I am seeing on a well known implementation of Int IS-IS is that when an IS has no L1 adjacencies, the L2 LSP being generated does not contain the Area Address TLV. The spec states that an LSP should be generated but not transmitted unless it has an adjacency! So there should always be a L1 LSP number = 0 for each IS with IS-type = L1 or L1/L2. 1. Is this the correct behavior or should the area address TLV always be present in an L2 LSP? 2. What is the Area Address TLV used for when contained within a L2 LSP? I can think of the following two purposes: a Calculation of NSAP based routes and subsequent forwarding of CLNS packets. b. Determining if an IS is connected to another L2 area as stated above? So, should each L2 LSP contain an Area Address TLV regardless of the L1 adjacencies it possesses. If not, I would think (as I have observed) this would break the rules for determining when to set the Attached bit! Cheers, Ken Larmer From cmartin@gnilink.net Tue Jun 12 17:42:11 2001 From: cmartin@gnilink.net (Martin, Christian) Date: Tue, 12 Jun 2001 12:42:11 -0400 Subject: [Isis-wg] Other than 6 octet ID ? Message-ID: <94B9091E1149D411A45C00508BACEB359CDBC3@entmail.gnilink.com> I recall Radia saying at one point that the variable length system ID was a bad idea. I wonder if the new 10589 spec will change this to make it static at 6 octets? -chris > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Monday, June 11, 2001 8:50 AM > To: David Hudek > Cc: isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Other than 6 octet ID ? > > > At 20:00 10/06/2001 -0700, David Hudek wrote: > >Hi all, > > > >As I understand it, the ISIS specification allows the ID field > >of a NET to vary from between 1 to 8 octets, with the constraint > >that everyone within a routing domain must use the same ID size. > > > >Is anyone anywhere actually using an ID size other than 6 octets? > >Would it be correct to say that as a practical matter the > >ID is fixed at 6 octets? > > I believe that is the case, unless someone can prove me wrong. > > Mike > > > Or are alternate ID sizes commonly > >deployed in real networks? > > > >adTHANKSvance, > >dave h > >_______________________________________________ > >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 mshand@cisco.com Tue Jun 12 17:59:45 2001 From: mshand@cisco.com (mike shand) Date: Tue, 12 Jun 2001 17:59:45 +0100 Subject: [Isis-wg] Other than 6 octet ID ? In-Reply-To: <94B9091E1149D411A45C00508BACEB359CDBC3@entmail.gnilink.com > Message-ID: <4.3.2.7.2.20010612175635.03448340@jaws.cisco.com> At 12:42 12/06/2001 -0400, Martin, Christian wrote: >I recall Radia saying at one point that the variable length system ID was a >bad idea. I wonder if the new 10589 spec will change this to make it static >at 6 octets? Of course it was a bad idea, but at the time there were those on the ISO committee who wanted it. There were actually two camps. Those who wanted a shorter ID (3 octets as I recall), and those who wanted a longer (8 octets). The only way to get the standards to progress was to accommodate them in such a way that it didn't change the normal 6 octet usage. However, I'd be very surprised in V2 could reverse this. It really doesn't matter provided that nobody implements it. Mike > -chris > > > -----Original Message----- > > From: mike shand [mailto:mshand@cisco.com] > > Sent: Monday, June 11, 2001 8:50 AM > > To: David Hudek > > Cc: isis-wg@spider.juniper.net > > Subject: Re: [Isis-wg] Other than 6 octet ID ? > > > > > > At 20:00 10/06/2001 -0700, David Hudek wrote: > > >Hi all, > > > > > >As I understand it, the ISIS specification allows the ID field > > >of a NET to vary from between 1 to 8 octets, with the constraint > > >that everyone within a routing domain must use the same ID size. > > > > > >Is anyone anywhere actually using an ID size other than 6 octets? > > >Would it be correct to say that as a practical matter the > > >ID is fixed at 6 octets? > > > > I believe that is the case, unless someone can prove me wrong. > > > > Mike > > > > > Or are alternate ID sizes commonly > > >deployed in real networks? > > > > > >adTHANKSvance, > > >dave h > > >_______________________________________________ > > >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 mshand@cisco.com Tue Jun 12 18:09:15 2001 From: mshand@cisco.com (mike shand) Date: Tue, 12 Jun 2001 18:09:15 +0100 Subject: [Isis-wg] L2 LSP Area Address TLV In-Reply-To: Message-ID: <4.3.2.7.2.20010612180449.033ae008@jaws.cisco.com> Ken, While what you describe is the "correct" behaviour, there are some advantages to not advertising the area addresses of an isolated L1 router, since this give some rudimentary protection against area partitioning. The thought is that there is probably some other larger portion of the L1 area, and not advertising the area address for this stub, prevents traffic for the area being erroneously directed to this sub-functional router. Of course if this really is the ONLY router in the L1 area, then you might actually want the traffic. I think most well known IS-IS implementations probably have a way to turn off this feature if required. Mike At 12:12 12/06/2001 -0400, Ken Larmer wrote: >Hi, > > I am in doubt about the use of the L2 LSP Area Address TLV? > >ISO-10589-06n1704 states the following: > >7.3.9 Generation of level 2 LSPs (non-pseudonode) > >- In the Area Addresses option — the set of partitionAreaAddresses >for this >intermediate system as described in 7.2.10.3 > >7.2.10.3 Computation of partition area addresses > >For systems which do not implement partition repair, the value of >partitionAreaAddresses is identical to the value computed for areaAddresses >as described in 7.2.11. > >7.2.11 Computation of area addresses > >A Level 1 or Level 2 Intermediate System shall compute the values of >areaAddresses (the set of area addresses for this Level 1 area), by forming >the union of the sets of manualAreaAddresses reported in the Area Addresses >field of all Level 1 LSPs with LSP number zero in the local Intermediate >system’s link state database. > >NOTES > >18 This includes all source systems, whether currently reachable or not. It >also includes the local Intermediate system’s own Level 1 LSP with LSP >number zero. > >7.1.5 Manual area addresses > >...Each level 1 IS distributes its manualAreaAddresses in its Level 1 LSP’s >Area Addresses field, thus allowing level 2 ISs to create a composite list >of all area addresses in use within a given area. Level 2 ISs in turn >advertise the composite list throughout the level 2 subdomain by including >it in their Level 2 LSP’s Area Addresses field, thus distributing >information on all the area addresses associated with the entire routeing >domain. ... > >7.2.9.2 Setting the attached flag in level 2 intermediate systems > >When executing the level 2 decision process for each supported metric, level >2 IS shall ascertain whether or not it can reach any destinations outside >its area using that metric. The IS considers itself attached if either: > >a) it can reach at least one other area using the coresponding routeing >metric, or >b) it has at least one enabled reachable address prefix with the >corresponding metric defined. > >Otherwise the IS considers itself not attached. > >END OF ISO-10589 REFERENCES: > > > > What I am seeing on a well known implementation of Int IS-IS is > that when >an IS has no L1 adjacencies, the L2 LSP being generated does not contain the >Area Address TLV. The spec states that an LSP should be generated but not >transmitted unless it has an adjacency! So there should always be a L1 LSP >number = 0 for each IS with IS-type = L1 or L1/L2. > >1. Is this the correct behavior or should the area address TLV always be >present in an L2 LSP? >2. What is the Area Address TLV used for when contained within a L2 LSP? I >can think of the following two purposes: > a Calculation of NSAP based routes and subsequent forwarding of CLNS >packets. > b. Determining if an IS is connected to another L2 area as stated > above? > >So, should each L2 LSP contain an Area Address TLV regardless of the L1 >adjacencies it possesses. If not, I would think (as I have observed) this >would break the rules for determining when to set the Attached bit! > >Cheers, >Ken Larmer > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mbartell@cisco.com Tue Jun 12 19:26:24 2001 From: mbartell@cisco.com (Micah Bartell) Date: Tue, 12 Jun 2001 13:26:24 -0500 Subject: [Isis-wg] Other than 6 octet ID ? In-Reply-To: <94B9091E1149D411A45C00508BACEB359CDBC3@entmail.gnilink.com > Message-ID: <4.3.2.7.2.20010612130429.02163120@cactus.cisco.com> Christian, Section 7.1.3.2 will read: ID System identifier a variable length field from 1 to 8 octets (inclusive). Each routeing domain employing this protocol shall select a single size for the ID field and all Intermediate systems in the routeing domain shall use this length for the system IDs of all systems in the routeing domain. The set of ID lengths supported by an implementation is an implementation choice, provided that at least one value in the permitted range can be accepted. The routeing domain administrator must ensure that all ISs included in a routeing domain are able to use the ID length chosen for that domain. As you can see, we are still allowing variable length, but it is implementation dependent on what size you support. It just so happens that 6 is what everyone supports. Variable length systemID's are definitely of questionable value, but since we have not had an issue with it, it is easier to let it just remain. /mpb At 12:42 06/12/2001 -0400, Martin, Christian wrote: >I recall Radia saying at one point that the variable length system ID was a >bad idea. I wonder if the new 10589 spec will change this to make it static >at 6 octets? > > -chris > > > -----Original Message----- > > From: mike shand [mailto:mshand@cisco.com] > > Sent: Monday, June 11, 2001 8:50 AM > > To: David Hudek > > Cc: isis-wg@spider.juniper.net > > Subject: Re: [Isis-wg] Other than 6 octet ID ? > > > > > > At 20:00 10/06/2001 -0700, David Hudek wrote: > > >Hi all, > > > > > >As I understand it, the ISIS specification allows the ID field > > >of a NET to vary from between 1 to 8 octets, with the constraint > > >that everyone within a routing domain must use the same ID size. > > > > > >Is anyone anywhere actually using an ID size other than 6 octets? > > >Would it be correct to say that as a practical matter the > > >ID is fixed at 6 octets? > > > > I believe that is the case, unless someone can prove me wrong. > > > > Mike > > > > > Or are alternate ID sizes commonly > > >deployed in real networks? > > > > > >adTHANKSvance, > > >dave h > > >_______________________________________________ > > >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 purush_isis@rediffmail.com Wed Jun 13 10:44:55 2001 From: purush_isis@rediffmail.com (Purushothaman NandaKumaran) Date: 13 Jun 2001 09:44:55 -0000 Subject: [Isis-wg] External Metrics Message-ID: <20010613094455.8144.qmail@mailweb29.rediffmail.com> Hi All, This doubt is regarding external reachability TLV's information going in the LSPS with the external metric type. In what situation a router will originate this kind of TLVs?. (If it is based on configuration please tell me when the administrator wants to send such routes as external metrics) Is it anyway related to the Type 1 and Type 2 external metrics in OSPF context?. That is the route is in another autonomous system and the metric to the destination is not correctly predictable. Thanks in Advance, with best regards, Purush _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com From Radia Perlman - Boston Center for Networking Mon Jun 11 18:29:58 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Mon, 11 Jun 2001 13:29:58 -0400 (EDT) Subject: [Isis-wg] Other than 6 octet ID ? Message-ID: <200106111729.NAA06541@bcn.East.Sun.COM> At 20:00 10/06/2001 -0700, David Hudek wrote: >Hi all, > >As I understand it, the ISIS specification allows the ID field >of a NET to vary from between 1 to 8 octets, with the constraint >that everyone within a routing domain must use the same ID size. > >Is anyone anywhere actually using an ID size other than 6 octets? >Would it be correct to say that as a practical matter the >ID is fixed at 6 octets? That is a frill that I was unhappy about ISO adding. It's not clear why it would be useful, and it certainly won't work if nodes within a domain are configured for different ID sizes. It would be nice if it could be set to be constant 6, and remove the field in the LSP that states what you think the ID size is, and remove all mention of it in the spec like the size of things being IDlength+2. I'd also advocate for doing the same for number of area addresses, and fix that at 3. Radia From narayananl@rediffmail.com Wed Jun 13 05:20:34 2001 From: narayananl@rediffmail.com (Lakshminarayanan R) Date: 13 Jun 2001 04:20:34 -0000 Subject: [Isis-wg] IP Unnumbered ! Message-ID: <20010613042034.32260.qmail@mailweb14.rediffmail.com> hi, 1) Is there any draft/rfc/materials about IP unnumbered implementation for Is-Is ? 2) Can we have one numbered side and leave the otherside un-numbered in Is-Is ? 3) Why an Un-numbered interface cannot be pinged directly? 4) Can we associate an alternate IP address for an un-nmbered interface if suppose the primary address goes down? 5) Can Is-Is supports multiple un-numbered interfaces associated with a single broadcast IP address ? 6) How the Is-Is decision module distinguishes the route updation of a default route with an unnumbered interface whose associated broadcast address gone down(i.e.: it's become 0.0.0.0)? I believe some basic questions may not be relevant to Is-Is working group! but if i get answered for all, it'll be very helpful for my understanding !! Thanks in advance, lakshminarayan r _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com From narayananl@rediffmail.com Wed Jun 13 10:58:39 2001 From: narayananl@rediffmail.com (Lakshminarayanan R) Date: 13 Jun 2001 09:58:39 -0000 Subject: [Isis-wg] IP Unnumbered ! Message-ID: <20010613095839.26953.qmail@mailweb20.rediffmail.com> hi, 1) Is there any draft/rfc/materials about IP unnumbered implementation for Is-Is ? 2) Can we have one numbered side and leave the otherside un-numbered in Is-Is ? 3) Why an Un-numbered interface cannot be pinged directly? 4) Can we associate an alternate IP address for an un-nmbered interface if suppose the primary address goes down? 5) Can Is-Is supports multiple un-numbered interfaces associated with a single broadcast IP address ? 6) How the Is-Is decision module distinguishes the route updation of a default route with an unnumbered interface whose associated broadcast address gone down(i.e.: it's become 0.0.0.0)? I believe some basic questions may not be relevant to Is-Is working group! but if i get answered for all, it'll be very helpful for my understanding !! Thanks in advance, lakshminarayan r _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com From tli@Procket.com Sat Jun 16 01:40:59 2001 From: tli@Procket.com (Tony Li) Date: Fri, 15 Jun 2001 17:40:59 -0700 (PDT) Subject: [Isis-wg] Jumbo frames... Message-ID: <15146.43803.917819.341025@alpha-tli.procket.com> Folks, You may recall that a LONG time ago we sent draft-kaplan-isis-ext-eth-02.txt up to the IESG for submission as an Informational RFC. Well, it got stuck in the IESG. They felt that it was necessary to consult with the IEEE. It has since come back to us, with the comments from the IEEE. The authors have attached those comments and their responses to those comments as appendicies to the draft. We would like to again move this revised copy (attached) forward. We would like to propose: a) That this now become a WG draft. [We didn't bother before.] b) That the IESG publish this as an Informational RFC. In the interests of rapid closure, please comment by 17:01 PDT, 6/22. A copy will also be submitted to the Secretariat for publication as an ID. Tony ---------------------------------------------------------------------- Network Working Group Jed Kaplan Internet Draft P.J. Singh Expiration Date: November 1999 Allegro Networks, Inc. Mike O'Dell John Hayes Archduke Design, Inc. Ted Schroeder Alteon WebSystems, Inc. Daemon Morrell Juniper Networks, Inc. Jennifer Hsu Extended Ethernet Frame Size Support draft-ietf-isis-ext-eth-00.txt 1. 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/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 2. Abstract This document presents an extension to current Ethernet Frame specifications for hardware and frame format to support payloads greater than 1500 Bytes for Type interpretation and Length interpretation frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. 3. Overview There are two fundamental frame types defined for Ethernet: Type interpretation [IEEE-ISO] [RFC894] and Length interpretation [IEEE-ISO]. Length interpretation headers may be followed by a Logical Link Control header, 802.2 [IEEE802.2]. Both types of encapsulations can co-exist on the same media at the same time. Encodings for Type interpretation and Length interpretation frames evolved such that, as long as payloads were less than 1500 bytes, Type interpretation frames could always be distinguished from Length interpretation frames. However, when the payload is greater than 1500 bytes frames may not be uniquely distinguishable as conforming to Type interpretation or Length interpretation formats. This document extends the Ethernet frame format to allow Type interpretation or Length interpretation frame payloads larger than 1500 bytes to be uniquely distinguished. 4. Ethernet Frame Formats A. Type interpretation +----+----+------+------+-----+ | DA | SA | Type | Data | FCS | +----+----+------+------+-----+ DA Destination MAC Address (6 bytes) SA Source MAC Address (6 bytes) Type Protocol Type (2 bytes) Data Protocol Data (46 - 1500 bytes) FCS Frame Checksum (4 bytes) B. Length interpretation and derivatives +----+----+------+------+-----+ | DA | SA | Len | Data | FCS | +----+----+------+------+-----+ DA Destination MAC Address (6 bytes) SA Source MAC Address (6 bytes) Len Length of Data field (2 bytes) Data Protocol Data (46 - 1500 bytes) FCS Frame Checksum (4 bytes) The derivatives include LLC (802.2) and SNAP which prefix the data field with an LLC header. In these instances the Len field then corresponds to the combined size of both the data portion of the frame and the LLC header. On reception, the two formats are differentiated based on the magnitude of the Type/Length field, as follows: > 1536 bytes: value corresponds to a type field. The frame is an Ethernet II frame, with type values starting at 1536 (600 hex). <= maxValidFrame bytes: value corresponds to a length field. The frame is an IEEE 802.3 format (or derivative) with a maximum data length of 1500 bytes. 5. Problem with Large Length interpretation Frames in the presence of Type Interpretation Frames Some protocols commonly used in the Internet have no reserved Ethertype. An example is the set of ISO Network layer protocols, of which ISIS is a member. Such protocols are only defined to use the IEEE 802.3/802.2 encoding, and so their packets are limited in length to 1500 bytes. Type Interpretation frames have no length field. Protocols encapsulated in Type interpretation frames, such as IP, are not limited in length to 1500 bytes by framing. 6. Proposed Ethernet Frame Extension Large Length interpretation and Type interpretation frames can be supported by the following: + Define an Ethertype for 802.3, 0x8870, and encode large frames (where the data field is greater than 1500 bytes), exclusive of the Destination MAC address, Source MAC address, and Data length fields, within Type interpretation frames. Large 802.3/802.2 frames would have the following fields: +----+----+------+------+------+------+------+-----+ | DA | SA | Type | DSAP | SSAP | Ctrl | Data | FCS | +----+----+------+------+------+------+------+-----+ === 802.2 Header === DA Destination MAC Address (6 bytes) SA Source MAC Address (6 bytes) Type 0x8870 (Ethertype) (2 bytes) DSAP 802.2 Destination Service Access Point (1 byte) SSAP 802.2 Source Service Access Point (1 byte) Ctrl 802.2 Control Field (1 byte) Data Protocol Data (46 bytes) FCS Frame Checksum (4 bytes) + Allow Type interpretation frames to have payloads greater than 1500 bytes. There is no loss of information from 802.3/802.2 frames. Although the 802.3 length field is missing, the frame length is known by virtue of the frame being accepted by the network interface. In this manner, all Type interpretation frames, including large Length interpretation frames, can be longer than 1500 bytes, yet are uniquely identified. 7. References [IEEE-ISO] IEEE Std. 802.3 [2000 Edition], ISO/IEC 8802-3:2000. [RFC894] IETF RFC 894 [IEEE802] IEEE Std 802 [IEEE802.3Z] IEEE Std 802.3z [802.3X] IEEE Std. 802.3X [March 20, 1997], sec 4.2.7.1. [EXT.FRAME] "Use of Extended Frame Sizes in Ethernet Networks", draft 2.1, Alteon Networks, Inc. 8. Author's Addresses Jed Kaplan Allegro Networks, Inc. 12700 Failr Lakes Circle Suite 100 Fairfax, Va 22033 email: jkaplan@allegronetworks.com P.J. Singh Allegro Networks, Inc. 6399 San Ignacio Blvd. San Jose, Ca. 95119 408-281-5500 email: pjsingh@allegronetworks.com Mike O'Dell email: mo@ccr.net John Hayes Archduke Design, Inc. 24700 Skyland Road Los Gatos, CA 95033 (408) 691-6891 email: hayes@archdukedesign.com Ted Schroeder email: ted@alteon.com Daemon Morrell Juniper Networks, Inc. 12343-D Sunrise Valley Drive Reston, VA 20191 email: dmorrell@juniper.net Jennifer Hsu jhsu@mur.com 9. Appendix 1. Following is the response from the IEEE to draft-kaplan-isis-ext-eth-02.txt. From: Geoff Thompson, Chair, IEEE 802.3 To: Scott O. Bradner, IETF Re: 802.3 Position on Extended Ethernet Frame Size Support Scott- This is in response to your query for a position regarding the publication of Extended Ethernet Frame Size Support - draft-kaplan-isis-ext-eth-02.txt - as an informational RFC. This response was approved in concept and draft by 802.3 during its closing plenary at Hilton Head on March 15. The final form was drafted by myself and reviewed by an ad hoc that was formed during our closing plenary. It should be considered the position of the 802.3 Working Group. The response is composed of two parts, specific comments on the draft and general comments on the use of jumbo frames in Ethernet networks, however, virtually all traffic uses the type/length field as a type field. It seems unlikely that the implementations using the length format would take advantage of longer packets. Therefore, the draft conveys a very limited value. Specific comments on: Extended Ethernet Frame Size Support - draft-kaplan-isis-ext-eth-02.txt The draft makes no mention that extended frames are not likely to be successfully handled by Ethernet equipment unless the network is composed entirely of equipment that is specifically designed, beyond the specifications of the Ethernet Standard, to relay extended size frames. In section 2, Abstract, the document asserts that it presents an extension to the "current Ethernet Frame Standards to support payloads greater than 1500 bytes..." Neither the original Ethernet specification (it was not a "Standard") nor IEEE Std. 802.3 is a "frame standard". They are, rather, complete specifications for hardware and frame format with the expectation that parameters from one portion of the standard can be taken as a given in other portions of the Standard. Moreover, this draft is not an "extension" to those documents but rather a proposal to violate specific provisions of those documents. In section 3, the draft refers to "Ethernet II [ETH] and points to the reference [ETH] The reference, as cited, is incorrect or incomplete. Ethernet II would seem to point to Ethernet Version 2.0. That would specifically not be "version 1.0...September 1980". The citation in fact points to 2 different documents and fails to note that the November 1982 edition is in fact Version 2.0. Further, both of these are obsolete references and have been superceded by IEEE Std. 802.3 and ISO/IEC 8802-3. The current version of these Standards is IEEE Std. 802.3 [2000 Edition] and ISO/IEC 8802-3 : 2000. The details of section 4 are badly out of date. IEEE Std. 802.3 has included both Type and Length encoded packets ever since the adoption of IEEE Std. 802.3x on March 20, 1997. The current text of the 802.3 text covering this reads: ================================================================ 3.2.6 Length/Type Field This two-octet field takes one of two meanings,depending on its numeric value. For numerical evaluation, the first octet is the most significant octet of this field. a)If the value of this field is less than or equal to the value of maxValidFrame (as specified in 4.2.7.1), then the Length/Type field indicates the number of MAC client data octets contained in the subsequent data field of the frame (Length interpretation). b)If the value of this field is greater than or equal to 1536 decimal (equal to 0600 hexadecimal),then the Length/Type field indicates the nature of the MAC client protocol (Type interpretation). The Length and Type interpretations of this field are mutually exclusive. ================================================================ Please note that any value over "the value of maxValidFrame" is NOT a valid value for encoding length. Additionally, the values between maxValidFrame and "1536 decimal" are undefined in the Ethernet standard. The behavior of equipment at these values is not specified and can not be depended on. The draft implies that these values are valid type fields. This is not true. These values are not valid for either Type or Length. Section 4 Re: "...are not limited in length to 1500 bytes by framing." While this seems to be true, it is not necessarily true for a number of sometimes subtle reasons, some of which are noted in the "General" section below. Section 5: Regarding the statement "Although the 802.3 length field is missing, the frame length is missing, the frame length is known by virtue of the frame being accepted by the network interface." This statement is not correct. Many Ethernet interfaces, particularly those of relay equipment, accept frames without regard for packet type or content. There is no reasonable expectation that standards based Ethernet/802.3 equipment will reject the proposed frames. They may very well accept the frame and corrupt it before passing it on. This corruption may consist of truncation or alteration of the data within the packet. General comments on the use of jumbo frames in Ethernet networks: Consideration #1: The expectation of no more than 15-1600 bytes between frames and an interpacket gap before the next frame is deeply ingrained throughout the design and implementation of standardized Ethernet/802.3 hardware. This shows up in buffer allocation schemes, clock skew and tolerance compensation and fifo design. Consideration #2: For some Ethernet/802.3 hardware (repeaters are one specific example) it is not possible to design compliant equipment which meets all of the requirements and will still pass extra long frames. Further, since clock frequency may vary with time and temperature, equipment may successfully pass long frames at times and corrupt them at other times. Therefore, attempts to verify the ability to send long frames over a path may produce inaccurate results. Consideration #3: The error checking mechanism embodied in the 4 byte checksum has not been well characterized at greater frame lengths, but is known to degrade. Therefore the data reliability of transfers in long frame transfers will have a greater rate of undetected frame errors. Consideration #4: The length of frames proposed by this draft can not be assured to pass through standards conformant hardware. The huge value of Ethernet/802.3 systems in the data networking universe is their standardization and the resulting assurance that systems will all interoperate. No such assurance can be provided for oversize frames with both the current broadly accepted standard and the large installed base ofstandards based equipment. In summary with regard to greatly longer frames for Ethernet, much of the gear produced today would be intolerant of greatly longer frames. There is no way proposed to distinguish between frame types in the network as they arrive from the media. Bridges might and repeaters would drop or truncate frames (and cause errors doing so) right and left for uncharacterized reasons. It would be a mess. What might seem okay for small carefully characterized networks would be enormously difficult or impossible to do across the Standard. The choice of frame size for Ethernet packets is really the domain of 802.3 (CSMA/CD) and 802.1 (Bridging, VLANs). The only time the frame size has been modified over the history of the Standard was in order to increase maximum length by four bytes in order to accommodate VLANs, 802.1 initiated this work and 802.3 also modified the Ethernet standard to include these few extra bytes. The people with the experience dealing with this sort of thing attend IEEE 802. It's easy to define a new ethertype, but it's not too easy to figure out what happens when these non-standard frames are given to standardized transmission equipment e.g. bridges. We would expect discussions of this type to take place in both 802.3 & 802.1. The giant frame issue has been mentioned several times over the years in 802.3, discussed in the back halls and considered each time we move to a higher speed. It has never had consensus support in that context. It has never been brought forward as a separate proposal. Backward compatibility has always been more important than ease of performance improvement. The problem is that the change is very easy to do in the standard and hard to do in the world. It is just like changing the gauge on railroad tracks. All you have to do is change one line in the standard, never mind all of the rails you have to move. The Kaplan draft is just meant for carrying IS-IS routing protocol frames (the IS-IS working group is the intended sponsor of this draft). We expect those vendors supporting the larger frame will support this will show up and support this proposal. Those vendors not supporting the larger frame as well as those protecting the installed base will not support this activity nor having this sort of item standardized outside IEEE 802.3. With best regards, Geoff Thompson, Chair, IEEE 802.3 10. Appendix 2. Comments from the draft's authors. With respect to Consideration #2, paragraph 1: With the advent of full duplex ethernet and higher speed ethernet phys, transcievers have gone from transmitting when they have data ready send to transmitting constantly, sending IDLEs when they have nothing to send. Any clock drift due to time and temperature will affect the system without regard to the frame lengths being used. With respect to Consideration #3, paragraph 1: The error checking mechanism of ethernet (CRC-32) was characterized by R. Jain, "Error Characteristics of Fiber Distributed Data Interface (FDDI)," IEEE Transactions on Communications, Vol. 38, No. 8, August 1990, pp. 1244-1252. http://www.cis.ohio-state.edu/~jain/papers/xie1.htm FDDI and Ethernet use the same error checking mechanism; CRC-32. The probability of undetected errors remains constant for frame sizes between 3007 and 91639 bits (approximately 376 to 11455 bytes). Setting the maximum size of jumbo frames to 9018 bytes falls well within this range. There is no increase in undetected errors when using jumbo frames and the existing CRC-32 as the error detection mechanism. With respect to Consideration #4, paragraph 1: This proposal provides a workable mechanism to identify and handle jumbo frames through systems that do support jumbo frames. From rja@inet.org Sat Jun 16 02:27:53 2001 From: rja@inet.org (RJ Atkinson) Date: Fri, 15 Jun 2001 21:27:53 -0400 Subject: [Isis-wg] Jumbo frames... In-Reply-To: <15146.43803.917819.341025@alpha-tli.procket.com> Message-ID: <5.1.0.14.2.20010615212420.009d2730@10.30.15.2> At 20:40 15/06/01, Tony Li wrote: >You may recall that a LONG time ago we sent >draft-kaplan-isis-ext-eth-02.txt up to the IESG for submission as an >Informational RFC. > >Well, it got stuck in the IESG. They felt that it was necessary to consult >with the IEEE. It has since come back to us, with the comments from the >IEEE. The authors have attached those comments and their responses to >those comments as appendicies to the draft. > >We would like to again move this revised copy (attached) forward. We would >like to propose: > >a) That this now become a WG draft. [We didn't bother before.] >b) That the IESG publish this as an Informational RFC. > >In the interests of rapid closure, please comment by 17:01 PDT, 6/22. A >copy will also be submitted to the Secretariat for publication as an ID. With all respect, the draft is incomplete. We ought to specify a default IP MTU for Ethernet jumbograms. This will help those vendors who choose to implement jumbograms do so in a way that maximises interoperability. I would propose 9180 bytes as the default IP MTU on grounds that it is pretty widely implemented by Ethernet vendors and that there is operational experience indicating that the 9K size is particularly useful for servers. Possibly relevant is the *rationale* in RFC-1626, which spec'd the same MTU for ATM AAL5. ATM itself, of course, is not relevant here. Ran rja@inet.org From tli@Procket.com Sat Jun 16 08:22:50 2001 From: tli@Procket.com (Tony Li) Date: Sat, 16 Jun 2001 00:22:50 -0700 (PDT) Subject: [Isis-wg] Jumbo frames... In-Reply-To: <5.1.0.14.2.20010615212420.009d2730@10.30.15.2> References: <15146.43803.917819.341025@alpha-tli.procket.com> <5.1.0.14.2.20010615212420.009d2730@10.30.15.2> Message-ID: <15147.2378.397394.142911@redcs1.procket.com> | With all respect, the draft is incomplete. We ought to | specify a default IP MTU for Ethernet jumbograms. This will | help those vendors who choose to implement jumbograms do so | in a way that maximises interoperability. | | I would propose 9180 bytes as the default IP MTU on grounds | that it is pretty widely implemented by Ethernet vendors and that | there is operational experience indicating that the 9K size is | particularly useful for servers. Possibly relevant is the *rationale* | in RFC-1626, which spec'd the same MTU for ATM AAL5. ATM itself, | of course, is not relevant here. Ran is very much correct when he says that ATM is not relevant. So is its MTU. Experience building networking equipment for a 9180 byte MTU says that it is extremely painful and costly. Given that the predominant media for the forseeable future are POS and Ethernet (of various speeds), plus the fact that there are an insignificant number of IP hosts running with an MTU higher than that of FDDI, it seems more useful to use the POS/FDDI MTU of 4470. If, of course, folks want to specify a default MTU at all. Tony From rja@extremenetworks.com Sat Jun 16 14:31:43 2001 From: rja@extremenetworks.com (Ran Atkinson) Date: Sat, 16 Jun 2001 09:31:43 -0400 Subject: [Isis-wg] Jumbo frames... In-Reply-To: <15147.2378.397394.142911@redcs1.procket.com> References: <5.1.0.14.2.20010615212420.009d2730@10.30.15.2> <15146.43803.917819.341025@alpha-tli.procket.com> <5.1.0.14.2.20010615212420.009d2730@10.30.15.2> Message-ID: <5.1.0.14.2.20010616091659.00ac9ec0@10.30.15.2> At 03:22 16/06/01, Tony Li wrote: >Ran is very much correct when he says that ATM is not relevant. So >is its MTU. Experience building networking equipment for a 9180 byte >MTU says that it is extremely painful and costly. Given that the >predominant media for the forseeable future are POS and Ethernet >(of various speeds), plus the fact that there are an insignificant >number of IP hosts running with an MTU higher than that of FDDI, >it seems more useful to use the POS/FDDI MTU of 4470. The FDDI MTU is equally irrelevant as ATM since it isn't widely deployed anyplace (not even exchange points now a days). POS MTU is configurable in any event. Most Gigabit Ethernet products sold today **already** support the 9180 byte IP MTU. In fact, it isn't hard to either implement or support (at least for some of us). The main exception is that some cisco Ethernet products support 9180 byte MTU, while others only support a 4470 byte MTU today (different product design teams within cisco apparently don't talk with each other). PAIX, LINX, and several other exchange points have already deployed equipment that supports the 9180 byte IP MTU over Ethernet. Some operators are using this today at those exchange points. So a majority of Gigabit Ethernet vendors disagree with tli's assertion that such an MTU is too painful and costly to implement. Further, the trend is for Ethernet-based exchange points to support the 9180 byte IP MTU. The *rationale* for the 9180 byte MTU, present in RFC-1626, is in fact still relevant. For while this happens by accident to be a draft within the IS-IS WG, the scope of the document goes very far beyond IS-IS or even the Routing Area. In fact the reason IEEE got a bit upset was partly that a jumbogram won't work properly on a pure CSMA/CD deployment of Ethernet and partly that the draft describes a purely layer-2 feature outside the usual scope of IETF. Now, in practice, IEEE has its head in the sand on this issue, vendors have deployed the 9K MTU already, and there is value in documenting deployed practice so that interoperability can more easily be ensured. In any event, tli's gripes about pain and cost aren't terribly relevant in an Informational RFC which is non-binding in the first place. No one is required to pay any attention to an Informational RFC. It either is useful and gets deployed xor it isn't useful and gets ignored. Ran From rja@extremenetworks.com Sat Jun 16 14:49:02 2001 From: rja@extremenetworks.com (Ran Atkinson) Date: Sat, 16 Jun 2001 09:49:02 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> A quick check reveals that GigE host adapters from Intel, 3COM, and Broadcom all support a 9K MTU. Further, widely used inexpensive commodity chipsets, such as the Intel LXT1000 and Broadcom BCM-5701, are specifically designed to support the 9K IP/GigE MTU (confirmed just now by reviewing those data sheets). WindowsNT, Windows2000, and WindowsXP all support the 9K MTU. Many other server vendors also support the 9K MTU for IP/GigE. I'm unaware of (and unable to locate quickly) any 10/100 Ethernet products that support anything other than the standard 1518 byte MTU. Data on any specific 10/100 products that support an MTU larger than 1518 (+ allowance for 802.1q VLAN tags && 802.1p precedence) would be interesting to me at least. Cheers, Ran rja@inet.org From tli@Procket.com Sat Jun 16 22:42:28 2001 From: tli@Procket.com (Tony Li) Date: Sat, 16 Jun 2001 14:42:28 -0700 (PDT) Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> Message-ID: <15147.53956.476731.291265@redcs1.procket.com> Ran, Apparently we're trying to solve different problems. I'm trying to eliminate the need to do high speed fragmentation in the backbone of the Internet. Having multiple MTU sizes is not a good thing for anyone and it causes unnecessary inefficiencies for both the router and the end host that has to do the reassembly. >From that perspective, adding another MTU size to the Internet simply increases the need for fragmentation. Server sends 9180B packet to router A. Router A fragments to 4470B to get through a POS link. Somewhere down the path, router B fragments down to 1500B to actually deliver to the user over 10BaseT. How did this help? The rationale in RFC 1626 is flawed. At the very least, modern NFS runs over TCP, not UDP. The rest of the RFC has no compelling rationale for a larger MTU. RFC 1626 does get one thing right, tho: Fragmentation of IP datagrams is known to be highly undesirable. [KM87] Do you no longer agree with this? Tony From jesper@skriver.dk Sat Jun 16 22:57:09 2001 From: jesper@skriver.dk (Jesper Skriver) Date: Sat, 16 Jun 2001 23:57:09 +0200 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <15147.53956.476731.291265@redcs1.procket.com>; from tli@Procket.com on Sat, Jun 16, 2001 at 02:42:28PM -0700 References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <15147.53956.476731.291265@redcs1.procket.com> Message-ID: <20010616235709.B71941@skriver.dk> On Sat, Jun 16, 2001 at 02:42:28PM -0700, Tony Li wrote: > > Ran, > > Apparently we're trying to solve different problems. > > I'm trying to eliminate the need to do high speed fragmentation in the > backbone of the Internet. Having multiple MTU sizes is not a good thing > for anyone and it causes unnecessary inefficiencies for both the router and > the end host that has to do the reassembly. > > From that perspective, adding another MTU size to the Internet simply > increases the need for fragmentation. Server sends 9180B packet to > router A. Router A fragments to 4470B to get through a POS link. pMTUd is what's used generally, so fragmentation by routers isn't seen much in real life. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From tli@Procket.com Sat Jun 16 23:13:56 2001 From: tli@Procket.com (Tony Li) Date: Sat, 16 Jun 2001 15:13:56 -0700 (PDT) Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <20010616235709.B71941@skriver.dk> References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <15147.53956.476731.291265@redcs1.procket.com> <20010616235709.B71941@skriver.dk> Message-ID: <15147.55844.423463.777557@redcs1.procket.com> | pMTUd is what's used generally, so fragmentation by routers isn't | seen much in real life. If that were true, then my life would be a GOOD bit easier. Sigh. Tony From raszuk@cisco.com Sun Jun 17 13:00:33 2001 From: raszuk@cisco.com (Robert Raszuk) Date: Sun, 17 Jun 2001 05:00:33 -0700 Subject: [Isis-wg] More vendor data on IP/GigE MTU References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <15147.53956.476731.291265@redcs1.procket.com> <20010616235709.B71941@skriver.dk> Message-ID: <3B2C9BE1.29B461AD@cisco.com> Jesper, > pMTUd is what's used generally, so fragmentation by routers isn't > seen much in real life. Well I am not sure what is your definition of "real life", but at least in mine the fragmentation is a nightmare of each customer deploying mpls in his network. By adding 4 or 8 bytes to already maxed ethernet frame you either must support jumbo frames or fragment. As a contrary I would say that MTU path discovery almost never works :). In 90 % of cases I have seen this is due to misconfigured firewalls (or as security team say: "configure very tightly" ;). The rest 10% of pmtud reasons for failures can be found here: http://www.cisco.com/warp/public/105/38.shtml R. From jesper@skriver.dk Sun Jun 17 13:17:18 2001 From: jesper@skriver.dk (Jesper Skriver) Date: Sun, 17 Jun 2001 14:17:18 +0200 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <3B2C9BE1.29B461AD@cisco.com>; from raszuk@cisco.com on Sun, Jun 17, 2001 at 05:00:33AM -0700 References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <15147.53956.476731.291265@redcs1.procket.com> <20010616235709.B71941@skriver.dk> <3B2C9BE1.29B461AD@cisco.com> Message-ID: <20010617141718.A5183@skriver.dk> On Sun, Jun 17, 2001 at 05:00:33AM -0700, Robert Raszuk wrote: > Jesper, > > > pMTUd is what's used generally, so fragmentation by routers isn't > > seen much in real life. > > Well I am not sure what is your definition of "real life", but at least > in mine the fragmentation is a nightmare of each customer deploying mpls > in his network. By adding 4 or 8 bytes to already maxed ethernet frame > you either must support jumbo frames or fragment. Yes, you need to be able to support atleast 1508 bytes to avoid fragmentation, but again allmost all modern operating systems do path MTU discovery ... > As a contrary I would say that MTU path discovery almost never works :). As said most OS's have it enabled, and if it doesn't work, there will be no connectivity, as the routers can't fragment the packets, and yes I have seen the misconfigured packet filters and firewall's, it's a pain, but saying that pMTUd almost never work, is not a accurate statement. And as most/all OS's have pMTUd enabled, the routers won't have to do much fragmentation. > In 90 % of cases I have seen this is due to misconfigured firewalls (or > as security team say: "configure very tightly" ;). The rest 10% of pmtud > reasons for failures can be found here: > http://www.cisco.com/warp/public/105/38.shtml /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From tli@Procket.com Mon Jun 18 10:43:19 2001 From: tli@Procket.com (Tony Li) Date: Mon, 18 Jun 2001 02:43:19 -0700 (PDT) Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> Message-ID: <15149.52535.103197.207393@redcs1.procket.com> | Au contraire. I fully agree with this. It is precisely | for this reason that we should settle on 9180. 9180 is already | quite widely deployed and supported in the Gigabit Ethernet world. | Having a 9180 end-to-end MTU supported, which this draft can | greatly facilitate, will reduce current fragmentation of 9180 | into smaller packets (for situations where PMTU is not in use | or has been broken somehow). POS is has a configurable MTU. | FDDI is effectively dead, so we ought not limit ourselves to | the 4K MTU of FDDI. Well, unfortunately, no one let all of the manufacturers of POS links in on your little plan. The default as shipped is 4470 and I don't know of a single one that has the buffering to support 9180. Also, 9180 is NOT necessary to support page flipping. 4470 would seem to very nicely support a single 4k page. I agree that NFS over UDP isn't dead yet. But I sure don't think we should be optimizing the entire Internet to support a protocol that we're trying to kill off. Tony From rja@inet.org Mon Jun 18 02:28:39 2001 From: rja@inet.org (RJ Atkinson) Date: Sun, 17 Jun 2001 21:28:39 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <15147.53956.476731.291265@redcs1.procket.com> References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> Message-ID: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> At 17:42 16/06/01, Tony Li wrote: >I'm trying to eliminate the need to do high speed fragmentation in the >backbone of the Internet. Having multiple MTU sizes is not a good thing >for anyone and it causes unnecessary inefficiencies for both the router >and the end host that has to do the reassembly. The above is a fine rationale for not supporting any form of jumbogram and just using an end-to-end MTU of 1518 bytes. Its not consistent with the draft, however. >From that perspective, adding another MTU size to the Internet simply >increases the need for fragmentation. Server sends 9180B packet to >router A. Router A fragments to 4470B to get through a POS link. Of course, POS links are configurable. Many, even in Internet core routers, happen to be configured for 1518 bytes. See above. >Somewhere down the path, router B fragments down to 1500B to actually >deliver to the user over 10BaseT. How did this help? > >The rationale in RFC 1626 is flawed. At the very least, modern NFS runs >over TCP, not UDP. The rest of the RFC has no compelling rationale for a >larger MTU. Page flipping in servers is a significant performance advantage. Further, per-packet overhead costs dominate per-byte costs in most systems. So having a larger MTU significantly improves the throughput in practice. This advantage is not changed by use of NFS/TCP vice NFS/UDP. While I'm a big fan of NFS/TCP, it has not (in practice) eliminated broad use of NFS/TCP. >RFC 1626 does get one thing right, tho: > > Fragmentation of IP datagrams is known to be highly > undesirable. [KM87] > >Do you no longer agree with this? Au contraire. I fully agree with this. It is precisely for this reason that we should settle on 9180. 9180 is already quite widely deployed and supported in the Gigabit Ethernet world. Having a 9180 end-to-end MTU supported, which this draft can greatly facilitate, will reduce current fragmentation of 9180 into smaller packets (for situations where PMTU is not in use or has been broken somehow). POS is has a configurable MTU. FDDI is effectively dead, so we ought not limit ourselves to the 4K MTU of FDDI. Cheers, Ran From rja@inet.org Mon Jun 18 14:13:32 2001 From: rja@inet.org (RJ Atkinson) Date: Mon, 18 Jun 2001 09:13:32 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <15149.52535.103197.207393@redcs1.procket.com> References: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> Message-ID: <5.1.0.14.2.20010618090255.00a0fad0@10.30.15.2> At 05:43 18/06/01, Tony Li wrote: >Well, unfortunately, no one let all of the manufacturers of POS links >in on your little plan. The default as shipped is 4470 and >I don't know of a single one that has the buffering to support 9180. I know of some POS interfaces that do have RTT ms of buffering for a 9180 byte MTU. I don't know if these are the ones that you built or not, perhaps not given your comment. Big fast routers with 9180 byte MTU on their GigE interfaces do exist off the shelf from multiple vendors today. >Also, 9180 is NOT necessary to support page flipping. >4470 would seem to very nicely support a single 4k page. True, but 8K pages are commonly used these days, not 4K, so its of much less benefit than it was in the FDDI era. >I agree that NFS over UDP isn't dead yet. But I sure don't think >we should be optimizing the entire Internet to support a protocol >that we're trying to kill off. I didn't know you were on a crusade to kill off NFS. Over in other IETF WGs, there are efforts to improve NFS. As noted before, page flipping means that 9180 is the right size for NFS/TCP as well. Even if one isn't running NFS, the per-packet overhead in most end systems means that the only way to get 1 Gbps through a GigE interface is to support large jumbograms. This is why the de facto MTU for GigE jumbograms is 9180 bytes. More generally, *most* Gigabit Ethernet products that have shipped in the past 3 years *already* support the 9180 MTU, including big fast routers with GigE interfaces. So you forgot to tell the rest of the world about your plan for 4470 to be the standard MTU. This means that fragmentation is *already* inevitable on GigE links (if PMTU is turned off or broken in some way). My main goal is to document widely deployed existing practice. I happen to agree with the reasons that such is the existing practice as well (obvious to anyone reading this thread). As I noted at the outset, an Informational RFC is totally non-binding (and the content of standards-track RFCs are pretty frequently ignored as well), so I don't see why you are getting spun up. I think your perspective and mine are pretty well established at this point (and neither seems to have changed since the prior conversation when RFC-1626 was an I-D :-). It would be much more useful and productive (IMHO) to hear from other folks here on the list, to see if there is consensus one way or the other (perhaps we're both confused :-). Cheers, Ran rja@inet.org From mjyang@etri.re.kr Tue Jun 19 02:50:52 2001 From: mjyang@etri.re.kr (mjyang) Date: Tue, 19 Jun 2001 10:50:52 +0900 Subject: [Isis-wg] Help] Figure2 in RFC 1195 Message-ID: <001601c0f862$45b2c0c0$37c2fe81@etri.re.kr> This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C0F8AD.B57A5DA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkuLg0KDQpJIGFtIGJlZ2lubmVyIGZvciBJUy1JUy4uDQpJIHdhbnQgdG8gZ2V0IHRoZSBmaWd1 cmUgMihFeGFtcGxlIHJvdXRpbm5nIGRvbWFpbikgaW4gUkZDIDExOTUNCmFuZCBtb3JlIHN0cnVj dHVyZSBkaWFncmFtIGFuZCBmaWd1cmVzIGFib3V0IElTLUlTIGlmIGFueS4uDQpUaGFuayB5b3Uu Lg0KDQotLS0tLS0tLS0tLS0tLS0tLQ0KTWlqdW5nIFlhbmcgLyBFVFJJIA0KVEVMOiArODItNDIt ODYwLTQ5MjIgDQpGQVg6ICs4Mi00Mi04NjAtNTQ0MCANCkUtbWFpbDogbWp5YW5nQGV0cmkucmUu a3IgDQoNCg== ------=_NextPart_000_0013_01C0F8AD.B57A5DA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLi48L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBhbSBiZWdp bm5lciBmb3IgSVMtSVMuLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgd2FudCB0 byBnZXQgdGhlIGZpZ3VyZSAyKEV4YW1wbGUgcm91dGlubmcgZG9tYWluKSBpbiBSRkMgDQoxMTk1 PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YW5kIG1vcmUgc3RydWN0dXJlIGRpYWdy YW0gYW5kIGZpZ3VyZXMgYWJvdXQgSVMtSVMgaWYgDQphbnkuLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPlRoYW5rIHlvdS4uPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPi0tLS0tLS0tLS0tLS0tLS0tPEJSPk1panVuZyBZYW5nIC8gRVRS SSA8QlI+VEVMOiANCis4Mi00Mi04NjAtNDkyMiA8QlI+RkFYOiArODItNDItODYwLTU0NDAgPEJS PkUtbWFpbDogPEEgDQpocmVmPSJtYWlsdG86bWp5YW5nQGV0cmkucmUua3IiPm1qeWFuZ0BldHJp LnJlLmtyPC9BPiANCjxCUj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0013_01C0F8AD.B57A5DA0-- From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_20016192138201571825916 Content-Type: text/plain; charset=us-ascii Hi all, Please update me on the following draft. I am unable to get the draft. Callon R W., " Use of OSI IS-IS for Routing in TCP/IP and dual environments" Internet draft <draft-ietf-isis-tcpip-00>, January 1993. also updat me on ISO/IEC 10589 latest version. Thanks in advance Regards, Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_20016192138201571825916 Content-Type: text/html; charset=us-ascii

Hi all,

Please update me on the following draft. I am unable to get the draft.

Callon R W., " Use of OSI IS-IS for Routing in TCP/IP and dual environments" Internet draft <draft-ietf-isis-tcpip-00>, January 1993.

also updat me on ISO/IEC 10589 latest version.

Thanks in advance

Regards,

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_20016192138201571825916-- From Russ White Tue Jun 19 12:27:32 2001 From: Russ White (Russ White) Date: Tue, 19 Jun 2001 07:27:32 -0400 (EDT) Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <15149.52535.103197.207393@redcs1.procket.com> Message-ID: All of the pos links I've checked are 4470 mtu, so that's what I'd go with. I don't see where the 9180 is gaining you much more, at least until media that support this sort of mtu are widely deployed. We can always push a change to this in the future, if it would be advantageous to do so. In the meantime, let's not beg for more fragmentation than we already have. :-) Russ On Mon, 18 Jun 2001, Tony Li wrote: > > | Au contraire. I fully agree with this. It is precisely > | for this reason that we should settle on 9180. 9180 is already > | quite widely deployed and supported in the Gigabit Ethernet world. > | Having a 9180 end-to-end MTU supported, which this draft can > | greatly facilitate, will reduce current fragmentation of 9180 > | into smaller packets (for situations where PMTU is not in use > | or has been broken somehow). POS is has a configurable MTU. > | FDDI is effectively dead, so we ought not limit ourselves to > | the 4K MTU of FDDI. > > > Well, unfortunately, no one let all of the manufacturers of POS links in on > your little plan. The default as shipped is 4470 and I don't know of a > single one that has the buffering to support 9180. > > Also, 9180 is NOT necessary to support page flipping. 4470 would seem to > very nicely support a single 4k page. > > I agree that NFS over UDP isn't dead yet. But I sure don't think we should > be optimizing the entire Internet to support a protocol that we're trying > to kill off. > > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _____________________________ riw@cisco.com <>< Grace Alone From jlearman@cisco.com Tue Jun 19 18:25:40 2001 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 19 Jun 2001 13:25:40 -0400 Subject: [Isis-wg] request for a draft In-Reply-To: <200106190725.MAA02637@WS0005.indiatimes.com> Message-ID: <4.3.2.7.2.20010619132353.0190b458@dingdong.cisco.com> I believe that would be RFC-1195, which is no longer a draft (!) To get a copy of an ISO document, you'll need to contact your country's representative agency for ISO documents (ANSI in the US, if I remember correctly.) Regards, Jeff At 03:38 AM 6/19/2001, Sivakumar A wrote: >Hi all, > >Please update me on the following draft. I am unable to get the draft. > >Callon R W., " Use of OSI IS-IS for Routing in TCP/IP and dual environments" Internet draft , January 1993. > >also updat me on ISO/IEC 10589 latest version. > >Thanks in advance > >Regards, > >Sivakumar A > >---------- >Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com >Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com From gmatey@equipecom.com Tue Jun 19 18:52:59 2001 From: gmatey@equipecom.com (George Matey) Date: Tue, 19 Jun 2001 13:52:59 -0400 Subject: [Isis-wg] request for a draft Message-ID: ISO/IEC 10589, and its companion documents, are publicly available at: http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvai lableStandards.htm -- George > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Tuesday, June 19, 2001 1:26 PM > To: Sivakumar A > Cc: workgroup > Subject: Re: [Isis-wg] request for a draft > > > > I believe that would be RFC-1195, which is no longer a draft (!) > > To get a copy of an ISO document, you'll need to contact your > country's representative agency for ISO documents (ANSI in the US, > if I remember correctly.) > > Regards, > Jeff > > At 03:38 AM 6/19/2001, Sivakumar A wrote: > > >Hi all, > > > >Please update me on the following draft. I am unable to get > the draft. > > > >Callon R W., " Use of OSI IS-IS for Routing in TCP/IP and > dual environments" Internet draft , > January 1993. > > > >also updat me on ISO/IEC 10589 latest version. > > > >Thanks in advance > > > >Regards, > > > >Sivakumar A > > > >---------- > >Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com >Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From dhudek@ma.ultranet.com Tue Jun 19 22:20:31 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Tue, 19 Jun 2001 14:20:31 -0700 Subject: [Isis-wg] request for a draft References: <4.3.2.7.2.20010619132353.0190b458@dingdong.cisco.com> Message-ID: <3B2FC21F.4430786@ma.ultranet.com> Yes, in the US, ANSI (www.ansi.org) has electronic versions (pdf files) available for sale, and Global Engineering Documents (global.ihs.com) has paper copies for sale. The electronic ones are cheaper :-) dave h Jeff Learman wrote: > To get a copy of an ISO document, you'll need to contact your > country's representative agency for ISO documents (ANSI in the US, > if I remember correctly.) > Regards, > Jeff From dhudek@ma.ultranet.com Tue Jun 19 22:24:13 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Tue, 19 Jun 2001 14:24:13 -0700 Subject: [Isis-wg] request for a draft References: Message-ID: <3B2FC2FD.5FCD502C@ma.ultranet.com> Wow, I didn't know they were available for free now! Please ignore my last email about ansi and global eng docs. dave h George Matey wrote: > > ISO/IEC 10589, and its companion documents, are publicly available at: > http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvai > lableStandards.htm > George From danny@ambernetworks.com Tue Jun 19 19:13:02 2001 From: danny@ambernetworks.com (Danny McPherson) Date: Tue, 19 Jun 2001 12:13:02 -0600 Subject: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: <200106191813.MAA00676@tcb.net> > All of the pos links I've checked are 4470 mtu, so that's what > I'd go with. I don't see where the 9180 is gaining you much more, > at least until media that support this sort of mtu are widely > deployed. We can always push a change to this in the future, if > it would be advantageous to do so. Agreed, and I for one am ot aware of SPs configuring their POS links with smaller MTUs. I'd also like to hear from other GE switch/router vendors that agree with Ran that 9180 is 'de facto', we've only heard from one thus far (i.e., Ran's). -danny From tli@Procket.com Tue Jun 19 20:31:33 2001 From: tli@Procket.com (Tony Li) Date: Tue, 19 Jun 2001 12:31:33 -0700 (PDT) Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <5.1.0.14.2.20010618090255.00a0fad0@10.30.15.2> References: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <5.1.0.14.2.20010618090255.00a0fad0@10.30.15.2> Message-ID: <15151.43157.504408.482017@redcs1.procket.com> Ran, | >I agree that NFS over UDP isn't dead yet. But I sure don't think | >we should be optimizing the entire Internet to support a protocol | >that we're trying to kill off. | | I didn't know you were on a crusade to kill off NFS. Only the UDP transport. | So you forgot to tell the rest | of the world about your plan for 4470 to be the standard MTU. Yup, I assumed that this draft would have made it obvious. Obviously not. Oh well. ;-) | As I noted at the outset, an Informational RFC is totally | non-binding (and the content of standards-track RFCs are pretty | frequently ignored as well), so I don't see why you are getting | spun up. >From the level of invective, you seem to be the one getting spun up. As to it being Informational, we both know that that's a canard. This is what will get deployed and used. We should agree, because it will become reality. | I think your perspective and mine are pretty well established | at this point (and neither seems to have changed since the prior | conversation when RFC-1626 was an I-D :-). It would be much more | useful and productive (IMHO) to hear from other folks here on the list, | to see if there is consensus one way or the other (perhaps we're both | confused :-). I agree completely. We've now heard from three parties, including ourselves and not one of the authors of the draft. This will be an incredibly rough consensus given the importance of this. I'll also point out that this difference of opinion also makes it obvious that the draft DOES need to include some comment as to what the default MTU should be. We should not be moving forward without some decision. Tony From tli@Procket.com Tue Jun 19 20:48:50 2001 From: tli@Procket.com (Tony Li) Date: Tue, 19 Jun 2001 12:48:50 -0700 (PDT) Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> References: <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> Message-ID: <15151.44194.820031.284764@redcs1.procket.com> | >I'm trying to eliminate the need to do high speed fragmentation in the | >backbone of the Internet. Having multiple MTU sizes is not a good thing | >for anyone and it causes unnecessary inefficiencies for both the router | >and the end host that has to do the reassembly. | | The above is a fine rationale for not supporting any form of | jumbogram and just using an end-to-end MTU of 1518 bytes. | Its not consistent with the draft, however. The draft can be changed. | >From that perspective, adding another MTU size to the Internet simply | >increases the need for fragmentation. Server sends 9180B packet to | >router A. Router A fragments to 4470B to get through a POS link. | | Of course, POS links are configurable. Many, even in Internet | core routers, happen to be configured for 1518 bytes. See above. Not all POS links can be configured upwards. Please pardon a short digression into hardware design. When designing a store-and-forward device, an interface will have a number of buffers that it will receive frames into before passing them on for further processing. Typically, there will need to be at least two of those buffers (double buffering) to sustain packet rate and most commonly three. This gives one buffer for the incoming packet, one for the packet being handed off into the guts of the system and another just to insure that we don't get into a bad race condition when both packets are swapping roles at the same time. Such buffers are typically on-chip and thus are relatively expensive. They also need to be MTU sized. The combination of these two factors generally push designers to want a smaller MTU. It makes the hardware more efficient, which in turn makes the system more efficient. Obviously, there are other hardware designs that are possible. One can do scatter-gather, for example. However, that makes the hardware more complicated, not less. It seems to me that if we want our systems to have the peak performance, we should be optimizing them to be efficient and simple. | Page flipping in servers is a significant performance advantage. I agree. However, we can't use this argument alone to track the evolving page sizes in processors. Over the years, we've seen the page size increase (wasn't the VAX 512B?) and we will not be able to change the MTU of the Internet to match. There will always be something bigger. At the same time, we know that 1500B is inconvenient for everyone. Even having the MTU be half or a quarter of the page size would be better as the driver could then still do page flipping at its external boundary. | It is precisely | for this reason that we should settle on 9180. 9180 is already | quite widely deployed and supported in the Gigabit Ethernet world. | Having a 9180 end-to-end MTU supported, which this draft can | greatly facilitate, will reduce current fragmentation of 9180 | into smaller packets (for situations where PMTU is not in use | or has been broken somehow). POS is has a configurable MTU. Again, there are many POS links in the world which will not work at 9180, so this is not a deployable solution. You can come down. We can't go up. It's that simple. Tony From jparker@axiowave.com Tue Jun 19 20:57:26 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 19 Jun 2001 15:57:26 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: Ran, Tony - I remember the history behind this showing up in IS-IS, but suspect that some who may be interested in the outcome might not be watching the IS-IS list for a decision about MTU. I'm not sure where it should go, but I suspect that even if we get {N-1, 1, 0} consensus on one view or another, it will be judged moot unless we get this before a wider venue: some group in Transport or IP, perhaps. Is there a lurking AD with an opinion? - jeff parker - axiowave networks From vijay@umbc.edu Tue Jun 19 20:59:23 2001 From: vijay@umbc.edu (Vijay Gill) Date: Tue, 19 Jun 2001 15:59:23 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <15151.43157.504408.482017@redcs1.procket.com> Message-ID: On Tue, 19 Jun 2001, Tony Li wrote: > > | So you forgot to tell the rest > | of the world about your plan for 4470 to be the standard MTU. > > > Yup, I assumed that this draft would have made it obvious. Obviously not. > Oh well. ;-) Most of the backbone devices that go into networks that I have some familiarity with are required to support at least 4470 MTU (+ whatever overhead for labels, et al is needed). Reasons for this are varied but in general tend to be something along the lines of datacenter to datacenter traffic and OC-x connected customers with servers doing jumbos on gigabit ethernet devices wanting to talk to other branch offices, and therefore we'd like to avoid fragmentation if possible. As an overall percentage of traffic, this is negligible, but thats what I ask for from an operational perspective. I don't care if someone supports 9k jumbos, but I do care that my pos and gige boxes can support 4470 MTU. /vijay From vijay@umbc.edu Tue Jun 19 21:29:42 2001 From: vijay@umbc.edu (Vijay Gill) Date: Tue, 19 Jun 2001 16:29:42 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> Message-ID: On Sun, 17 Jun 2001, RJ Atkinson wrote: > Au contraire. I fully agree with this. It is precisely > for this reason that we should settle on 9180. 9180 is already > quite widely deployed and supported in the Gigabit Ethernet world. > Having a 9180 end-to-end MTU supported, which this draft can > greatly facilitate, will reduce current fragmentation of 9180 > into smaller packets (for situations where PMTU is not in use > or has been broken somehow). POS is has a configurable MTU. > FDDI is effectively dead, so we ought not limit ourselves to > the 4K MTU of FDDI. Ran, for various reasons, including some I sent earlier to the list, from an operational perspective, I've never seen any demand for > 4470+overhead MTU. Therefore, any devices that go into networks that I've worked on have been required to support an MTU of ~4470, and I do not see this changing in the future. The amount of traffic at even 4470 is fairly small, but there have been customers who have asked for a 4k MTU. I see no operational customer based demand to go greater than 4k, and I suspect this will be true for a while. /vijay From jkaplan@allegronetworks.com Tue Jun 19 21:38:24 2001 From: jkaplan@allegronetworks.com (Jed Kaplan) Date: Tue, 19 Jun 2001 16:38:24 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: <0850602E0461D511B54B00E0B1041F550230E9@poker.allegronetworks.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_01C0F8FF.C92C81A0 Content-Type: text/plain; charset="iso-8859-1" With respect to default IP MTU, although the draft did not specify a value, 4470 was desired; to be able to avoid fragmenting large FDDI packets in some of the authors' ISP networks. Its not clear which is needed more (or less), large FDDI or (somewhat large) ATM. In the time between writing the draft and now, another reason for jumbo frames became clear - to avoid fragmenting MPLS packets. pMTUd rarely works. Without more input on the predominance of FDDI vs ATM, 4470 seems the correct choice for default. -Jed Jed Kaplan Allegro Networks 12700 Fair Lakes Circle, Suite 100 Fairfax, Va 22022 email: jkaplan@allegronetworks.com ph: (703) 802-2348 ------_=_NextPart_001_01C0F8FF.C92C81A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] More vendor data on IP/GigE MTU

With respect to default IP MTU, = although the draft did not specify a value, 4470 was desired; to be = able to avoid fragmenting

large FDDI packets in some of the = authors' ISP networks.

Its not clear which is needed more (or = less), large FDDI or (somewhat large) ATM. In the time between writing = the draft and now,

another reason for jumbo frames became = clear -  to avoid fragmenting MPLS packets.  pMTUd rarely = works.

Without more input on the predominance = of FDDI vs ATM, 4470 seems the correct choice for default.

-Jed

Jed Kaplan
Allegro Networks
12700 Fair Lakes Circle, Suite = 100
Fairfax, Va 22022
email: = jkaplan@allegronetworks.com
ph: (703) 802-2348

------_=_NextPart_001_01C0F8FF.C92C81A0-- From cmartin@gnilink.net Tue Jun 19 22:59:06 2001 From: cmartin@gnilink.net (Martin, Christian) Date: Tue, 19 Jun 2001 17:59:06 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: <94B9091E1149D411A45C00508BACEB359CDBF8@entmail.gnilink.com> >From discussions I've had with folks that were closely involved with Cisco from the late 80's into the mid 90's, the 4470 MTU was decided upon to support Token Ring/FDDI-HSSI-Token Ring/FDDI connectivity without fragmentation. This MTU was carried over to the PODS3/POS cards in order to reuse system designs/components, as well as allow for a migration to these technolgies while preserving the aforementioned environment. As such, it would seem that the idea was/should be to have the WAN link MTU be >= to the largest LAN MTU that is commonplace. In the early/mid 90's, TR and FDDI were more common than jumbo-GE/10GE are today, relatively speaking. Today, however, there are very few LANs utilizing either of these technologies (except perhaps big SNA shops). So logic would dictate that we not reinvent the wheel, keep it simple, and continue to support 1500 (or 4k if needed). As to Vijay's point about >4k MTU traffic being fairly smaall, I think that data provided by providers would indicate that the majority of 4k packets are BGP updates, and this generally only occurs during session flaps (where updates can be aggregated because of matching path attribs and MinAdvertisementInterval is ignored). As far as customer traffic, 'fairly' is an understatement. Words like diminishingly, vanishingly, infinitessimally, and nil fit the bill nicely, in fact. The only exception would be the various tunneling mechanisms in use today (MPLS, GRE, L2TP), and this still only adds a few hundred bytes, max. The only need for 9k MTUs would be server-to-server traffic (I am still waiting for my OC-3 connection to my home and my 10GE NIC for my PC ;>). If this has to be done across the Internet at large, then the argument is moot as this requirement is not going to drive every ISP to change all the POS/DS3 MTUs in their networks. If the WAN is under the control of the operator from end-to-end, then this small subset of hardware purchasers need to make enough of a stink to get their respective vendors to allow for 9k buffer allocation, in hardware, on the respective WAN interfaces. I doubt this will happen without serious clout (clout = $$$), especially given Tony's quite fascinating discussion on interface hardware design. So, we have a few choices: 1) Leave the MTU at 9k as it has been deployed and allow PMTUD to determine MTU's. For those vendors that wish to support 9180k MTUs on routers, design a WAN interface that allows for 9k MTUs to get around fragmentation. 2) Set the MTU to 4470 to match the thousands of deployed links that are in use today. 3) Restandardize the PPP/HDLC framing for use over POS to 9180 and force all the hardware vendors into compliance. 4) Scrap the whole jumbogram idea altogether. As I see it, these are ranked in order of preference, and perhaps in order of likeliness as well. An Operator's Perspective, -chris > > Ran, for various reasons, including some I sent earlier to > the list, from > an operational perspective, I've never seen any demand for > > 4470+overhead > MTU. Therefore, any devices that go into networks that I've > worked on have > been required to support an MTU of ~4470, and I do not see > this changing > in the future. The amount of traffic at even 4470 is fairly small, but > there have been customers who have asked for a 4k MTU. I see no > operational customer based demand to go greater than 4k, and I suspect > this will be true for a while. > > /vijay > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From dhudek@ma.ultranet.com Wed Jun 20 06:04:31 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Tue, 19 Jun 2001 22:04:31 -0700 Subject: [Isis-wg] Whither draft-ietf-isis-hmac-nn.txt ? Message-ID: <3B302EDF.4717E787@ma.ultranet.com> Hi all, Whatever happened to draft-ietf-isis-hmac-01.txt ? It seems to have expired, and doesn't seem to have graduated into an official RFC yet? The last thing I could find mentioning it said it was stable and clear for implementation (back in Aug of last year)... was the work abandoned? adTHANKSvance, dave h From prz@redback.com Wed Jun 20 05:47:21 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 19 Jun 2001 21:47:21 -0700 Subject: [Isis-wg] Whither draft-ietf-isis-hmac-nn.txt ? References: <3B302EDF.4717E787@ma.ultranet.com> Message-ID: <3B302AD9.D72AD6C3@redback.com> David Hudek wrote: > Hi all, > > Whatever happened to draft-ietf-isis-hmac-01.txt ? > It seems to have expired, and doesn't seem to have > graduated into an official RFC yet? The last > thing I could find mentioning it said it was stable > and clear for implementation (back in Aug of last year)... > was the work abandoned? RJA is working on a new version that should have been forthcoming since a while. Funny enough, it's implemented and deployed already ;-) by some leading vendors ... thanks -- tony From mshand@cisco.com Wed Jun 20 09:53:40 2001 From: mshand@cisco.com (mike shand) Date: Wed, 20 Jun 2001 09:53:40 +0100 Subject: [Isis-wg] Help] Figure2 in RFC 1195 In-Reply-To: <001601c0f862$45b2c0c0$37c2fe81@etri.re.kr> Message-ID: <4.3.2.7.2.20010620095304.032ee270@jaws.cisco.com> At 10:50 19/06/2001 +0900, mjyang wrote:
Hi..
 
I am beginner for IS-IS..
I want to get the figure 2(Example routinng domain) in RFC 1195
and more structure diagram and figures about IS-IS if any..
Thank you..

Try the postScript version

ftp://ftp.isi.edu/in-notes/rfc1195.ps


 
-----------------
Mijung Yang / ETRI
TEL: +82-42-860-4922
FAX: +82-42-860-5440
E-mail: mjyang@etri.re.kr
From Internet-Drafts@ietf.org Wed Jun 20 11:50:13 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 20 Jun 2001 06:50:13 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-eth-00.txt Message-ID: <200106201050.GAA01820@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 : Extended Ethernet Frame Size Support Author(s) : J. Kaplan et al. Filename : draft-ietf-isis-ext-eth-00.txt Pages : Date : 19-Jun-01 This document presents an extension to current Ethernet Frame specifications for hardware and frame format to support payloads greater than 1500 Bytes for Type interpretation and Length interpretation frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-eth-00.txt 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-ext-eth-00.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-ext-eth-00.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: <20010619113121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ext-eth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ext-eth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010619113121.I-D@ietf.org> --OtherAccess-- --NextPart-- From ras@e-gerbil.net Wed Jun 20 02:29:01 2001 From: ras@e-gerbil.net (Richard A. Steenbergen) Date: Tue, 19 Jun 2001 21:29:01 -0400 (EDT) Subject: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: On Mon, Jun 18, 2001 at 09:13:32AM -0400, RJ Atkinson wrote: > > >Also, 9180 is NOT necessary to support page flipping. > >4470 would seem to very nicely support a single 4k page. > > True, but 8K pages are commonly used these days, not 4K, > so its of much less benefit than it was in the FDDI era. Not really, but they will probably be more common w/IA64 and other architectures, which will probably NOT want to use 4K pages. > More generally, *most* Gigabit Ethernet products that have > shipped in the past 3 years *already* support the 9180 MTU, including > big fast routers with GigE interfaces. So you forgot to tell the rest > of the world about your plan for 4470 to be the standard MTU. This > means that fragmentation is *already* inevitable on GigE links (if > PMTU is turned off or broken in some way). My main goal is to > document widely deployed existing practice. I happen to agree with > the reasons that such is the existing practice as well (obvious to > anyone reading this thread). In my experience, most GigE vendors do NOT support 9180. I've seen all kinds of numbers all around that, and some not even close depending on the product line or specific hardware. > As I noted at the outset, an Informational RFC is totally > non-binding (and the content of standards-track RFCs are pretty > frequently ignored as well), so I don't see why you are getting > spun up. I think the most useful thing this could do is establish a definition for "real" jumbo frame support. At this point I don't really care what it is, 8192 and some bytes for headers, 9180 is fine, but we need a STANDARD. Any such document should also spend time covering the benefits of jumbo frame support, since it seems that a number of people just don't "get it". I have to admit I really don't understand the IEEE. GigE/10GE is going to be far more common on a router or at an exchange point then on a host for a long time. There are simply too many legitimate reasons to desire support for a common larger frame size on non-host ethernet to reject the concept on the basis of someone's hardon for what their 1985 copy of Merriam Webster says for "WAN" and "LAN". Perhaps it would also be useful to focus on fixing Path MTU Discovery. For example, it might make sense to inform the sender about fragmentation in the TCP ACK, to prevent misconfigured icmp filters or rate limits. If PMTUD worked right, we would be able to support the most optimal MTU size seemlessly. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) From rja@inet.org Wed Jun 20 13:47:25 2001 From: rja@inet.org (RJ Atkinson) Date: Wed, 20 Jun 2001 08:47:25 -0400 Subject: [Isis-wg] Whither draft-ietf-isis-hmac-nn.txt ? In-Reply-To: <3B302AD9.D72AD6C3@redback.com> References: <3B302EDF.4717E787@ma.ultranet.com> Message-ID: <5.1.0.14.2.20010620084531.00a15890@10.30.15.2> At 00:47 20/06/01, Tony Przygienda wrote: >RJA is working on a new version that should have been >forthcoming since a while. Funny enough, it's implemented >and deployed already ;-) by some leading vendors ... The draft I recently came up with didn't get past the small set of editors. So an edit spin is currently in progress to try to fix the identified bugs. With luck, that version will get past the internal editors and appear as an I-D. Operator feedback during the past long while has had substantial impact on this draft's technical content. Ran From rja@inet.org Wed Jun 20 13:53:25 2001 From: rja@inet.org (RJ Atkinson) Date: Wed, 20 Jun 2001 08:53:25 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: References: <15151.43157.504408.482017@redcs1.procket.com> Message-ID: <5.1.0.14.2.20010620085009.00a1a660@10.30.15.2> At 15:59 19/06/01, Vijay Gill wrote: > least 4470 MTU (+ whatever >overhead for labels, et al is needed). Reasons for this are varied but in >general tend to be something along the lines of datacenter to datacenter >traffic and OC-x connected customers with servers doing jumbos on gigabit >ethernet devices wanting to talk to other branch offices, and therefore >we'd like to avoid fragmentation if possible. Vijay, I'm confused by your reasoning method. As currently deployed, "jumbos on gigabit ethernet devices" have an MTU of 9180, not 4470. If your comment had said "jumbos on gig ethernet devices are uncommon", then the conclusion in favour of 4470 would have been a ton more obvious to me. Saying that "jumbos on gigabit ethernet devices" and wanting to avoid fragmentation are reasons for 9180 instead of 4470. (Clarification welcome. :-) There is also the small matter that a number of exchange points (notably LINX, PAIX) support 9180 MTU Ethernet today. I recognise you're on the AboveNet side rather than the PAIX side, but any comments on that ? Ran From rja@inet.org Wed Jun 20 14:02:05 2001 From: rja@inet.org (RJ Atkinson) Date: Wed, 20 Jun 2001 09:02:05 -0400 Subject: [Isis-wg] hardware tradeoffs In-Reply-To: <15151.44194.820031.284764@redcs1.procket.com> References: <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> <5.1.0.14.2.20010616093521.00a119d0@10.30.15.2> <5.1.0.14.2.20010617212305.01ddab80@10.30.15.2> Message-ID: <5.1.0.14.2.20010620085427.00a1e760@10.30.15.2> At 15:48 19/06/01, Tony Li wrote: >Again, there are many POS links in the world which will not work at 9180, >so this is not a deployable solution. You can come down. We can't go up. >It's that simple. Having done a fair amount of hardware work lately, including some on POS interfaces, I'll simply note that its entirely practical and cost-effective to design a POS interface that can have variable amounts of memory buffering. Some other vendors have shipped these, even if you have chosen not to do this. As to the GigE MTU, a number of implementations can't change MTU downwards easily without spinning hardware (this is one of the business risks associated with very highly integrated devices; entirely analagous to the business risk of not designing a POS interface to be able to support enough buffer memory) and getting paying customers very very upset with us. GigE vendors went to 9180 due to strong paying customer demand, not on some whim. That noted, if folks only offer GigE frames with a 4470 MTU, then they obviously get passed through GigE devices just fine. It is not realistic to expect that existing GigE devices will be doing the fragmentation on behalf of some downstream device that's out of step with the rest of the GigE world. Most hosts use software for generating packets, so the originating hosts notionally could reconfigure their MTU down to 4470 on their GigE interfaces. No doubt there is some "registry" variable for this in Windows, for example. It sure sounds like we had all better start trying to figure out how to make PMTU work more reliably... :-) Regards, Ran From rja@inet.org Wed Jun 20 14:05:42 2001 From: rja@inet.org (RJ Atkinson) Date: Wed, 20 Jun 2001 09:05:42 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <200106191813.MAA00676@tcb.net> Message-ID: <5.1.0.14.2.20010620090309.00a1bec0@10.30.15.2> At 14:13 19/06/01, Danny McPherson wrote: >I'd also like to hear from other GE switch/router vendors >that agree with Ran that 9180 is 'de facto', we've only heard >from one thus far (i.e., Ran's). Foundry, Cisco (most products, one exception that I've heard about anecdotally), and Alteon (original proponent of 9180; now owned by Nortel) all support 9180 IP MTU (9200 byte Ethernet MTU). A range of workstations/servers, including WindowsNT/Windows2000, support it. Not all of those vendors are subscribed to the IS-IS mailing list, by the way, so I'd encourage you to pick up the phone if you want to hear answers from them directly. Ran From vijay@umbc.edu Wed Jun 20 20:31:38 2001 From: vijay@umbc.edu (Vijay Gill) Date: Wed, 20 Jun 2001 15:31:38 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <5.1.0.14.2.20010620085009.00a1a660@10.30.15.2> Message-ID: On Wed, 20 Jun 2001, RJ Atkinson wrote: Ran, > I'm confused by your reasoning method. As currently deployed, > "jumbos on gigabit ethernet devices" have an MTU of 9180, not 4470. > If your comment had said "jumbos on gig ethernet devices are uncommon", > then the conclusion in favour of 4470 would have been a ton more obvious > to me. Saying that "jumbos on gigabit ethernet devices" and wanting > to avoid fragmentation are reasons for 9180 instead of 4470. > (Clarification welcome. :-) Apologies for the unclear wording. I really should have said 'all we _cared_ about was ~4k mtu.' If it went higher, ok, we set it to 4470 and moved on. The point being that we didn't care about an mtu higher than ~4k, we only ensured that the edge-edge MTU in the network was at least 4470. Now this was the result of historical accident perhaps, but the only MTU related questions (a few) customers asked was if we had a 4k mtu, and we could answer in the affirmative to that. No one asked for a 9k that I was aware of, so we did not bother. > There is also the small matter that a number of exchange > points (notably LINX, PAIX) support 9180 MTU Ethernet today. I > recognise you're on the AboveNet side rather than the PAIX side, but > any comments on that ? I work for Metromedia, not AboveNet. PAIX questions would be best answered by Paul and company, but I do know that there has always been a push for large MTU by those folks. /vijay From danny@ambernetworks.com Thu Jun 21 23:09:41 2001 From: danny@ambernetworks.com (Danny McPherson) Date: Thu, 21 Jun 2001 16:09:41 -0600 Subject: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: <200106212209.QAA20071@tcb.net> [] To: isis-wg@juniper.net From: RJ Atkinson Date: Mon, 18 Jun 2001 09:13:32 -0400 [...] As I noted at the outset, an Informational RFC is totally non-binding (and the content of standards-track RFCs are pretty frequently ignored as well), so I don't see why you are getting spun up. [...] Then: [] Date: Thu, 21 Jun 2001 17:48:38 -0400 To: ipng@sunroof.eng.sun.com From: Ran Atkinson [...] Because all IS-IS WG documents are published as Informational RFCs (because ISO is the standards-body for IS-IS), many folks treat Informational RFCs from the IS-IS WG as carrying equal weight as a standards-track document. While it might not precisely *be* a standards-tack document, this tends to be the reality of output from that particular WG. [...] Quite the change of heart... However, I'm not sure I agree with your second assessment Of course, most folks outside the IETF seem to place little emphasis on the "track", regardless of what WG a given document is a product of. Then again, we're not outside the IETF. I recall the initial reasoning for the "Extended Ethernet Frame Size Support" draft being a product of the ISIS WG, but I believe now that it should probably fall into an area that would get it more exposure and feedback. -danny From Internet-Drafts@ietf.org Fri Jun 22 12:12:13 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 22 Jun 2001 07:12:13 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-03.txt Message-ID: <200106221112.HAA15925@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 for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-traffic-03.txt Pages : 11 Date : 21-Jun-01 This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-03.txt 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-traffic-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-traffic-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010621134404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-traffic-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-traffic-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134404.I-D@ietf.org> --OtherAccess-- --NextPart-- From rja@inet.org Fri Jun 22 19:28:57 2001 From: rja@inet.org (RJ Atkinson) Date: Fri, 22 Jun 2001 14:28:57 -0400 Subject: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <200106212209.QAA20071@tcb.net> Message-ID: <5.1.0.14.2.20010622142811.00a21e10@10.30.15.2> At 18:09 21/06/01, Danny McPherson wrote: >Quite the change of heart... Customer input is a very good way, probably the most effective way, to help me change my mind. That happened in this case. Ran From anders.lowinger@xelerated.com Tue Jun 26 22:18:38 2001 From: anders.lowinger@xelerated.com (Anders Lowinger) Date: Tue, 26 Jun 2001 23:18:38 +0200 Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: <31A473DBB655D21180850008C71E251A04D67B52@mail.kebne.se> > Such buffers are typically on-chip and thus are relatively > expensive. They also need to be MTU sized. The combination of > these two factors generally push designers to want a smaller MTU. > It makes the hardware more efficient, which in turn makes the > system more efficient. Tony, I'm pretty sure you know this so this is for the rest of the list. One big difference between POS and Ethernet is that if you have channelized interfaces on POS the data is byte-interleaved => reassembly is needed. If you have channelization on Ethernet, or VLAN's as it is called :-) each frame is sent back-to-back. What is the difference? Well, on a 10GE interface, to support 192 VLAN's you need 3x9180 bytes of store-and-forward buffer. On a channelized OC192 down to OC1 (DS3/T3) this will require 192x9180 bits of store-and-forward buffer. As Tony mentioned these buffers usually are on-chip and 1,68 Mbyte of on-chip memory is very much. (Actually you need the same amount in the transmit path also). Lower MTU really helps here! Back to ISIS, do we really need LSP datagrams with sizes over 1492? We could use the trick with multiple system-ID's if we run out of LSP space. What is the probability that we will have an ISIS area in which we can increase the LSP size >1492? I doubt we will see many of them. Send IP Jumbograms with EthernetII type codes, the ISIS datagrams as we do today (I think Henk mentioned this a long time ago). Regards Anders Lowinger From tli@Procket.com Wed Jun 27 00:04:37 2001 From: tli@Procket.com (Tony Li) Date: Tue, 26 Jun 2001 16:04:37 -0700 Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <31A473DBB655D21180850008C71E251A04D67B52@mail.kebne.se> References: <31A473DBB655D21180850008C71E251A04D67B52@mail.kebne.se> Message-ID: <15161.5381.530373.68221@redcs1.procket.com> | On a channelized OC192 down to OC1 (DS3/T3) this will require | 192x9180 bits of store-and-forward buffer. As Tony mentioned | these buffers usually are on-chip and 1,68 Mbyte of on-chip | memory is very much. Excellent point. | Back to ISIS, do we really need LSP datagrams with sizes over | 1492? We could use the trick with multiple system-ID's if we | run out of LSP space. Practically speaking, increasing the size of the LSP is a non-starter. It requires domain-wide coordination of the LSP size. That would practically be impossible for any domain that actually needed a larger LSP. | Send IP Jumbograms with EthernetII type codes, the ISIS | datagrams as we do today (I think Henk mentioned this | a long time ago). It's not just the LSPs. There are also the IIH's to think about. Tony From henk@Procket.com Wed Jun 27 00:10:09 2001 From: henk@Procket.com (Henk Smit) Date: Tue, 26 Jun 2001 16:10:09 -0700 (PDT) Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <31A473DBB655D21180850008C71E251A04D67B52@mail.kebne.se> from "Anders Lowinger" at Jun 26, 2001 11:18:38 PM Message-ID: <200106262310.f5QNA9U28078@redd3174.procket.com> > Back to ISIS, do we really need LSP datagrams with sizes over 1492? No, ISIS doesn't need larger LSPs. The problem was this: *) Some router vendors support "jumboframes" over GE. *) IP packets are encapsulated in EthernetII frames. (*) *) Encapsulation of EthernetII frames in such jumboframes is easy. *) ISIS sends hellos padded to mtu size, to do early detection of mtu mismatches, and other problems. *) Some ISPs wanted this early detection to keep working even over GE with jumboframes. *) Therefor, ISIS must send hellos padded up to "jumboframe mtu" *) ISIS packets are encapsulated in 802.3/802.2 frames. (*) *) 802.3/802.2 frames can not be longer than 1500 bytes. *) Therefor ISIS can not use jumboframes. *) To solve this problem (and IMHO only this problem of padded hellos) draft-ietf-isis-ext-eth-00.txt was written. Possible solutions: 1) Change ethernet specs. 2) Make IS-IS use EthernetII encapsulation. 3) Make IS-IS use IP encapsulation. 4) Forget about padding IS-IS hellos to mtu-size. It seems proposal 1) encountered more opposition than envisioned. :-) Proposals 2) and 3) are gonna introduce lots and lots of interoperability problems. Not worthwile, IMHO. Doing 4) seems a nice and simple solution. And it has the benefit that ISIS will keep working on bridged networks of GE and other flavors of Ethernet. I never understood why ISPs insisted on keeping ISIS to pad its hellos to mtu-size. OSPF sends small hellos, and that does not seem to give many more headaches. henk. -- PS.(*) I know this terminology is not the proper lingo anymore. If you know how to call those 2 encapsulation methods, please educate me. Thanks. From myeung@procket.com Wed Jun 27 00:27:09 2001 From: myeung@procket.com (Derek Yeung) Date: Tue, 26 Jun 2001 16:27:09 -0700 Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU References: <200106262310.f5QNA9U28078@redd3174.procket.com> Message-ID: <3B391A4D.2492FF7E@procket.com> Henk Smit wrote: > > > Back to ISIS, do we really need LSP datagrams with sizes over 1492? > > No, ISIS doesn't need larger LSPs. > > The problem was this: > *) Some router vendors support "jumboframes" over GE. > *) IP packets are encapsulated in EthernetII frames. (*) > *) Encapsulation of EthernetII frames in such jumboframes is easy. > *) ISIS sends hellos padded to mtu size, to do early detection > of mtu mismatches, and other problems. > *) Some ISPs wanted this early detection to keep working even over > GE with jumboframes. > *) Therefor, ISIS must send hellos padded up to "jumboframe mtu" > *) ISIS packets are encapsulated in 802.3/802.2 frames. (*) > *) 802.3/802.2 frames can not be longer than 1500 bytes. > *) Therefor ISIS can not use jumboframes. > *) To solve this problem (and IMHO only this problem of padded hellos) > draft-ietf-isis-ext-eth-00.txt was written. > > Possible solutions: > 1) Change ethernet specs. > 2) Make IS-IS use EthernetII encapsulation. > 3) Make IS-IS use IP encapsulation. > 4) Forget about padding IS-IS hellos to mtu-size. > > It seems proposal 1) encountered more opposition than envisioned. :-) > Proposals 2) and 3) are gonna introduce lots and lots of interoperability > problems. Not worthwile, IMHO. > > Doing 4) seems a nice and simple solution. And it has the benefit that > ISIS will keep working on bridged networks of GE and other flavors > of Ethernet. > > I never understood why ISPs insisted on keeping ISIS to pad its hellos > to mtu-size. OSPF sends small hellos, and that does not seem to give > many more headaches. OSPF have the same problem. OSPF solves the problem by putting the MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable to put a TLV in IIH to carry the MTU instead of padding IIH to full MTU size ? - Derek > > henk. > > -- > PS.(*) I know this terminology is not the proper lingo anymore. If you know > how to call those 2 encapsulation methods, please educate me. Thanks. > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Wed Jun 27 01:06:18 2001 From: Alex Zinin (Alex Zinin) Date: Tue, 26 Jun 2001 17:06:18 -0700 Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <3B391A4D.2492FF7E@procket.com> References: <200106262310.f5QNA9U28078@redd3174.procket.com> <3B391A4D.2492FF7E@procket.com> Message-ID: <15919150156.20010626170618@nexsi.com> I like Derek's suggestion. On the other hand, (and I do know option 3 has been beaten to death), using IP encapsulation solves this problem in a "natural" way, i.e., routing traffic follows the path of transit traffic. As an additional benefit, this will solve the problem of an ISIS adjacency staying up (and thus attracting transit traffic) even though IP processing of the box (or a line card) has gone south. Alex. >> Possible solutions: >> 1) Change ethernet specs. >> 2) Make IS-IS use EthernetII encapsulation. >> 3) Make IS-IS use IP encapsulation. >> 4) Forget about padding IS-IS hellos to mtu-size. >> >> It seems proposal 1) encountered more opposition than envisioned. :-) >> Proposals 2) and 3) are gonna introduce lots and lots of interoperability >> problems. Not worthwile, IMHO. >> >> Doing 4) seems a nice and simple solution. And it has the benefit that >> ISIS will keep working on bridged networks of GE and other flavors >> of Ethernet. >> >> I never understood why ISPs insisted on keeping ISIS to pad its hellos >> to mtu-size. OSPF sends small hellos, and that does not seem to give >> many more headaches. > OSPF have the same problem. OSPF solves the problem by putting the > MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable to put a TLV in > IIH to carry the MTU instead of padding IIH to full MTU size ? > - Derek From prz@redback.com Wed Jun 27 02:07:41 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 26 Jun 2001 18:07:41 -0700 Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU References: <200106262310.f5QNA9U28078@redd3174.procket.com> Message-ID: <3B3931DC.5366A3E0@redback.com> Henk Smit wrote: > > Back to ISIS, do we really need LSP datagrams with sizes over 1492? > > No, ISIS doesn't need larger LSPs. > > Possible solutions: > 1) Change ethernet specs. > 2) Make IS-IS use EthernetII encapsulation. > 3) Make IS-IS use IP encapsulation. > 4) Forget about padding IS-IS hellos to mtu-size. > > Proposals 2) and 3) are gonna introduce lots and lots of interoperability > problems. agreed for 2), for 3) I think you're exaggerating. I still think long-term that will take care of quite some problems that a lot of hacks are being invented to get around today. I remember the e-mail exchange and don't care to rehash all the arguments again. Let's just wait till time is ripe (and I know, it may be never ;-) > Not worthwile, IMHO. > > Doing 4) seems a nice and simple solution. And it has the benefit that > ISIS will keep working on bridged networks of GE and other flavors > of Ethernet. I never understood why ISPs insisted on keeping ISIS to pad > its hellos > to mtu-size. OSPF sends small hellos, and that does not seem to give > many more headaches. Some vendors feel strongly (maybe there was some marketing brain-washing that caused that, don't know) that it's a desirable feature to detect MTU mismatches and broken equipment loosing last 2-3 bytes and such jazz. I like Derek proposal and I think that a TLV is easily added for that purpose ... That will not diagnose broken equipment that looses the last bytes but it will take care of misconfiguration. And yes, for the list, most modern implementations allow to squelch off the padding to mtu-size as people probably know. thanks -- tony From Radia Perlman - Boston Center for Networking Wed Jun 27 03:00:20 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Tue, 26 Jun 2001 22:00:20 -0400 (EDT) Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: <200106270200.WAA02503@bcn.East.Sun.COM> Apologies in advance...I'm behind on email and haven't been following this thread, so I hope I'm not duplicating what someone else said. >>Re: Why pad to full MTU size? I vaguely remember the reason was that although you might think you're on the same link as your neighbor, you might have bridges bridging your packet over a sub-link with a smaller packet size. So the only way to tell if you really can send a packet as big as you think you can is to send such a big packet. Telling your neighbor "I can send 4000 byte packets" because you're on FDDI, and he's on FDDI, won't work if the bridged path between you contains an Ethernet with MTU 1500. I vaguely remember another reason was that someone told me that some links have failure modes where small packets go through OK but big ones don't, so you don't want to bring up the adjancency if the link is that flaky. Radia From dkatz@juniper.net Wed Jun 27 03:26:07 2001 From: dkatz@juniper.net (Dave Katz) Date: Tue, 26 Jun 2001 19:26:07 -0700 (PDT) Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU In-Reply-To: <200106262310.f5QNA9U28078@redd3174.procket.com> (message from Henk Smit on Tue, 26 Jun 2001 16:10:09 -0700 (PDT)) Message-ID: <200106270226.TAA24834@cirrus.juniper.net> For what it's worth, we only pad to the max LSP size (1492) since that's really all the padding is trying to accomplish (detecting links too small to carry some of the LSPs.) In all of the years I've been working with ISIS, the padding has shown no obvious operational benefit, but has created countless problems (anybody remember FDDI/Ethernet bridges?) MTU mismatch detection is best handled as a more straightforward extension, if anybody really cares. --Dave X-JNPR-Received-From: outside From: Henk Smit X-Confidential: Procket Confidential/Need to know Cc: isis-wg@juniper.net X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Jun 2001 16:10:09 -0700 (PDT) > Back to ISIS, do we really need LSP datagrams with sizes over 1492? No, ISIS doesn't need larger LSPs. The problem was this: *) Some router vendors support "jumboframes" over GE. *) IP packets are encapsulated in EthernetII frames. (*) *) Encapsulation of EthernetII frames in such jumboframes is easy. *) ISIS sends hellos padded to mtu size, to do early detection of mtu mismatches, and other problems. *) Some ISPs wanted this early detection to keep working even over GE with jumboframes. *) Therefor, ISIS must send hellos padded up to "jumboframe mtu" *) ISIS packets are encapsulated in 802.3/802.2 frames. (*) *) 802.3/802.2 frames can not be longer than 1500 bytes. *) Therefor ISIS can not use jumboframes. *) To solve this problem (and IMHO only this problem of padded hellos) draft-ietf-isis-ext-eth-00.txt was written. Possible solutions: 1) Change ethernet specs. 2) Make IS-IS use EthernetII encapsulation. 3) Make IS-IS use IP encapsulation. 4) Forget about padding IS-IS hellos to mtu-size. It seems proposal 1) encountered more opposition than envisioned. :-) Proposals 2) and 3) are gonna introduce lots and lots of interoperability problems. Not worthwile, IMHO. Doing 4) seems a nice and simple solution. And it has the benefit that ISIS will keep working on bridged networks of GE and other flavors of Ethernet. I never understood why ISPs insisted on keeping ISIS to pad its hellos to mtu-size. OSPF sends small hellos, and that does not seem to give many more headaches. henk. -- PS.(*) I know this terminology is not the proper lingo anymore. If you know how to call those 2 encapsulation methods, please educate me. Thanks. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From rja@extremenetworks.com Wed Jun 27 15:34:13 2001 From: rja@extremenetworks.com (Ran Atkinson) Date: Wed, 27 Jun 2001 10:34:13 -0400 Subject: [Isis-wg] Derek's proposal for MTU discovery in IS-IS In-Reply-To: <3B391A4D.2492FF7E@procket.com> References: <200106262310.f5QNA9U28078@redd3174.procket.com> Message-ID: <5.1.0.14.2.20010627102922.01f5ac60@10.30.15.2> Henk's historical analysis is extremely helpful. I hope we are all now focused on the problem at hand. Thanks much for the detailed analysis and history. At 19:27 26/06/01, Derek Yeung wrote: > OSPF have the same problem. OSPF solves the problem by putting the >MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable >to put a TLV in IIH to carry the MTU instead of padding IIH to full >MTU size ? This seems like a simpler approach. The concept is known to work (thanks to OSPF). Why don't we just try this to solve the immediate IS-IS issue that Henk outlined ? Oh, and if we do this, it might not hurt to add a MIB object or two to make MTU mismatches discovered by IS-IS easy for operators to grab via SNMP. Quite separately, I'll probably draft up an "IP over Jumbogram Ethernet-II Framing" spec that just documents the as deployed IP/Ethernet practice, as an Informational RFC. I don't see that as an IS-IS WG work item, in no small part because IS-IS does not use Ethernet-II Framing. Cheers, Ran rja@inet.org From jparker@axiowave.com Wed Jun 27 17:10:34 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 27 Jun 2001 12:10:34 -0400 Subject: [Isis-wg] Derek's proposal for MTU discovery in IS-IS Message-ID: > it might not hurt to add a MIB object or two to make MTU mismatches > discovered by IS-IS easy for operators to grab via SNMP. Ran - Would a counter in the Circuit table help? Something along the lines of isisCircRejAdjs today? - jeff parker - MIB scribe From tli@Procket.com Wed Jun 27 21:07:56 2001 From: tli@Procket.com (Tony Li) Date: Wed, 27 Jun 2001 13:07:56 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt Message-ID: <15162.15644.474511.856119@redcs1.procket.com> Folks, It's equally been forever on this draft as well, but we WOULD appreciate it if you could look it over again. It's been submitted as a revised ID. If we could get comments in by the end of next week, please. Assuming that there are no objections, we will push this forward to Informational. Ran & Tony ====================================================================== Network Working Group Tony Li INTERNET DRAFT Procket Networks draft-ietf-isis-hmac-03.txt RJ Atkinson Extreme Networks 20 June 2001 IS-IS Cryptographic Authentication STATUS OF THIS MEMO This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). ABSTRACT This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions to support IPv4 described in [3]. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. Li & Atkinson Expires in 6 months [Page 1] Internet Draft IS-IS Authentication 20 June 2001 1. Introduction The IS-IS protocol, as specified in ISO 10589, provides for the authentication of Link State PDUs (LSPs) through the inclusion of authentication information as part of the LSP. This authentication information is encoded as a Type-Length-Value (TLV) tuple. The type of the TLV is specified as 10. The length of the TLV is variable. The value of the TLV depends on the authentication algorithm and related secrets being used. The first octet of the value is used to specify the authentication type. Type 0 is reserved, type 1 indicates a cleartext password, and type 255 is used for routing domain private authentication methods. The remainder of the TLV value is known as the Authentication Value. This document extends the above situation by allocating a new authentication type for HMAC-MD5 and specifying the algorithms for the computation of the Authentication Value. This document also describes modifications to the base protocol to insure that the authentication mechanisms described in this document are effective. This document is a publication of the IS-IS Working Group within the IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual inclusion with ISO 10589. 2. Authentication Procedures The authentication type used for HMAC-MD5 is 54 (0x36). The length of the Authentication Value for HMAC-MD5 is 16, and the length field in the TLV is 17. The HMAC-MD5 algorithm requires a key K and text T as input. The key K is the password for the PDU type, as specified in ISO 10589. The text T is the PDU to be authenticated with the Authentication Value field inside of the Authentication Information TLV set to zero. Note that the Authentication Type is set to 54 and the length of the TLV is set to 17 before authentication is computed. When LSPs are authenticated, the Checksum and Remaining Lifetime fields are set to zero (0) before authentication is computed. The result of the algorithm is placed in the Authentication Value field. When calculating the HMAC-MD5 result for Sequence Number PDUs and IS-IS HELLO PDUs, Level 1 Sequence Number PDUs SHALL use the Area Authentication string as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use the domain authentication string as in Level 2 Link State PDUs. IS-IS HELLO PDUs SHALL use the Link Level Li & Atkinson Expires in 6 months [Page 2] Internet Draft IS-IS Authentication 20 June 2001 Authentication String, which MAY be different from that of Link State PDUs. The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded to the MTU size, if padding is not disabled. Implementations that support the optional checksum for the Sequence Number PDUs and IS-IS HELLO PDUs MUST NOT include the Checksum TLV. An implementation that implements HMAC-MD5 authentication and receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value is incorrect. An implementation MAY include HMAC-MD5 Authentication Information in PDUs even if it does not fully implement HMAC-MD5 authentication. This allows an implementation to generate authentication information without verifying the authentication information. This is a transition aid for networks in the process of deploying authentication. An implementation MAY check a set of passwords when verifying the Authentication Value. This provides a mechanism for incrementally changing passwords in a network. An implementation that does not implement HMAC-MD5 authentication MAY accept a PDU that contains the HMAC-MD5 Authentication Type. ISes (routers) that implement HMAC-MD5 authentication and initiate LSP purges MUST remove the body of the LSP and add the authentication TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept unauthenticated purges. ISes MUST NOT accept purges that contain TLVs other than the authentication TLV. These restrictions are necessary to prevent a hostile system from receiving an LSP, setting the Remaining Lifetime field to zero, and flooding it, thereby initiating a purge without knowing the authentication password. 2.1 Implementation Considerations There is an implementation issue just after password rollover on an IS-IS router that might benefit from additional commentary. Immediately after password rollover on the router, the router or IS- IS process may restart. If this happens, this causes the LSP Sequence Number restarts from the value 1 using the new password. However, neighbors will reject those new LSPs because the Sequence Number is smaller. The router can not increase its own LSP Sequence Number because it fails to authenticate its own old LSP that neighbors keep sending to it. So the router can not update its LSP Sequence Number to its neighbors until all the neighbors time out all of the original LSPs. One possible solution to this problem is for the IS-IS process to detect if any inbound LSP with an authentication failure has the local System ID and also has a higher Sequence Number Li & Atkinson Expires in 6 months [Page 3] Internet Draft IS-IS Authentication 20 June 2001 than the IS-IS process has. In this event, the IS-IS process SHOULD increase its own LSP Sequence Number accordingly and re-flood the LSPs. However, as this scenario could also be triggered by an active attack by an adversary, it is recommended that a counter also be kept on this case to mitigate the risk from such an active attack. 3. Security Considerations This document enhances the security of the IS-IS routing protocol. Because a routing protocol contains information that need not be kept secret, privacy is not a requirement. However, authentication of the messages within the protocol is of interest, to reduce the risk of an adversary compromising the routing system by deliberately injecting false information into the routing system. The technology in this document provides an authentication mechanism for IS-IS. The mechanism described here is not perfect and does not need to be perfect. Instead, this mechanism represents a significant increase in the work function of an adversary attacking the IS-IS protocol, while not causing undue implementation, deployment, or operational complexity. This mechanism does not prevent replay attacks, however such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information. Denial of service attacks are not generally preventable in a useful networking protocol [4]. Changes to the authentication mechanism described here (primarily: to add a Key-ID field such as OSPFv2 and RIPv2 have) were considered at some length, but ultimately were rejected. The mechanism here was already widely implemented in 1999. As of this writing, this mechanism is fairly widely deployed within the users interested in cryptographic authentication of IS-IS. The improvement provided by the proposed revised mechanism was not large enough to justify the change, given the installed base and lack of operator interest in deploying the proposed revised mechanism. If and when a key management protocol appears that is both widely implemented and easily deployed to secure routing protocols such as IS-IS, a different authentication mechanism that is designed for use with that key management schema could be added if desired. If a stronger authentication were believed to be required, then the use of a full digital signature [5] would be an approach that should be seriously considered. It was rejected for this purpose at this time because the computational burden of full digital signatures Li & Atkinson Expires in 6 months [Page 4] Internet Draft IS-IS Authentication 20 June 2001 is believed to be much higher than is reasonable given the current threat environment in operational commercial networks. ACKNOWLEDGMENTS The author would like to thank (in alphabetical order) Ran Atkinson, Dave Katz, Steven Luong, Tony Pryzygienda, Nai-Ming Shen, and Henk Smit for their comments and suggestions on this document. REFERENCES [1] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, February 1997 [2] ISO, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", International Standard 10589 [Also republished as RFC 1142]. [3] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual environments", RFC-1195, December 1990. [4] V.L. Voydock & S. T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. [5] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital Signatures", RFC-2154, June 1997. Author's Address Tony Li Procket Networks 1100 Cadillac Ct. Milpitas, California 95035 USA Email: tli@procket.net Phone: +1 (408) 635-7903 RJ Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA Email: rja@extremenetworks.com Phone: +1 (408) 579-2800 Li & Atkinson Expires in 6 months [Page 5] Internet Draft IS-IS Authentication 20 June 2001 Li & Atkinson Expires in 6 months [Page 6] From Alex Zinin Thu Jun 28 23:01:55 2001 From: Alex Zinin (Alex Zinin) Date: Thu, 28 Jun 2001 15:01:55 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <15162.15644.474511.856119@redcs1.procket.com> References: <15162.15644.474511.856119@redcs1.procket.com> Message-ID: <139736780.20010628150155@nexsi.com> ------------618D80177E8F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit After some discussion with tli, I quickly drafted a small document (attached) that addresses some nasty replay attacks not covered by the HMAC doc. The intention is to see if people interested in ISIS authentication care about this stuff at all. If there's enough interest, I'll beautify the text and we can make it a separate WG item. Another point for discussion---it may be a good idea to say that the implementations must put the Auth TLV in the beginning of the packet. This way we can drop attacker's packets and authenticate valid ones faster (we don't have to parse the whole thing). This, of course, will work only if the current implementations already do so, which I'm not 100% sure about, so more clue is welcome. Cheers, -- Alex Zinin Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote: > Folks, > It's equally been forever on this draft as well, but we WOULD appreciate it > if you could look it over again. It's been submitted as a revised ID. If > we could get comments in by the end of next week, please. Assuming that > there are no objections, we will push this forward to Informational. > Ran & Tony ------------618D80177E8F1 Content-Type: text/plain; name="draft-ietf-isis-auth-anti-replay-00.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-isis-auth-anti-replay-00.txt" CgoKCgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBbGV4IFppbmluCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTmV4c2kgU3lzdGVtcwpFeHBpcmF0aW9uIERhdGU6IERl Y2VtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDEKRmls ZSBuYW1lOiBkcmFmdC1pZXRmLWlzaXMtYXV0aC1hbnRpLXJlcGxheS0wMC50eHQKCgogICAgICAg ICAgICAgICAgICBQcm90ZWN0aW5nIElTSVMgZnJvbSByZXBsYXkgYXR0YWNrcwoKICAgICAgICAg ICAgICAgIGRyYWZ0LWlldGYtaXNpcy1hdXRoLWFudGktcmVwbGF5LTAwLnR4dAoKClN0YXR1cyBv ZiB0aGlzIE1lbW8KCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlz IGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aAogICBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEw IG9mIFJGQzIwMjYuCgogICBJbnRlcm5ldCBEcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIEFyZWFz LCBhbmQgaXRzIFdvcmtpbmcgR3JvdXBzLiBOb3RlIHRoYXQgb3RoZXIKICAgZ3JvdXBzIG1heSBh bHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQgRHJhZnRzLgoKICAg SW50ZXJuZXQgRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXgKICAgbW9udGhzLiBJbnRlcm5ldCBEcmFmdHMgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkKICAgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBu b3QgYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0CiAgIERyYWZ0cyBhcyByZWZlcmVuY2UgbWF0 ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgYSAid29ya2luZwogICBkcmFmdCIg b3IgIndvcmsgaW4gcHJvZ3Jlc3MiLgoKICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1E cmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQt YWJzdHJhY3RzLnR4dAoKICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVj dG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sLgoKCkFic3RyYWN0CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFkZGl0aW9uYWwg bWVjaGFuaXNtIGZvciBJU0lTCiAgIGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24gdGhhdCBw cm90ZWN0cyBuZXR3b3JrcyBydW5uaW5nIElTSVMgZnJvbQogICBzaW1wbGUgcGFja2V0IHJlcGxh eSBhdHRhY2tzLgoKMSBNb3RpdmF0aW9uCgogICBUaGUgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNh dGlvbiBtZWNoYW5pc20gZm9yIFtJU0lTXSwgZGVzY3JpYmVkIGluCiAgIFtITUFDXSBwcm92aWRl cyBiYXNpYyBhdXRoZW50aWNhdGlvbiBmdW5jdGlvbmFsaXR5IHN1ZmZpY2llbnQgZm9yIHRoZQog ICBtYWpvcml0eSBvZiBzaXR1YXRpb25zLiBIb3dldmVyLCB0aGlzIG1lY2hhbmlzbSBkb2VzIG5v dCBwcm90ZWN0IElTSVMKICAgbmV0d29ya3MgZnJvbSB0aGUgcmVwbGF5IGF0dGFja3MgdGhhdCBj YW4gYmUgcGVyZm9ybWVkIGJ5IHRoZQogICBhdHRhY2tlciBpZiBpdCBoYXMgZGlyZWN0IGFjY2Vz cyB0byBhIGJyb2FkY2FzdCBzZWdtZW50IHJ1bm5pbmcgSVNJUy4KCiAgIEJlY2F1c2UgdGhlIG1l Y2hhbmlzbSBkZXNjcmliZWQgaW4gW0hNQUNdIGRvZXMgbm90IGluY2x1ZGUgdGhlIG5vdGlvbgog ICBvZiAiY3J5cHRvZ3JhcGhpYyBzZXF1ZW5jZSBudW1iZXIiLCBhbiBhdHRhY2tlciBjYW4gZWFz aWx5IHJlcGxheQoKCgpaaW5pbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0KCgoKCgpJTlRFUk5FVCBEUkFGVCAgICAgUHJv dGVjdGluZyBJU0lTIGZyb20gcmVwbGF5IGF0dGFja3MgICAgICAgICBKdW5lIDIwMDEKCgogICBy ZWNvcmRlZCBJU0lTIHBhY2tldHMuCgogICBFeGFtcGxlcyBvZiB0aGVzZSBhdHRhY2tzIGluY2x1 ZGUgcmVwbGF5aW5nIGFuIGVtcHR5IChsaXN0aW5nIG5vCiAgIG5laWdoYm9yIElTKSBJSUggcGFj a2V0cyBhbmQgdGh1cyBjYXVzaW5nIHJvdXRlcnMgb24gdGhlIHNlZ21lbnQgdG8KICAgZGVzdHJv eSB0aGUgYWRqYWNlbmNpZXMgd2l0aCB0aGUgcm91dGVyIHVuZGVyIGF0dGFjaywgcmVwbGF5aW5n IENTTlAKICAgcGFja2V0cyBhbmQgdGh1cyBhcnRpZmljYWxseSBhdHRyYWN0aW5nIElTSVMgdHJh ZmZpYyAoTFNQcykgdG8gdGhlCiAgIHNlZ21lbnQncyBESVMsIGFuZCBzbyBvbi4gV2hlbiB1c2Vk IHBlcmlvZGljYWxseSwgdGhlc2UgYXR0YWNrcyBjYW4KICAgY2F1c2UgZ2xvYmFsIGluc3RhYmls aXR5IGluIGFuIElTSVMgZG9tYWluLgoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2ltcGxl IG1lY2hhbmlzbSwgc2ltaWxhciB0byB0aGUgb25lIHVzZWQgaW4KICAgdGhlIE9TUEYgcHJvdG9j b2wsIHRvIHByb3RlY3QgYW4gSVNJUyBuZXR3b3JrIGZyb20gdGhlIHJlcGxheSBhdHRhY2tzCiAg IGJ5IGludHJvZHVjaW5nIGNyeXB0b2dyYXBoaWMgc2VxdWVuY2UgbnVtYmVyIGludG8gSVNJUyBw YWNrZXRzLiBUaGUKICAgbWV0aG9kIGlzIGNvbXBhdGlibGUgd2l0aCB0aGUgZXhzaXRpbmcgaW1w bGVtZW50YXRpb25zIG9mIFtITUFDXS4KICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwcm92aWRl IGEgc29sdXRpb24gZm9yIHJlcGxheSBhdHRhY2tzIGJhc2VkIG9uCiAgIHRoZSBjcnlwdG9ncmFw aGljIHNlcXVlbmNlIG51bWJlciByb2xsLW92ZXIuIFRoZSBhZG1pbmlzdHJhdG9yIGlzCiAgIHN1 cHBvc2VkIHRvIGNoYW5nZSB0aGUga2V5cyB0byBwcmV2ZW50IHRoaXMgdHlwZSBvZiBhdHRhY2tz LgoKMiBQcm9wb3NlZCBTb2x1dGlvbgoKICAgVGhlIGNyeXB0b2dyYXBoaWMgc2VxdWVuY2UgbnVt YmVyIGlmIGludHJvZHVjZWQgaW4gSVNJUyBwYWNrZXRzIGluCiAgIHRoZSBmb3JtIG9mIGEgbmV3 IFRMViB3aXRoIHRoZSB0eXBlIGNvZGUgPFRCRD4uIFRoZSBsZW5ndGggb2YgdGhlCiAgIFZhbHVl IGZpZWxkIGluIHRoZSBUTFYgaXMgNCBieXRlcyAoMzIgYml0cykuIFRoZSB2YWx1ZSBvZiB0aGUg TGVuZ3RoCiAgIGZpZWxkIGlzIDUuCgogICBUaGUgdmFsdWUgZmllbGQgb2YgdGhlIFRMViBjb250 YWlucyB0aGUgY3J5cHRvZ3JhcGhpYyBzZXF1ZW5jZQogICBudW1iZXIuCgogMi4xIFNlbmRpbmcg SVNJUyBQYWNrZXRzIHdpdGggQ3J5cHRvZ3JhcGhpYyBTZXF1ZW5jZSBOdW1iZXIKCiAgIEltcGxl bWVudGF0aW9ucyBzdXBwb3J0aW5nIHRoZSBleHRlbnNpb25zIGRlc2NyaWJlZCBpbiB0aGlzIGRv Y3VtZW50CiAgIHNob3VsZCBtYWludGFpbiB0aGUgY3J5cHRvZ3JhcGhpYyBzZXF1ZW5jZSBudW1i ZXIgY291bnRlciBvbiBhIHBlci0KICAgaW50ZXJmYWNlIGJhc2lzLiBJbXBsZW1lbnRhdGlvbnMg bWF5IHVzZSB0aGUgdXAtdGltZSB0aW1lciwgb3IKICAgaW5pdGlhbGl6ZSB0aGUgY291bnRlciB3 aXRoIGEgemVybyB2YWx1ZSBhbmQgaW5jcmVtZW50IGl0IGFmdGVyCiAgIHNlbmRpbmcgZWFjaCBw YWNrZXQgb24gdGhlIGludGVyZmFjZS4gVGhlIGNyeXB0b2dyYXBoaWMgc2VxdWVuY2UKICAgbnVt YmVyIHJvbGwtb3ZlciBwcm9jZWR1cmUgaXMgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4K CiAgIFdoZW4gY29uc3RydWN0aW5nIGFuIElTSVMgcGFja2V0IGF1dGhlbnRpY2F0ZWQgdXNpbmcg W0hNQUNdLCB0aGUKICAgcm91dGVyIG1heSBpbmNsdWRlIHRoZSBjcnlwdG9ncmFwaGljIHNlcXVl bmNlIG51bWJlciBUTFYgaW4gaXQuIElmCiAgIHRoZSBUTFYgaXMgaW5jbHVkZWQsIGl0IHNob3Vs ZCBiZSBjb25zaWRlcmVkIGEgcGFydCBvZiB0aGUgdGV4dCBmb3IKICAgdGhlIGRpZ2VzdCBjYWxj dWxhdGlvbi4KCiAyLjMgUmVjZWl2aW5nIElTSVMgUGFja2V0cyB3aXRoIENyeXB0b2dyYXBoaWMg U2VxdWVuY2UgTnVtYmVyCgogICBJU0lTIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0aW5nIGRlc2Ny aWJlZCBleHRlbnNpb25zIHNob3VsZCBtYWludGFpbgogICB0aGUgcmVjZWl2ZWQgY3J5cHRvZ3Jh cGhpYyBzZXF1ZW5jZSBudW1iZXIgb24gYSBwZXItbmVpZ2hib3IgYmFzaXMuCgogICBXaGVuIHJl Y2VpdmluZyBhdXRoZW50aWNhdGVkIElTSVMgcGFja2V0cywgdGhlIHJvdXRlciBwZXJmb3JtcyB0 aGUKICAgZm9sbG93aW5nIGNoZWNrcy4KCgoKWmluaW4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgoKCgoKSU5URVJORVQg RFJBRlQgICAgIFByb3RlY3RpbmcgSVNJUyBmcm9tIHJlcGxheSBhdHRhY2tzICAgICAgICAgSnVu ZSAyMDAxCgoKICAgIDEuIElmIHRoZSBjcnlwdG9ncmFwaGljIHNlcXVlbmNlIG51bWJlciBUTFYg aXMgcHJlc2VudCBpbgogICAgICAgdGhlIHJlY2VpdmVkIHBhY2tldCwgY29tcGFyZSB0aGUgdmFs dWUgZm91bmQgaW4gdGhlIFRMVgogICAgICAgd2l0aCB0aGUgdmFsdWUgaW4gdGhlIG5laWdoYm9y IGRhdGEgc3RydWN0dXJlLiBJZiB0aGUKICAgICAgIHJlY2VpdmVkIHZhbHVlIGlzIGxlc3MgdGhh biB0aGUgbG9jYWxseSByZWNvcmRlZCBvbmUsCiAgICAgICB0aGUgSVNJUyBwYWNrZXQgc2hvdWxk IGJlIGlnbm9yZWQuIE90aGVyd2lzZSwgdGhlIHJvdXRlcgogICAgICAgc2hvdWxkIHBlcmZvcm0g dGhlIHBhY2tldCB2ZXJpZmljYXRpb24gcHJvY2VkdXJlIGFzCiAgICAgICBkZXNjcmliZWQgaW4g W0hNQUNdIGFuZCB1cGRhdGUgdGhlIG5laWdoYm9yIGRhdGEgc3RydWN0dXJlCiAgICAgICB3aXRo IHRoZSByZWNlaXZlZCBjcnlwbyBzZXF1ZW5jZSBudW1iZXIuCgogICAgMi4gSWYgdGhlIElTSVMg cGFja2V0IGlzIGF1dGhlbnRpY2F0ZWQgdXNpbmcgW0hNQUNdLCBkb2VzIG5vdAogICAgICAgY29u dGFpbiB0aGUgY3J5cHRvIHNlcXVlbmNlIG51bWJlciBUTFYsIGFuZCB0aGUgcm91dGVyIGlzCiAg ICAgICBjb25maWd1cmVkIHRvIHBlcmZvcm0gY3J5cHRvIHNlcXVlbmNlIG51bWJlciB2ZXJpZmlj YXRpb24KICAgICAgIG9uIHRoZSByZWNlaXZpbmcgaW50ZXJmYWNlLCB0aGUgSVNJUyBwYWNrZXQg c2hvdWxkIGJlIGlnbm9yZWQuCiAgICAgICBPdGhlcndpc2UgKHRoZSByb3V0ZXIgaXMgbm90IGNv bmZpZ3VyZWQgdG8gcGVyZm9ybSB0aGlzCiAgICAgICB2ZXJpZmljYXRpb24pLCB0aGUgcGFja2V0 IHNob3VsZCBiZSBhdXRoZW50aWNhdGVkIGFzCiAgICAgICBkZXNjcmliZWQgaW4gW0hNQUNdLgoK MyBDb21wYXRpYmlsaXR5IElzc3VlcwoKICAgSW1wbGVtZW50YXRpb25zIG5vdCBzdXBwb3J0aW5n IGRlc2NyaWJlZCBleHRlbnNpb25zIHdpbGwgaWdub3JlIHRoZQogICBjcnlwdG9ncmFwaGljIHNl cXVlbmNlIG51bWJlciBUTFYuIEFsc28sIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0aW5nCiAgIHRo ZSBuZXcgVExWIHdpbGwgaW50ZXJvcGVyYXRlIHdpdGggaW1wbGVtZW50YXRpb24gdXNpbmcgW0hN QUNdIG9ubHkKICAgdW5sZXNzIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0byBwZXJmb3JtIHNlcXVl bmNlIG51bWJlciB2ZXJpZmljYXRpb24sCiAgIHdoaWNoIGlzIGV4cGVjdGVkIHRvIGJlIGRvbmUg d2hlbiBhbGwgcm91dGVycyBvbiBhIHNlZ21lbnQgc3VwcG9ydAogICBkZXNjcmliZWQgbWVjaGFu aXNtLgoKNCBTZWN1cml0eSBpc3N1ZXMKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVj aGFuaXNtIHRoYXQgaW1wcm92ZXMgc2VjdXJpdHkgb2YgdGhlCiAgIElTSVMgcHJvdG9jb2wuCgo1 IEFja25vd2xlZGdlbWVudHMKCiAgIDxUQkQ+Cgo2IFJlZmVyZW5jZXMKCiAgIFtJU0lTXSBJU08s ICJJbnRlcm1lZGlhdGUgc3lzdGVtIHRvIEludGVybWVkaWF0ZSBzeXN0ZW0gcm91dGVpbmcKICAg ICAgICAgIGluZm9ybWF0aW9uIGV4Y2hhbmdlIHByb3RvY29sIGZvciB1c2UgaW4gY29uanVuY3Rp b24gd2l0aCB0aGUKICAgICAgICAgIFByb3RvY29sIGZvciBwcm92aWRpbmcgdGhlIENvbm5lY3Rp b25sZXNzLW1vZGUgTmV0d29yayBTZXJ2aWNlCiAgICAgICAgICAoSVNPIDg0NzMpLCIgSVNPL0lF QyAxMDU4OToxOTkyLgoKICAgW0hNQUNdIExpLCBULiwgUkogQXRraW5zb24uICJJUy1JUyBDcnlw dG9ncmFwaGljIEF1dGhlbnRpY2F0aW9uIgogICAgICAgICAgV29yayBpbiBwcm9ncmVzcy4gMjAg SnVuZSAyMDAxLiBkcmFmdC1pZXRmLWlzaXMtaG1hYy0wMy50eHQuCgo3IEF1dGhvcnMnIGFkZHJl c3NlcwoKICAgQWxleCBaaW5pbgoKCgpaaW5pbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10KCgoKCgpJTlRFUk5FVCBEUkFG VCAgICAgUHJvdGVjdGluZyBJU0lTIGZyb20gcmVwbGF5IGF0dGFja3MgICAgICAgICBKdW5lIDIw MDEKCgogICBOZXhzaSBTeXN0ZW1zCiAgIDE5NTkgQ29uY291cnNlIERyaXZlCiAgIFNhbiBKb3Nl LCBDQSA5NTEzMQogICBhemluaW5AbmV4c2kuY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKWmluaW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRdCgoK ------------618D80177E8F1-- From Alex Zinin Thu Jun 28 23:52:09 2001 From: Alex Zinin (Alex Zinin) Date: Thu, 28 Jun 2001 15:52:09 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <20010629002937.A24703@juniper.net> References: <15162.15644.474511.856119@redcs1.procket.com> <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net> Message-ID: <16012749723.20010628155209@nexsi.com> Hannes, Thanks for the comment. Except for the savings on the TLV header, what would be the benefit? On the other hand, having a new TLV that is "covered" by the HMAC digest provides a nice transition behavior, i.e., those who don't know about it, just ignore it... BTW, there's a mistake in my draft---the Length field should be 4 bytes, not 5 :) -- Alex Zinin Thursday, June 28, 2001, 3:29:37 PM, Hannes Gredler wrote: > alex, > couldn't we use a different authentication subtype > rather than a new TLV ? > hmac-md5 uses id 54 so maybe 55 ? > frame format would be 5 bytes of cryptograhic sequence # > plus 16 bytes of MD5 hash. TLV [10] length is always 22. > /hannes > On Thu, Jun 28, 2001 at 03:01:55PM -0700, Alex Zinin wrote: > | > | After some discussion with tli, I quickly drafted a small > | document (attached) that addresses some nasty replay attacks not > | covered by the HMAC doc. The intention is to see if people > | interested in ISIS authentication care about this stuff > | at all. If there's enough interest, I'll beautify the text > | and we can make it a separate WG item. > | > | Another point for discussion---it may be a good idea to say > | that the implementations must put the Auth TLV in the beginning > | of the packet. This way we can drop attacker's packets and > | authenticate valid ones faster (we don't have to parse the whole > | thing). This, of course, will work only if the current > | implementations already do so, which I'm not 100% sure about, > | so more clue is welcome. > | > | Cheers, > | > | -- > | Alex Zinin > | > | Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote: > | > | | >> Folks, > | | >> It's equally been forever on this draft as well, but we WOULD appreciate it | >> if you could look it over again. It's been submitted as a revised ID. If | >> we could get comments in by the end of next week, please. Assuming that | >> there are no objections, we will push this forward to Informational. > | | >> Ran & Tony > | > | > | > | > | > | > | Network Working Group Alex Zinin > | Internet Draft Nexsi Systems > | Expiration Date: December 2001 June 2001 > | File name: draft-ietf-isis-auth-anti-replay-00.txt > | > | > | Protecting ISIS from replay attacks > | > | draft-ietf-isis-auth-anti-replay-00.txt > | > | > | 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. Internet Drafts may be updated, replaced, or obsoleted by > | other documents at any time. It is not appropriate to use Internet > | Drafts as reference material or to cite them other than as a "working > | draft" or "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. > | > | > | Abstract > | This document describes an additional mechanism for ISIS > | cryptographic authentication that protects networks running ISIS from > | simple packet replay attacks. > | > | 1 Motivation > | > | The cryptographic authentication mechanism for [ISIS], described in > | [HMAC] provides basic authentication functionality sufficient for the > | majority of situations. However, this mechanism does not protect ISIS > | networks from the replay attacks that can be performed by the > | attacker if it has direct access to a broadcast segment running ISIS. > | > | Because the mechanism described in [HMAC] does not include the notion > | of "cryptographic sequence number", an attacker can easily replay > | > | > | > | Zinin [Page 1] > | > | > | > | > | > | INTERNET DRAFT Protecting ISIS from replay attacks June 2001 > | > | > | recorded ISIS packets. > | > | Examples of these attacks include replaying an empty (listing no > | neighbor IS) IIH packets and thus causing routers on the segment to > | destroy the adjacencies with the router under attack, replaying CSNP > | packets and thus artifically attracting ISIS traffic (LSPs) to the > | segment's DIS, and so on. When used periodically, these attacks can > | cause global instability in an ISIS domain. > | > | This document defines a simple mechanism, similar to the one used in > | the OSPF protocol, to protect an ISIS network from the replay attacks > | by introducing cryptographic sequence number into ISIS packets. The > | method is compatible with the exsiting implementations of [HMAC]. > | This document does not provide a solution for replay attacks based on > | the cryptographic sequence number roll-over. The administrator is > | supposed to change the keys to prevent this type of attacks. > | > | 2 Proposed Solution > | > | The cryptographic sequence number if introduced in ISIS packets in > | the form of a new TLV with the type code . The length of the > | Value field in the TLV is 4 bytes (32 bits). The value of the Length > | field is 5. > | > | The value field of the TLV contains the cryptographic sequence > | number. > | > | 2.1 Sending ISIS Packets with Cryptographic Sequence Number > | > | Implementations supporting the extensions described in this document > | should maintain the cryptographic sequence number counter on a per- > | interface basis. Implementations may use the up-time timer, or > | initialize the counter with a zero value and increment it after > | sending each packet on the interface. The cryptographic sequence > | number roll-over procedure is not defined in this document. > | > | When constructing an ISIS packet authenticated using [HMAC], the > | router may include the cryptographic sequence number TLV in it. If > | the TLV is included, it should be considered a part of the text for > | the digest calculation. > | > | 2.3 Receiving ISIS Packets with Cryptographic Sequence Number > | > | ISIS implementations supporting described extensions should maintain > | the received cryptographic sequence number on a per-neighbor basis. > | > | When receiving authenticated ISIS packets, the router performs the > | following checks. > | > | > | > | Zinin [Page 2] > | > | > | > | > | > | INTERNET DRAFT Protecting ISIS from replay attacks June 2001 > | > | > | 1. If the cryptographic sequence number TLV is present in > | the received packet, compare the value found in the TLV > | with the value in the neighbor data structure. If the > | received value is less than the locally recorded one, > | the ISIS packet should be ignored. Otherwise, the router > | should perform the packet verification procedure as > | described in [HMAC] and update the neighbor data structure > | with the received crypo sequence number. > | > | 2. If the ISIS packet is authenticated using [HMAC], does not > | contain the crypto sequence number TLV, and the router is > | configured to perform crypto sequence number verification > | on the receiving interface, the ISIS packet should be ignored. > | Otherwise (the router is not configured to perform this > | verification), the packet should be authenticated as > | described in [HMAC]. > | > | 3 Compatibility Issues > | > | Implementations not supporting described extensions will ignore the > | cryptographic sequence number TLV. Also, implementations supporting > | the new TLV will interoperate with implementation using [HMAC] only > | unless explicitly configured to perform sequence number verification, > | which is expected to be done when all routers on a segment support > | described mechanism. > | > | 4 Security issues > | > | This document describes a mechanism that improves security of the > | ISIS protocol. > | > | 5 Acknowledgements > | > | > | > | 6 References > | > | [ISIS] ISO, "Intermediate system to Intermediate system routeing > | information exchange protocol for use in conjunction with the > | Protocol for providing the Connectionless-mode Network Service > | (ISO 8473)," ISO/IEC 10589:1992. > | > | [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication" > | Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt. > | > | 7 Authors' addresses > | > | Alex Zinin > | > | > | > | Zinin [Page 3] > | > | > | > | > | > | INTERNET DRAFT Protecting ISIS from replay attacks June 2001 > | > | > | Nexsi Systems > | 1959 Concourse Drive > | San Jose, CA 95131 > | azinin@nexsi.com > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | Zinin [Page 4] > | > | From hannes@juniper.net Thu Jun 28 23:29:37 2001 From: hannes@juniper.net (Hannes Gredler) Date: Fri, 29 Jun 2001 00:29:37 +0200 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <139736780.20010628150155@nexsi.com>; from azinin@nexsi.com on Thu, Jun 28, 2001 at 03:01:55PM -0700 References: <15162.15644.474511.856119@redcs1.procket.com> <139736780.20010628150155@nexsi.com> Message-ID: <20010629002937.A24703@juniper.net> alex, couldn't we use a different authentication subtype rather than a new TLV ? hmac-md5 uses id 54 so maybe 55 ? frame format would be 5 bytes of cryptograhic sequence # plus 16 bytes of MD5 hash. TLV [10] length is always 22. /hannes On Thu, Jun 28, 2001 at 03:01:55PM -0700, Alex Zinin wrote: | | After some discussion with tli, I quickly drafted a small | document (attached) that addresses some nasty replay attacks not | covered by the HMAC doc. The intention is to see if people | interested in ISIS authentication care about this stuff | at all. If there's enough interest, I'll beautify the text | and we can make it a separate WG item. | | Another point for discussion---it may be a good idea to say | that the implementations must put the Auth TLV in the beginning | of the packet. This way we can drop attacker's packets and | authenticate valid ones faster (we don't have to parse the whole | thing). This, of course, will work only if the current | implementations already do so, which I'm not 100% sure about, | so more clue is welcome. | | Cheers, | | -- | Alex Zinin | | Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote: | | | > Folks, | | > It's equally been forever on this draft as well, but we WOULD appreciate it | > if you could look it over again. It's been submitted as a revised ID. If | > we could get comments in by the end of next week, please. Assuming that | > there are no objections, we will push this forward to Informational. | | > Ran & Tony | | | | | | | Network Working Group Alex Zinin | Internet Draft Nexsi Systems | Expiration Date: December 2001 June 2001 | File name: draft-ietf-isis-auth-anti-replay-00.txt | | | Protecting ISIS from replay attacks | | draft-ietf-isis-auth-anti-replay-00.txt | | | 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. Internet Drafts may be updated, replaced, or obsoleted by | other documents at any time. It is not appropriate to use Internet | Drafts as reference material or to cite them other than as a "working | draft" or "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. | | | Abstract | This document describes an additional mechanism for ISIS | cryptographic authentication that protects networks running ISIS from | simple packet replay attacks. | | 1 Motivation | | The cryptographic authentication mechanism for [ISIS], described in | [HMAC] provides basic authentication functionality sufficient for the | majority of situations. However, this mechanism does not protect ISIS | networks from the replay attacks that can be performed by the | attacker if it has direct access to a broadcast segment running ISIS. | | Because the mechanism described in [HMAC] does not include the notion | of "cryptographic sequence number", an attacker can easily replay | | | | Zinin [Page 1] | | | | | | INTERNET DRAFT Protecting ISIS from replay attacks June 2001 | | | recorded ISIS packets. | | Examples of these attacks include replaying an empty (listing no | neighbor IS) IIH packets and thus causing routers on the segment to | destroy the adjacencies with the router under attack, replaying CSNP | packets and thus artifically attracting ISIS traffic (LSPs) to the | segment's DIS, and so on. When used periodically, these attacks can | cause global instability in an ISIS domain. | | This document defines a simple mechanism, similar to the one used in | the OSPF protocol, to protect an ISIS network from the replay attacks | by introducing cryptographic sequence number into ISIS packets. The | method is compatible with the exsiting implementations of [HMAC]. | This document does not provide a solution for replay attacks based on | the cryptographic sequence number roll-over. The administrator is | supposed to change the keys to prevent this type of attacks. | | 2 Proposed Solution | | The cryptographic sequence number if introduced in ISIS packets in | the form of a new TLV with the type code . The length of the | Value field in the TLV is 4 bytes (32 bits). The value of the Length | field is 5. | | The value field of the TLV contains the cryptographic sequence | number. | | 2.1 Sending ISIS Packets with Cryptographic Sequence Number | | Implementations supporting the extensions described in this document | should maintain the cryptographic sequence number counter on a per- | interface basis. Implementations may use the up-time timer, or | initialize the counter with a zero value and increment it after | sending each packet on the interface. The cryptographic sequence | number roll-over procedure is not defined in this document. | | When constructing an ISIS packet authenticated using [HMAC], the | router may include the cryptographic sequence number TLV in it. If | the TLV is included, it should be considered a part of the text for | the digest calculation. | | 2.3 Receiving ISIS Packets with Cryptographic Sequence Number | | ISIS implementations supporting described extensions should maintain | the received cryptographic sequence number on a per-neighbor basis. | | When receiving authenticated ISIS packets, the router performs the | following checks. | | | | Zinin [Page 2] | | | | | | INTERNET DRAFT Protecting ISIS from replay attacks June 2001 | | | 1. If the cryptographic sequence number TLV is present in | the received packet, compare the value found in the TLV | with the value in the neighbor data structure. If the | received value is less than the locally recorded one, | the ISIS packet should be ignored. Otherwise, the router | should perform the packet verification procedure as | described in [HMAC] and update the neighbor data structure | with the received crypo sequence number. | | 2. If the ISIS packet is authenticated using [HMAC], does not | contain the crypto sequence number TLV, and the router is | configured to perform crypto sequence number verification | on the receiving interface, the ISIS packet should be ignored. | Otherwise (the router is not configured to perform this | verification), the packet should be authenticated as | described in [HMAC]. | | 3 Compatibility Issues | | Implementations not supporting described extensions will ignore the | cryptographic sequence number TLV. Also, implementations supporting | the new TLV will interoperate with implementation using [HMAC] only | unless explicitly configured to perform sequence number verification, | which is expected to be done when all routers on a segment support | described mechanism. | | 4 Security issues | | This document describes a mechanism that improves security of the | ISIS protocol. | | 5 Acknowledgements | | | | 6 References | | [ISIS] ISO, "Intermediate system to Intermediate system routeing | information exchange protocol for use in conjunction with the | Protocol for providing the Connectionless-mode Network Service | (ISO 8473)," ISO/IEC 10589:1992. | | [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication" | Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt. | | 7 Authors' addresses | | Alex Zinin | | | | Zinin [Page 3] | | | | | | INTERNET DRAFT Protecting ISIS from replay attacks June 2001 | | | Nexsi Systems | 1959 Concourse Drive | San Jose, CA 95131 | azinin@nexsi.com | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Zinin [Page 4] | | From hannes@juniper.net Fri Jun 29 07:28:40 2001 From: hannes@juniper.net (Hannes Gredler) Date: Fri, 29 Jun 2001 08:28:40 +0200 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <16012749723.20010628155209@nexsi.com>; from azinin@nexsi.com on Thu, Jun 28, 2001 at 03:52:09PM -0700 References: <15162.15644.474511.856119@redcs1.procket.com> <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net> <16012749723.20010628155209@nexsi.com> Message-ID: <20010629082840.A25186@juniper.net> Alex, no practical ones, only for-clarity reasons - just want to avoid to have authentication distributed over 3 TLVs. [10,133,and your TLV] - motivation for that is that some greenfield-customers of mine [=people new to the IS-IS protocol] kept asking about the motivation behind TLV 133 ... however i do admit that having the crypto-seq-key in a dedicated TLV does provide some migration-sexyness. what could be done is to _proper_ structure [subTLVs] your new TLV in order to have _one_ extensible general purpose authentication TLV, which potentially can carry future, arbitrary, security related information [pub-keys] etc ... i'd volunteer for the draft if people find that interesting .... /hannes On Thu, Jun 28, 2001 at 03:52:09PM -0700, Alex Zinin wrote: | | Hannes, | | Thanks for the comment. | | Except for the savings on the TLV header, what would | be the benefit? On the other hand, having a new TLV | that is "covered" by the HMAC digest provides a nice | transition behavior, i.e., those who don't know about | it, just ignore it... | | BTW, there's a mistake in my draft---the Length field | should be 4 bytes, not 5 :) | | -- | Alex Zinin | | Thursday, June 28, 2001, 3:29:37 PM, Hannes Gredler wrote: | | > alex, | | > couldn't we use a different authentication subtype | > rather than a new TLV ? | | > hmac-md5 uses id 54 so maybe 55 ? | | > frame format would be 5 bytes of cryptograhic sequence # | > plus 16 bytes of MD5 hash. TLV [10] length is always 22. | | > /hannes | | | > On Thu, Jun 28, 2001 at 03:01:55PM -0700, Alex Zinin wrote: | > | | > | After some discussion with tli, I quickly drafted a small | > | document (attached) that addresses some nasty replay attacks not | > | covered by the HMAC doc. The intention is to see if people | > | interested in ISIS authentication care about this stuff | > | at all. If there's enough interest, I'll beautify the text | > | and we can make it a separate WG item. | > | | > | Another point for discussion---it may be a good idea to say | > | that the implementations must put the Auth TLV in the beginning | > | of the packet. This way we can drop attacker's packets and | > | authenticate valid ones faster (we don't have to parse the whole | > | thing). This, of course, will work only if the current | > | implementations already do so, which I'm not 100% sure about, | > | so more clue is welcome. | > | | > | Cheers, | > | | > | -- | > | Alex Zinin | > | | > | Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote: | > | | > | | | >> Folks, | > | | | >> It's equally been forever on this draft as well, but we WOULD appreciate it | | >> if you could look it over again. It's been submitted as a revised ID. If | | >> we could get comments in by the end of next week, please. Assuming that | | >> there are no objections, we will push this forward to Informational. | > | | | >> Ran & Tony | > | | > | | > | | > | | > | | > | | > | Network Working Group Alex Zinin | > | Internet Draft Nexsi Systems | > | Expiration Date: December 2001 June 2001 | > | File name: draft-ietf-isis-auth-anti-replay-00.txt | > | | > | | > | Protecting ISIS from replay attacks | > | | > | draft-ietf-isis-auth-anti-replay-00.txt | > | | > | | > | 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. Internet Drafts may be updated, replaced, or obsoleted by | > | other documents at any time. It is not appropriate to use Internet | > | Drafts as reference material or to cite them other than as a "working | > | draft" or "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. | > | | > | | > | Abstract | > | This document describes an additional mechanism for ISIS | > | cryptographic authentication that protects networks running ISIS from | > | simple packet replay attacks. | > | | > | 1 Motivation | > | | > | The cryptographic authentication mechanism for [ISIS], described in | > | [HMAC] provides basic authentication functionality sufficient for the | > | majority of situations. However, this mechanism does not protect ISIS | > | networks from the replay attacks that can be performed by the | > | attacker if it has direct access to a broadcast segment running ISIS. | > | | > | Because the mechanism described in [HMAC] does not include the notion | > | of "cryptographic sequence number", an attacker can easily replay | > | | > | | > | | > | Zinin [Page 1] | > | | > | | > | | > | | > | | > | INTERNET DRAFT Protecting ISIS from replay attacks June 2001 | > | | > | | > | recorded ISIS packets. | > | | > | Examples of these attacks include replaying an empty (listing no | > | neighbor IS) IIH packets and thus causing routers on the segment to | > | destroy the adjacencies with the router under attack, replaying CSNP | > | packets and thus artifically attracting ISIS traffic (LSPs) to the | > | segment's DIS, and so on. When used periodically, these attacks can | > | cause global instability in an ISIS domain. | > | | > | This document defines a simple mechanism, similar to the one used in | > | the OSPF protocol, to protect an ISIS network from the replay attacks | > | by introducing cryptographic sequence number into ISIS packets. The | > | method is compatible with the exsiting implementations of [HMAC]. | > | This document does not provide a solution for replay attacks based on | > | the cryptographic sequence number roll-over. The administrator is | > | supposed to change the keys to prevent this type of attacks. | > | | > | 2 Proposed Solution | > | | > | The cryptographic sequence number if introduced in ISIS packets in | > | the form of a new TLV with the type code . The length of the | > | Value field in the TLV is 4 bytes (32 bits). The value of the Length | > | field is 5. | > | | > | The value field of the TLV contains the cryptographic sequence | > | number. | > | | > | 2.1 Sending ISIS Packets with Cryptographic Sequence Number | > | | > | Implementations supporting the extensions described in this document | > | should maintain the cryptographic sequence number counter on a per- | > | interface basis. Implementations may use the up-time timer, or | > | initialize the counter with a zero value and increment it after | > | sending each packet on the interface. The cryptographic sequence | > | number roll-over procedure is not defined in this document. | > | | > | When constructing an ISIS packet authenticated using [HMAC], the | > | router may include the cryptographic sequence number TLV in it. If | > | the TLV is included, it should be considered a part of the text for | > | the digest calculation. | > | | > | 2.3 Receiving ISIS Packets with Cryptographic Sequence Number | > | | > | ISIS implementations supporting described extensions should maintain | > | the received cryptographic sequence number on a per-neighbor basis. | > | | > | When receiving authenticated ISIS packets, the router performs the | > | following checks. | > | | > | | > | | > | Zinin [Page 2] | > | | > | | > | | > | | > | | > | INTERNET DRAFT Protecting ISIS from replay attacks June 2001 | > | | > | | > | 1. If the cryptographic sequence number TLV is present in | > | the received packet, compare the value found in the TLV | > | with the value in the neighbor data structure. If the | > | received value is less than the locally recorded one, | > | the ISIS packet should be ignored. Otherwise, the router | > | should perform the packet verification procedure as | > | described in [HMAC] and update the neighbor data structure | > | with the received crypo sequence number. | > | | > | 2. If the ISIS packet is authenticated using [HMAC], does not | > | contain the crypto sequence number TLV, and the router is | > | configured to perform crypto sequence number verification | > | on the receiving interface, the ISIS packet should be ignored. | > | Otherwise (the router is not configured to perform this | > | verification), the packet should be authenticated as | > | described in [HMAC]. | > | | > | 3 Compatibility Issues | > | | > | Implementations not supporting described extensions will ignore the | > | cryptographic sequence number TLV. Also, implementations supporting | > | the new TLV will interoperate with implementation using [HMAC] only | > | unless explicitly configured to perform sequence number verification, | > | which is expected to be done when all routers on a segment support | > | described mechanism. | > | | > | 4 Security issues | > | | > | This document describes a mechanism that improves security of the | > | ISIS protocol. | > | | > | 5 Acknowledgements | > | | > | | > | | > | 6 References | > | | > | [ISIS] ISO, "Intermediate system to Intermediate system routeing | > | information exchange protocol for use in conjunction with the | > | Protocol for providing the Connectionless-mode Network Service | > | (ISO 8473)," ISO/IEC 10589:1992. | > | | > | [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication" | > | Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt. | > | | > | 7 Authors' addresses | > | | > | Alex Zinin | > | | > | | > | | > | Zinin [Page 3] | > | | > | | > | | > | | > | | > | INTERNET DRAFT Protecting ISIS from replay attacks June 2001 | > | | > | | > | Nexsi Systems | > | 1959 Concourse Drive | > | San Jose, CA 95131 | > | azinin@nexsi.com | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | Zinin [Page 4] | > | | > | | | | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg From prz@net4u.ch Fri Jun 29 08:20:07 2001 From: prz@net4u.ch (Tony Przygienda) Date: Fri, 29 Jun 2001 09:20:07 +0200 (MEST) Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <139736780.20010628150155@nexsi.com> from Alex Zinin at "Jun 28, 2001 3: 1:55 pm" Message-ID: <200106290720.JAA15862@net4u.net4u.ch> > > After some discussion with tli, I quickly drafted a small > document (attached) that addresses some nasty replay attacks not > covered by the HMAC doc. The intention is to see if people > interested in ISIS authentication care about this stuff > at all. If there's enough interest, I'll beautify the text > and we can make it a separate WG item. hmm , wouldn't that be rather something that we'd stick together with key id into the HMAC TLV ? I'm getting just so litle concerned about the proliferation of arbitrary TLVs floating around. It's not even that much the number space but you have to define the correlation of all those pieces of junk (eeeh, sorry, information) to each other. What you do if HMAC is not around and you have this crypto sequence number in the packet? And what if you have HMAC but not the crypto. The answer is always 'Obviously you do X' but if not spelled out in some clear specs what X must be , multiple implementors arrive to different 'X' solutions and interesting effects will occur. This group is here to prevent those interesting effects from happening. Technically, I glanced over your draft and it seems to me that what you trying to field is a 'nonce'. I've been told nonces are pretty useless unless you actually negotiate them during adjacency bring-up since otherwise somebody can record a session and replay it with the recorded nonces. So not much protection you give. As well, think about implementations that process hellos before they get to CSNP so they reorder internally. That makes nonces hard since those implementations could drop packets arbitrarily. Nothing anywhere seems to say that you have to process packets in the sequence you take them of the wire. BGP is simpler in this respect. Rja may want to chime in here but otherwise I'd strongly suggest to consult a security expert who's done that before. I did that mechanism (key negotiation, nonce, even source authentication) in all gory details once and it has more to it than meets the eye. Key id was kind of too obvious to let it pass I thought but getting into nonces will take it sweet time to get right. Having said that, I have nothing against a draft that specifies TLV as we have today, key id+HMAC variation of the TLV and later version/RFC with key id + nonce + HMAC variation of the TLV. They'll be all backwards compatible since you can differentiate them on the length of the TLV. The only sentence needed is "implementation MUST ignore HMAC TLV with unexpected length". Of course per interface knob is needed to say "send-plain-HMAC", "send-keyid-HMAC", "send-keyid-nonce-HMAC". I don't have any particular preference, I'm just trying to keep the discussion technically sound and speak out trade-offs involved. > Another point for discussion---it may be a good idea to say > that the implementations must put the Auth TLV in the beginning > of the packet. This way we can drop attacker's packets and > authenticate valid ones faster (we don't have to parse the whole > thing). This, of course, will work only if the current > implementations already do so, which I'm not 100% sure about, > so more clue is welcome. parsing the TLV headers until you arrive to the HMAC tlv is very cheap (withough looking @ the content until you hit HMAC). If you enforce that Auth TLV must be first, then you have to say what the implemenation supposed to do when it's not. Dropping the packet is kind of too harsh so you probably want "it SHOULD put it in the beginning and if it's somewhere else, accept anyway". Paul Koning taught me something about protocol design: If you want something in a packet but then you accept it anyway if it's not that way, it's a waste of time even specifying it. Occams razor or in words of Goethe "In der Beschraenkung zeigt sich der Meister" or in words of Henk "be liberal in what you accept" ;-) -- tony From prz@redback.com Fri Jun 29 08:07:19 2001 From: prz@redback.com (Tony Przygienda) Date: Fri, 29 Jun 2001 00:07:19 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <15162.15644.474511.856119@redcs1.procket.com> <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net> <16012749723.20010628155209@nexsi.com> <20010629082840.A25186@juniper.net> Message-ID: <3B3C2927.7F19E4BD@redback.com> Hannes Gredler wrote: > Alex, > > no practical ones, only for-clarity reasons - > just want to avoid to have authentication distributed over 3 TLVs. > [10,133,and your TLV] - > motivation for that is that some greenfield-customers of mine > [=people new to the IS-IS protocol] kept asking about > the motivation behind TLV 133 ... > > however i do admit that having the crypto-seq-key in a > dedicated TLV does provide some migration-sexyness. > > what could be done is to _proper_ structure [subTLVs] > your new TLV in order to have _one_ extensible > general purpose authentication TLV, which potentially > can carry future, arbitrary, security related information > [pub-keys] etc ... > > i'd volunteer for the draft if people find that interesting .... not a bad idea me thinks. That could take care of the key-id, nonce and other stuff in a cleaner way that all other ways I've seen so far. Why wouldn't we attach that stuff in 133 right after the HMAC e.g. ? -- tony From Alex Zinin Fri Jun 29 08:46:31 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 29 Jun 2001 00:46:31 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <20010629082840.A25186@juniper.net> References: <15162.15644.474511.856119@redcs1.procket.com> <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net> <16012749723.20010628155209@nexsi.com> <20010629082840.A25186@juniper.net> Message-ID: <1193487614.20010629004631@nexsi.com> Hannes, > no practical ones, only for-clarity reasons - > just want to avoid to have authentication distributed over 3 TLVs. > [10,133,and your TLV] - > motivation for that is that some greenfield-customers of mine > [=people new to the IS-IS protocol] kept asking about > the motivation behind TLV 133 ... Well, since 133 is not used anyway, we have only two, which should be ok :) > however i do admit that having the crypto-seq-key in a > dedicated TLV does provide some migration-sexyness. Yes, and I think this is pretty valuable. > what could be done is to _proper_ structure [subTLVs] > your new TLV in order to have _one_ extensible > general purpose authentication TLV, which potentially > can carry future, arbitrary, security related information > [pub-keys] etc ... Hmmm... No problem subdividing... Would save the T-space, I guess... Kind of having hard time imagining people actually putting anything there considering the current state of interest in security, though :)) > i'd volunteer for the draft if people find that interesting .... Let's see what people say and coordinate then. Alex. From Alex Zinin Fri Jun 29 09:13:19 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 29 Jun 2001 01:13:19 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <200106290720.JAA15862@net4u.net4u.ch> References: <200106290720.JAA15862@net4u.net4u.ch> Message-ID: <1145095136.20010629011319@nexsi.com> That's a long one :) See below, pls. >> After some discussion with tli, I quickly drafted a small >> document (attached) that addresses some nasty replay attacks not >> covered by the HMAC doc. The intention is to see if people >> interested in ISIS authentication care about this stuff >> at all. If there's enough interest, I'll beautify the text >> and we can make it a separate WG item. > hmm , wouldn't that be rather something that we'd stick together > with key id into the HMAC TLV ? Correct me if I'm wrong, but HMAC is not trying to send the Key ID, just the digest. I specifically wanted to introduce as less changes to the HMAC mechanism (since it is already deployed, I take it) as possible. > I'm getting just so litle concerned > about the proliferation of arbitrary TLVs floating around. It's > not even that much the number space but you have to define the > correlation of all those pieces of junk (eeeh, sorry, information) > to each other. What you do if HMAC is not around and you have > this crypto sequence number in the packet? And what if you have > HMAC but not the crypto. The answer is always 'Obviously you do X' > but if not spelled out in some clear specs what X must be , > multiple implementors > arrive to different 'X' solutions and interesting effects will > occur. This group is here to prevent those interesting effects > from happening. That's why I said this is a quick _draft_ and I'll address this if there's enough interest. > Technically, I glanced over your draft and it seems to me that what you > trying to field is a 'nonce'. Exactly, but not a random one as other protos do... > I've been told nonces are pretty > useless unless you actually negotiate them during adjacency > bring-up since otherwise somebody can record a session and > replay it with the recorded nonces. So not much protection you give. Yes and no. Yes, meaning that the attacker can replay the session. No meaning that protection is still there. We use the same mechanism in OSPF. The assumption is that the key is changed on the segment (in the domain) before the CryproSeqNum rolls over. > As well, think about implementations that process hellos before > they get to CSNP so they reorder internally. That makes nonces > hard since those implementations could drop packets arbitrarily. > Nothing anywhere seems to say that you have to process packets in the > sequence you take them of the wire. BGP is simpler in this respect. I agree here. Note however, that implementations usually do the authentication check as a part of the common sanity check and _then_ diverge the processing paths. So, this is addressible. > Rja may want to chime > in here but otherwise I'd strongly suggest to consult a security > expert who's done that before. I did that mechanism (key > negotiation, nonce, even source authentication) in all gory > details once and it has more to it than meets the eye. Key id > was kind of too obvious to let it pass I thought but getting > into nonces will take it sweet time to get right. Hmmm... I think it's doable. The scheme works for OSPF already. > Having said > that, I have nothing against a draft that specifies TLV > as we have today, key id+HMAC variation of the TLV and later version/RFC > with key id + nonce + HMAC variation of the TLV. They'll be all > backwards compatible since you can differentiate them on the > length of the TLV. The only sentence needed is "implementation > MUST ignore HMAC TLV with unexpected length". Of course per > interface knob is needed to say "send-plain-HMAC", "send-keyid-HMAC", > "send-keyid-nonce-HMAC". I don't have any particular > preference, I'm just trying to keep the discussion > technically sound and speak out trade-offs involved. I guess another consideration here is how much HMAC is deployed and whether the length check is there or not. If it's not there, and it's relatively widely deployed, we better off using a new TLV. >> Another point for discussion---it may be a good idea to say >> that the implementations must put the Auth TLV in the beginning >> of the packet. This way we can drop attacker's packets and >> authenticate valid ones faster (we don't have to parse the whole >> thing). This, of course, will work only if the current >> implementations already do so, which I'm not 100% sure about, >> so more clue is welcome. > parsing the TLV headers until you arrive to the HMAC tlv is > very cheap (withough looking @ the content until you hit HMAC). One could envision an attacker doing a DOS-type of attack sending invalid, MTU-long IIHs, containing bogus TLVs and putting the HMAC one the last in set. Couple of loads instead of hundreds sounds like a difference. Now recall jumbos and subsecond hellos... I'm not saying this will save us from it, but it just seems better to me. > If you enforce that Auth TLV must be first, then you > have to say what the implemenation supposed to do when it's not. > Dropping the packet > is kind of too harsh so you probably want "it SHOULD put it in > the beginning and if it's somewhere else, accept anyway". No, this would defeat the whole thing. > Paul Koning taught me something about protocol > design: If you want something in a packet but then you accept it > anyway if it's not that way, it's a waste of time even specifying > it. Exactly. > Occams razor or > in words of Goethe "In der Beschraenkung zeigt sich der Meister" or > in words of Henk "be liberal in what you accept" ;-) Well, I guess protocol security itself is kind of an exception from this rule :) IMHO if implementations do put 10 in some order today, we should take advantage of this. Alex. From Alex Zinin Fri Jun 29 09:18:31 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 29 Jun 2001 01:18:31 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <3B3C2927.7F19E4BD@redback.com> References: <15162.15644.474511.856119@redcs1.procket.com> <139736780.20010628150155@nexsi.com> <20010629002937.A24703@juniper.net> <16012749723.20010628155209@nexsi.com> <20010629082840.A25186@juniper.net> <3B3C2927.7F19E4BD@redback.com> Message-ID: <435406984.20010629011831@nexsi.com> Putting the key-id sounds indeed as a _real_ reason for sub-TLVs. Alex. > not a bad idea me thinks. That could take care of the key-id, nonce > and other stuff in a cleaner way that all other ways I've seen so far. > Why wouldn't we attach that stuff in 133 right after the HMAC e.g. ? > -- tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Fri Jun 29 09:29:29 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 29 Jun 2001 01:29:29 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <1145095136.20010629011319@nexsi.com> References: <200106290720.JAA15862@net4u.net4u.ch> <1145095136.20010629011319@nexsi.com> Message-ID: <1536064900.20010629012929@nexsi.com> Friday, June 29, 2001, 1:13:19 AM, Alex Zinin wrote: > I guess another consideration here is how much HMAC is deployed > and whether the length check is there or not. If it's not there, > and it's relatively widely deployed, we better off using a new TLV. Commenting myself. I would expect the length check to be there as a part of normal well-known TLV processing, so probably this is not a problem. But using 133 with Sub-TLVs sounds indeed better to me. Alex. From dhudek@ma.ultranet.com Fri Jun 29 21:21:58 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Fri, 29 Jun 2001 13:21:58 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <200106290720.JAA15862@net4u.net4u.ch> <1145095136.20010629011319@nexsi.com> Message-ID: <3B3CE366.6D5259D7@ma.ultranet.com> Alex Zinin wrote: > > As well, think about implementations that process hellos before > > they get to CSNP so they reorder internally. That makes nonces > > hard since those implementations could drop packets arbitrarily. > > Nothing anywhere seems to say that you have to process packets in the > > sequence you take them of the wire. BGP is simpler in this respect. > > I agree here. Note however, that implementations usually do the > authentication check as a part of the common sanity check and _then_ > diverge the processing paths. So, this is addressible. This might make things more difficult for implementations that use a separate high priority/urgent data path for received hellos, taking a divergent processing path _before_ any common protocol sanity checking. Of course, there are alternate methods that could be employed, but it raises a question... Out of curiosity, what would be the security effects of slightly loosening the condition that a received message must have a higher crypto seq num than the last recorded crypto seq num from the nbr, to instead say that a received message must have a crypto seq num no less than N behind the last recorded crypto seq num from the nbr (for small N) ? Instead of monotonically increasing received seq numbers, there would then be a small window of lagging but still valid numbers which slides up. On the one hand, it would permit a small amount of internal reordering (e.g., hellos could leapfrog up a bit), but on the other hand it would allow a malicious entity to replay some of the currently last N messages. How much of a lag would there need to be to cause a serious security risk? Side note: after rereading the draft, I have another question... in section 2.3 step 1, it says that the received crypto seq number cannot be less than the last recorded one... assuming that seq nums should be increasing per sec 2.1, should that say instead that it cannot be less than or equal to the recorded one (i.e., must be greater)? Also, if so, then sec 2.1 should probably say on sending to init at 1 or greater instead of allowing 0 since the increment is done after sending (assuming the receiving side will init the recorded value to 0). Thanks, dave h From rja@inet.org Fri Jun 29 17:45:51 2001 From: rja@inet.org (RJ Atkinson) Date: Fri, 29 Jun 2001 12:45:51 -0400 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <1145095136.20010629011319@nexsi.com> References: <200106290720.JAA15862@net4u.net4u.ch> <200106290720.JAA15862@net4u.net4u.ch> Message-ID: <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2> At 04:13 29/06/01, Alex Zinin wrote: >> I've been told nonces are pretty >> useless unless you actually negotiate them during adjacency >> bring-up since otherwise somebody can record a session and >> replay it with the recorded nonces. So not much protection you give. > >Yes and no. Yes, meaning that the attacker can replay the session. >No meaning that protection is still there. We use the same mechanism >in OSPF. The assumption is that the key is changed on the segment >(in the domain) before the CryproSeqNum rolls over. There are known issues with the OSPF and RIP use of the sequence number. Vernon Schryver is normally happy to discuss at some length if asked. As it happens, the deployment was too widespread for it to be realistic to change either of those specs -- at the point that issue entered the public literature. Ran From Alex Zinin Fri Jun 29 19:00:04 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 29 Jun 2001 11:00:04 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <3B3CE366.6D5259D7@ma.ultranet.com> References: <200106290720.JAA15862@net4u.net4u.ch> <1145095136.20010629011319@nexsi.com> <3B3CE366.6D5259D7@ma.ultranet.com> Message-ID: <14340299757.20010629110004@nexsi.com> David, Friday, June 29, 2001, 1:21:58 PM, David Hudek wrote: >> I agree here. Note however, that implementations usually do the >> authentication check as a part of the common sanity check and _then_ >> diverge the processing paths. So, this is addressible. > This might make things more difficult for implementations > that use a separate high priority/urgent data path for > received hellos, taking a divergent processing path _before_ > any common protocol sanity checking. Of course, there are alternate > methods that could be employed, but it raises a question... Good point, see below. > Out of curiosity, what would be the security effects of slightly > loosening the condition that a received message must have a higher > crypto seq num than the last recorded crypto seq num from the nbr, > to instead say that a received message must have a crypto seq num > no less than N behind the last recorded crypto seq num from the nbr > (for small N) ? Instead of monotonically increasing received seq > numbers, there would then be a small window of lagging but still valid > numbers which slides up. On the one hand, it would permit a small amount > of internal reordering (e.g., hellos could leapfrog up a bit), > but on the other hand it would allow a malicious entity to replay > some of the currently last N messages. How much of > a lag would there need to be to cause a serious security risk? Well... this would give a much bigger window to the attacker. I think the right way to address the problem of convergent processing paths is maintaining separate CSNs on the sending and the receiving sides so that CSNs, SNPs and LSPs have different contexts. In fact, since ISIS is authenticating LSPs, one would probably want to have separate CSNs for LSPs anyway. So we can just make it generalized enough and say the three groups have separate sets. > Side note: after rereading the draft, > I have another question... in section 2.3 step 1, it says that > the received crypto seq number cannot be less than the last > recorded one... assuming that seq nums should be increasing per sec 2.1, > should that say instead that it cannot be less than or equal to > the recorded one (i.e., must be greater)? The reason for strict "not less" is to allow implementations that use a local timer as the CSN and send multiple packets within a sec. Thanks, Alex. > Also, if so, then sec 2.1 should probably say on sending > to init at 1 or greater instead of allowing 0 since the increment > is done after sending (assuming the receiving side will init the > recorded value to 0). > Thanks, > dave h > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Fri Jun 29 19:06:28 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 29 Jun 2001 11:06:28 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2> References: <200106290720.JAA15862@net4u.net4u.ch> <200106290720.JAA15862@net4u.net4u.ch> <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2> Message-ID: <3140683129.20010629110628@nexsi.com> Ran, Thanks for the info, I'll get in touch with Vernon. Meanwhile, do you have any pointers? -- Alex Zinin Friday, June 29, 2001, 9:45:51 AM, RJ Atkinson wrote: > At 04:13 29/06/01, Alex Zinin wrote: >>> I've been told nonces are pretty >>> useless unless you actually negotiate them during adjacency >>> bring-up since otherwise somebody can record a session and >>> replay it with the recorded nonces. So not much protection you give. >> >>Yes and no. Yes, meaning that the attacker can replay the session. >>No meaning that protection is still there. We use the same mechanism >>in OSPF. The assumption is that the key is changed on the segment >>(in the domain) before the CryproSeqNum rolls over. > There are known issues with the OSPF and RIP use of the > sequence number. Vernon Schryver is normally happy to discuss > at some length if asked. As it happens, the deployment was > too widespread for it to be realistic to change either of those specs > -- at the point that issue entered the public literature. > Ran > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Fri Jun 29 23:16:01 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 29 Jun 2001 15:16:01 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <14340299757.20010629110004@nexsi.com> References: <200106290720.JAA15862@net4u.net4u.ch> <1145095136.20010629011319@nexsi.com> <3B3CE366.6D5259D7@ma.ultranet.com> <14340299757.20010629110004@nexsi.com> Message-ID: <12355656019.20010629151601@nexsi.com> Friday, June 29, 2001, 11:00:04 AM, Alex Zinin wrote: > I think the right way to address the problem of convergent processing > paths is maintaining separate CSNs on the sending and the receiving > sides so that CSNs, SNPs and LSPs have different contexts. In fact, since > ISIS is authenticating LSPs, one would probably want to have separate > CSNs for LSPs anyway. So we can just make it generalized enough and > say the three groups have separate sets. Thinking more about this... I guess we can go without CSNs in LSPs, as the LSP's own SN should be enough in most cases (except for the purge case, which is described in HMAC). So, we need only two CSN groups---IIH & SNPs. Alex. From Alex Zinin Sat Jun 30 04:06:09 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 29 Jun 2001 20:06:09 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <3140683129.20010629110628@nexsi.com> References: <200106290720.JAA15862@net4u.net4u.ch> <200106290720.JAA15862@net4u.net4u.ch> <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2> <3140683129.20010629110628@nexsi.com> Message-ID: <10773060375.20010629200609@nexsi.com> Folks, So, we had a discussion with Vernon (RJ was CC'ed, so he'll probably step in if I do not reflect the discussion correctly). The SeqNum problems discussed are as follows: 1. What happens when the SeqNum rolls back to 0. 2. What happens when the router restarts. I share these concerns completely. They way I suggest these problems to be addressed is as follows. (I belive Jerome Etienne has a paper on a similar mechanism for OSPF somewhere.) 1. SeqNum roll back does not seem to be a problem to me, see item 4 below. 2. In the new TLV, introduce the generation ID (16 or 32 bits). 3. The implementations guarantee that the generation ID is incremented with each reboot using one of multiple methods, e.g., reading, incrementing and writing it back to nvram on each boot, or using seconds since somewhen, or a calendar clock, whatever is better suited for a specific system. 4. The CSN is incremented after each packet. If a system sends 10 packs per sec, 32-bit space will give us more than 10 years of a key lifetime. We may want to increase it though, if we seriously consider subsecond hellos. 5. The receiving side checks that the CSN in the packet is _greater_ than the locally stored value. Vernon did not seem to like the scheme, because of the possible issues with NVRAM, and calendar clock... I believe the scheme works. The NVRAM/flash/disk/floppy/tape/punch-card portion should work, since the write is happening once per reboot and does not depend on the packet sending frequency. In fact I believe this is an implementation issue and the doc should only hint on this, but definitely not specify. If anyone believes there are flaws, please speak up. Cheers, Alex. From dhudek@ma.ultranet.com Sat Jun 30 19:59:32 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Sat, 30 Jun 2001 11:59:32 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <200106290720.JAA15862@net4u.net4u.ch> <1145095136.20010629011319@nexsi.com> <3B3CE366.6D5259D7@ma.ultranet.com> <14340299757.20010629110004@nexsi.com> <12355656019.20010629151601@nexsi.com> Message-ID: <3B3E2194.9D853DEE@ma.ultranet.com> Alex Zinin wrote: > Thinking more about this... I guess we can go without CSNs in LSPs, > as the LSP's own SN should be enough in most cases (except for > the purge case, which is described in HMAC). So, we need only > two CSN groups---IIH & SNPs. Sounds good. Allows implementations to easily reorder types of messages if desired (e.g., high priority hellos) ------------------------------------------------------------------- I had another question, but upon reading my email this morning, I see that it's already been addressed :-) (problem with restarting after being up for a while... after restart you are using small seq num but BadGuy replays one of your previous high seq num to your peer... so peer stops listening to you until/unless your seq num increments up to the old value) I'm definitely NOT a security expert, but since there were some drawbacks mentioned for the proposed scheme (issues with NVRAM, and calendar clock), I'm wondering what would be the drawbacks of taking a page from the LSP seq num handling and just putting in a mechanism for an entity to bump up their seq num state if they discover a prior incarnation with higher state floating about. They could discover that if the crypto data in a hello included not only your crypto state (seqNum, or genId + seqNum) for the message in question, but also your current view of your neighbor's state for each category (IIH, SNP). If upon examining your neighbor's hello, you discovered that they had been fooled, you could set your seq number state appropriately (e.g., set genId/seqNum higher) and so recover. To handle the case of both sides under attack at the same time, I suppose the procedure would have to change to have you conditionally trust the neighbor's view of yourself even if their own seq num is too small to trust the rest of the message (assuming it passes the hmac test)... only trust and act upon it if the number is greater than your current value, so you only ratchet up (never reduce) crypto state. As long as both sides only ratchet up their crypto state, naively it would appear to be OK for such trust (don't at first see how a BadGuy could exploit the conditional trust of the neighbor's view of your seq num... even if they replayed an older one with smaller values you wouldn't set your state lower). There may be horrible security flaws in this :-), but it does seem a little simpler and more automatic, without any nvram, calendar clock, etc. issues. You can start off with 0 state and recover to acceptable state after a hello from your peer. Might be worth discussing? Actually, I just thought of one possible bad scenario, but it seems sort of far-out?... if a BadGuy had a large history of your prior messages (you had been up a long time), then they could incrementally fool your neighbor... replay to set seq num a bit higher than you, then you recover, then they replay a different one to set yet a bit higher, then you recover, etc. You could recover with a relatively large extra jump to reduce this, I suppose, but then you'll start using up the space faster. If the space is large enough (genID+seqNum) then this might not be an issue? thanks, dave h From dhudek@ma.ultranet.com Sat Jun 30 23:15:48 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Sat, 30 Jun 2001 15:15:48 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <15162.15644.474511.856119@redcs1.procket.com> Message-ID: <3B3E4F94.1DA6313B@ma.ultranet.com> Quick comment on a possible implication of the hello text... > IS-IS HELLO PDUs SHALL use the Link Level > Authentication String, which MAY be different from that of Link State > PDUs. The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be > calculated after the Packet is padded to the MTU size, if padding is > not disabled. This would seem to imply that if padding is not disabled, then if you want to interoperate you must pad every hello, which would appear to be a change to the Point-to-point hello procedure in 10589 (where it says to only pad the first IIH hello). Are the "dominant implementations" padding all the p2p hellos anyway? Thanks, dave h From sluong@cisco.com Sat Jun 30 20:20:32 2001 From: sluong@cisco.com (steve luong) Date: Sat, 30 Jun 2001 12:20:32 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <15162.15644.474511.856119@redcs1.procket.com> <3B3E4F94.1DA6313B@ma.ultranet.com> Message-ID: <3B3E2680.C308B342@cisco.com> No, it does not imply that. That sentence does not change the decision to pad or not to pad the IIH in anyway. It tells you the sequence of what to do first. The sequence is you pad the IIH first (if the IIH is supposed to be padded), then do the MD5 calculation over the entire PDU. David Hudek wrote: > > Quick comment on a possible implication of the hello text... > > > IS-IS HELLO PDUs SHALL use the Link Level > > Authentication String, which MAY be different from that of Link State > > PDUs. The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be > > calculated after the Packet is padded to the MTU size, if padding is > > not disabled. > > This would seem to imply that if padding is not disabled, > then if you want to interoperate you must > pad every hello, which would appear to be a change to > the Point-to-point hello procedure in 10589 > (where it says to only pad the first IIH hello). > Are the "dominant implementations" padding all the > p2p hellos anyway? > > Thanks, > dave h > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Sun Jul 1 09:12:18 2001 From: Alex Zinin (Alex Zinin) Date: Sun, 1 Jul 2001 01:12:18 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <3B3E2194.9D853DEE@ma.ultranet.com> References: <200106290720.JAA15862@net4u.net4u.ch> <1145095136.20010629011319@nexsi.com> <3B3CE366.6D5259D7@ma.ultranet.com> <14340299757.20010629110004@nexsi.com> <12355656019.20010629151601@nexsi.com> <3B3E2194.9D853DEE@ma.ultranet.com> Message-ID: <156177829084.20010701011218@nexsi.com> David, >> Thinking more about this... I guess we can go without CSNs in LSPs, >> as the LSP's own SN should be enough in most cases (except for >> the purge case, which is described in HMAC). So, we need only >> two CSN groups---IIH & SNPs. > Sounds good. Allows implementations to easily reorder > types of messages if desired (e.g., high priority hellos) > ------------------------------------------------------------------- > I had another question, but upon reading my email this morning, > I see that it's already been addressed :-) > (problem with restarting after being up for a while... > after restart you are using small seq num but BadGuy replays > one of your previous high seq num to your peer... so peer stops > listening to you until/unless your seq num increments up to the > old value) > I'm definitely NOT a security expert, but since there > were some drawbacks mentioned for the proposed scheme > (issues with NVRAM, and calendar clock), With the reservation that each system will select it's own source for generation ID, I think the nv memory approach is good. If we assume that the genID is saved in the same place as the device's config or other settings, the case of a failure of this block should be extremely rare and would require attention anyway (the router has no config, no IP addresses, no ISIS started, no nothing, so no worries about authentication)... > I'm wondering what would be the drawbacks of taking a page > from the LSP seq num handling and just putting in a mechanism > for an entity to bump up their seq num state if they discover a > prior incarnation with higher state floating about. > They could discover that if the crypto data in a hello > included not only your crypto state (seqNum, or genId + seqNum) > for the message in question, but also your current view of your > neighbor's state for each category (IIH, SNP). You see, when a router goes down, it is very likely that other routers will destroy the adjacency and the associated neighbor data structure by the time it is back. Hence, when the router is back up, it won't see itself's state in the neighbors' Hellos, and I wouldn't like to introduce changes in other parts of implementations. One could also think about maintaining a single CSN per segment and pushing the transmit CSN up whenever a greater one is received. This also has multiple drawbacks. One is decreased key lifetime (since routers are "racing"). The key lifetime is in inverse proportion to the number of routers on the segment. Another is none of the two addresses the case of all routers being restarted, so one would want to save the genID anyway. > Actually, I just thought of one possible bad scenario, but > it seems sort of far-out?... if a BadGuy had a large > history of your prior messages (you had been up a long time), > then they could incrementally fool your neighbor... replay to > set seq num a bit higher than you, then you recover, then they > replay a different one to set yet a bit higher, then you recover, etc. > You could recover with a relatively large extra jump to reduce this, > I suppose, but then you'll start using up the space faster. > If the space is large enough (genID+seqNum) then this > might not be an issue? The above would be possible if the attacker recorded a session and the genID of the router under attack rolled back to zero. The way this problem is addressed now is by making sure the keys are changed before the CSN is used up. I think this is a practically acceptable assumption, since (as mentioned before) each 32-bit CSN is enough for more than 10 years. Alex. From omer@cwnt.com Sun Jul 1 10:42:52 2001 From: omer@cwnt.com (Omer Sali) Date: Sun, 1 Jul 2001 12:42:52 +0300 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt Message-ID: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> Hi, in section 2.1 it says: "Implementations supporting the extensions described in this document should maintain the cryptographic sequence number counter on a per- interface basis." Is it essential to have a different CSN for each interface ? (Clearly it is better, but is it essential?) Having a different CSN means that if we flood an LSP over 100 interface we have to recalculate MD5 100 times. If we adopt Alex's suggestion for using only LSP's own SN we'll get over this drawback. Omer From dhudek@ma.ultranet.com Sun Jul 1 19:48:25 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Sun, 01 Jul 2001 11:48:25 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <15162.15644.474511.856119@redcs1.procket.com> <3B3E4F94.1DA6313B@ma.ultranet.com> <3B3E2680.C308B342@cisco.com> Message-ID: <3B3F7079.5445EB3B@ma.ultranet.com> steve luong wrote: > No, it does not imply that. That sentence does not change the decision > to pad or not to pad the IIH > in anyway. It tells you the sequence of what to do first. The sequence is you > pad the IIH first (if the IIH is supposed to be padded), then do the MD5 > calculation over the entire PDU. While that is certainly a reasonable approach, it is not what the draft rfc currently specifies. If the wording was something more like "This rfc does not take any position regarding hello padding rules, but if a hello is to be padded it MUST occur prior to the hmac-md5 calculation," then I would agree. (and it lets you remain padding agnostic with regard to p2p hellos, allowing for both implementation styles of a) always padding all p2p hellos [which at least one dominant implementation has done], and b) a strictly 10589 compliant implementation which only pads the first p2p hello) Instead, when it speaks of hellos, it currently says, "The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded to the MTU size, if padding is not disabled." which mandates the hmac-md5 calc (SHALL be calculated) qualified by two conditions, a state condition (padding enabled/disabled) and an event condition (padding has occured/padding has not occured). It explicitly says to compute under one of four possible state/event combinations (3 of which are potentially valid, and 1 of which would be a bug), and stands mute on the other cases. The other cases are left ambiguous and so up to the implementors' discretion. I'm reminded of a recent comment by Tony P when talking about some ambiguity in a different draft rfc :-) >The answer is always 'Obviously you do X' >but if not spelled out in some clear specs what X must be , >multiple implementors arrive to different 'X' solutions and >interesting effects will occur. I would simply suggest that the wording in the draft be tightened up a little to reduce the ambiguity. Thanks, dave h From Alex Zinin Sun Jul 1 20:31:35 2001 From: Alex Zinin (Alex Zinin) Date: Sun, 1 Jul 2001 12:31:35 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> Message-ID: <86218586660.20010701123135@nexsi.com> Omer, To make it clear, let's differentiate btw LSPs and all other ISIS packets. The difference is in the fact that LSPs have domain-wide distribution, while other packets are local to a specific segment. As far as link-local packets are concerned, everything is pretty much clear. We need increasing CSNs for everything a router sends. Maintaining one CSN for all interfaces does not give us any benefit, as we have to calculate HMAC anyway. As for LSPs, we have two options---use link-specific CSNs or rely on the ISIS SNs. The choice between the two is essentially the choice between attack prevention and attack detection. CSNs will provide attack prevention, as the attacker will not be able to replay old LSPs. ISIS SNs will not save us from attacks (because once an LSP has been purged, the domain loses the crypto state for it), i.e., the attacker will be able to replay LSPs, but the real originating router will be able to detect the attack and draw the administrator's attention to it. I guess I will change the draft to say CSN MAY be included in an LSP and if it is, the value should be taken from the outbound interface's CSN whenever an LSP is sent. This is somewhat hacky, because it breaks the main principle of link-state routing---"never mess with someone else's link-state data", but this seems to be the only choice, since we don't have LSPs encapsulated into some "update" packets as in OSPF. Alex. > Hi, > in section 2.1 it says: > "Implementations supporting the extensions described in this document > should maintain the cryptographic sequence number counter on a per- > interface basis." > Is it essential to have a different CSN for each interface ? (Clearly it > is better, but is it essential?) > Having a different CSN means that if we flood an LSP over 100 interface > we have to recalculate MD5 100 times. > If we adopt Alex's suggestion for using only LSP's own SN we'll get over > this drawback. > Omer > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From myeung@procket.com Mon Jul 2 00:44:31 2001 From: myeung@procket.com (Derek Yeung) Date: Sun, 01 Jul 2001 16:44:31 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> <86218586660.20010701123135@nexsi.com> Message-ID: <3B3FB5DF.53507879@procket.com> Alex Zinin wrote: > > Omer, > > To make it clear, let's differentiate btw LSPs and all other > ISIS packets. The difference is in the fact that LSPs have > domain-wide distribution, while other packets are local to > a specific segment. > > As far as link-local packets are concerned, everything is > pretty much clear. We need increasing CSNs for everything > a router sends. Maintaining one CSN for all interfaces does > not give us any benefit, as we have to calculate HMAC anyway. > > As for LSPs, we have two options---use link-specific CSNs > or rely on the ISIS SNs. The choice between the two is essentially > the choice between attack prevention and attack detection. > CSNs will provide attack prevention, as the attacker will not > be able to replay old LSPs. ISIS SNs will not save us from I have not follow this thread closely so my comment may be just a misunderstanding. I don't expect there is any synchronization of CSN in the whole network. So it is possible for a interface in the network has much larger CSN for another interface in the same network. As a result, one can caputure the LSP on the interface with larger CSN and replay it on the interface with lower CSN and there is still no attack prevention. Thanks, - Derek > attacks (because once an LSP has been purged, the domain loses > the crypto state for it), i.e., the attacker will be able to > replay LSPs, but the real originating router will be able to detect > the attack and draw the administrator's attention to it. > > I guess I will change the draft to say CSN MAY be included > in an LSP and if it is, the value should be taken from the > outbound interface's CSN whenever an LSP is sent. This is > somewhat hacky, because it breaks the main principle of > link-state routing---"never mess with someone else's link-state > data", but this seems to be the only choice, since we don't have LSPs > encapsulated into some "update" packets as in OSPF. > > Alex. > > > Hi, > > > in section 2.1 it says: > > "Implementations supporting the extensions described in this document > > should maintain the cryptographic sequence number counter on a per- > > interface basis." > > > Is it essential to have a different CSN for each interface ? (Clearly it > > is better, but is it essential?) > > > Having a different CSN means that if we flood an LSP over 100 interface > > we have to recalculate MD5 100 times. > > > If we adopt Alex's suggestion for using only LSP's own SN we'll get over > > this drawback. > > > Omer > > _______________________________________________ > > 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 myeung@procket.com Mon Jul 2 01:44:32 2001 From: myeung@procket.com (Derek Yeung) Date: Sun, 01 Jul 2001 17:44:32 -0700 Subject: [Isis-wg] Derek's proposal for MTU discovery in IS-IS References: <200106262310.f5QNA9U28078@redd3174.procket.com> <5.1.0.14.2.20010627102922.01f5ac60@10.30.15.2> Message-ID: <3B3FC3F0.3AFB80CA@procket.com> Sorry for the late reply. Given enough interest, I can send out a draft in a week or so for the MTU TLV for IIH. Going through the thread, it appear to me the problem this new TLV does not solve is the FDDI-Ethernet type bridged network Radia mentioned. IMHO, this network model is broken in nature and hopefully it is not wide-spread enough to render the suggestion useless. For Henk's comment - > In theory there are two more problems that can be detected early > when the IIH is really padded to mtu-size. > 1) bit errors or packet corruption that has a higher probability to > occur with larger packets. Supposedly this is something from the > past when transmissions were over copper, not fibre. I suppose it can be better detected/solved by checksum/authentication. > 2) bugs. interfaces that have their MTU off by 1 (or 4. (I have seen > these bugs in cisco)). If the MTU is off such that both side does not match, it would be fine as adjacency is not found and this problem should be caught in early developement. > or routers running out of huge buffers. > stuff like that. Given that only the first IIH is padded, it is not helpful to detect temporary outage of huge buffer. If the outage is permanent, the system should probably detect it and take some action. I agree with Henk that these two issues is not big deal though. Cheers, - Derek Ran Atkinson wrote: > > Henk's historical analysis is extremely helpful. > I hope we are all now focused on the problem at hand. > Thanks much for the detailed analysis and history. > > At 19:27 26/06/01, Derek Yeung wrote: > > OSPF have the same problem. OSPF solves the problem by putting the > >MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable > >to put a TLV in IIH to carry the MTU instead of padding IIH to full > >MTU size ? > > This seems like a simpler approach. The concept is known to > work (thanks to OSPF). Why don't we just try this to solve the > immediate IS-IS issue that Henk outlined ? Oh, and if we do this, > it might not hurt to add a MIB object or two to make MTU mismatches > discovered by IS-IS easy for operators to grab via SNMP. > > Quite separately, I'll probably draft up an "IP over > Jumbogram Ethernet-II Framing" spec that just documents the > as deployed IP/Ethernet practice, as an Informational RFC. I don't > see that as an IS-IS WG work item, in no small part because IS-IS > does not use Ethernet-II Framing. > > Cheers, > > Ran > rja@inet.org > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Mon Jul 2 06:32:10 2001 From: Alex Zinin (Alex Zinin) Date: Sun, 1 Jul 2001 22:32:10 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <3B3FB5DF.53507879@procket.com> References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> <86218586660.20010701123135@nexsi.com> <3B3FB5DF.53507879@procket.com> Message-ID: <143254621456.20010701223210@nexsi.com> Derek, >> As for LSPs, we have two options---use link-specific CSNs >> or rely on the ISIS SNs. The choice between the two is essentially >> the choice between attack prevention and attack detection. >> CSNs will provide attack prevention, as the attacker will not >> be able to replay old LSPs. ISIS SNs will not save us from > I have not follow this thread closely so my comment may be just > a misunderstanding. > I don't expect there is any synchronization of CSN in the whole > network. So it is possible for a interface in the network has much larger > CSN for another interface in the same network. As a result, one can caputure > the LSP on the interface with larger CSN and replay it on the interface > with lower CSN and there is still no attack prevention. Yes, a very interesting observation. Two moments here, however. First, this assumes that the two segments are configured with the same secret key. Second, wouldn't the attacker have to establish an adjacency with some router on the segment before the replayed LSP is accepted? I don't recall the ISIS spec actually saying so, but I would suspect the implementations to do this check. Thanks, Derek! Alex. From naiming@redback.com Mon Jul 2 06:57:10 2001 From: naiming@redback.com (Naiming Shen) Date: Sun, 01 Jul 2001 22:57:10 -0700 Subject: [Isis-wg] Derek's proposal for MTU discovery in IS-IS In-Reply-To: Mail from Derek Yeung dated Sun, 01 Jul 2001 17:44:32 PDT <3B3FC3F0.3AFB80CA@procket.com> Message-ID: <20010702055710.4371826BD1A@prattle.redback.com> I once helped a big ISP troubleshooting a network problem, the isis adjacency wouldn't come up. The link was an ATM interface, the ip level seemed fine. Then it was found if the IIH was never padded, the adjacency came up. It turned out to be the ATM link provider had some rate-limiting mechanim inside the ATM network, the 4470 bytes of padded IIH on this port just happen to exceed their limit, so some of the ATM cells got dropped with large packet size. I forget in this case if it was a misconfiguration by the ATM network provider or the ISP did agree to buy the link with this limitation, the point here is, without the isis padding(the first IIH), that ISP might never notice this problem, then some of their BGP packets could be dropped also over that link. Yes, isis have cuased lots of "troubles" for vendors and ISPs due to this padding issue. in most of the cases, IMHO, isis is only the messenger. if it is shot, unfortunately, there will be no other messengers around who can detect such a problem in earlier stage. With all this said, I do sympathize with the isis developers, they have to prove their innocence every time a bug is filed, because the bugs usually have the title of "Urgent: IS-IS does not work over .....";-) thanks. - Naiming From mshand@cisco.com Mon Jul 2 12:14:31 2001 From: mshand@cisco.com (mike shand) Date: Mon, 02 Jul 2001 12:14:31 +0100 Subject: [Isis-wg] Derek's proposal for MTU discovery in IS-IS In-Reply-To: <3B3FC3F0.3AFB80CA@procket.com> References: <200106262310.f5QNA9U28078@redd3174.procket.com> <5.1.0.14.2.20010627102922.01f5ac60@10.30.15.2> Message-ID: <4.3.2.7.2.20010702112745.032ef3b8@jaws.cisco.com> At 17:44 01/07/2001 -0700, Derek Yeung wrote: > Sorry for the late reply. > > Given enough interest, I can send out a draft in a week or so for > the MTU TLV >for IIH. How does this compare with the proposal which was originated in the Sonet Interoperability Forum and is being incorporated in ISO/IEC 10589 second edition? > Going through the thread, it appear to me the problem this new > TLV does not >solve is the FDDI-Ethernet type bridged network Radia mentioned. IMHO, >this network model >is broken in nature and hopefully it is not wide-spread enough to render >the suggestion useless. > > For Henk's comment - > > > In theory there are two more problems that can be detected early > > when the IIH is really padded to mtu-size. > > 1) bit errors or packet corruption that has a higher probability to > > occur with larger packets. Supposedly this is something from the > > past when transmissions were over copper, not fibre. > > I suppose it can be better detected/solved by > checksum/authentication. Well, no it can't, because it only happens when you have big packets. (Naiming gives an example in his reply). > > 2) bugs. interfaces that have their MTU off by 1 (or 4. (I have seen > > these bugs in cisco)). > > If the MTU is off such that both side does not match, it would be > fine >as adjacency is not found and this problem should be caught in early >developement. > > > or routers running out of huge buffers. > > stuff like that. > > Given that only the first IIH is padded, it is not helpful to detect >temporary outage of huge buffer. If the outage is permanent, the system >should >probably detect it and take some action. Well its only pt-pt links that only have the first IIH padded, and even that is an anachronism, since it was designed for connection oriented data links (such as HDLC I-frame service). Running over PPP (using HDLC UI-frames) doesn't have the right properties, so it should probably be always padded (or not at all if that what you want). > I agree with Henk that these two issues is not big deal though. Yes, I agree its not a big deal. >Cheers, >- Derek > > >Ran Atkinson wrote: > > > > Henk's historical analysis is extremely helpful. > > I hope we are all now focused on the problem at hand. > > Thanks much for the detailed analysis and history. > > > > At 19:27 26/06/01, Derek Yeung wrote: > > > OSPF have the same problem. OSPF solves the problem by putting the > > >MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable > > >to put a TLV in IIH to carry the MTU instead of padding IIH to full > > >MTU size ? > > > > This seems like a simpler approach. The concept is known to > > work (thanks to OSPF). Why don't we just try this to solve the > > immediate IS-IS issue that Henk outlined ? Oh, and if we do this, > > it might not hurt to add a MIB object or two to make MTU mismatches > > discovered by IS-IS easy for operators to grab via SNMP. > > > > Quite separately, I'll probably draft up an "IP over > > Jumbogram Ethernet-II Framing" spec that just documents the > > as deployed IP/Ethernet practice, as an Informational RFC. I don't > > see that as an IS-IS WG work item, in no small part because IS-IS > > does not use Ethernet-II Framing. > > > > Cheers, > > > > Ran > > rja@inet.org > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From rja@inet.org Sat Jun 30 14:55:02 2001 From: rja@inet.org (RJ Atkinson) Date: Sat, 30 Jun 2001 09:55:02 -0400 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <10773060375.20010629200609@nexsi.com> References: <3140683129.20010629110628@nexsi.com> <200106290720.JAA15862@net4u.net4u.ch> <200106290720.JAA15862@net4u.net4u.ch> <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2> <3140683129.20010629110628@nexsi.com> Message-ID: <5.1.0.14.2.20010630094943.01d80620@10.30.15.2> At 23:06 29/06/01, Alex Zinin wrote: >(I belive Jerome Etienne has a paper on a similar > mechanism for OSPF somewhere.) With all respect to the author, that proposal creates more security problems than it solves. It changes how one engages in an active attack, but does not increase the attacker's work function. Further, the author of proposal seems to (erroneously) think the goal of OSPF MD5 is perfect security, which it never was. The goal of OSPF MD5 and RIP MD5 was to make a plausible (not necessarily optimal) engineering tradeoff between increased work function for the attacker and implementation/deployment complexity -- and to eliminate purely passive attacks as a significant threat. > 1. SeqNum roll back does not seem to be a problem to me, > see item 4 below. > > 2. In the new TLV, introduce the generation ID (16 or 32 bits). > > 3. The implementations guarantee that the generation ID is > incremented with each reboot using one of multiple methods, > e.g., reading, incrementing and writing it back to nvram > on each boot, or using seconds since somewhen, or a calendar > clock, whatever is better suited for a specific system. > > 4. The CSN is incremented after each packet. If a system sends > 10 packs per sec, 32-bit space will give us more than 10 > years of a key lifetime. We may want to increase it though, > if we seriously consider subsecond hellos. > > 5. The receiving side checks that the CSN in the packet is > _greater_ than the locally stored value. > > Vernon did not seem to like the scheme, because of the possible > issues with NVRAM, and calendar clock... I'm with Vernon. The attack changes, but it is not obvious that the new attack would be any more work, just different. To be useful, a security mechanism needs to visibly increase the work that an attacker must make against the system being attacked, IMHO. IMHO, the likely next logical improvement step would be to move to real digital signatures (as different from a keyed hash function). I doubt there is much interest in implementing or deploying that, taking the existence of OSPF with Digital Signatures as a datum. Ran rja@inet.org From Alex Zinin Mon Jul 2 21:40:50 2001 From: Alex Zinin (Alex Zinin) Date: Mon, 2 Jul 2001 13:40:50 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <5.1.0.14.2.20010630094943.01d80620@10.30.15.2> References: <3140683129.20010629110628@nexsi.com> <200106290720.JAA15862@net4u.net4u.ch> <200106290720.JAA15862@net4u.net4u.ch> <5.1.0.14.2.20010629124312.01dd8e00@10.30.15.2> <3140683129.20010629110628@nexsi.com> <5.1.0.14.2.20010630094943.01d80620@10.30.15.2> Message-ID: <1385397280.20010702134050@nexsi.com> Ran, To make sure we're on the same page, I'm not looking at this as an attempt to improve the authentication mechanism from the crypto perspective (as you mentioned, Digital Signatures do not seem to be of real interest to people), but as an attempt to prevent very simple replay attacks _within_ HMAC and try to fix those well-known problems with the sequence numbers that you mentioned and Vernon elaborated on. -- Alex Zinin Saturday, June 30, 2001, 6:55:02 AM, RJ Atkinson wrote: > At 23:06 29/06/01, Alex Zinin wrote: >>(I belive Jerome Etienne has a paper on a similar >> mechanism for OSPF somewhere.) > With all respect to the author, that proposal creates more > security problems than it solves. It changes how one engages in an > active attack, but does not increase the attacker's work function. > Further, the author of proposal seems to (erroneously) think the > goal of OSPF MD5 is perfect security, which it never was. The goal > of OSPF MD5 and RIP MD5 was to make a plausible (not necessarily optimal) > engineering tradeoff between increased work function for the attacker > and implementation/deployment complexity -- and to eliminate purely > passive attacks as a significant threat. >> 1. SeqNum roll back does not seem to be a problem to me, >> see item 4 below. >> >> 2. In the new TLV, introduce the generation ID (16 or 32 bits). >> >> 3. The implementations guarantee that the generation ID is >> incremented with each reboot using one of multiple methods, >> e.g., reading, incrementing and writing it back to nvram >> on each boot, or using seconds since somewhen, or a calendar >> clock, whatever is better suited for a specific system. >> >> 4. The CSN is incremented after each packet. If a system sends >> 10 packs per sec, 32-bit space will give us more than 10 >> years of a key lifetime. We may want to increase it though, >> if we seriously consider subsecond hellos. >> >> 5. The receiving side checks that the CSN in the packet is >> _greater_ than the locally stored value. >> >> Vernon did not seem to like the scheme, because of the possible >> issues with NVRAM, and calendar clock... > I'm with Vernon. The attack changes, but it is not obvious > that the new attack would be any more work, just different. To be > useful, a security mechanism needs to visibly increase the work > that an attacker must make against the system being attacked, > IMHO. > IMHO, the likely next logical improvement step would be to > move to real digital signatures (as different from a keyed hash > function). I doubt there is much interest in implementing or > deploying that, taking the existence of OSPF with Digital Signatures > as a datum. > Ran > rja@inet.org > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From myeung@procket.com Mon Jul 2 22:17:47 2001 From: myeung@procket.com (Derek Yeung) Date: Mon, 02 Jul 2001 14:17:47 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> <86218586660.20010701123135@nexsi.com> <3B3FB5DF.53507879@procket.com> <143254621456.20010701223210@nexsi.com> Message-ID: <3B40E4FB.E6613FC6@procket.com> Alex Zinin wrote: > > Derek, > > >> As for LSPs, we have two options---use link-specific CSNs > >> or rely on the ISIS SNs. The choice between the two is essentially > >> the choice between attack prevention and attack detection. > >> CSNs will provide attack prevention, as the attacker will not > >> be able to replay old LSPs. ISIS SNs will not save us from > > > I have not follow this thread closely so my comment may be just > > a misunderstanding. > > > I don't expect there is any synchronization of CSN in the whole > > network. So it is possible for a interface in the network has much larger > > CSN for another interface in the same network. As a result, one can caputure > > the LSP on the interface with larger CSN and replay it on the interface > > with lower CSN and there is still no attack prevention. > > Yes, a very interesting observation. Two moments here, however. > First, this assumes that the two segments are configured with the same > secret key. I suppose we are talking about LSP here, which use the same key within one area. Second, wouldn't the attacker have to establish an adjacency with > some router on the segment before the replayed LSP is accepted? I don't recall The digest in LSP does not include the MAC header, so one can fake it, right ? To be clear, my comment is that adding CSN to LSP does not help much. Adding CSN to other ISIS packet type is a different issue. - Derek > the ISIS spec actually saying so, but I would suspect the implementations to > do this check. > > Thanks, Derek! > > Alex. From jparker@axiowave.com Mon Jul 2 23:38:02 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 2 Jul 2001 18:38:02 -0400 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt Message-ID: Tony - Looks good. Two minor nits. First, a quote An implementation that implements HMAC-MD5 authentication and receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value is incorrect. An implementation MAY include HMAC-MD5 Authentication Information in PDUs even if it does not fully implement HMAC-MD5 authentication. This allows an implementation to generate authentication information without verifying the authentication information. This is a transition aid for networks in the process of deploying authentication. This indicates a difference between "implementing" and "fully implementing" and seems to contradict the "MUST discard" from first paragraph. It may be clearer if you talk about a protocol configuration that allows a "transition mode" or something along those lines. The text suggests that you run the checksum over the PDU. A brief look at the use of the term PDU in 10589 includes usage where the header is part of the PDU: you should make clear that you do not checksum the header. - jeff parker - axiowave networks - Ambivalent? Well, yes and no. From tli@Procket.com Tue Jul 3 01:22:46 2001 From: tli@Procket.com (Tony Li) Date: Mon, 2 Jul 2001 17:22:46 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: References: Message-ID: <15169.4182.825927.570597@alpha-tli.procket.com> Jeff, Thanks for the comments. | An implementation that implements HMAC-MD5 authentication and | receives HMAC-MD5 Authentication Information MUST discard the PDU if | the Authentication Value is incorrect. | | An implementation MAY include HMAC-MD5 Authentication Information | in PDUs even if it does not fully implement HMAC-MD5 authentication. | This allows an implementation to generate authentication information | without verifying the authentication information. This is a | transition aid for networks in the process of deploying | authentication. | | This indicates a difference between "implementing" and "fully implementing" | and seems to contradict the "MUST discard" from first paragraph. | It may be clearer if you talk about a protocol configuration that allows a | "transition mode" or something along those lines. I've reworded the second paragraph to read: An implementation MAY have a transition mode where it includes HMAC-MD5 Authentication Information in PDUs but does not verify the HMAC-MD5 authentication information. This is a transition aid for networks in the process of deploying authentication. | The text suggests that you run the checksum over the PDU. | A brief look at the use of the term PDU in 10589 includes usage where | the header is part of the PDU: you should make clear that you do not | checksum the header. Ummm... to be specific here, the intent is that you run the checksum over the IS-IS PDU, including the fixed length header. But not the link layer header. Is that not what you understood from the existing text? I've tried to reinforce this by specifically mentioning the "IS-IS PDU" vs. the "PDU". Tony From navaneeth@www.com Tue Jul 3 03:04:11 2001 From: navaneeth@www.com (Navaneeth Krishnan) Date: Mon, 2 Jul 2001 19:04:11 -0700 Subject: [Isis-wg] Mac Address Change.. Message-ID: <200107030204.TAA25598@mail23.bigmailbox.com> ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From navaneeth@www.com Tue Jul 3 03:06:02 2001 From: navaneeth@www.com (Navaneeth Krishnan) Date: Mon, 2 Jul 2001 19:06:02 -0700 Subject: [Isis-wg] Mac Address Change.. Message-ID: <200107030206.TAA25786@mail23.bigmailbox.com> Hi All, This question is with specific reference to certain routers that allow configurable MAC addresses. what are the specific issues involved if MAC address change occurs, that any ISIS implementation needs to care about? Is there any reference materials/drafts available on MAC address change? thanks in advance Naren ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From jparker@axiowave.com Tue Jul 3 14:40:44 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 3 Jul 2001 09:40:44 -0400 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt Message-ID: > | The text suggests that you run the checksum over the PDU. > | A brief look at the use of the term PDU in 10589 includes > | usage where the header is part of the PDU: you should make > | clear that you do not checksum the header. > > > Ummm... to be specific here, the intent is that you run the > checksum over the IS-IS PDU, including the fixed length header. > But not the link layer header. Is that not what you understood > from the existing text? I've tried to reinforce this by specifically > mentioning the "IS-IS PDU" vs. the "PDU". > > Tony Color me confused. My concern was the Remaining Lifetime field. You describe how to deal with that quite clearly in the second paragraph of section 2. - jeff parker From Alex Zinin Tue Jul 3 19:48:34 2001 From: Alex Zinin (Alex Zinin) Date: Tue, 3 Jul 2001 11:48:34 -0700 Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt In-Reply-To: <3B40E4FB.E6613FC6@procket.com> References: <95734BD21894AC4B9AEF464C5A2985EA4AEAA3@bart.cwnt.com> <86218586660.20010701123135@nexsi.com> <3B3FB5DF.53507879@procket.com> <143254621456.20010701223210@nexsi.com> <3B40E4FB.E6613FC6@procket.com> Message-ID: <16885059168.20010703114834@nexsi.com> Derek, > I suppose we are talking about LSP here, which use > the same key within one area. I was thinking about using per-interface CSNs and keys. I know it's not consistent with the nature of LSPs, i.e. the area significance scope, but it should work. Alex. > Second, wouldn't the attacker have to establish an adjacency with >> some router on the segment before the replayed LSP is accepted? I don't recall > The digest in LSP does not include the MAC header, so one can fake it, right ? > To be clear, my comment is that adding CSN to LSP does not help much. > Adding CSN to other ISIS packet type is a different issue. > - Derek >> the ISIS spec actually saying so, but I would suspect the implementations to >> do this check. >> >> Thanks, Derek! >> >> Alex. From ginsberg@pluris.com Mon Jul 2 21:05:21 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Mon, 2 Jul 2001 13:05:21 -0700 Subject: [Isis-wg] Derek's proposal for MTU discovery in IS-IS Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A4C1@avalon.pluris.com> > > How does this compare with the proposal which was originated > in the Sonet > Interoperability Forum and is being incorporated in ISO/IEC > 10589 second > edition? > > > The SIF proposal is concerned with advertising originatingLSPBufferSize. The TLV appears in an LSP and has area wide(L1) or domain-wide(L2) implications. The MTU discovery proposal TLV appears in an IIH and has immediate significance only between neighbors on a link. It is certainly true that there is a relationship between originatingLSPBufferSize and link MTU size in that the MTU size on ALL links on which LSPs will be propagated must be >= originatingLSPBufferSize. In that sense the two proposals complement each other - though the use of padding appropriately applied also serves this purpose. For those who are interested, the SIF proposal was posted to the list back in 1998 and (amazingly) is still available at: ftp.juniper.net:pub/isis/lspsize.PDF It is allegedly still available on the SIF website but I found that link to be stale. It should also be mentioned that a minor change to the proposal above has been made to resolve the TLV conflict with draft-ietf-isis-wg-snp-checksum-01.txt. The two TLVs (12 and 13) mentioned in the document have been combined into a single TLV(14). The determination of whether the size being advertised is L1 or L2 is determined by the LSP type in which the TLV is found. (I have been waiting for formal commitment for this change to be incorporated into the latest draft of ISO 10589 before announcement - guess I have done it now.) Les From iesg-secretary@ietf.org Tue Jul 3 22:59:09 2001 From: iesg-secretary@ietf.org (The IESG) Date: Tue, 03 Jul 2001 17:59:09 -0400 Subject: [Isis-wg] Document Action: IS-IS Transient Blackhole Avoidance to Informational Message-ID: <200107032159.RAA25569@ietf.org> The IESG has approved the Internet-Draft 'IS-IS Transient Blackhole Avoidance' as a Informational. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Abha Ahuja and Rob Coltun. From Internet-Drafts@ietf.org Thu Jul 5 11:52:33 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Thu, 05 Jul 2001 06:52:33 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-eth-01.txt Message-ID: <200107051052.GAA06369@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 : Extended Ethernet Frame Size Support Author(s) : J. Kaplan et al. Filename : draft-ietf-isis-ext-eth-01.txt Pages : Date : 03-Jul-01 This document presents an extension to current Ethernet Frame specifications for hardware and frame format to support payloads greater than 1500 Bytes for Type interpretation and Length interpretation frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-eth-01.txt 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-ext-eth-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-ext-eth-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: <20010703124516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124516.I-D@ietf.org> --OtherAccess-- --NextPart-- From tli@Procket.com Thu Jul 5 18:39:13 2001 From: tli@Procket.com (Tony Li) Date: Thu, 5 Jul 2001 10:39:13 -0700 Subject: [Isis-wg] forwarded message from Internet-Drafts@ietf.org Message-ID: <15172.42561.62675.380472@alpha-tli.procket.com> --eZX0VkAf8B Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Folks, Please note the revised ID on Extended Frame Support. Could we please get comments by 5:00PM PDT July 13? Again the proposal is to ask to have this published as an Informational RFC. Thanks, Tony --eZX0VkAf8B Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Return-Path: Received: from slr.procket.com (slr.procket.com [10.1.1.5]) by miata.procket.com (8.11.1/8.11.1) with ESMTP id f65B04417788; Thu, 5 Jul 2001 04:00:04 -0700 (PDT) Received: from slr.procket.com (localhost [127.0.0.1]) by slr.procket.com (8.11.1/8.9.3) with ESMTP id f65B04I12234; Thu, 5 Jul 2001 04:00:04 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [10.1.1.1]) by slr.procket.com (8.11.1/8.9.3) with ESMTP id f65AxLI12068 for ; Thu, 5 Jul 2001 03:59:21 -0700 (PDT) X-Confidential: Procket Confidential/Need to know Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by miata.procket.com (8.11.1/8.11.1) with ESMTP id f65AxL417744; Thu, 5 Jul 2001 03:59:21 -0700 (PDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA77663; Thu, 5 Jul 2001 03:57:45 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA77647 for ; Thu, 5 Jul 2001 03:56:43 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f65ApUw95329 for ; Thu, 5 Jul 2001 03:51:30 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06369; Thu, 5 Jul 2001 06:52:33 -0400 (EDT) Message-Id: <200107051052.GAA06369@ietf.org> Reply-to: Internet-Drafts@ietf.org X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk Errors-To: isis-wg-external-admin@Procket.com X-BeenThere: isis-wg-external@mailist.procket.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: From: Internet-Drafts@ietf.org Sender: isis-wg-external-admin@Procket.com To: IETF-Announce: ; Cc: isis-wg@juniper.net Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ext-eth-01.txt Date: Thu, 05 Jul 2001 06:52:33 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Extended Ethernet Frame Size Support Author(s) : J. Kaplan et al. Filename : draft-ietf-isis-ext-eth-01.txt Pages : Date : 03-Jul-01 This document presents an extension to current Ethernet Frame specifications for hardware and frame format to support payloads greater than 1500 Bytes for Type interpretation and Length interpretation frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-eth-01.txt 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-ext-eth-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-ext-eth-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: <20010703124516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124516.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ 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 --eZX0VkAf8B-- From raj_hegde@www.com Wed Jul 4 02:40:25 2001 From: raj_hegde@www.com (Rajesh Hegde) Date: Tue, 3 Jul 2001 18:40:25 -0700 Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: <200107040140.SAA11092@mail23.bigmailbox.com> Hi, What to we do for supporting ethernet jumboframes ? Do we go ahead with padding hellos to mtu-size ? What will happen to the LSP buffersize ? Does it need to be increased beyond 1492 bytes? Or else try to establish the adjacency with small hellos without bothering to the padding of hellos to mtu-size ? thanks and Regards, Rajesh > Back to ISIS, do we really need LSP datagrams with sizes over 1492? No, ISIS doesn't need larger LSPs. The problem was this: *) Some router vendors support "jumboframes" over GE. *) IP packets are encapsulated in EthernetII frames. (*) *) Encapsulation of EthernetII frames in such jumboframes is easy. *) ISIS sends hellos padded to mtu size, to do early detection of mtu mismatches, and other problems. *) Some ISPs wanted this early detection to keep working even over GE with jumboframes. *) Therefor, ISIS must send hellos padded up to "jumboframe mtu" *) ISIS packets are encapsulated in 802.3/802.2 frames. (*) *) 802.3/802.2 frames can not be longer than 1500 bytes. *) Therefor ISIS can not use jumboframes. *) To solve this problem (and IMHO only this problem of padded hellos) draft-ietf-isis-ext-eth-00.txt was written. Possible solutions: 1) Change ethernet specs. 2) Make IS-IS use EthernetII encapsulation. 3) Make IS-IS use IP encapsulation. 4) Forget about padding IS-IS hellos to mtu-size. It seems proposal 1) encountered more opposition than envisioned. :-) Proposals 2) and 3) are gonna introduce lots and lots of interoperability problems. Not worthwile, IMHO. Doing 4) seems a nice and simple solution. And it has the benefit that ISIS will keep working on bridged networks of GE and other flavors of Ethernet. I never understood why ISPs insisted on keeping ISIS to pad its hellos to mtu-size. OSPF sends small hellos, and that does not seem to give many more headaches. henk. -- PS.(*) I know this terminology is not the proper lingo anymore. If you know how to call those 2 encapsulation methods, please educate me. Thanks. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ____________________________________________________ Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From raj_hegde@www.com Wed Jul 4 06:38:36 2001 From: raj_hegde@www.com (Rajesh Hegde) Date: Tue, 3 Jul 2001 22:38:36 -0700 Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU Message-ID: <200107040538.WAA10040@mail10.bigmailbox.com> Hi, What to we do for supporting ethernet jumboframes ? Do we go ahead with padding hellos to mtu-size ? What will happen to the LSP buffersize ? Does it need to be increased beyond 1492 bytes? Or else try to establish the adjacency with small hellos without bothering to the padding of hellos to mtu-size ? What will happen to LSP bufer size in case of data link interfaces having link MTU size lesser than 1500 bytes (for ex. DC interfaces) ? Thanks and Regards, Rajesh ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From mjyang@etri.re.kr Thu Jul 5 09:03:33 2001 From: mjyang@etri.re.kr (mjyang) Date: Thu, 5 Jul 2001 17:03:33 +0900 Subject: [Isis-wg] [Question] About ISIS packet format? Message-ID: <006701c10528$fc776b80$37c2fe81@etri.re.kr> This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C10574.6C46A980 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0064_01C10574.6C46A980" ------=_NextPart_001_0064_01C10574.6C46A980 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsLi4NCg0KV2UgYXJlIGRldmVsb3BpbmcgSVMtSVMgcm91dGluZyBwcm90b2NvbC4NCldl IGhhdmUgc29tZSBxdWVzdGlvbiBhYm91dCBJU0lTLg0KSW4gSVNJUyBmb3IgSVAsIEkgd2FudCB0 byBjb25maXJtIElTSVMgcGFja2V0IGVuY2Fwc3VsYXRpb24gZm9ybWF0Lg0KSXMgdGhlIGZvbGxv d2luZyBmaWd1cmUgcmlnaHQ/DQoNCkF3YWl0aW5nIHRoZSBwbGVhc3VyZSBvZiB5b3VyIHJlcGx5 LiANClJlZ2FyZHMsDQogDQpNLkouWWFuZy4uDQoNCi0tLS0tLS0tLS0tLS0tLS0tDQpNaWp1bmcg WWFuZyAvIEVUUkkgDQpURUw6ICs4Mi00Mi04NjAtNDkyMiANCkZBWDogKzgyLTQyLTg2MC01NDQw IA0KRS1tYWlsOiBtanlhbmdAZXRyaS5yZS5rciANCg0K ------=_NextPart_001_0064_01C10574.6C46A980 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbC4u PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPldlIGFy ZSBkZXZlbG9waW5nIElTLUlTIHJvdXRpbmcgcHJvdG9jb2wuPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+V2UgaGF2ZSBzb21lIHF1ZXN0aW9uIGFib3V0IElTSVMuPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+SW4gSVNJUyBmb3IgSVAsIEkgd2FudCB0byBjb25maXJtIElT SVMgcGFja2V0IGVuY2Fwc3VsYXRpb24gDQpmb3JtYXQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+SXMgdGhlIGZvbGxvd2luZyBmaWd1cmUgcmlnaHQ/PC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9Mj5Bd2FpdGluZyB0 aGUgcGxlYXN1cmUgb2YgeW91ciByZXBseS48L0ZPTlQ+IA0KPERJVj48Rk9OVCBzaXplPTI+UmVn YXJkcyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5NLkouWWFuZy4uPEJSPjwvRk9OVD48L0ZPTlQ+PElNRyBhbGln bj1iYXNlbGluZSBhbHQ9IiIgDQpib3JkZXI9MCBoc3BhY2U9MCANCnNyYz0iY2lkOjAwNjIwMWMx MDUyOCRmYzRlMzhhMCQzN2MyZmU4MUBldHJpLnJlLmtyIj48L0RJVj48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPi0tLS0tLS0tLS0tLS0tLS0tPEJSPk1panVuZyBZYW5nIC8gRVRSSSA8QlI+VEVM OiANCis4Mi00Mi04NjAtNDkyMiA8QlI+RkFYOiArODItNDItODYwLTU0NDAgPEJSPkUtbWFpbDog PEEgDQpocmVmPSJtYWlsdG86bWp5YW5nQGV0cmkucmUua3IiPm1qeWFuZ0BldHJpLnJlLmtyPC9B PiANCjxCUj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_001_0064_01C10574.6C46A980-- ------=_NextPart_000_0063_01C10574.6C46A980 Content-Type: image/gif; name="ISISFrameFormat.GIF" Content-Transfer-Encoding: base64 Content-ID: <006201c10528$fc4e38a0$37c2fe81@etri.re.kr> R0lGODdhvwPPAvcAAAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAC/A88C QAj/AAMIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXQoTgNOnUKNKnUq1qtWrWLNqrTpyq9evYMOK tdp1rNmzaM8yXcu2rdu3SwEglFvQ6UC6BO0mxBuR70G9AejK5Qu1ol+Ph+8aBHwYcN3EQiFvhNwY b+W9kn9mhsu5s+fPoDtu5jiaZ2mLpzE6nig1r0DBigPHppiatsnVhjHnfaqxdujfwIMLdzs4qmvZ yGEHHvx6uXLavB/HZn43Ouuuzq0nb759+XbeuIf6WpZYvPB07srtwgY/3mb74fDjy59P3+H7+qLx u9fPv7///wCuFF6AF91HIEMDHqjgggw26KBCBv4XIYATPmjhhRhmqF+CAVYYHIcahijiiCQ26CFx /p1Y4oostrDoInwgdqaiZjO+aOONOOYIXI038fhSjDoGKeSQREoomHamTYWTecgV6eSTUEaZUVpU VmnllVhmqeWWSHKX3Vx1ndfdc+Wdx16TUqap5pohnUZYlxCymZSPctZp55050bkYZ2/iFh11ZHpp 2Ziv6RmToXgmquiit2XnWHroFfqdXogySpqlmGaq6aYnVcrpp6CGKuqHo5Zq6qmo9udpqqy26uqr KK0K66y01mqrfbfmqorrrrxe2uuvwAYrrJfDFmvssaNSxSJhcS7kW4KDIiutsFxWa+212Gar7bZM Tuvtt4feJmutQE4J7rnoCugos4QmB6hz3sHVZ2XrRWpvk++6y2d52kE65rvgpSvwwCJ5Wu7ABxdI 8MIMT8ntwxBHLPHE1jZs8cUYZ6zxxhx37PHHIIcs8sgkl2zyySg4p6zyyiy37PLLMMcs88w012zz zTjnrPPOPPfs889ABy300EQXbfTRSCet9NJMN+3001BHLfXUVFcxbfXVWGet9dZcd+3112CHLfbY ZJdt9tlop6322my37fbbcMct99x012333XjnrffefCr37fffgAcu+OCEF2744YgnrvjijDfu+OOQ Ry755JRXbvnlmGeu+eacd+4o+eeghy766KSXbvrpqKeu+uqst+7667DHLvvstNdu++2456777rz3 7qX778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fTUy/gXY+rBWyh1f6GW/fayYX8knLgWPJf44aOf WMJ5YreY+trDS9m4H9FfPX7rU6r9n/F3b9ij+2NMdSJkqPmth1L6Ix/7HjO+vcymN+5jYHP+lEBo VahLAXMUBO9XJPOQz1kghE6/soc+DdqmYBRsT2YWuJsGVgd8KVQYChGoQghd0DjpswwLHci1QSJ5 8FHzktSRwIemvqymTPHTIQHLQsPdtHCIQ5Sf/RDDRBdKaoBQvOKZjjLFHmKqi/QB44bE6EWPkdF6 OTpjGWWmRqS0kYtvXGPR4qgTOi5Jjo+zo0v0mJId4jFyfGyTZwL5x8ARMjdwLCTzuEIjP1axW3tU DyS390FF0qw0KUzYITVFr/4xEINbLIxxRjjK4lgSXZhsYl/kRUNHHmeV8jrl1X5Yw2YRR5XdE1+0 kqhLIfJJloRWo6UTsejLePHPjMBMZpiUyUwHbbKZ0JTJM6NJzZZMs5rYjFU2t1mfa3Lzm/UDpzh/ M8kR+aVPxELS+mYTxT3hS4Lt+tI4W2Qwby7KlQ+x5zzvJEzy2JCV48MnsfK5rxj6k4f7zFg/r0jJ YjZRoHnC5Z56KagSyvN7b8HhCJ/o0AbqM6EncqrnxyCKIJCa9KQoTalKV8rSlrr0pTCNqUxnStOa 2vSmOM2pTnfKIdOe+vSnQA2qUIdK1KIa9ahITapSl8rUpjr1qVCNqlSnSiHVqlr1qljNqla3ytWu evWrYA2rWMdK1rKa9axoTata18of1ra69a1wjatc50rXutr1rnjNq173yte++vWvgA2sYB0HS9jC GvawiE2sYhfL2MY69rGQjaxkJ0vZylr2sqmYzaxmN8vZznr2s6ANLeRW9dFXgkSkboxgWVL7WMo8 MFAPXOZBxYSeXb7zOuYDUzoFZdoXslaQ/kMTbAfqW6OUdqmu3e1tiRtbgh6HXTrsLW6BG1zovvZ6 c1LtK62r3Pf9trGk/W44S+JKdum2iKrRbps81JjtNne64O2UeKlI3iVe173Lhe94SQLR9rIzP60V 7gkROt3n6Ku77ymggPUrnfnmx7ywPJ+DfhPLvQWLaVDnfK9zTUsmCA/4tBYuor/Ct0yS7hE7EM5w d0j83OMyl8Ly5aJ6T+viF09GXBMWLX9rnN2Q6hh/HYySiX8cyzQOachE/hCP72ijJSc5oiRysjSl /OTIZIjKKkFylUWEZf6aaMub6jJ9JQRmVGk5x0ou863EPNs0q4eZWsNhc3Df/C05uxNFdL7YmaUZ FzvnGUqXaaSSepS/P7Ns0D5pDaHLaWiUYQUoe/YeI5vy3zvb2M9bDi8y77wZFberw7b1l4Eb3aiG mDc1mBYSGT1M6h6Vz8a25FiqW33jUmcUvzKMMJ5prSBN31rDvA3ULjF8LzvPmtfpZfWrzyuf0Rwb kcg7JlCFPTziCud3Y8+O9odnjLFsaztU3v421sIt7mCWO3bkPvfU0q3uqLG73U97N7ybJu95L63e 9k4avvOAfbR983uO/0advwPeM7IQ3HOKXpGnjYk9S/9XgPGiLfcEiFGGHhxHkW42hyOVr/sO+17N 5W61YY1Z1HYs48C+uLrqO1KDqXwmJpe1y18eLmWb+p9F5m1629yWiic41jS3ZohVLOwSG1u67i26 zlk83FsOvcTBhnrQf4TjMJZU2jMkn7rQWW7GrGt95Ttuua2/Tvaym/3saE+72tfO9ra7/e1wj7vc GOdO97rb/e54z7ve9873vvv974APvOAHTxn4whv+8IhPvOIXz/jGO/7xkI+85CdP+cpbGP7ymM+8 5jfP+c57/vOgD73oR0/60pv+9BeoT73qV8/61rv+9bCPvexnT/va2/72uBbPve53z/ve+/73wA++ 8IdP/OIb//jIFk++8pfP/OY7//nQj770p0/96lv/+tgWz772t8/97nv/++APv/jHT/7ym//86BVP v/rXz/72u//98I+//OdP//rb//4V+M+//vfP//77//8AGIACOIAEWIAGF3iACJiACriADNiADviA EBiBEjiBFFiB/6bia0WhYFwnY7kVdhzoWBhIFBrogR8IYhuYgZCVXPgyXNACbfqjRRtHcgS2X5zm W8NWaGhmLtVlg+w0PzlYWCoYcenkbNs2TIphYLYFESNoaUdkhNj1g7kmW0IoXJ1WYwOnUkH4XMwm hUp4c9+BdLpGg1xIW2M4hSLIbcmVhcWFggFWXdESXZfmgsWFhGDYhR3IaW84h09YgmLYgxKXhGt4 hm1IXlCIGlUHbehlgzOyhCi0Qdv1cTsHgjFmXNyGGPY1UBC3gpdogiQYhYF4bUWoWCEoHpUoGpsY RLcFiHZIXaulgwi1iCk4iWzIio1oiB6nc6q4YZzYipGYPpVWa0OSaHPO0mm2uGIviGCheCnCiHMS Voi5sYy6EY2UGGDU9iZO1E7MYSA3GCZ0KINbSEXV6ITfQ3EoR4jmE45rOI4YVo6lnmhY08ZRRLSO x6iNIVQvKbds4ZRi1nFMOZQePKZg+lhC8uiPzhhY73hh9uJBS8dgEJdivZiPMShqDfUvPSZIDvlp E0mQfLhYo2hld1iLGwlgnSiIIEgxJukVj3SSKjlpNLaSLoloKneFLCGTTUGTJSdkbMKOc6eT/GGT 2vR5PrmLPmR6QekrR7Z6PBlnQZKUiFeUxfgiTNl4TslzJRKVTJE3lbpoTljZblsJdFeGfFbJFF05 Z8o3lvfYIdQ3ll0ZlqzHlh55IG4Je04ZlHFJe3VZR0aifjQ5cHfpe3zZTfbXl5QWH2bZlPNBboVx KZUwQk6JeZXelmqCmX3PZmyNuXmRSYt9ZoHeGJLTqJkOJ5ZKUZlt+Y8GB2me2WaVtGgJVxNHJJq3 t5o9AZMwJ0quiXvKAmmM9iOyeZoitJs7kZozyZIntpD39Y3gB5ysqZq3SXXEiYnDREFPlI16WHGU bNeR3baDQIdOmoiL8DRi1SmL2IadBCZyxkRc5Lli3+mFzTmDGrNqdZh3boJrV3dyh4KcdhefZ0mW 7Wmby1ZL9Pma4MkWp6Ya43GZIll71hkX8jlBcMge09ZwL3R0ADp2Pfeeb/iCkOguTVehE2qOvwZr CRR1S5cvVsShtneQRhRCh6meZAag6Ghx6niEiahkkmGfhD/JnwGpRMHGj7UJmC4akQmZket5nR3q ZZt2oi+ZpEq6pNvCmzDnpJzSo1AaoFOqKFJapUaKpYxypVqKmV1qJ1wq+qVjJqb8RKaJEqZm6ohp 6mNrWido2qZPCadp8qZyymB1+iR0eqerqKeAb8anUpKnfjqfgRpkg+okgFqoxomoGKeoaVSajKpw y8llOPQ//pWosBmYlxoiC1eGnOqV+Tl/k1qVsjVyIuZd+zNB14NLB2RKeRh+NupMo1pszlmDHKef 57mhruoil0qbxERJDyVJvDpALRSdkhRxBp7KVjGHbV7HeMnansu6eM2qUM+qeNHabdOaeNWqZ9dq mCeorBQKrSGWTyskoUOqhAVKmeFqHysEeSgKo9aIjZ4koAvqi1oErFQIh8WUUe0qhEB0YPTqeO3K JDx6URZnojOKixj6iy6Ui5mZo8L6Tgp5sIcXsEGqoaJGrhIbohCrsJ92rL1BsRhJsOjJrIeocYKa Its6sSULIxZUlOx4qCd3la0W87LsurLO+q3UarPSirPYqrPWyrOPGrRCO7REW7RGe7RIm7QTSru0 TNu0Tvu0UBu1Uju1VFu1VhV7tVibtVq7tVzbtV77tWAbtmI7tmQUW7Zme7Zom7Zqu7Zs27Zu+7Zw G7cTcju3dFu3dnu3eJu3eru3fNu3fhT7t4AbuII7uIRbuIZ7uIibuIq7uBOM27iO+7iQG7mSO7mU W7mWe7mYEpu5mru5nNu5nvu5oBu6oju6pBRbuqZ7uqibuqq7uqzbuq77urAbuxKyO7u0W7u2e7u4 m7u6u7u827sSvvu7wBu8wju8xFu8xnu8yJu8Esq7vMzbvM77vNAbvdI7vdRbvRLWe73Ym73au73c 273e+73gG74Q4ju+5Fu+5nu+6Ju+6ru+7BLbvu77vvAbv/I7v/Rbv/Z7v/gRm7/6u7/827/++78A HMACPMASBFzABnzACJzACrzADNzADvzAEBAcwRI8wRRcwRZ8wRicwRoRvMEc3MEe/MEgHMIiPMIk XMISJnzCKJzCKrzCLNzCLvzCMhMQADs= ------=_NextPart_000_0063_01C10574.6C46A980-- From rja@inet.org Thu Jul 5 21:14:14 2001 From: rja@inet.org (RJ Atkinson) Date: Thu, 05 Jul 2001 16:14:14 -0400 Subject: [Isis-wg] Re: GigE JumboGrams & IS-IS In-Reply-To: <15172.42561.62675.380472@alpha-tli.procket.com> Message-ID: <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> All, Proposed new revised text for Section 7 is below. This does not change the basic conclusion, though it does add some additional text describing the current deployed reality. Specifically the revised text does attempt to discourage the use of any MTU other than 1518, 4470, or 9180/9200. If this change is accepted, the rest of the document is fine with me. Ran rja@inet.org ================================================================= 7. Default MTU The motivation for this draft was support of FDDI frames across the end-to-end Internet without intermediate fragmentation. According to RFC-1188, the IP MTU over FDDI is 4352 bytes, which is roughly 4470 bytes after including standard framing. RFC-1188 notes that the FDDI frame size as specified by ANSI is actually 4500 bytes, not 4470 bytes. Deployed IP/FDDI implementations are known to have adhered to RFC-1188. Supporting MPLS over Ethernet without fragmentation requires 4 or 8 additional bytes beyond Ethernet MTU. Supporting Ethernet-layer precedence ("IEEE 802.1p") or Ethernet Virtual LANs ("IEEE 802.1q") require a few bytes beyond the normal Ethernet MTU of 1518 bytes. Many, but not all, deployed servers with Gigabit Ethernet support an IP MTU of 9180. Server throughput is generally related closely to the per-packet processing costs, rather than the per-byte processing costs. So many servers have much better throughput with a larger MTU size. Many, but not all, deployed Gigabit Ethernet switch/router products support an Ethernet MTU of 9200 bytes today. An IP MTU of 9180 bytes is equivalent to an Ethernet MTU of 9200 bytes, considering Ethernet-layer framing overhead, etc. Additionally, RFC-1209 specifies an IP MTU of 9180 bytes over SMDS. RFC-1626 specifies an IP MTU of 9180 for IP over ATM AAL5. Some equipment providers claim significant cost to support the 9180 IP MTU, while other equipment providers claim that there is no significant change in cost to support 9180 versus 4470 as the IP MTU. Some, but not all, deployed very large backbone routers have support for the 9180 IP MTU over Gigabit Ethernet. A majority of currently deployed PPP over SONET interfaces support a default IP MTU of 4470 bytes. This 4470 MTU is believed to be nearly universal in deployed POS links today, though the POS MTU is theoretically configurable. An MTU of 4470 bytes for IS-IS PDUs over Gigabit Ethernet is recommended when the larger MTU value of 9180 is not needed, because use of the widespread POS MTU (i.e. 4470) greatly reduces the chance of intermediate fragmentation across the end-to-end Internet. If an Ethernet MTU larger than 4470 bytes is needed, then an Ethernet MTU of 9200 bytes is recommended. Use of any Ethernet MTU other than 1518, 4470, or 9200 bytes is specifically discouraged in order to avoid increasing MTU entropy. Varying MTU sizes across the end-to-end Internet path can cause packet loss as part of normal operation of Path MTU Discovery or can cause intermediate fragmentation of IPv4 datagrams. Intermediate fragmentation of IPv4 datagrams is widely believed to be very undesirable. Early implementations of Path MTU Discovery did not always work well. At present, there are mixed reports about the quality of deployed PMTU Discovery implementations. ============================================================================ From mbartell@cisco.com Thu Jul 5 21:56:09 2001 From: mbartell@cisco.com (Micah Bartell) Date: Thu, 05 Jul 2001 15:56:09 -0500 Subject: [Isis-wg] [Question] About ISIS packet format? In-Reply-To: <006701c10528$fc776b80$37c2fe81@etri.re.kr> Message-ID: <4.3.2.7.2.20010705155549.0226b108@cactus.cisco.com> --=====================_20003884==_.REL Content-Type: text/plain; charset="us-ascii"; format=flowed No, that is incorrect. ISIS packets are not enapsulated in IP. /mpb At 17:03 07/05/2001 +0900, mjyang wrote: >Hi all.. > >We are developing IS-IS routing protocol. >We have some question about ISIS. >In ISIS for IP, I want to confirm ISIS packet encapsulation format. >Is the following figure right? > >Awaiting the pleasure of your reply. >Regards, > >M.J.Yang.. >1312f2f.GIF >----------------- >Mijung Yang / ETRI >TEL: +82-42-860-4922 >FAX: +82-42-860-5440 >E-mail: mjyang@etri.re.kr > --=====================_20003884==_.REL Content-Type: image/gif; name="1312f2f.GIF"; x-mac-type="47494666"; x-mac-creator="4A565752" Content-ID: <4.3.2.7.2.20010705155549.0226b108@cactus.cisco.com.1> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="1312f2f.GIF" R0lGODdhvwPPAvcAAAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAC/A88C QAj/AAMIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXQoTgNOnUKNKnUq1qtWrWLNqrTpyq9evYMOK tdp1rNmzaM8yXcu2rdu3SwEglFvQ6UC6BO0mxBuR70G9AejK5Qu1ol+Ph+8aBHwYcN3EQiFvhNwY b+W9kn9mhsu5s+fPoDtu5jiaZ2mLpzE6nig1r0DBigPHppiatsnVhjHnfaqxdujfwIMLdzs4qmvZ yGEHHvx6uXLavB/HZn43Ouuuzq0nb759+XbeuIf6WpZYvPB07srtwgY/3mb74fDjy59P3+H7+qLx u9fPv7///wCuFF6AF91HIEMDHqjgggw26KBCBv4XIYATPmjhhRhmqF+CAVYYHIcahijiiCQ26CFx /p1Y4oostrDoInwgdqaiZjO+aOONOOYIXI038fhSjDoGKeSQREoomHamTYWTecgV6eSTUEaZUVpU VmnllVhmqeWWSHKX3Vx1ndfdc+Wdx16TUqap5pohnUZYlxCymZSPctZp55050bkYZ2/iFh11ZHpp 2Ziv6RmToXgmquiit2XnWHroFfqdXogySpqlmGaq6aYnVcrpp6CGKuqHo5Zq6qmo9udpqqy26uqr KK0K66y01mqrfbfmqorrrrxe2uuvwAYrrJfDFmvssaNSxSJhcS7kW4KDIiutsFxWa+212Gar7bZM Tuvtt4feJmutQE4J7rnoCugos4QmB6hz3sHVZ2XrRWpvk++6y2d52kE65rvgpSvwwCJ5Wu7ABxdI 8MIMT8ntwxBHLPHE1jZs8cUYZ6zxxhx37PHHIIcs8sgkl2zyySg4p6zyyiy37PLLMMcs88w012zz zTjnrPPOPPfs889ABy300EQXbfTRSCet9NJMN+3001BHLfXUVFcxbfXVWGet9dZcd+3112CHLfbY ZJdt9tlop6322my37fbbcMct99x012333XjnrffefCr37fffgAcu+OCEF2744YgnrvjijDfu+OOQ Ry755JRXbvnlmGeu+eacd+4o+eeghy766KSXbvrpqKeu+uqst+7667DHLvvstNdu++2456777rz3 7qX778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fTUy/gXY+rBWyh1f6GW/fayYX8knLgWPJf44aOf WMJ5YreY+trDS9m4H9FfPX7rU6r9n/F3b9ij+2NMdSJkqPmth1L6Ix/7HjO+vcymN+5jYHP+lEBo VahLAXMUBO9XJPOQz1kghE6/soc+DdqmYBRsT2YWuJsGVgd8KVQYChGoQghd0DjpswwLHci1QSJ5 8FHzktSRwIemvqymTPHTIQHLQsPdtHCIQ5Sf/RDDRBdKaoBQvOKZjjLFHmKqi/QB44bE6EWPkdF6 OTpjGWWmRqS0kYtvXGPR4qgTOi5Jjo+zo0v0mJId4jFyfGyTZwL5x8ARMjdwLCTzuEIjP1axW3tU DyS390FF0qw0KUzYITVFr/4xEINbLIxxRjjK4lgSXZhsYl/kRUNHHmeV8jrl1X5Yw2YRR5XdE1+0 kqhLIfJJloRWo6UTsejLePHPjMBMZpiUyUwHbbKZ0JTJM6NJzZZMs5rYjFU2t1mfa3Lzm/UDpzh/ M8kR+aVPxELS+mYTxT3hS4Lt+tI4W2Qwby7KlQ+x5zzvJEzy2JCV48MnsfK5rxj6k4f7zFg/r0jJ YjZRoHnC5Z56KagSyvN7b8HhCJ/o0AbqM6EncqrnxyCKIJCa9KQoTalKV8rSlrr0pTCNqUxnStOa 2vSmOM2pTnfKIdOe+vSnQA2qUIdK1KIa9ahITapSl8rUpjr1qVCNqlSnSiHVqlr1qljNqla3ytWu evWrYA2rWMdK1rKa9axoTata18of1ra69a1wjatc50rXutr1rnjNq173yte++vWvgA2sYB0HS9jC GvawiE2sYhfL2MY69rGQjaxkJ0vZylr2sqmYzaxmN8vZznr2s6ANLeRW9dFXgkSkboxgWVL7WMo8 MFAPXOZBxYSeXb7zOuYDUzoFZdoXslaQ/kMTbAfqW6OUdqmu3e1tiRtbgh6HXTrsLW6BG1zovvZ6 c1LtK62r3Pf9trGk/W44S+JKdum2iKrRbps81JjtNne64O2UeKlI3iVe173Lhe94SQLR9rIzP60V 7gkROt3n6Ku77ymggPUrnfnmx7ywPJ+DfhPLvQWLaVDnfK9zTUsmCA/4tBYuor/Ct0yS7hE7EM5w d0j83OMyl8Ly5aJ6T+viF09GXBMWLX9rnN2Q6hh/HYySiX8cyzQOachE/hCP72ijJSc5oiRysjSl /OTIZIjKKkFylUWEZf6aaMub6jJ9JQRmVGk5x0ou863EPNs0q4eZWsNhc3Df/C05uxNFdL7YmaUZ FzvnGUqXaaSSepS/P7Ns0D5pDaHLaWiUYQUoe/YeI5vy3zvb2M9bDi8y77wZFberw7b1l4Eb3aiG mDc1mBYSGT1M6h6Vz8a25FiqW33jUmcUvzKMMJ5prSBN31rDvA3ULjF8LzvPmtfpZfWrzyuf0Rwb kcg7JlCFPTziCud3Y8+O9odnjLFsaztU3v421sIt7mCWO3bkPvfU0q3uqLG73U97N7ybJu95L63e 9k4avvOAfbR983uO/0advwPeM7IQ3HOKXpGnjYk9S/9XgPGiLfcEiFGGHhxHkW42hyOVr/sO+17N 5W61YY1Z1HYs48C+uLrqO1KDqXwmJpe1y18eLmWb+p9F5m1629yWiic41jS3ZohVLOwSG1u67i26 zlk83FsOvcTBhnrQf4TjMJZU2jMkn7rQWW7GrGt95Ttuua2/Tvaym/3saE+72tfO9ra7/e1wj7vc GOdO97rb/e54z7ve9873vvv974APvOAHTxn4whv+8IhPvOIXz/jGO/7xkI+85CdP+cpbGP7ymM+8 5jfP+c57/vOgD73oR0/60pv+9BeoT73qV8/61rv+9bCPvexnT/va2/72uBbPve53z/ve+/73wA++ 8IdP/OIb//jIFk++8pfP/OY7//nQj770p0/96lv/+tgWz772t8/97nv/++APv/jHT/7ym//86BVP v/rXz/72u//98I+//OdP//rb//4V+M+//vfP//77//8AGIACOIAEWIAGF3iACJiACriADNiADviA EBiBEjiBFFiB/6bia0WhYFwnY7kVdhzoWBhIFBrogR8IYhuYgZCVXPgyXNACbfqjRRtHcgS2X5zm W8NWaGhmLtVlg+w0PzlYWCoYcenkbNs2TIphYLYFESNoaUdkhNj1g7kmW0IoXJ1WYwOnUkH4XMwm hUp4c9+BdLpGg1xIW2M4hSLIbcmVhcWFggFWXdESXZfmgsWFhGDYhR3IaW84h09YgmLYgxKXhGt4 hm1IXlCIGlUHbehlgzOyhCi0Qdv1cTsHgjFmXNyGGPY1UBC3gpdogiQYhYF4bUWoWCEoHpUoGpsY RLcFiHZIXaulgwi1iCk4iWzIio1oiB6nc6q4YZzYipGYPpVWa0OSaHPO0mm2uGIviGCheCnCiHMS Voi5sYy6EY2UGGDU9iZO1E7MYSA3GCZ0KINbSEXV6ITfQ3EoR4jmE45rOI4YVo6lnmhY08ZRRLSO x6iNIVQvKbds4ZRi1nFMOZQePKZg+lhC8uiPzhhY73hh9uJBS8dgEJdivZiPMShqDfUvPSZIDvlp E0mQfLhYo2hld1iLGwlgnSiIIEgxJukVj3SSKjlpNLaSLoloKneFLCGTTUGTJSdkbMKOc6eT/GGT 2vR5PrmLPmR6QekrR7Z6PBlnQZKUiFeUxfgiTNl4TslzJRKVTJE3lbpoTljZblsJdFeGfFbJFF05 Z8o3lvfYIdQ3ll0ZlqzHlh55IG4Je04ZlHFJe3VZR0aifjQ5cHfpe3zZTfbXl5QWH2bZlPNBboVx KZUwQk6JeZXelmqCmX3PZmyNuXmRSYt9ZoHeGJLTqJkOJ5ZKUZlt+Y8GB2me2WaVtGgJVxNHJJq3 t5o9AZMwJ0quiXvKAmmM9iOyeZoitJs7kZozyZIntpD39Y3gB5ysqZq3SXXEiYnDREFPlI16WHGU bNeR3baDQIdOmoiL8DRi1SmL2IadBCZyxkRc5Lli3+mFzTmDGrNqdZh3boJrV3dyh4KcdhefZ0mW 7Wmby1ZL9Pma4MkWp6Ya43GZIll71hkX8jlBcMge09ZwL3R0ADp2Pfeeb/iCkOguTVehE2qOvwZr CRR1S5cvVsShtneQRhRCh6meZAag6Ghx6niEiahkkmGfhD/JnwGpRMHGj7UJmC4akQmZket5nR3q ZZt2oi+ZpEq6pNvCmzDnpJzSo1AaoFOqKFJapUaKpYxypVqKmV1qJ1wq+qVjJqb8RKaJEqZm6ohp 6mNrWido2qZPCadp8qZyymB1+iR0eqerqKeAb8anUpKnfjqfgRpkg+okgFqoxomoGKeoaVSajKpw y8llOPQ//pWosBmYlxoiC1eGnOqV+Tl/k1qVsjVyIuZd+zNB14NLB2RKeRh+NupMo1pszlmDHKef 57mhruoil0qbxERJDyVJvDpALRSdkhRxBp7KVjGHbV7HeMnansu6eM2qUM+qeNHabdOaeNWqZ9dq mCeorBQKrSGWTyskoUOqhAVKmeFqHysEeSgKo9aIjZ4koAvqi1oErFQIh8WUUe0qhEB0YPTqeO3K JDx6URZnojOKixj6iy6Ui5mZo8L6Tgp5sIcXsEGqoaJGrhIbohCrsJ92rL1BsRhJsOjJrIeocYKa Its6sSULIxZUlOx4qCd3la0W87LsurLO+q3UarPSirPYqrPWyrOPGrRCO7REW7RGe7RIm7QTSru0 TNu0Tvu0UBu1Uju1VFu1VhV7tVibtVq7tVzbtV77tWAbtmI7tmQUW7Zme7Zom7Zqu7Zs27Zu+7Zw G7cTcju3dFu3dnu3eJu3eru3fNu3fhT7t4AbuII7uIRbuIZ7uIibuIq7uBOM27iO+7iQG7mSO7mU W7mWe7mYEpu5mru5nNu5nvu5oBu6oju6pBRbuqZ7uqibuqq7uqzbuq77urAbuxKyO7u0W7u2e7u4 m7u6u7u827sSvvu7wBu8wju8xFu8xnu8yJu8Esq7vMzbvM77vNAbvdI7vdRbvRLWe73Ym73au73c 273e+73gG74Q4ju+5Fu+5nu+6Ju+6ru+7BLbvu77vvAbv/I7v/Rbv/Z7v/gRm7/6u7/827/++78A HMACPMASBFzABnzACJzACrzADNzADvzAEBAcwRI8wRRcwRZ8wRicwRoRvMEc3MEe/MEgHMIiPMIk XMISJnzCKJzCKrzCLNzCLvzCMhMQADs= --=====================_20003884==_.REL-- From henk@Procket.com Thu Jul 5 22:05:43 2001 From: henk@Procket.com (Henk Smit) Date: Thu, 5 Jul 2001 14:05:43 -0700 (PDT) Subject: [Isis-wg] Re: GigE JumboGrams & IS-IS In-Reply-To: <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> from "RJ Atkinson" at Jul 05, 2001 04:14:14 PM Message-ID: <200107052105.f65L5hq03139@redd3174.procket.com> > > Proposed new revised text for Section 7 is below. This does > not change the basic conclusion, though it does add some additional > text describing the current deployed reality. Just curious, how many ISIS implementations are out there today that send IIHs larger than 1500 bytes over GigE ? Zero ? One ? Two ? More than two ? henk. From tli@Procket.com Thu Jul 5 23:45:22 2001 From: tli@Procket.com (Tony Li) Date: Thu, 5 Jul 2001 15:45:22 -0700 Subject: [Isis-wg] Re: GigE JumboGrams & IS-IS In-Reply-To: <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> References: <15172.42561.62675.380472@alpha-tli.procket.com> <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> Message-ID: <15172.60930.37609.415804@alpha-tli.procket.com> Some comments on Ran's proposal. | 7. Default MTU | | The motivation for this draft was support of FDDI frames | across the end-to-end Internet without intermediate fragmentation. More accurately: the MTU of much of the deployed core of the Internet was (and is) >= 4000 bytes. | According to RFC-1188, the IP MTU over FDDI is 4352 bytes, | which is roughly 4470 bytes after including standard framing. | RFC-1188 notes that the FDDI frame size as specified by | ANSI is actually 4500 bytes, not 4470 bytes. Deployed IP/FDDI | implementations are known to have adhered to RFC-1188. Very early FDDI implementations used an MTU of 4470 bytes. This was then propagated into early POS implementations. Somewhere in between RFC 1188 dropped the FDDI MTU to 4352. I'm unaware of any implementations that followed suit. | Supporting MPLS over Ethernet without fragmentation | requires 4 or 8 additional bytes beyond Ethernet MTU. More generally: Support for one level of of MPLS label will require 4 bytes of link layer frame above the IP MTU. Similarly two labels will require 8 bytes. | Supporting Ethernet-layer precedence ("IEEE 802.1p") or | Ethernet Virtual LANs ("IEEE 802.1q") require a few bytes | beyond the normal Ethernet MTU of 1518 bytes. I think many people will find "normal Ethernet MTU" and "1518 bytes" confusing. | Many, but not all, deployed servers with Gigabit Ethernet | support an IP MTU of 9180. Server throughput is generally | related closely to the per-packet processing costs, | rather than the per-byte processing costs. So many servers | have much better throughput with a larger MTU size. Many, | but not all, deployed Gigabit Ethernet switch/router products | support an Ethernet MTU of 9200 bytes today. An IP MTU | of 9180 bytes is equivalent to an Ethernet MTU of 9200 bytes, | considering Ethernet-layer framing overhead, etc. Specifically, that allows for 20 bytes outside of the IP packet. Certain amounts of overhead are necessary: DA (6 bytes) SA (6 bytes) Type (2 bytes) CRC (4 bytes) This would leave 2 bytes for optional additions. Unfortunately, the common options that I can think of are: VLAN tag (4 bytes) MPLS label (4 bytes) MPLS 2 labels (8 bytes) It appears as if an IP MTU of 9180 is still too large. | Additionally, RFC-1209 specifies an IP MTU of 9180 bytes over | SMDS. I believe that the SMDS experiment is conclucded. ;-) | RFC-1626 specifies an IP MTU of 9180 for IP over | ATM AAL5. Some equipment providers claim significant cost | to support the 9180 IP MTU, while other equipment providers | claim that there is no significant change in cost to support | 9180 versus 4470 as the IP MTU. Some, but not all, deployed | very large backbone routers have support for the 9180 IP MTU | over Gigabit Ethernet. | | A majority of currently deployed PPP over SONET interfaces | support a default IP MTU of 4470 bytes. This 4470 MTU is | believed to be nearly universal in deployed POS links today, | though the POS MTU is theoretically configurable. | | An MTU of 4470 bytes for IS-IS PDUs over Gigabit Ethernet | is recommended when the larger MTU value of 9180 is not needed, | because use of the widespread POS MTU (i.e. 4470) greatly reduces | the chance of intermediate fragmentation across the end-to-end | Internet. If an Ethernet MTU larger than 4470 bytes is needed, | then an Ethernet MTU of 9200 bytes is recommended. Use of any | Ethernet MTU other than 1518, 4470, or 9200 bytes is specifically | discouraged in order to avoid increasing MTU entropy. I would add one more line in here: The default IP MTU for Gigabit Ethernet should be 4470 bytes. While I appreciate the additional discussion, we must not appear to be ambiguous. Tony From rja@inet.org Fri Jul 6 01:34:33 2001 From: rja@inet.org (RJ Atkinson) Date: Thu, 05 Jul 2001 20:34:33 -0400 Subject: [Isis-wg] Re: GigE JumboGrams & IS-IS In-Reply-To: <15172.60930.37609.415804@alpha-tli.procket.com> References: <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> <15172.42561.62675.380472@alpha-tli.procket.com> <5.1.0.14.2.20010705152259.00a44400@10.30.15.2> Message-ID: <5.1.0.14.2.20010705201440.00a09090@10.30.15.2> At 18:45 05/07/01, Tony Li wrote: > | 7. Default MTU > | > | The motivation for this draft was support of FDDI frames > | across the end-to-end Internet without intermediate fragmentation. > > >More accurately: the MTU of much of the deployed core of the Internet was >(and is) >= 4000 bytes. Please take that level of re-write up with the original authors. I didn't want to edit their assertion of motivation that severely. > | According to RFC-1188, the IP MTU over FDDI is 4352 bytes, > | which is roughly 4470 bytes after including standard framing. > | RFC-1188 notes that the FDDI frame size as specified by > | ANSI is actually 4500 bytes, not 4470 bytes. Deployed IP/FDDI > | implementations are known to have adhered to RFC-1188. > > >Very early FDDI implementations used an MTU of 4470 bytes. This was then >propagated into early POS implementations. Somewhere in between RFC 1188 >dropped the FDDI MTU to 4352. I'm unaware of any implementations that >followed suit. I'd be interested in Dave Katz's inputs since he wrote that RFC and was involved in the earliest implementations. When you say "MTU", do you mean link MTU or IP MTU ? If you mean link MTU, that's consistent with what I've said above. The as-deployed-for-IP link MTU was 4470 not 4500 bytes, according to RFC-1188. > | Supporting MPLS over Ethernet without fragmentation > | requires 4 or 8 additional bytes beyond Ethernet MTU. > >More generally: Support for one level of of MPLS label will require 4 bytes >of link layer frame above the IP MTU. Similarly two labels will require 8 >bytes. No objection. The quoted text came from the original draft. > | Supporting Ethernet-layer precedence ("IEEE 802.1p") or > | Ethernet Virtual LANs ("IEEE 802.1q") require a few bytes > | beyond the normal Ethernet MTU of 1518 bytes. > > >I think many people will find "normal Ethernet MTU" and "1518 bytes" >confusing. A specific edit proposal would be helpful. > | Many, but not all, deployed servers with Gigabit Ethernet > | support an IP MTU of 9180. Server throughput is generally > | related closely to the per-packet processing costs, > | rather than the per-byte processing costs. So many servers > | have much better throughput with a larger MTU size. Many, > | but not all, deployed Gigabit Ethernet switch/router products > | support an Ethernet MTU of 9200 bytes today. An IP MTU > | of 9180 bytes is equivalent to an Ethernet MTU of 9200 bytes, > | considering Ethernet-layer framing overhead, etc. > > >Specifically, that allows for 20 bytes outside of the IP packet. Certain >amounts of overhead are necessary: > > DA (6 bytes) > SA (6 bytes) > Type (2 bytes) > CRC (4 bytes) > >This would leave 2 bytes for optional additions. Unfortunately, the common >options that I can think of are: > > VLAN tag (4 bytes) > MPLS label (4 bytes) > MPLS 2 labels (8 bytes) > >It appears as if an IP MTU of 9180 is still too large. Actually, you've just constructed a case that 9220 is too small when one or more of those options are present. The 9180 number is actually deployed pretty widely (e.g. in servers, switches, routers), hence is hard to change at this point. ASIDE: If you do the same math, by the way, for IP over IEEE standard Ethernet, you'll discover that IEEE has 2 link MTUs for standard Ethernet (the original one & an IEEE jumbo frame which increases the max Ethernet frame size by 4 bytes -- for a single VLAN tag). > | Additionally, RFC-1209 specifies an IP MTU of 9180 bytes over > | SMDS. > > >I believe that the SMDS experiment is conclucded. ;-) It is relevant in the same manner that FDDI is relevant, to provide historical context. FDDI is basically gone also at this point. I don't even think FDDI chipsets are in active production any longer, for example. (This caused some panic in parts of the US Navy, whose ships have been using FDDI for many years now as their shipboard backbone). > | RFC-1626 specifies an IP MTU of 9180 for IP over > | ATM AAL5. Some equipment providers claim significant cost > | to support the 9180 IP MTU, while other equipment providers > | claim that there is no significant change in cost to support > | 9180 versus 4470 as the IP MTU. Some, but not all, deployed > | very large backbone routers have support for the 9180 IP MTU > | over Gigabit Ethernet. > | > | A majority of currently deployed PPP over SONET interfaces > | support a default IP MTU of 4470 bytes. This 4470 MTU is > | believed to be nearly universal in deployed POS links today, > | though the POS MTU is theoretically configurable. > | > | An MTU of 4470 bytes for IS-IS PDUs over Gigabit Ethernet > | is recommended when the larger MTU value of 9180 is not needed, > | because use of the widespread POS MTU (i.e. 4470) greatly reduces > | the chance of intermediate fragmentation across the end-to-end > | Internet. If an Ethernet MTU larger than 4470 bytes is needed, > | then an Ethernet MTU of 9200 bytes is recommended. Use of any > | Ethernet MTU other than 1518, 4470, or 9200 bytes is specifically > | discouraged in order to avoid increasing MTU entropy. > > >I would add one more line in here: The default IP MTU for Gigabit Ethernet >should be 4470 bytes. >While I appreciate the additional discussion, we must not appear to be >ambiguous. That is OK, we will have a whole draft on IP/GigE elsewhere. :-) How IP is encapsulated over anything is WAY outside the charter of this WG, whereas how IS-IS is carried anywhere is reasonably within charter for this WG. If you feel compelled to put IP in here specifically, it ought to be phrased as it was by the original authors for IS-IS: An MTU of 4470 bytes for IP packets or IS-IS PDUs over Gigabit Ethernet is recommended when the larger MTU of 9180 is not needed. [remaining text roughly as proposed earlier] Cheers, Ran rja@inet.org From Internet-Drafts@ietf.org Fri Jul 6 11:50:23 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 06 Jul 2001 06:50:23 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-03.txt Message-ID: <200107061050.GAA25859@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 Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-03.txt Pages : 6 Date : 05-Jul-01 This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions to support IPv4 described in [3]. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-hmac-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-hmac-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010705113838.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Fri Jul 6 11:50:23 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 06 Jul 2001 06:50:23 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-03.txt Message-ID: <200107061050.GAA25859@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 Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-03.txt Pages : 6 Date : 05-Jul-01 This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions to support IPv4 described in [3]. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-hmac-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-hmac-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- From mjyang@etri.re.kr Mon Jul 9 11:35:15 2001 From: mjyang@etri.re.kr (Mijung Yang) Date: Mon, 9 Jul 2001 19:35:15 +0900 Subject: [Isis-wg] [Question] ISIS encapsulation over AAL5 ? Message-ID: <006e01c10862$d739ef40$37c2fe81@etri.re.kr> This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C108AE.46F6DDC0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsLi4NCkkgaGF2ZSAyIHF1ZXN0aW9uLi4NCg0KRmlyc3QuLg0KSSB3YW50IHRvIGNvbmZp cm0gdGhlIGZvbGxvd2luZyBkYXRhIGZvcm1hdCBpbiBjYXNlIG9mIHVzaW5nIEFBTDUuLg0KDQor LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCnwgTExDIHwgTkxQSUQgfCAgIElTLUlTIFBEVXMo TGVuZ3RoIEluZGljYXRvciB+KSAgICAgICB8IFBBRCB8IENQQ1MtUERVIHRyYWlsZXIgfA0KKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCkxMQyA9IDB4RkUtRkUtMDMNCk5MUElEID0gMHg4 Mw0KDQpJZiBFUy1JUywgTkxQSUQgPSAgMHg4MiBhbmQgRVMtSVMgUERVKExlbmd0aCBJbmRpY2F0 b3IgfikuDQoNCklzIGl0IHJpZ2h0Pw0KDQpTZWNvbmQuLg0KSW4gSW50ZWdyYXRlZCBJUy1JUyhS RkMgMTE5NSksIHdoaWNoIHZhbHVlIGNhbiBiZSBpbmNsdWRlZCBpbiAiUHJvdG9jb2wgU3VwcG9l cnRlZCIgY29kZT8NCldoYXQgaXMgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSAiSW50cmFkb21haW4g Um91dGluZyBQcm90b2NvbCBEaXNjcmltaW5hdG9yIiBpbiBJU0lTIFBEVSBoZWFlciANCmFuZCAi UHJvdG9jb2wgU3VwcG9lcnRlZCIgY29kZSBpbiBJbnRlZ3JhdGVkIElTLUlTPw0KDQpBd2FpdGlu ZyB0aGUgcGxlYXN1cmUgb2YgeW91ciByZXBseS4NClJlZ2FyZHMuLg0KDQotLS0tLS0tLS0tLS0t LS0tLQ0KTWlqdW5nIFlhbmcgLyBFVFJJIA0KVEVMOiArODItNDItODYwLTQ5MjIgDQpGQVg6ICs4 Mi00Mi04NjAtNTQ0MCANCkUtbWFpbDogbWp5YW5nQGV0cmkucmUua3IgDQoNCg== ------=_NextPart_000_006B_01C108AE.46F6DDC0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbC4u PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBoYXZlIDIgcXVlc3Rpb24uLjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkZpcnN0Li48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHdhbnQg dG8gY29uZmlybSB0aGUgZm9sbG93aW5nIGRhdGEgZm9ybWF0IGluIGNhc2Ugb2YgdXNpbmcgDQpB QUw1Li48QlI+PEJSPistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxCUj58IA0KTExDIHwgTkxQ SUQgfCZuYnNwOyZuYnNwOyBJUy1JUyBQRFVzKExlbmd0aCBJbmRpY2F0b3IgDQp+KSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFBBRCB8IENQQ1MtUERVIHRyYWlsZXIgDQp8 PEJSPistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxCUj48QlI+TExDIA0KPSAweEZFLUZFLTAz PEJSPk5MUElEID0gMHg4MzxCUj48QlI+SWYgRVMtSVMsIE5MUElEID0mbmJzcDsgMHg4MiBhbmQg RVMtSVMgDQpQRFUoTGVuZ3RoIEluZGljYXRvciB+KS48QlI+PEJSPklzIGl0IHJpZ2h0PzxCUj48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5TZWNvbmQuLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPkluIEludGVncmF0ZWQgSVMtSVMoUkZDIDExOTUpLCB3aGljaCB2YWx1 ZSBjYW4gYmUgaW5jbHVkZWQgaW4gDQoiUHJvdG9jb2wgU3VwcG9lcnRlZCIgY29kZT88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5XaGF0IGlzIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUg IkludHJhZG9tYWluIFJvdXRpbmcgUHJvdG9jb2wgDQpEaXNjcmltaW5hdG9yIiBpbiBJU0lTIFBE VSBoZWFlciA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hbmQgIlByb3RvY29sIFN1 cHBvZXJ0ZWQiIGNvZGUgaW4gSW50ZWdyYXRlZCANCklTLUlTPzwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPjxCUj5Bd2FpdGluZyB0aGUgcGxlYXN1cmUgb2YgeW91ciANCnJlcGx5LjxC Uj5SZWdhcmRzLi48QlI+PC9ESVY+PC9GT05UPg0KPERJVj48Rk9OVCBzaXplPTI+LS0tLS0tLS0t LS0tLS0tLS08QlI+TWlqdW5nIFlhbmcgLyBFVFJJIDxCUj5URUw6IA0KKzgyLTQyLTg2MC00OTIy IDxCUj5GQVg6ICs4Mi00Mi04NjAtNTQ0MCA8QlI+RS1tYWlsOiA8QSANCmhyZWY9Im1haWx0bzpt anlhbmdAZXRyaS5yZS5rciI+bWp5YW5nQGV0cmkucmUua3I8L0E+IA0KPEJSPjwvRk9OVD48L0RJ Vj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_006B_01C108AE.46F6DDC0-- From Larmer@CommSense.Net Thu Jul 12 20:17:08 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 12 Jul 2001 15:17:08 -0400 Subject: [Isis-wg] DR election Message-ID: Hi, I have a question pertaining to the DR election process within Int IS-IS. ISO-10589 states the following: Broadcast subnetworks 8.4.1 Enabling of broadcast circuits When the broadcast circuit is enabled on an Intermediate system the IS shall perform the following actions. a) Commence sending IIH PDUs with the LAN ID field set to the concatenation of its own systemID and its locally assigned one octet Local Circuit ID. b) Solicit the End system configuration as described in 8.4.6 c) Start listening for ISO 9542 ESH PDUs and acquire adjacencies as appropriate. Do not run the Designated Intermediate System election process. d) After waiting iSISHelloTimer × 2 seconds, run the Level 1 and or the level 2 designated intermediate system election process depending on the Intermediate system type. LAN designated intermediate systems The IS shall run the Level 1 and/or the Level 2 Designated Intermediate System election process (depending on the Intermediate system type) whenever an IIH PDU is received or transmitted as described in 8.4.4. (For these purposes, the transmission of the system’s own IIH PDU is equivalent to receiving it). If there has been no change to the information on which the election is performed since the last time it was run, the previous result can be assumed. The relevant information is f) the set of Intermediate system adjacency states; g) the set of Intermediate System priorities (including this system’s); and h) the existence (or otherwise) of at least one “Up” End system (not including manual adjacencies) or Intermediate system adjacency on the circuit. I understanding waiting iSISHelloTimer X 2 seconds when a circuit is first enabled, however, what happens when we have a circuit failure, which times out all of our adjacencies and then the circuit comes back. Do we then run the DR election process after we receive our first LAN IIH with an adjacency reference to us in its IS Neighbors field or do we wait the iSISHelloTimer X 2. If we wait iSISHelloTimer x 2, our convergence times may be delayed considerably? Secondly, our iSISHelloTimer may be different from our neighbors, which we may be unaware of because we have yet to receive an IIH from them. I can see the DR changing multiple times given the correct configuration prior to the correct DR being elected. Should there be some check against the LAN ID contained within the IIH prior to running the DR election process? Your comments greatly appreciated! Cheers, Ken Larmer From Larmer@CommSense.Net Thu Jul 12 20:40:05 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 12 Jul 2001 15:40:05 -0400 Subject: [Isis-wg] DR election In-Reply-To: Message-ID: Hi, I believe I have answered my own question? If there is more than one IS on a LAN, there is already a DR. In accordance with ISO-10589, the DR will use the dRISISHelloTimer = 1 second. So, with this considered, we will receive a LAN IIH from the DR advertising an adjacency to us prior to electing a new DR. This is because we send our LAN IIH to the allL1/L2 multicast address, so all ISs on the LAN will receive it at the same time. Consequently, the IS with the shortest ISISHelloTimer will be the first system we form an adjacency with. If we do not have a higher priority than the current DR, than we will not elect ourselves as the DR. Thanks, Ken > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Ken Larmer > Sent: Thursday, July 12, 2001 3:17 PM > To: Isis-Wg@Juniper. Net > Cc: Ken Larmer > Subject: [Isis-wg] DR election > > > Hi, > > I have a question pertaining to the DR election process > within Int IS-IS. > ISO-10589 states the following: > > Broadcast subnetworks > > 8.4.1 Enabling of broadcast circuits > > When the broadcast circuit is enabled on an Intermediate system > the IS shall > perform the following actions. > > a) Commence sending IIH PDUs with the LAN ID field set to the > concatenation > of its own systemID and its locally assigned one octet Local Circuit ID. > > b) Solicit the End system configuration as described in 8.4.6 > > c) Start listening for ISO 9542 ESH PDUs and acquire adjacencies as > appropriate. Do not run the Designated Intermediate System > election process. > > d) After waiting iSISHelloTimer × 2 seconds, run the Level 1 and or the > level 2 designated intermediate system election process depending on the > Intermediate system type. > > > LAN designated intermediate systems > > The IS shall run the Level 1 and/or the Level 2 Designated Intermediate > System election process (depending on the Intermediate system > type) whenever > an IIH PDU is received or transmitted as described in 8.4.4. (For these > purposes, the transmission of the system’s own IIH PDU is equivalent to > receiving it). If there has been no change to the information on which the > election is performed since the last time it was run, the previous result > can be assumed. The relevant information is > > f) the set of Intermediate system adjacency states; > > g) the set of Intermediate System priorities (including this > system’s); and > > h) the existence (or otherwise) of at least one “Up” End system (not > including manual adjacencies) or Intermediate system adjacency on the > circuit. > > > I understanding waiting iSISHelloTimer X 2 seconds when a > circuit is first > enabled, however, what happens when we have a circuit failure, which times > out all of our adjacencies and then the circuit comes back. Do we then run > the DR election process after we receive our first LAN IIH with > an adjacency > reference to us in its IS Neighbors field or do we wait the > iSISHelloTimer X > 2. If we wait iSISHelloTimer x 2, our convergence times may be delayed > considerably? > > Secondly, our iSISHelloTimer may be different from our > neighbors, which we > may be unaware of because we have yet to receive an IIH from > them. I can see > the DR changing multiple times given the correct configuration > prior to the > correct DR being elected. Should there be some check against the LAN ID > contained within the IIH prior to running the DR election process? > > Your comments greatly appreciated! > > Cheers, > Ken Larmer > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From tli@Procket.com Fri Jul 13 19:33:04 2001 From: tli@Procket.com (Tony Li) Date: Fri, 13 Jul 2001 11:33:04 -0700 Subject: [Isis-wg] London Message-ID: <15183.16096.534542.645079@alpha-tli.procket.com> Folks, There are currently no plans to have a WG meeting in London. We'd like to encourage people to continue to contribute via the mailing list. Thanks, Tony & Tony From Internet-Drafts@ietf.org Mon Jul 16 12:00:17 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 16 Jul 2001 07:00:17 -0400 Subject: [Isis-wg] I-D ACTION:draft-ash-ospf-isis-congestion-control-00.txt Message-ID: <200107161100.HAA10237@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Mechanisms for Congestion Control/Failure Recovery in OSPF & ISIS Networks Author(s) : J. Ash Filename : draft-ash-ospf-isis-congestion-control-00.txt Pages : Date : 13-Jul-01 Earlier papers and contributions identified issues of congestion control and failure recovery for link-state protocol networks, such as OSPF, ISIS, and PNNI networks [maunder, choudhury, pappalardo1, pappalardo2, atm01-0101]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-00.txt 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-ash-ospf-isis-congestion-control-00.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-ash-ospf-isis-congestion-control-00.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: <20010713124200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-ospf-isis-congestion-control-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ash-ospf-isis-congestion-control-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124200.I-D@ietf.org> --OtherAccess-- --NextPart-- From prz@redback.com Mon Jul 16 23:50:27 2001 From: prz@redback.com (Tony Przygienda) Date: Mon, 16 Jul 2001 15:50:27 -0700 Subject: [Isis-wg] London References: <15183.16096.534542.645079@alpha-tli.procket.com> Message-ID: <3B536FB3.18D25B55@redback.com> Tony Li wrote: > Folks, > > There are currently no plans to have a WG meeting in London. We'd like to > encourage people to continue to contribute via the mailing list. that was crying wolf a little to early. I will be in London Wed-Sat and requested a slot since there are enough things in flux to talk about IMHO ... If I get a slot I'll send a call for agenda items ... thanks --- tony From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_200171131757202066148151 Content-Type: text/plain; charset=us-ascii Hello all, Is Partition Detection and Repair supported for IP only routers? Thanks in Advance Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_200171131757202066148151 Content-Type: text/html; charset=us-ascii

Hello all,

Is Partition Detection and Repair supported for IP only routers?

Thanks in Advance

Regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_200171131757202066148151-- From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_2001713518233713798878 Content-Type: text/plain; charset=us-ascii Hello all, Is Partition Detection and Repair supported for IP only routers? Thanks in Advance Regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_2001713518233713798878 Content-Type: text/html; charset=us-ascii

Hello all,

Is Partition Detection and Repair supported for IP only routers?

Thanks in Advance

Regards

Sivakumar A

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_2001713518233713798878-- From sluong@cisco.com Tue Jul 17 01:56:53 2001 From: sluong@cisco.com (Steven Luong) Date: Mon, 16 Jul 2001 17:56:53 -0700 Subject: [Isis-wg] draft-ietf-isis-wg-multi-topology-00.txt References: <200102281155.GAA02125@ietf.org> <20010228112859.C27593@ivmg.net> <3A9DDE62.5F271B14@redback.com> Message-ID: <3B538D55.D804614F@cisco.com> I saw MT-ID 2 is reserved for IPv6 routing topology. There is no Multi-Topology Reachable IPv6 Prefixes TLV defined. So I assume that the only way to advertise IPv6 Reachability Prefixes is via 236, defined in draft-ietf-isis-ipv6-02.txt. If somebody is to implement ISIS-IPv6 multi-topology, how do these two drafts fit together? Do you advertise IS adjacencies via MT Intermediate Systems TLV and Reachability Prefixes via 236? People who implemented ISIS-IPv6 using draft-ietf-isis-ipv6-02.txt may not understand MT Intermediate Systems TLV and they expect either IS Reachability TLV or Extended IS Reachability TLV only. From Rajesh Hegde" This is a multi-part message in MIME format. ------=_NextPart_000_00FD_01C10EFE.391760C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Following are the doubts regarding the usage of size of LSP mtu By having default size of 1497 bytes works for most of the data link = types. Ex : Ethernet, FrameRelay and Serial Links where the size of the = DataLink BlockSize is 1500 bytes. =20 1 ) How it should be handled If the datalink type is POS where the = default DataLinkBlockSize is 512 bytes ? 2) How the negotiation of the Hello PDUs to be done in case of FDDI and = Gigabit ethernet where the DataLinkBlockSize is greater than the default = size of 1497 bytes ? (i.e Do we pad the Hello PDU to the size of DataLink Block Size or = increase the LSP MTU size ? )=20 3) Shall the parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp = mtu and level 2 lsp-mtu) be made configurable ? Suppose a router with 3 interfaces 1 ethernet(Link Mtu 1500 bytes), 1 = Gigabit ethernet (Link MTU is 9180 bytes), 1 POS interface (link MTU 512 = bytes ) In this case how to decide the size of the LSP-mtu ? Thanks and Regards, Rajesh ------=_NextPart_000_00FD_01C10EFE.391760C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Following are the doubts regarding = the usage=20 of size of LSP mtu
 
By having default size of 1497 bytes = works for most=20 of the data link types. Ex : Ethernet, FrameRelay and Serial Links where = the=20 size of the DataLink BlockSize is 1500 bytes.
 
1 )  How it should be handled If = the datalink=20 type is POS where the default DataLinkBlockSize is     = 512 bytes=20 ?
 
2) How the negotiation of the Hello = PDUs to be done=20 in case of FDDI and Gigabit ethernet where the DataLinkBlockSize is = greater than=20 the default size of 1497 bytes ?
(i.e Do we pad the Hello PDU to the = size of=20 DataLink Block Size or increase the LSP MTU size ? ) 
 
3) Shall the=20 parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp mtu and = level 2=20 lsp-mtu) be made configurable ?
 
Suppose a router with 3 interfaces 1 = ethernet(Link=20 Mtu 1500 bytes), 1 Gigabit ethernet (Link MTU is 9180 bytes), 1 POS = interface (link MTU 512 bytes )
 
In this case how to decide the size of = the LSP-mtu=20 ?
 
Thanks and Regards,
Rajesh
 
 
 
 
------=_NextPart_000_00FD_01C10EFE.391760C0-- From prz@redback.com Tue Jul 17 18:20:03 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 17 Jul 2001 10:20:03 -0700 Subject: [Isis-wg] FYI: small draft with TLV numbers ... Message-ID: <3B5473C2.C81EBCFA@redback.com> Put a small draft together to prevent TLV conflicts, would appreciate if the word spreads to SIF and OSI so we have a place people can check before steping on each others' toes. If missed something or inexact, pls let me know and will correct and put updated version out ... thansk - tony Internet Engineering Task Force T. Przygienda INTERNET DRAFT Redback July 2001 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 Jan 2002 [Page 1] Internet Draft TLV Codepoints July 2001 1. TLV Codepoints reserved ___________________________________________________________ Name Value IIH LSP SNP Status ___________________________________________________________ Area Addresses 1 y y n RFC IIS Neighbors 2 n y n RFC ES Neighbors 3 n y n RFC Part. DIS 4 n y n RFC Prefix Neighbors 5 n y n RFC IIS Neighbors 6 y n n RFC Padding 8 y n n RFC LSP Entries 9 n n y RFC Authentication 10 y y y IETF-draft Opt. Checksum 12 y n y IETF-draft LSPBufferSize 14 y? y n SIF-draft TE IIS Neigh. 22 n y n IETF-draft MT-ISN 222 n y n IETF-draft IP Int. Reach 128 n y n RFC Prot. Supported 129 y y n RFC M-Topologies 229 y y n IETF-draft IP Ext. Address 130 n y n RFC IDRPI 131 n y y RFC IP Intf. Address 132 y y n RFC IPv6 Intf. Addr. 232 y y n IETF-draft illegal 133 n n n ? Router ID 134 n y n IETF-draft TE IP. Reach 135 n y n IETF-draft MT IP. Reach 235 n y n IETF-draft IPv6 IP. Reach 236 n y n IETF-draft Dynamic Name 137 n y n RFC 3-Way hellos 240 y n n RFC 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 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, Przygienda Expires Jan 2002 [Page 2] Internet Draft TLV Codepoints July 2001 no plausible central authority to assign TLV numbers exists as of today. 3. Acknowledgments 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. 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, Przygienda Expires Jan 2002 [Page 3] Internet Draft TLV Codepoints July 2001 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 Jan 2002 [Page 4] From iesg-secretary@ietf.org Tue Jul 17 18:16:53 2001 From: iesg-secretary@ietf.org (The IESG) Date: Tue, 17 Jul 2001 13:16:53 -0400 Subject: [Isis-wg] Note Well Message-ID: <200107171716.NAA23758@ietf.org> Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From mshand@cisco.com Tue Jul 17 19:21:21 2001 From: mshand@cisco.com (mike shand) Date: Tue, 17 Jul 2001 19:21:21 +0100 Subject: [Isis-wg] FYI: small draft with TLV numbers ... In-Reply-To: <3B5473C2.C81EBCFA@redback.com> Message-ID: <4.3.2.7.2.20010717191951.00b9af88@jaws.cisco.com> You missed 42. DECnet PhaseIV :-) But this is a VERY good idea. Thanks. Mike At 10:20 17/07/2001 -0700, Tony Przygienda wrote: >Put a small draft together to prevent TLV conflicts, would appreciate if >the word spreads >to SIF and OSI so we have a place people can check before steping on >each others' toes. >If missed something or inexact, pls let me know and will correct and put >updated version >out ... > > thansk > > - tony > > > > >Internet Engineering Task Force T. >Przygienda >INTERNET DRAFT >Redback > >July 2001 > 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 Jan 2002 >[Page 1] > >Internet Draft TLV Codepoints >July 2001 > >1. TLV Codepoints reserved > ___________________________________________________________ > Name Value IIH LSP SNP Status > > ___________________________________________________________ > > Area Addresses 1 y y n RFC > IIS Neighbors 2 n y n RFC > ES Neighbors 3 n y n RFC > Part. DIS 4 n y n RFC > Prefix Neighbors 5 n y n RFC > IIS Neighbors 6 y n n RFC > Padding 8 y n n RFC > LSP Entries 9 n n y RFC > Authentication 10 y y y IETF-draft > Opt. Checksum 12 y n y IETF-draft > LSPBufferSize 14 y? y n SIF-draft > TE IIS Neigh. 22 n y n IETF-draft > MT-ISN 222 n y n IETF-draft > IP Int. Reach 128 n y n RFC > Prot. Supported 129 y y n RFC > M-Topologies 229 y y n IETF-draft > IP Ext. Address 130 n y n RFC > IDRPI 131 n y y RFC > IP Intf. Address 132 y y n RFC > IPv6 Intf. Addr. 232 y y n IETF-draft > illegal 133 n n n ? > Router ID 134 n y n IETF-draft > TE IP. Reach 135 n y n IETF-draft > MT IP. Reach 235 n y n IETF-draft > IPv6 IP. Reach 236 n y n IETF-draft > Dynamic Name 137 n y n RFC > 3-Way hellos 240 y n n RFC > > > >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 > > 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, > > > >Przygienda Expires Jan 2002 >[Page 2] > >Internet Draft TLV Codepoints >July 2001 > > no plausible central authority to assign TLV numbers exists as of > today. > > > >3. Acknowledgments > >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. > > > >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, >Przygienda Expires Jan 2002 >[Page 3] > >Internet Draft TLV Codepoints >July 2001 > > 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 Jan 2002 >[Page 4] > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Tue Jul 17 19:39:36 2001 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 17 Jul 2001 14:39:36 -0400 Subject: [Isis-wg] FYI: small draft with TLV numbers ... In-Reply-To: <3B5473C2.C81EBCFA@redback.com> Message-ID: <4.3.2.7.2.20010717143108.0208ed58@dingdong.cisco.com> FYI, SIF, the SONET Interoperability Forum, rechartered themselves as NSIF, the Network and Services Integration Forum. (For more info, see "http://www.atis.org/atis/sif/sifhom.htm".) SIF did not allocate TLV IDs; rather, member company contributors directed their requests through their ISO member organizations. There should be no need to mention SIF in this document. Regards, Jeff At 01:20 PM 7/17/2001, Tony Przygienda wrote: >Put a small draft together to prevent TLV conflicts, would appreciate if >the word spreads >to SIF and OSI so we have a place people can check before steping on >each others' toes. >If missed something or inexact, pls let me know and will correct and put >updated version >out ... > > thansk > > - tony > > > > >Internet Engineering Task Force T. >Przygienda >INTERNET DRAFT >Redback > >July 2001 > 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 Jan 2002 >[Page 1] > >Internet Draft TLV Codepoints >July 2001 > >1. TLV Codepoints reserved > ___________________________________________________________ > Name Value IIH LSP SNP Status > > ___________________________________________________________ > > Area Addresses 1 y y n RFC > IIS Neighbors 2 n y n RFC > ES Neighbors 3 n y n RFC > Part. DIS 4 n y n RFC > Prefix Neighbors 5 n y n RFC > IIS Neighbors 6 y n n RFC > Padding 8 y n n RFC > LSP Entries 9 n n y RFC > Authentication 10 y y y IETF-draft > Opt. Checksum 12 y n y IETF-draft > LSPBufferSize 14 y? y n SIF-draft > TE IIS Neigh. 22 n y n IETF-draft > MT-ISN 222 n y n IETF-draft > IP Int. Reach 128 n y n RFC > Prot. Supported 129 y y n RFC > M-Topologies 229 y y n IETF-draft > IP Ext. Address 130 n y n RFC > IDRPI 131 n y y RFC > IP Intf. Address 132 y y n RFC > IPv6 Intf. Addr. 232 y y n IETF-draft > illegal 133 n n n ? > Router ID 134 n y n IETF-draft > TE IP. Reach 135 n y n IETF-draft > MT IP. Reach 235 n y n IETF-draft > IPv6 IP. Reach 236 n y n IETF-draft > Dynamic Name 137 n y n RFC > 3-Way hellos 240 y n n RFC > > > >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 > > 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, > > > >Przygienda Expires Jan 2002 >[Page 2] > >Internet Draft TLV Codepoints >July 2001 > > no plausible central authority to assign TLV numbers exists as of > today. > > > >3. Acknowledgments > >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. > > > >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, >Przygienda Expires Jan 2002 >[Page 3] > >Internet Draft TLV Codepoints >July 2001 > > 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 Jan 2002 >[Page 4] > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mbartell@cisco.com Tue Jul 17 19:52:15 2001 From: mbartell@cisco.com (Micah Bartell) Date: Tue, 17 Jul 2001 13:52:15 -0500 Subject: [Isis-wg] FYI: small draft with TLV numbers ... In-Reply-To: <4.3.2.7.2.20010717143108.0208ed58@dingdong.cisco.com> References: <3B5473C2.C81EBCFA@redback.com> Message-ID: <4.3.2.7.2.20010717135115.03269e98@cactus.cisco.com> Just replacing SIF w/ ISO should be sufficient. Along with the other TLV's marked RFC that are actually ISO defined. /mpb At 14:39 07/17/2001 -0400, Jeff Learman wrote: >FYI, > >SIF, the SONET Interoperability Forum, rechartered themselves as >NSIF, the Network and Services Integration Forum. (For more info, >see "http://www.atis.org/atis/sif/sifhom.htm".) > >SIF did not allocate TLV IDs; rather, member company contributors >directed their requests through their ISO member organizations. >There should be no need to mention SIF in this document. > >Regards, >Jeff > >At 01:20 PM 7/17/2001, Tony Przygienda wrote: > >Put a small draft together to prevent TLV conflicts, would appreciate if > >the word spreads > >to SIF and OSI so we have a place people can check before steping on > >each others' toes. > >If missed something or inexact, pls let me know and will correct and put > >updated version > >out ... > > > > thansk > > > > - tony > > > > > > > > > >Internet Engineering Task Force T. > >Przygienda > >INTERNET DRAFT > >Redback > > > >July 2001 > > 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 Jan 2002 > >[Page 1] > > > >Internet Draft TLV Codepoints > >July 2001 > > > >1. TLV Codepoints reserved > > ___________________________________________________________ > > Name Value IIH LSP SNP Status > > > > ___________________________________________________________ > > > > Area Addresses 1 y y n RFC > > IIS Neighbors 2 n y n RFC > > ES Neighbors 3 n y n RFC > > Part. DIS 4 n y n RFC > > Prefix Neighbors 5 n y n RFC > > IIS Neighbors 6 y n n RFC > > Padding 8 y n n RFC > > LSP Entries 9 n n y RFC > > Authentication 10 y y y IETF-draft > > Opt. Checksum 12 y n y IETF-draft > > LSPBufferSize 14 y? y n SIF-draft > > TE IIS Neigh. 22 n y n IETF-draft > > MT-ISN 222 n y n IETF-draft > > IP Int. Reach 128 n y n RFC > > Prot. Supported 129 y y n RFC > > M-Topologies 229 y y n IETF-draft > > IP Ext. Address 130 n y n RFC > > IDRPI 131 n y y RFC > > IP Intf. Address 132 y y n RFC > > IPv6 Intf. Addr. 232 y y n IETF-draft > > illegal 133 n n n ? > > Router ID 134 n y n IETF-draft > > TE IP. Reach 135 n y n IETF-draft > > MT IP. Reach 235 n y n IETF-draft > > IPv6 IP. Reach 236 n y n IETF-draft > > Dynamic Name 137 n y n RFC > > 3-Way hellos 240 y n n RFC > > > > > > > >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 > > > > 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, > > > > > > > >Przygienda Expires Jan 2002 > >[Page 2] > > > >Internet Draft TLV Codepoints > >July 2001 > > > > no plausible central authority to assign TLV numbers exists as of > > today. > > > > > > > >3. Acknowledgments > > > >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. > > > > > > > >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, > >Przygienda Expires Jan 2002 > >[Page 3] > > > >Internet Draft TLV Codepoints > >July 2001 > > > > 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 Jan 2002 > >[Page 4] > > > > > >_______________________________________________ > >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 prz@redback.com Tue Jul 17 23:11:19 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 17 Jul 2001 15:11:19 -0700 Subject: [Isis-wg] FYI: small draft with TLV numbers ... References: <4.3.2.7.2.20010717191951.00b9af88@jaws.cisco.com> Message-ID: <3B54B807.EFACCE18@redback.com> mike shand wrote: > You missed 42. DECnet PhaseIV :-) > > But this is a VERY good idea. Thanks. > > will do, don't want to get into trouble with anyone out there still running it. Do we put DEC or Compaq as the authority that assigned that number ;-)) ? ---- tony From Internet-Drafts@ietf.org Wed Jul 18 11:57:56 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 18 Jul 2001 06:57:56 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-transient-01.txt Message-ID: <200107181057.GAA24946@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 Transient Blackhole Avoidance Author(s) : D. McPherson Filename : draft-ietf-isis-transient-01.txt Pages : 6 Date : 17-Jul-01 This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-01.txt 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-transient-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-transient-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: <20010717132951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-transient-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-transient-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132951.I-D@ietf.org> --OtherAccess-- --NextPart-- From danny@ambernetworks.com Wed Jul 18 18:58:01 2001 From: danny@ambernetworks.com (Danny McPherson) Date: Wed, 18 Jul 2001 11:58:01 -0600 Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt Message-ID: <200107181758.f6IHw1i22475@tcb.net> Folks, the only update in this version is the addition of some text surrounding handling of "stale" LSPs. Thanks to Stefano for pointing this out. -danny > 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 Transient Blackhole Avoidance > Author(s) : D. McPherson > Filename : draft-ietf-isis-transient-01.txt > Pages : 6 > Date : 17-Jul-01 > > This document describes a simple, interoperable mechanism that can be > employed in IS-IS networks in order to decrease data loss associated > with deterministic blackholing of packets during transient network > conditions. The mechanism proposed here requires no IS-IS protocol > changes and is completely interoperable with the existing IS-IS > specification. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-01.txt > > 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-transient-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-transient-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. > > > > > From Anand@ambernetworks.com Wed Jul 18 20:58:02 2001 From: Anand@ambernetworks.com (Anand Ammundi) Date: Wed, 18 Jul 2001 12:58:02 -0700 Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt Message-ID: <9F4704BE89F7D4118A0F0002B328C36C084CF4@usa04.ambernetworks.com> Hi I had a question on the IS-IS black-holing subject. IS-IS (and OSPF rfc's) both talk about rebuilding the LSP/LSA (self-lsp/lsa) on an adjacency down/Ckt_down event. yet, many vendors choose not do this...the rationale being that frequent link flapping would result in LSP/LSA storms...but then, not rebuilding one's link-state can cause blackholes just on an adjacency down event. Is there anything among the existing documents that deals with bridging the gap between not wanting to LSP Storm and not wanting blackholes...(say something like BGP dampening). TIA anand -----Original Message----- From: Danny McPherson [mailto:danny@ambernetworks.com] Sent: Wednesday, July 18, 2001 10:58 AM To: isis-wg@juniper.net Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt Folks, the only update in this version is the addition of some text surrounding handling of "stale" LSPs. Thanks to Stefano for pointing this out. -danny > 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 Transient Blackhole Avoidance > Author(s) : D. McPherson > Filename : draft-ietf-isis-transient-01.txt > Pages : 6 > Date : 17-Jul-01 > > This document describes a simple, interoperable mechanism that can be > employed in IS-IS networks in order to decrease data loss associated > with deterministic blackholing of packets during transient network > conditions. The mechanism proposed here requires no IS-IS protocol > changes and is completely interoperable with the existing IS-IS > specification. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-01.txt > > 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-transient-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-transient-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. > > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From prz@redback.com Thu Jul 19 01:08:34 2001 From: prz@redback.com (Tony Przygienda) Date: Wed, 18 Jul 2001 17:08:34 -0700 Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt References: <9F4704BE89F7D4118A0F0002B328C36C084CF4@usa04.ambernetworks.com> Message-ID: <3B562502.655829C7@redback.com> Anand Ammundi wrote: > Hi > I had a question on the IS-IS black-holing subject. > IS-IS (and OSPF rfc's) both talk about rebuilding the LSP/LSA > (self-lsp/lsa) > on an adjacency down/Ckt_down event. yet, many vendors > choose not do this...the rationale being that frequent link flapping would > result in LSP/LSA storms...but then, not rebuilding one's link-state > can cause blackholes just on an adjacency down event. Is there anything > among > the existing documents that deals with bridging the gap between not wanting > > to LSP Storm and not wanting blackholes...(say something like BGP > dampening). this is somehow an implementation question so I answer with my personal preference here: I always found that dampening @ protocol level is an inferior solution (BGP is a different case, they dampen prefixes not link flaps!) and it's much better solved closer to the hardware since that can affect many other components beside a single protocol. E.g. dampening @ hardware level (for things like broken fiber 'blinking' and on top of that putting a hysterisis on top of the device driver) has proven much better for me ... -- tony From sachidananda_k@hotmail.com Wed Jul 18 08:05:41 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Wed, 18 Jul 2001 07:05:41 -0000 Subject: [Isis-wg] Doubts regarding encapsulation. Message-ID: Hello, I'm a student studying the networking and routing concepts. My doubts are related to the packet formats used for IS-IS PDUs. I had also gone through the RFC 1142 and RFC 1195 for the same. Having gone through the 2 RFCs I am confused as to whether the IS-IS PDUs are encapsulated within the IP datagram or are they encapsulated using CLNP header. If anyone could please tell me as to how does the IS-IS PDU looks like in the physical media (let me be specific to say in ethernet frame). I shall be obliged to get any response on this issue. Thanking you in advance for all the early replies that I get. Sachi _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From jlearman@cisco.com Thu Jul 19 03:36:03 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 18 Jul 2001 22:36:03 -0400 Subject: [Isis-wg] Doubts regarding encapsulation. References: Message-ID: <009c01c10ffb$9bc6f5c0$8c02530a@sevsisters> IS-IS PDUs are sent directly over the link layer. For example, on Ethernet, the format is 802.3 MAC header: 6-byte dest MAC address 6-byte src MAC address 2-byte length LLC header: FE (dest LSAP = OSI) FE (src LSAP = OSI) 03 (I frame) IS-IS stuff: 84 (IS-IS NLPID) ... The exceptions to this are (a) partition repair uses IS-IS / CLNP tunnels, but ignore that because it doesn't work (it'll be fixed in next IS-IS version), and (b) there was a draft RFC for IS-IS in IP encapsulation, but that was not popular and I don't recommend it. Jeff ----- Original Message ----- From: Sachidananda K To: Sent: Wednesday, July 18, 2001 3:05 AM Subject: [Isis-wg] Doubts regarding encapsulation. > Hello, > > I'm a student studying the networking and routing concepts. My doubts are > related to the packet formats used for IS-IS PDUs. I had also gone through > the RFC 1142 and RFC 1195 for the same. Having gone through the 2 RFCs I am > confused as to whether the IS-IS PDUs are encapsulated within the IP > datagram or are they encapsulated using CLNP header. If anyone could please > tell me as to how does the IS-IS PDU looks like in the physical media (let > me be specific to say in ethernet frame). > I shall be obliged to get any response on this issue. > > Thanking you in advance for all the early replies that I get. > Sachi > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Rajesh Hegde" This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C11046.B7990AE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Following are the doubts regarding the usage of size of LSP mtu By having default size of 1497 bytes works for most of the data link = types. Ex : Ethernet, FrameRelay and Serial Links where the size of the = DataLink BlockSize is 1500 bytes.=20 =20 1 ) How it should be handled If the datalink type is POS where the = default DataLinkBlockSize is 512 bytes ? 2) How the negotiation of the Hello PDUs to be done in case of FDDI and = Gigabit ethernet where the DataLinkBlockSize is greater than the default = size of 1497 bytes ? (i.e Do we pad the Hello PDU to the size of DataLink Block Size or = increase the LSP MTU size ? )=20 =20 3) Shall the parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp = mtu and level 2 lsp-mtu) be made configurable ? Suppose a router with 3 interfaces 1 ethernet(Link Mtu 1500 bytes), 1 = Gigabit ethernet (Link MTU is 9180 bytes), 1 POS interface (link MTU 512 = bytes ) In this case how to decide the size of the LSP-mtu ? Thanks and Regards, Rajesh ------=_NextPart_000_0038_01C11046.B7990AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Following are the doubts regarding = the usage=20 of size of LSP mtu
 
By having default size of 1497 bytes = works for most=20 of the data link types. Ex : Ethernet, FrameRelay and Serial Links where = the=20 size of the DataLink BlockSize is 1500 bytes.
 
1 )  How it should be handled If = the datalink=20 type is POS where the default DataLinkBlockSize is     = 512 bytes=20 ?
 
2) How the negotiation of the Hello = PDUs to be done=20 in case of FDDI and Gigabit ethernet where the DataLinkBlockSize is = greater than=20 the default size of 1497 bytes ?
(i.e Do we pad the Hello PDU to the = size of=20 DataLink Block Size or increase the LSP MTU size ? ) 
 
3) Shall the=20 parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp mtu and = level 2=20 lsp-mtu) be made configurable ?
 
Suppose a router with 3 interfaces 1 = ethernet(Link=20 Mtu 1500 bytes), 1 Gigabit ethernet (Link MTU is 9180 bytes), 1 POS = interface (link MTU 512 bytes )
 
In this case how to decide the size of = the LSP-mtu=20 ?
 
Thanks and Regards,
Rajesh
 
 
 
 
------=_NextPart_000_0038_01C11046.B7990AE0-- From ginsberg@pluris.com Thu Jul 19 04:45:40 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 18 Jul 2001 20:45:40 -0700 Subject: [Isis-wg] Isis-wg] - Regarding IS-IS LSP mtu size Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A529@avalon.pluris.com> > Hi all, > > Following are the doubts regarding the usage of size of LSP mtu > > By having default size of 1497 bytes works for most of the data link types. Ex : > Ethernet, FrameRelay and Serial Links where the size of the DataLink BlockSize is 1500 > bytes. > > 1 ) How it should be handled If the datalink type is POS where the default > DataLinkBlockSize is 512 bytes ? > The LSP MTU size must be <= to the smallest DataLinkBlockSize(MTU) of any subnetwork over which LSPs are to be propagated. Therefore, if you have even one link with an MTU of 512 over which LSPs will be propagated, then LSP MTU cannot be set larger than 512 in any router in the area/domain. > 2) How the negotiation of the Hello PDUs to be done in case of FDDI and Gigabit > ethernet where the DataLinkBlockSize is greater than the default size of 1497 bytes ? > (i.e Do we pad the Hello PDU to the size of DataLink Block Size or increase the LSP MTU > size ? ) > ISO 10589 is very clear about this. Padding is to the maximum of: o dataLinkBlockSize o originatingL1LSPBufferSize (If L1 routing supported) o originatingL2LSPBUfferSize (If L2 routing supported) See 8.2.3.c and 8.4.2. Setting of the LSP MTU is based NOT upon the dataLinkBlockSize of an individual link but upon the minimum MTU of all links over which LSPs are to be propagated. Since there is no way for the protocol to know this, it is up to the network administartor to configure it correctly and consistently on all routers in the area/domain. > 3) Shall the parameters L1LSPBufferSize and L2LSPBufferSize (Level 1 lsp mtu and level > 2 lsp-mtu) be made configurable ? > They are configurable. ISO 10589 specifies a range of 512-1492. > Suppose a router with 3 interfaces 1 ethernet(Link Mtu 1500 bytes), 1 Gigabit ethernet > (Link MTU is 9180 bytes), 1 POS interface (link MTU 512 bytes ) > >In this case how to decide the size of the LSP-mtu ? > LSP MTU must be 512 in this case. You may also find the SIF work on this subject of interest: ftp://ftp.juniper.net/pub/isis/lspsize.PDF Apart from the change of the TLVs from 12/13 to a single value of 14, the SIF work as written has been incorporated in the upcoming revision 2 of ISO 10589. > Thanks and Regards, > Rajesh Les From omer@cwnt.com Thu Jul 19 13:02:31 2001 From: omer@cwnt.com (Omer Sali) Date: Thu, 19 Jul 2001 15:02:31 +0300 Subject: [Isis-wg] draft-ietf-isis-auth-anti-replay-00.txt Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C1104A.B07A648C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C1104A.B07A648C" ------_=_NextPart_002_01C1104A.B07A648C Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, =20 What is the status of draft-ietf-isis-auth-anti-replay-00.txt? Is it going to be a WG item? =20 Thanks, Omer =20 ------_=_NextPart_002_01C1104A.B07A648C Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Pie Charts
Hi,
 
What is the=20 status of draft-ietf-isis-auth-anti-replay-00.txt? Is it going to be a = WG=20 item?
 
Thanks,
Omer
 
------_=_NextPart_002_01C1104A.B07A648C-- ------_=_NextPart_001_01C1104A.B07A648C Content-Type: image/jpeg; name="Pie Charts Bkgrd.JPG" Content-Transfer-Encoding: base64 Content-ID: <628510112@19072001-0f30> Content-Description: Pie Charts Bkgrd.JPG Content-Location: Pie%20Charts%20Bkgrd.JPG /9j/4AAQSkZJRgABAgEASABIAAD/7QYsUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA SAAAAAAC2AIo/+H/4gL5AkYDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////// //8D6AAAOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAEOAAAAAEAAACAAAAA gAAAAYAAAMAAAAAEHAAYAAH/2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkg QWRvYmUgUGhvdG9zaG9wqCA0LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsR FQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0Q Dg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM /8AAEQgAgACAAwEiAAIRAQMRAf/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkK CwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEF QVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKz hMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAME BQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcm NcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eH l6e3x//aAAwDAQACEQMRAD8A7VRTpdlYaqydMnSUukkkgpYpoUgkeElLJJJiipeU0JBOkpinSTlJ SydMnSKn/9DtYShOlCsNVaE0KSUJKYBOpQEiBCClgE5CQScdElKhRI5TymJRUsAnhIJwElLQlCeE ohJS21KEpUhwgVP/0e1TymTKw1WUFNBTSUpKSlEpxqo6lIGOUlM0xTSTwn1hJCySSWiSlJ0yQJSU zSUdQnB0QSojRRlPJShJT//S7VN3SSVhqqckOCnA8UxBSUoGFEqUFLakpiFKUtqRaUkLSmJT7SnD SkpYKQCbaU405SUolMEk6CVJkk6Sn//T7aEoSlKVO1VcJJinCSlinTFP2SUpJKUikpSSZOElKTO+ iU6XKSmNcnlShKAOEphJSiE0J0pSU//U7RJSTHhTtVUpSozrCc8fFJS/KZICE5MhJSwKdNwkDKSF 006pSlKSlElKUkklKlKUk0pKZSlKjPknCSn/1e1SPCeUo0U7VYgd0uU44TgQkpjCUKSaSkpYhNwp gApbQUkMUoUi0BMElLQnhOlKSmJCUKSUJJpjCcBJOCUlP//W7baAmnskCPBMXawp6ai4Tpk6VKUk AoEkHRSBMSkplwmlNJKXKSl5SCUJJKUkkkkpSdNKUlKk2opBJRKVKt//2ThCSU0EBgAAAAAABwAB AAAAAQEA//4AJ0ZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3CoIDQuMAD/7gAOQWRvYmUA ZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCABDAEMDASIAAhEBAxEB/90ABAAF/8QBPwAA AQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQ AAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw 4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIj wVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDuuUylCUKozLJRKQaU 4CSFk0zopaQmA5SStGqSePJKAkpZJPtSSQ//0O7mEpHimKXeeyqMyp1TyOFHtCQkJKXS+KaUh5oK ZAhIx80x8EkUKkpJapJKf//R7uAl5JtUpVRlX7pJgZ1CQKSl9EkyW4pKUAZM8dk5ATbilKSl4STS kkp//9Lu9VED8VLjzSCqMq0FMQVLlPxokphynAKcmUkFLEFNCkkUaUqCklokkp//0+7P0e6S+b0l TZn6O/PTr5wSSQ/SCS+b0kVP0gkvm9JBL9HpL5wSSU//2Q== ------_=_NextPart_001_01C1104A.B07A648C-- From jparker@axiowave.com Thu Jul 19 15:20:46 2001 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 19 Jul 2001 10:20:46 -0400 Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt Message-ID: Anand - My understanding on this, as we tried to capture in the I-D below, is that it is crucial to react quickly to down event. This is what prevents black holes. The damping should occur on up-events. If a link has been flapping, the rest of the world will see it as down. If done this way, damping might allow an up link to be thought of as down by those that are not adjacent, but should not allow a down link to be thought of as up. The ID is not currently a work group item, but tries to gather some recommendations in one place. http://search.ietf.org/internet-drafts/draft-parker-short-isis-hold-times-00 .txt - jeff parker - Axiowave Networks > Hi > I had a question on the IS-IS black-holing subject. > IS-IS (and OSPF rfc's) both talk about rebuilding the LSP/LSA > (self-lsp/lsa) > on an adjacency down/Ckt_down event. yet, many vendors > choose not do this...the rationale being that frequent link > flapping would > result in LSP/LSA storms...but then, not rebuilding one's link-state > can cause blackholes just on an adjacency down event. Is > there anything > among > the existing documents that deals with bridging the gap > between not wanting > > to LSP Storm and not wanting blackholes...(say something like BGP > dampening). > TIA > anand > > -----Original Message----- > From: Danny McPherson [mailto:danny@ambernetworks.com] > Sent: Wednesday, July 18, 2001 10:58 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-transient-01.txt > > > > Folks, the only update in this version is the addition of some > text surrounding handling of "stale" LSPs. Thanks to Stefano > for pointing this out. > > -danny > > > 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 Transient Blackhole Avoidance > > Author(s) : D. McPherson > > Filename : draft-ietf-isis-transient-01.txt > > Pages : 6 > > Date : 17-Jul-01 > > > > This document describes a simple, interoperable mechanism > that can be > > employed in IS-IS networks in order to decrease data loss associated > > with deterministic blackholing of packets during transient network > > conditions. The mechanism proposed here requires no IS-IS protocol > > changes and is completely interoperable with the existing IS-IS > > specification. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-01.txt > > > > 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-transient-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-transient-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. > > > > > > > > > > > > > > > _______________________________________________ > 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 amudha@future.futsoft.com Fri Jul 20 13:53:00 2001 From: amudha@future.futsoft.com (Amudhavalli Narayanan) Date: Fri, 20 Jul 2001 18:23:00 +0530 Subject: [Isis-wg] Help needed for ISIS error message in Cisco router Message-ID: <000601c1111a$e88867c0$0705a8c0@future.futsoft.com> Hi, We are trying an interoperability testing with Cisco. I get the following error message in Cisco router when it receives packets from the router under test "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length invalid from 2101:0102:0304 (Ethernet 1/0). It would be of great help, if someone can throw some light on this error message. Thanks, Amudha From jhall@UU.NET Fri Jul 20 13:59:10 2001 From: jhall@UU.NET (Jeremy Hall) Date: Fri, 20 Jul 2001 08:59:10 -0400 (EDT) Subject: [Isis-wg] Help needed for ISIS error message in Cisco router In-Reply-To: <000601c1111a$e88867c0$0705a8c0@future.futsoft.com> from Amudhavalli Narayanan at "Jul 20, 2001 06:23:00 pm" Message-ID: GOOD! it seems MTU checking works. ISIS wants the MTU on all interfaces to be the same so it can ensure that packets on a LAN are not dropped. IT means some device is reporting the MTU of 1497 rather than 1500. _J In the new year, Amudhavalli Narayanan wrote: > Hi, > We are trying an interoperability testing with Cisco. I get the following > error message in Cisco router when it receives packets from the router under > test > "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length > invalid from 2101:0102:0304 (Ethernet 1/0). > > It would be of great help, if someone can throw some light on this error > message. > > Thanks, > Amudha > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From henk@Procket.com Fri Jul 20 14:29:13 2001 From: henk@Procket.com (Henk Smit) Date: Fri, 20 Jul 2001 06:29:13 -0700 (PDT) Subject: [Isis-wg] Help needed for ISIS error message in Cisco router In-Reply-To: from "Jeremy Hall" at Jul 20, 2001 08:59:10 AM Message-ID: <200107201329.GAA25651@redcs4.procket.com> > GOOD! it seems MTU checking works. I am not sure what you mean by this. But ISIS implementations should *not* explicitely check the size of incoming hellos to see if they are exactly MTU size. If there is a problem with the reception of packet because of the size, that should be detected via indirect ways. Example, if one router sends hellos that are so big that the interface driver of the other router can not receive them, then of course the ISIS process will never receive the packet either. > ISIS wants the MTU on all interfaces to be the same so it can ensure that > packets on a LAN are not dropped. Huh ? All interfaces of an ISIS router can be configured with a different MTU size. No problem. As long as: 1) all the other routers on those interfaces have matching MTUs configured 2) the MTUs are not smaller than MaxLSPBuffersize (which is typically 1492) > IT means some device is reporting the > MTU of 1497 rather than 1500. > > "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length > > invalid from 2101:0102:0304 (Ethernet 1/0). Inside the ethernetheader there is a length field. The device your are testing has put value 1497 in there. This seems to be a correct value. 14 bytes ethernet header, 4 bytes CRC, and 3 bytes 802.2 header leave 1497 bytes available from the 1518 bytes in an ethernet frame. Inside the ISIS packets there is a length field too. The device you are testing has put value 1500 in there. This seems wrong. No way you can fit 1500 bytes inside 1497 bytes. Questions like these should typically be directed to the appropriate vendor's support channel (tac@cisco.com). Hope this helps, henk. > _J > > In the new year, Amudhavalli Narayanan wrote: > > Hi, > > We are trying an interoperability testing with Cisco. I get the following > > error message in Cisco router when it receives packets from the router under > > test > > "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length > > invalid from 2101:0102:0304 (Ethernet 1/0). > > > > It would be of great help, if someone can throw some light on this error > > message. > > > > Thanks, > > Amudha > > > > _______________________________________________ > > 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 Anand@ambernetworks.com Fri Jul 20 19:08:43 2001 From: Anand@ambernetworks.com (Anand Ammundi) Date: Fri, 20 Jul 2001 11:08:43 -0700 Subject: [Isis-wg] Help needed for ISIS error message in Cisco router Message-ID: <9F4704BE89F7D4118A0F0002B328C36C084D06@usa04.ambernetworks.com> Amudha, it might be a bug on your box. basically it is a mismatch between the peers in terms of ethernet 2 and 802.3. ISIS is supported over 802.3. Depending on the value of the type/len field one decides if it is ethernet 2 (type > 1500) or 802.3 (len < 1500) since ethernet 2 type's are always > 1500. since on the cisco the packet has come up as high as IS-IS (judging from the LAN Hello specific error), it has been assumed to be 802.3...so if you have sent it as ethernet 2, you might see this error. thanx anand -----Original Message----- From: Amudhavalli Narayanan [mailto:amudha@future.futsoft.com] Sent: Friday, July 20, 2001 5:53 AM To: isis-wg@juniper.net Subject: [Isis-wg] Help needed for ISIS error message in Cisco router Hi, We are trying an interoperability testing with Cisco. I get the following error message in Cisco router when it receives packets from the router under test "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length invalid from 2101:0102:0304 (Ethernet 1/0). It would be of great help, if someone can throw some light on this error message. Thanks, Amudha _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From henk@Procket.com Fri Jul 20 20:31:09 2001 From: henk@Procket.com (Henk Smit) Date: Fri, 20 Jul 2001 12:31:09 -0700 (PDT) Subject: [Isis-wg] Help needed for ISIS error message in Cisco router In-Reply-To: <9F4704BE89F7D4118A0F0002B328C36C084D06@usa04.ambernetworks.com> from "Anand Ammundi" at Jul 20, 2001 11:08:43 AM Message-ID: <200107201931.MAA14391@redcs4.procket.com> The boundary between length and type encapsulation is not exactly at 1500 bytes. It is somewhere at 1600 or maybe 2000 bytes. (Can't remember). So it is very unlikely that in this case the receiving router is confused about the encapsulation. Also the error message says that the length value inside the ethernet header was 1497 (wire length). So this packet has definitely not been sent using length encapsulation. The error is that the ISIS stack that sent this packet has put the wrong value in the isisheader->packetlength field. henk. > Amudha, > it might be a bug on your box. basically it is a mismatch > between the peers in terms of ethernet 2 and 802.3. > ISIS is supported over 802.3. Depending on the value of the > type/len field one decides if it is ethernet 2 (type > 1500) > or 802.3 (len < 1500) since ethernet 2 type's are always > 1500. > since on the cisco the packet has come up as high as IS-IS (judging > from the LAN Hello specific error), it has been assumed to be > 802.3...so if you have sent it as ethernet 2, you might see this > error. > thanx > anand > > -----Original Message----- > From: Amudhavalli Narayanan [mailto:amudha@future.futsoft.com] > Sent: Friday, July 20, 2001 5:53 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Help needed for ISIS error message in Cisco router > > > Hi, > We are trying an interoperability testing with Cisco. I get the following > error message in Cisco router when it receives packets from the router under > test > "%CLNS-3-BADPACKET: ISIS: LAN L1 hello, Packet(1500) or wire(1497) Length > invalid from 2101:0102:0304 (Ethernet 1/0). > > It would be of great help, if someone can throw some light on this error > message. > > Thanks, > Amudha > > _______________________________________________ > 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 omer@cwnt.com Sun Jul 22 10:26:31 2001 From: omer@cwnt.com (Omer Sali) Date: Sun, 22 Jul 2001 12:26:31 +0300 Subject: FW: [Isis-wg] draft-ietf-isis-auth-anti-replay-00.txt Message-ID: Hi, I resend my question, this time in plain text format and not HTML format. What is the status of draft-ietf-isis-auth-anti-replay-00.txt? Is it going to be a WG item? Thanks, Omer From Alex Zinin Mon Jul 23 11:42:25 2001 From: Alex Zinin (Alex Zinin) Date: Mon, 23 Jul 2001 03:42:25 -0700 Subject: FW: [Isis-wg] draft-ietf-isis-auth-anti-replay-00.txt In-Reply-To: References: Message-ID: <85191583422.20010723034225@nexsi.com> Omer, I was going to get the next version of the doc (intergrating the comments from the WG) prepared before London. We could discuss this topic there and the chairs would decide whether it should be a WG item or not. -- Alex Zinin Sunday, July 22, 2001, 2:26:31 AM, Omer Sali wrote: > Hi, > I resend my question, this time in plain text format and not HTML > format. > What is the status of draft-ietf-isis-auth-anti-replay-00.txt? Is it > going to be a WG item? > Thanks, > Omer > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From oran@cisco.com Mon Jul 23 19:03:35 2001 From: oran@cisco.com (David R. Oran) Date: Mon, 23 Jul 2001 14:03:35 -0400 Subject: [Isis-wg] FYI: small draft with TLV numbers ... In-Reply-To: <4.3.2.7.2.20010717191951.00b9af88@jaws.cisco.com> Message-ID: <020f01c113a1$cda46510$22ee2ca1@cisco.com> > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net] On Behalf Of mike shand > Sent: Tuesday, July 17, 2001 2:21 PM > To: Tony Przygienda > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] FYI: small draft with TLV numbers ... > > > You missed 42. DECnet PhaseIV :-) > As I recall, that particular value was chosen with care too! > But this is a VERY good idea. Thanks. > > Mike > > At 10:20 17/07/2001 -0700, Tony Przygienda wrote: > >Put a small draft together to prevent TLV conflicts, would > appreciate > >if the word spreads to SIF and OSI so we have a place people > can check > >before steping on each others' toes. > >If missed something or inexact, pls let me know and will > correct and put > >updated version > >out ... > > > > thansk > > > > - tony > > > > > > > > > >Internet Engineering Task Force T. > >Przygienda > >INTERNET DRAFT > >Redback > > > >July 2001 > > 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 Jan 2002 > >[Page 1] > > > >Internet Draft TLV Codepoints > >July 2001 > > > >1. TLV Codepoints reserved > > ___________________________________________________________ > > Name Value IIH LSP SNP Status > > > > ___________________________________________________________ > > > > Area Addresses 1 y y n RFC > > IIS Neighbors 2 n y n RFC > > ES Neighbors 3 n y n RFC > > Part. DIS 4 n y n RFC > > Prefix Neighbors 5 n y n RFC > > IIS Neighbors 6 y n n RFC > > Padding 8 y n n RFC > > LSP Entries 9 n n y RFC > > Authentication 10 y y y IETF-draft > > Opt. Checksum 12 y n y IETF-draft > > LSPBufferSize 14 y? y n SIF-draft > > TE IIS Neigh. 22 n y n IETF-draft > > MT-ISN 222 n y n IETF-draft > > IP Int. Reach 128 n y n RFC > > Prot. Supported 129 y y n RFC > > M-Topologies 229 y y n IETF-draft > > IP Ext. Address 130 n y n RFC > > IDRPI 131 n y y RFC > > IP Intf. Address 132 y y n RFC > > IPv6 Intf. Addr. 232 y y n IETF-draft > > illegal 133 n n n ? > > Router ID 134 n y n IETF-draft > > TE IP. Reach 135 n y n IETF-draft > > MT IP. Reach 235 n y n IETF-draft > > IPv6 IP. Reach 236 n y n IETF-draft > > Dynamic Name 137 n y n RFC > > 3-Way hellos 240 y n n RFC > > > > > > > >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 > > > > 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, > > > > > > > >Przygienda Expires Jan 2002 > >[Page 2] > > > >Internet Draft TLV Codepoints > >July 2001 > > > > no plausible central authority to assign TLV numbers > exists as of > > today. > > > > > > > >3. Acknowledgments > > > >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. > > > > > > > >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, > >Przygienda Expires Jan 2002 > >[Page 3] > > > >Internet Draft TLV Codepoints > >July 2001 > > > > 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 Jan 2002 > >[Page 4] > > > > > >_______________________________________________ > >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/i> sis-wg > From prz@redback.com Mon Jul 23 22:55:02 2001 From: prz@redback.com (Tony Przygienda) Date: Mon, 23 Jul 2001 14:55:02 -0700 Subject: [Isis-wg] agenda ... Message-ID: <3B5C9D35.6B9B6BF@redback.com> Didn't see the slot yet but we better start on the agenda items, mails to me pls --- tony From randy@psg.com Mon Jul 23 23:38:37 2001 From: randy@psg.com (Randy Bush) Date: Mon, 23 Jul 2001 15:38:37 -0700 Subject: [Isis-wg] agenda ... References: <3B5C9D35.6B9B6BF@redback.com> Message-ID: > Didn't see the slot yet wed 09:00-11:30 randy From Internet-Drafts@ietf.org Tue Jul 24 11:29:25 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 24 Jul 2001 06:29:25 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-tlv-codepoints-00.txt Message-ID: <200107241029.GAA05870@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-00.txt Pages : Date : 23-Jul-01 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-00.txt 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-00.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-00.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: <20010723140425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-tlv-codepoints-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140425.I-D@ietf.org> --OtherAccess-- --NextPart-- From jparker@axiowave.com Tue Jul 24 14:43:17 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 24 Jul 2001 09:43:17 -0400 Subject: [Isis-wg] RE: ISIS over NBMA Message-ID: I will try the third question > 3) In RFC-2973, ISIS Mesh Groups (page#4), > How the numbered mesh groups are connected by "transit circuits" > Let's consider a full-mesh topology with three routers A, B, C is divided in to two mesh groups 1 & 2 (full-mesh) > mesh group 1: A and B > mesh group 2: B and C > here B is the transit router whose both interfaces are 'meshset' > and if the interface link between A and C is 'meshblocked' > then where comes the transit interface ? > any response in this regard would be of great helpful > thanks in advance, > lakshminarayan r You assume a full mesh of three routers. The routers themselves are not in mesh groups: the circuits are. It is easy to configure mesh groups on the network below so it is not connected. One way to configure it so that it is connected would be to meshblock circuits v and x, and to put the circuits w and y in different mesh groups. This configuration is brittle: breaking either link AB or BC will disconnect the network, as link AC does not carry LSPs. A u v / \ / \ w x B y ----- z C There are more examples in the RFC to check out: mesh groups become more interesting as N gets much bigger than 3. In the example above, if there is any router that uses mesh groups to reduce flooding, then we can break a single link and break flooding. If there are 4 routers in a full mesh, it is possible to reduce flooding without risking disconnection through a single link failure. - jeff parker - axiowave networks From Lakshminarayanan Rajamanickam" This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C11469.5305DFA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi,=20 1) How the ISIS treats NBMA networks? as a multi-access network or as a = collection of point-to-point links or both ? 2) If the NBMA network is considered as a collection of logical p2p = sub-interfaces (s0.1, s0.2, s0.3, ....) only then, how the PDUs are exchanged over a physical interface(s0). In this case = ISIS PDUs are need to be processed similar=20 to point-to-point links ? or any parent-child relationship needs to be = maintained between the sub-interfaces and=20 the physical interface to track ? 3) In RFC-2973, ISIS Mesh Groups (page#4),=20 How the numbered mesh groups are connected by "transit circuits"=20 Let's consider a full-mesh topology with three routers A, B, C is = divided in to two mesh groups 1 & 2 (full-mesh) mesh group 1: A and B mesh group 2: B and C here B is the transit router whose both interfaces are 'meshset' and if the interface link between A and C is 'meshblocked' then where comes the transit interface ? any response in this regard would be of great helpful=20 thanks in advance, lakshminarayan r ------=_NextPart_000_0016_01C11469.5305DFA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
 
1) How the ISIS treats NBMA = networks? as=20 a multi-access network or as a collection of point-to-point links or = both=20 ?
 
2) If the NBMA network is considered as = a=20 collection of logical p2p sub-interfaces (s0.1, s0.2, s0.3, ....) only=20 then,
how the PDUs are exchanged over a = physical=20 interface(s0). In this case ISIS PDUs = are need to=20 be processed similar
to point-to-point links ? or any = parent-child=20 relationship needs to be maintained between the sub-interfaces and =
the physical interface to track = ?
 
3) In RFC-2973, ISIS Mesh Groups = (page#4),=20
How the numbered mesh groups are = connected by=20 "transit circuits"
 
Let's consider a full-mesh = topology with=20 three routers A, B, C is divided in to two mesh groups 1 & 2=20 (full-mesh)
 
mesh group 1: A and B
mesh group 2: B and C
 
here B is the transit router whose=20 both interfaces are 'meshset'
and if the interface link between A and = C is=20 'meshblocked'
then where comes the transit interface=20 ?
 
any response in this regard would be of = great=20 helpful 
 
thanks in advance,
lakshminarayan r
 
------=_NextPart_000_0016_01C11469.5305DFA0-- From prz@redback.com Thu Jul 26 19:13:35 2001 From: prz@redback.com (Tony Przygienda) Date: Thu, 26 Jul 2001 11:13:35 -0700 Subject: [Isis-wg] draft-ietf-isis-transient last call recall (total recall ? ;-) Message-ID: <3B605DCE.A3C8EBA5@redback.com> draft-ietf-isis-transient-01.txt underwent a change significant enough to justify another 2 weeks period till 8/12 for a last call. Comments pls to the list. From what I saw it's really just one paragraph but anyone who read -00 and cared will be easily able to figure out where it is ... Comment here (not sure it deserves inclusion since it's a tad of a hair-split): Seems to me seeting the OVLD bit and setting all outgoing links to inf (as described in alternative) is NOT entirely the same thing if traffic _originates_ @ the very router or a directly attached subnet. When OVLD bit is set, the router should be able to forward to the rest of the network, if all its outgoing links are (true) infinity, it will not since it sees the network unreachable. Leaving one link smaller than inf solves the problem partially but there is no guarantee the whole network can be reached by that very link. This observation may be significant for I-BGP session origination on this very router unless I missed something here. -- tony =================================================== Network Working Group Danny McPherson INTERNET DRAFT Amber Networks, Inc. July 2001 IS-IS Transient Blackhole Avoidance 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. 2. Abstract This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. McPherson, D. [Page 1] INTERNET DRAFT July 2001 3. Introduction When an IS-IS router that was previously a transit router becomes unavailable as a result of some transient condition such as a reboot, other routers within the routing domain must select an alternative path to reach destinations which had previously transited the failed router. Presumably, the newly selected router(s) comprising the path have been available for some time and, as a result, have complete forwarding information bases (FIBs) which contain a full set of reachability information for both internal and external (e.g., BGP) destination networks. When the previously failed router becomes available again, in only a few seconds paths that had previously transited the router are again selected as the optimal path by the IGP. As a result, forwarding tables are updated and packets are once again forwarded along the path. Unfortunately, external destination reachability information (e.g., learned via BGP) is not yet available to the router, and as a result, packets bound for destinations not learned via the IGP are unnecessarily discarded. A simple interoperable mechanism to alleviate the offshoot associated with this deterministic behavior is discussed below. 4. Discussion This document describes a simple, interoperable mechanism that can be employed in IS-IS [1, 2] networks in order to avoid transition to a newly available path until other associated routing protocols such as BGP have had sufficient time to converge. The benefits of such a mechanism can realized when considering the following scenario depicted in Figure 1. McPherson, D. [Page 2] INTERNET DRAFT July 2001 D.1 | +-------+ | RtrD | +-------+ / \ / \ +-------+ +-------+ | RtrB | | RtrC | +-------+ +-------+ \ / \ / +-------+ | RtrA | +-------+ | S.1 Figure 1: Example Network Topology Host S.1 is transmitting data to destination D.1 via a primary path of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to destina­ tion D.1 via BGP from RtrD. RtrA's primary path to D.1 is selected because when calculating the path to BGP NEXT_HOP of RtrD the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less than the sum of the metrics of the RtrA-RtrC-RtrD path. Assume RtrB becomes unavailable and as a result the RtrC path to RtrD is used. Once RtrA's FIB is updated and it begins forwarding packets to RtrC everything should behave properly as RtrC has existing forwarding information regarding destination D.1's availability via BGP NEXT_HOP RtrD. Assume now that RtrB comes back online. In only a few seconds IS-IS neighbor state has been established with RtrA and RtrD and database syn­ chronization has occurred. RtrA now realizes that the best path to des­ tination D.1 is via RtrB, and therefore updates it FIB appropriately. RtrA begins to forward packets destined to D.1 to RtrB. Though, because RtrB has yet to establish and synchronization it's BGP neighbor rela­ tionship and routing information with RtrD, RtrB has no knowledge regarding reachability of destination D.1, and therefore discards the packets received from RtrA destined to D.1. If RtrB were to temporarily set it's LSP Overload bit while synchroniz­ ing BGP tables with it's neighbors, RtrA would continue to use the work­ ing RtrA->RtrC->RtrD path, and the LSP should only be used to obtain McPherson, D. [Page 3] INTERNET DRAFT July 2001 reachability to locally connected networks (rather than for calculating transit paths through the router, as defined in [1]). However, it should be noted that when RtrB goes away its LSP is still present in the IS-IS databases of all other routers in the routing domain. When RtrB comes back it establishes adjacencies. As soon as its neighbors have an adjacency with RtrB, they will advertise their new adjacency in their new LSP. The result is that all the other routers will receive new LSPs from RtrA and RtrD containing the RtrB adjacency, even though RtrB is still completing its synchronization and therefore has not yet sent it's new LSP yet. At this time SPF is computed and everyone will include RtrB in their tree since they will use the old version of RtrB LSP (the new one has not yet arrived). Once RtrB has finished establishing all its adjacen­ cies, it will then regenerate its LSP and flood it. Then all other routers within the domain will finally compute SPF with the correct information. Only at that time will the Overload bit be taken into account. As such, it is recommended that each time a router establishes an adja­ cency, it will update its LSP and flood it immediately, even before beginning database synchronization. This will allow for the Overload bit setting to propagate immediately, and remove the potential for an older version of the reloaded routers LSP to be used. After synchronization of BGP tables with neighboring routers (or expiry of some other timer or trigger), RtrB would generate a new LSP, clearing the Overload bit, and RtrA could again begin using the optimal path via RtrB. Typically, in service provider networks IBGP connections are done via peerings with 'loopback' addresses. As such, the newly available router must advertise it's own loopback (or similar) IP address, as well as associated adjacencies, in order to make the loopbacks accessible to other routers within the routing domain. It's because of this that sim­ ply flooding an empty LSP is not sufficient. McPherson, D. [Page 4] INTERNET DRAFT July 2001 5. Deployment Considerations Such a mechanism increases overall network availability and allows network operators to alleviate the deterministic blackholing behavior introduced in this scenario. Similar mechanisms [3] have been defined for OSPF, though only after realizing the usefulness obtained from that of the IS-IS Overload bit technique. This mechanism has been deployed in several large IS-IS networks for a number of years. Triggers for setting the Overload bit as described are left to the implementer. Some potential triggers could perhaps include "N sec­ onds after booting", or "N number of BGP prefixes in the BGP Loc- RIB". Unlike similar mechanisms employed in [3], if the Overload bit is set in a router's LSP, NO transit paths are calculated through the router. As such, if no alternative paths are available to the desti­ nation network, employing such a mechanism may actually have a nega­ tive impact on convergence (i.e., the router maintains the only available path to reach downstream routers, but the Overload bit dis­ allows other nodes in the network from calculating paths via the router, and as such, no feasible path exists to the routers). Finally, if all systems within an IS-IS routing domain haven't imple­ mented the Overload bit correctly, forwarding loops may occur. 6. Potential Alternatives Alternatively, it may be considered more appealing to employ some­ thing more akin to [3] for this purpose. With this model, during transient conditions a node advertises excessively high link metrics to serve as an indication to other nodes in the network that paths transiting the router are "less desirable" than existing paths. The advantage of a metric-based mechanism over the Overload bit mech­ anism proposed here model is that transit paths may still be calcu­ lated through the router. Another advantage is that a metric- based mechanism does not require that all nodes in the IS-IS domain cor­ rectly implement the Overload bit. However, as currently deployed, IS-IS provides for only 6 bits of space for link metric allocation, and 10 bits aggregate path metric. Though extensions proposed in [4] remove this limitation, they've not yet been widely deployed. As such, there's currently little flexi­ bility when using link metrics for this purpose. Of course, both McPherson, D. [Page 5] INTERNET DRAFT July 2001 methods proposed in this document are backwards-compatible. 7. Security Considerations The mechanisms specified in this memo introduces no new security issues to IS-IS. 8. Acknowledgements The author of this document makes no claim to the originality of the idea. Thanks to Stefano Previdi for valuable feedback on the mecha­ nism discussed in this document. 9. References [1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992. [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. [3] Retana et al., "OSPF Stub Router Advertisement", RFC 3137, June 2001. [4] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", Work in Progress. 10. Author's Address Danny McPherson Amber Networks, Inc. 48664 Milmont Drive Fremont, CA 94538 Email: danny@ambernetworks.com McPherson, D. [Page 6] From mbartell@cisco.com Fri Jul 27 23:42:16 2001 From: mbartell@cisco.com (Micah Bartell) Date: Fri, 27 Jul 2001 17:42:16 -0500 Subject: [Isis-wg] ISO 10589v2 Latest Revision Document Availability Message-ID: <4.3.2.7.2.20010727173855.0226c0e8@cactus.cisco.com> Folks, I have made the latest revision of ISO 10589v2 and the Disposition of Comments file available. They are both located at ftp.cisco.com/pub/rfc/ISO/ The file names are: ISO 10589v2: ISO10589v2-2001-07-04.pdf Comments: DoC-2001-07-04.pdf If anyone has any comments to make, I will be accepting comments for two weeks before beginning the process in the ISO to move forward toward FDIS. /mpb From Alex Zinin Sat Jul 28 11:06:49 2001 From: Alex Zinin (Alex Zinin) Date: Sat, 28 Jul 2001 03:06:49 -0700 Subject: [Isis-wg] draft-ietf-isis-transient last call recall (total recall ? ;-) In-Reply-To: <3B605DCE.A3C8EBA5@redback.com> References: <3B605DCE.A3C8EBA5@redback.com> Message-ID: <3041383065.20010728030649@nexsi.com> Tony, Regarding the infinity thing. The solution that was actually described in the initial version of the OSPF doc, but was then taken out is to originate two LSAs/LSPs---one for the LSDB and neighbors and one for yourself, which you do not install in the LSDB, but use for Dijkstra as the root vertex. The difference between the two is that the external version has infinite costs and the internal has real ones. Wrt the draft: Danny, fix the paragraphs! :) -- Alex Zinin Thursday, July 26, 2001, 11:13:35 AM, Tony Przygienda wrote: > draft-ietf-isis-transient-01.txt underwent a change significant > enough to justify another 2 weeks period till 8/12 > for a last call. Comments > pls to the list. From what I saw it's really just one paragraph but > anyone who read -00 and cared will be easily able to figure out > where it is ... > Comment here (not sure it deserves inclusion since it's a tad of a > hair-split): Seems to me seeting > the OVLD bit and setting all outgoing links to inf > (as described in alternative) is NOT entirely > the same thing if traffic _originates_ @ the very router or a directly > attached subnet. When OVLD bit > is set, the router should be able to forward to the rest of the > network, if all its outgoing links are (true) infinity, it will not > since it > sees the network unreachable. Leaving one link smaller than inf > solves the problem partially but there is no guarantee the whole > network can be reached by that very link. This observation may > be significant for I-BGP session origination on this very router > unless I missed something here. > -- tony > =================================================== > Network Working Group Danny McPherson > INTERNET DRAFT Amber Networks, Inc. > July 2001 > IS-IS Transient Blackhole Avoidance > > 1. Status of this Memo > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > 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. > 2. Abstract > This document describes a simple, interoperable mechanism that can be > employed in IS-IS networks in order to decrease data loss associated > with deterministic blackholing of packets during transient network > conditions. The mechanism proposed here requires no IS-IS protocol > changes and is completely interoperable with the existing IS-IS > specification. > McPherson, D. [Page 1] > INTERNET DRAFT July 2001 > 3. Introduction > When an IS-IS router that was previously a transit router becomes > unavailable as a result of some transient condition such as a reboot, > other routers within the routing domain must select an alternative > path to reach destinations which had previously transited the failed > router. Presumably, the newly selected router(s) comprising the path > have been available for some time and, as a result, have complete > forwarding information bases (FIBs) which contain a full set of > reachability information for both internal and external (e.g., BGP) > destination networks. > When the previously failed router becomes available again, in only a > few seconds paths that had previously transited the router are again > selected as the optimal path by the IGP. As a result, forwarding > tables are updated and packets are once again forwarded along the > path. Unfortunately, external destination reachability information > (e.g., learned via BGP) is not yet available to the router, and as a > result, packets bound for destinations not learned via the IGP are > unnecessarily discarded. > A simple interoperable mechanism to alleviate the offshoot associated > with this deterministic behavior is discussed below. > 4. Discussion > This document describes a simple, interoperable mechanism that can be > employed in IS-IS [1, 2] networks in order to avoid transition to a > newly available path until other associated routing protocols such as > BGP have had sufficient time to converge. > The benefits of such a mechanism can realized when considering the > following scenario depicted in Figure 1. > McPherson, D. [Page 2] > INTERNET DRAFT July 2001 > D.1 > | > +-------+ > | RtrD | > +-------+ > / \ > / \ > +-------+ +-------+ > | RtrB | | RtrC | > +-------+ +-------+ > \ / > \ / > +-------+ > | RtrA | > +-------+ > | > S.1 > Figure 1: Example Network Topology > Host S.1 is transmitting data to destination D.1 via a primary path of RtrA->>RtrB->RtrD. Routers A, B and C learn of reachability to destina­ > tion D.1 via BGP from RtrD. RtrA's primary path to D.1 is selected > because when calculating the path to BGP NEXT_HOP of RtrD the sum of the > IS-IS link metrics on the RtrA-RtrB-RtrD path is less than the sum of > the metrics of the RtrA-RtrC-RtrD path. > Assume RtrB becomes unavailable and as a result the RtrC path to RtrD is > used. Once RtrA's FIB is updated and it begins forwarding packets to > RtrC everything should behave properly as RtrC has existing forwarding > information regarding destination D.1's availability via BGP NEXT_HOP > RtrD. > Assume now that RtrB comes back online. In only a few seconds IS-IS > neighbor state has been established with RtrA and RtrD and database syn­ > chronization has occurred. RtrA now realizes that the best path to des­ > tination D.1 is via RtrB, and therefore updates it FIB appropriately. > RtrA begins to forward packets destined to D.1 to RtrB. Though, because > RtrB has yet to establish and synchronization it's BGP neighbor rela­ > tionship and routing information with RtrD, RtrB has no knowledge > regarding reachability of destination D.1, and therefore discards the > packets received from RtrA destined to D.1. > If RtrB were to temporarily set it's LSP Overload bit while synchroniz­ > ing BGP tables with it's neighbors, RtrA would continue to use the work­ ing RtrA->>RtrC->RtrD path, and the LSP should only be used to obtain > McPherson, D. [Page 3] > INTERNET DRAFT July 2001 > reachability to locally connected networks (rather than for calculating > transit paths through the router, as defined in [1]). > However, it should be noted that when RtrB goes away its LSP is still > present in the IS-IS databases of all other routers in the routing > domain. When RtrB comes back it establishes adjacencies. As soon as its > neighbors have an adjacency with RtrB, they will advertise their new > adjacency in their new LSP. The result is that all the other routers > will receive new LSPs from RtrA and RtrD containing the RtrB adjacency, > even though RtrB is still completing its synchronization and therefore > has not yet sent it's new LSP yet. > At this time SPF is computed and everyone will include RtrB in their > tree since they will use the old version of RtrB LSP (the new one has > not yet arrived). Once RtrB has finished establishing all its adjacen­ > cies, it will then regenerate its LSP and flood it. Then all other > routers within the domain will finally compute SPF with the correct > information. Only at that time will the Overload bit be taken into > account. > As such, it is recommended that each time a router establishes an adja­ > cency, it will update its LSP and flood it immediately, even before > beginning database synchronization. This will allow for the Overload bit > setting to propagate immediately, and remove the potential for an older > version of the reloaded routers LSP to be used. > After synchronization of BGP tables with neighboring routers (or expiry > of some other timer or trigger), RtrB would generate a new LSP, clearing > the Overload bit, and RtrA could again begin using the optimal path via > RtrB. > Typically, in service provider networks IBGP connections are done via > peerings with 'loopback' addresses. As such, the newly available router > must advertise it's own loopback (or similar) IP address, as well as > associated adjacencies, in order to make the loopbacks accessible to > other routers within the routing domain. It's because of this that sim­ > ply flooding an empty LSP is not sufficient. > McPherson, D. [Page 4] > INTERNET DRAFT July 2001 > 5. Deployment Considerations > Such a mechanism increases overall network availability and allows > network operators to alleviate the deterministic blackholing behavior > introduced in this scenario. Similar mechanisms [3] have been > defined for OSPF, though only after realizing the usefulness obtained > from that of the IS-IS Overload bit technique. > This mechanism has been deployed in several large IS-IS networks for > a number of years. > Triggers for setting the Overload bit as described are left to the > implementer. Some potential triggers could perhaps include "N sec­ > onds after booting", or "N number of BGP prefixes in the BGP Loc- > RIB". > Unlike similar mechanisms employed in [3], if the Overload bit is set > in a router's LSP, NO transit paths are calculated through the > router. As such, if no alternative paths are available to the desti­ > nation network, employing such a mechanism may actually have a nega­ > tive impact on convergence (i.e., the router maintains the only > available path to reach downstream routers, but the Overload bit dis­ > allows other nodes in the network from calculating paths via the > router, and as such, no feasible path exists to the routers). > Finally, if all systems within an IS-IS routing domain haven't imple­ > mented the Overload bit correctly, forwarding loops may occur. > 6. Potential Alternatives > Alternatively, it may be considered more appealing to employ some­ > thing more akin to [3] for this purpose. With this model, during > transient conditions a node advertises excessively high link metrics > to serve as an indication to other nodes in the network that paths > transiting the router are "less desirable" than existing paths. > The advantage of a metric-based mechanism over the Overload bit mech­ > anism proposed here model is that transit paths may still be calcu­ > lated through the router. Another advantage is that a metric- based > mechanism does not require that all nodes in the IS-IS domain cor­ > rectly implement the Overload bit. > However, as currently deployed, IS-IS provides for only 6 bits of > space for link metric allocation, and 10 bits aggregate path metric. > Though extensions proposed in [4] remove this limitation, they've not > yet been widely deployed. As such, there's currently little flexi­ > bility when using link metrics for this purpose. Of course, both > McPherson, D. [Page 5] > INTERNET DRAFT July 2001 > methods proposed in this document are backwards-compatible. > 7. Security Considerations > The mechanisms specified in this memo introduces no new security > issues to IS-IS. > 8. Acknowledgements > The author of this document makes no claim to the originality of the > idea. Thanks to Stefano Previdi for valuable feedback on the mecha­ > nism discussed in this document. > 9. References > [1] ISO, "Intermediate system to Intermediate system routeing > information exchange protocol for use in conjunction with the > Protocol for providing the Connectionless-mode Network Service > (ISO 8473)," ISO/IEC 10589:1992. > [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, > December 1990. > [3] Retana et al., "OSPF Stub Router Advertisement", RFC 3137, June > 2001. > [4] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", > Work in Progress. > 10. Author's Address > Danny McPherson > Amber Networks, Inc. > 48664 Milmont Drive > Fremont, CA 94538 > Email: danny@ambernetworks.com > McPherson, D. [Page 6] > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From sachidananda_k@hotmail.com Wed Jul 25 09:41:21 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Wed, 25 Jul 2001 08:41:21 +0000 Subject: [Isis-wg] IS-IS on IP v4 Message-ID: Sir, Thanks a lot for having clarified my doubt related to encapsulation. I have another question related to the IS-IS for IP V4. I had read through the RFC 1195 which defines TLVs for incorporating IP specific information into IS-IS PDUs. My Question: Do we exceute the SPF algorithm separately for OSI and IP. I understand that different forwarding database are maintained for IP and OSI reoutes. Like wise, do we also have different adjacency database for OSI and IP or is it one and the same for the 2 protocols. I don't know as to whether it is implementation specific aspect and the implementer is free to implement either way. Is there any standard rule for this. if so, could you please let me know about the same. I shall be obliged to get any response on this regards. Thanking you in advance for all the early replies that I get. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From Sivakumar A" --=_MAILER_ATTACH_BOUNDARY1_200172861539591983827549 Content-Type: text/plain; charset=us-ascii Hello all, Kindly clarify the following : In a broadcast circuit consider 2 Intermediate Systems having the same contents in their respective LSP databases. At every CSNP interval each needs to transmit CSNP with the set of LSPs in its database. Considering the number of LSPs in the database, there may be more than one CSNP required to be transmitted. If the number of LSPs in the database is more then more than one CSNP is required to be transmitted. In this case first CSNP contains only a portion of the LSPs in its database. If this CSNP is received by other Intermediate system, it sets the SRM flags for the LSPs which are not listed in the CSNP received. Kindly clarify this. Thanks and regards Sivakumar A Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_200172861539591983827549 Content-Type: text/html; charset=us-ascii

Hello all,

Kindly clarify the following :

In a broadcast circuit consider 2 Intermediate Systems having the same contents in their respective LSP databases. At every CSNP interval each needs to transmit CSNP with the set of LSPs in its database. Considering the number of LSPs in the database, there may be more than one CSNP required to be transmitted. If the number of LSPs in the database is more then more than one CSNP is required to be transmitted. In this case first CSNP contains only a portion of the LSPs in its database. If this CSNP is received by other Intermediate system, it sets the SRM flags for the LSPs which are not listed in the CSNP received. Kindly clarify this.

Thanks and regards

Sivakumar A

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com --=_MAILER_ATTACH_BOUNDARY1_200172861539591983827549-- From aravindravikumar@yahoo.com Sun Jul 29 13:00:16 2001 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Sun, 29 Jul 2001 05:00:16 -0700 (PDT) Subject: [Isis-wg] ISIS-BGP interaction Message-ID: <20010729120016.74152.qmail@web11201.mail.yahoo.com> --0-971280378-996408016=:72090 Content-Type: text/plain; charset=us-ascii Hi, Is there any standard document, defining the interaction between integrated ISIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was that earlier (upto 94) there were references to ISIS-BGP interaction.But after that it was not mentioned at all.In july 94 meeting's minutes,it was mentioned that the status of ISIS-BGP interaction document is unknown and it needs to be published as as draft\rfc.Can I get more information on this issue. Aravind --------------------------------- Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --0-971280378-996408016=:72090 Content-Type: text/html; charset=us-ascii

Hi,

Is there any standard document, defining the interaction between integrated ISIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was that earlier (upto 94) there were references to ISIS-BGP interaction.But after that it was not mentioned at all.In july 94 meeting's minutes,it was mentioned that the status of ISIS-BGP interaction document is unknown and it needs to be published as as draft\rfc.Can I get more information on this issue.

Aravind


Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/ --0-971280378-996408016=:72090-- From jparker@axiowave.com Mon Jul 30 20:06:53 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 30 Jul 2001 15:06:53 -0400 Subject: [Isis-wg] Multiple CSNPs problem Message-ID: Two comments The transmission of CSNPs on a LAN is done by the "Designated IS", so at least one of your two routers can be silent A CSNP includes information on which part of the LSP DB it covers. Thus the reciever will not set SRM bits for LSPs that fall outside the scope of a CSNP. - jeff parker - axiowave networks - diagnostic: someone who doesn't believe in two gods From: Sivakumar A [mailto:sivaa@indiatimes.com] Sent: Saturday, July 28, 2001 6:10 AM To: workgroup Subject: [Isis-wg] Multiple CSNPs problem Hello all, Kindly clarify the following : In a broadcast circuit consider 2 Intermediate Systems having the same contents in their respective LSP databases. At every CSNP interval each needs to transmit CSNP with the set of LSPs in its database. Considering the number of LSPs in the database, there may be more than one CSNP required to be transmitted. If the number of LSPs in the database is more then more than one CSNP is required to be transmitted. In this case first CSNP contains only a portion of the LSPs in its database. If this CSNP is received by other Intermediate system, it sets the SRM flags for the LSPs which are not listed in the CSNP received. Kindly clarify this. Thanks and regards Sivakumar A From naiming@redback.com Mon Jul 30 20:43:05 2001 From: naiming@redback.com (Naiming Shen) Date: Mon, 30 Jul 2001 12:43:05 -0700 Subject: [Isis-wg] ISIS-BGP interaction In-Reply-To: Mail from Aravind Ravikumar dated Sun, 29 Jul 2001 05:00:16 PDT <20010729120016.74152.qmail@web11201.mail.yahoo.com> Message-ID: <20010730194305.A9649CAB72@prattle.redback.com> http://www.ietf.org/IESG/actions.html BGP4/IDRP for IP---OSPF Interaction (Historic) ] ]Hi, ] ]Is there any standard document, defining the interaction between integrated I SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was tha t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha t the status of ISIS-BGP interaction document is unknown and it needs to be pub lished as as draft\rfc.Can I get more information on this issue. ] ]Aravind ] - Naiming From Larmer@CommSense.Net Mon Jul 30 21:33:12 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Mon, 30 Jul 2001 16:33:12 -0400 Subject: [Isis-wg] Multiple CSNPs problem In-Reply-To: <200107281003.PAA18269@WS0005.indiatimes.com> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0112_01C11915.535FA7F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sivakumar, Each CSNP contains a Start and End LSP range. If a received CSNP does not contain a LSP entry within the given range (non-referenced LSP), the receiving IS should set the SRMflag and clear the SSNflag. When minimumBroadcastLSPTransmissionInterval (33 milliseconds) expires, scan the LSP database looking for LSPs with the SRMflag set. Once one is found, transmit the LSP on the appropriate circuit. The next scan of the LSP database commences once minimumBroadcastLSPTransmissionInterval expires again and should continue from the last LSP transmitted. When a second CSNP for the same level is received, this CSNP will also contain a Start and End LSP range. Repeat the steps above until all LSP entries have been processed. Hope this helps??? Cheers, Ken Larmer -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Sivakumar A Sent: Saturday, July 28, 2001 6:10 AM To: workgroup Subject: [Isis-wg] Multiple CSNPs problem Hello all, Kindly clarify the following : In a broadcast circuit consider 2 Intermediate Systems having the same contents in their respective LSP databases. At every CSNP interval each needs to transmit CSNP with the set of LSPs in its database. Considering the number of LSPs in the database, there may be more than one CSNP required to be transmitted. If the number of LSPs in the database is more then more than one CSNP is required to be transmitted. In this case first CSNP contains only a portion of the LSPs in its database. If this CSNP is received by other Intermediate system, it sets the SRM flags for the LSPs which are not listed in the CSNP received. Kindly clarify this. Thanks and regards Sivakumar A ---------------------------------------------------------------------------- -- Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM and Audio-Books from http://www.planetmonline.com ------=_NextPart_000_0112_01C11915.535FA7F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Sivakumar,
 
   =20 Each CSNP contains a Start and End LSP range. If a received CSNP does = not=20 contain a LSP entry within the given range (non-referenced LSP), the = receiving=20 IS should set the SRMflag and clear the SSNflag. When=20 minimumBroadcastLSPTransmissionInterval (33 milliseconds) = expires, scan the=20 LSP database looking for LSPs with the SRMflag set. Once one is found, = transmit=20 the LSP on the appropriate circuit. The next scan of the LSP=20 database commences once minimumBroadcastLSPTransmissionInterval=20 expires again and should continue from the last LSP=20 transmitted.
 
   =20 When a second CSNP for the same level is received, this CSNP will also = contain a=20 Start and End LSP range. Repeat the steps above until all LSP entries = have been=20 processed. Hope this helps???
 
Cheers,
Ken=20 Larmer
 
 -----Original = Message-----
From:=20 isis-wg-admin@external.juniper.net=20 [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Sivakumar = A
Sent: Saturday, July 28, 2001 6:10 AM
To:=20 workgroup
Subject: [Isis-wg] Multiple CSNPs=20 problem

Hello all,

Kindly clarify the following :

In a broadcast circuit consider 2 Intermediate Systems having the = same=20 contents in their respective LSP databases. At every CSNP interval = each needs=20 to transmit CSNP with the set of LSPs in its database. Considering the = number=20 of LSPs in the database, there may be more than one CSNP required to = be=20 transmitted. If the number of LSPs in the database is more then more = than one=20 CSNP is required to be transmitted. In this case first CSNP contains = only a=20 portion of the LSPs in its database. If this CSNP is received by other = Intermediate system, it sets the SRM flags for the LSPs which are = not=20 listed in the CSNP received. Kindly clarify this.

Thanks and regards

Sivakumar A

 

Get Your Private, Free E-mail from = Indiatimes at=20 http://email.indiatimes.com
Buy Music, = Video, CD-ROM=20 and Audio-Books from http://www.planetmonline.com = ------=_NextPart_000_0112_01C11915.535FA7F0-- From Larmer@CommSense.Net Mon Jul 30 21:42:21 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Mon, 30 Jul 2001 16:42:21 -0400 Subject: [Isis-wg] ISO 10589v2 Latest Revision Document Availability In-Reply-To: <4.3.2.7.2.20010727173855.0226c0e8@cactus.cisco.com> Message-ID: Hi Micah, Is the ISO-10589V2 document you referenced in your email the same as the Second Edition 2001-04-12 ISO-1589 document available on the jtc1sc06.org web page? The reason I ask is because the version on the jtc1sc06.org web page is in a MSWord format, which makes it easier to search for desired text. Cheers, Ken Larmer > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Micah Bartell > Sent: Friday, July 27, 2001 6:42 PM > To: isis-wg@juniper.net > Subject: [Isis-wg] ISO 10589v2 Latest Revision Document Availability > > > Folks, > > I have made the latest revision of ISO 10589v2 and the Disposition of > Comments file available. > > They are both located at ftp.cisco.com/pub/rfc/ISO/ > > The file names are: > > ISO 10589v2: ISO10589v2-2001-07-04.pdf > Comments: DoC-2001-07-04.pdf > > If anyone has any comments to make, I will be accepting comments for two > weeks before beginning the process in the ISO to move forward toward FDIS. > > /mpb > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mbartell@cisco.com Mon Jul 30 21:49:48 2001 From: mbartell@cisco.com (Micah Bartell) Date: Mon, 30 Jul 2001 15:49:48 -0500 Subject: [Isis-wg] ISO 10589v2 Latest Revision Document Availability In-Reply-To: References: <4.3.2.7.2.20010727173855.0226c0e8@cactus.cisco.com> Message-ID: <4.3.2.7.2.20010730154850.029e4740@cactus.cisco.com> It is different. The difference is specified in the Disposition of Comments file. I will add the word copy to the ftp site. /mpb At 16:42 07/30/2001 -0400, Ken Larmer wrote: >Hi Micah, > > Is the ISO-10589V2 document you referenced in your email the same > as the >Second Edition >2001-04-12 ISO-1589 document available on the jtc1sc06.org web page? The >reason I ask is because the version on the jtc1sc06.org web page is in a >MSWord format, which makes it easier to search for desired text. > >Cheers, >Ken Larmer > > > -----Original Message----- > > From: isis-wg-admin@external.juniper.net > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Micah Bartell > > Sent: Friday, July 27, 2001 6:42 PM > > To: isis-wg@juniper.net > > Subject: [Isis-wg] ISO 10589v2 Latest Revision Document Availability > > > > > > Folks, > > > > I have made the latest revision of ISO 10589v2 and the Disposition of > > Comments file available. > > > > They are both located at ftp.cisco.com/pub/rfc/ISO/ > > > > The file names are: > > > > ISO 10589v2: ISO10589v2-2001-07-04.pdf > > Comments: DoC-2001-07-04.pdf > > > > If anyone has any comments to make, I will be accepting comments for two > > weeks before beginning the process in the ISO to move forward toward FDIS. > > > > /mpb > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > From sachidananda_k@hotmail.com Tue Jul 31 15:48:32 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Tue, 31 Jul 2001 14:48:32 +0000 Subject: [Isis-wg] Dual IS-IS Message-ID: Hello, I have some doubts related to the the working of dual IS-IS. My question: Is the link state database maintained seperately for both OSI addresses and IP addresses or is it one and the same. I am not aware of any standard or draft giving any clue about this. Please help me understand this aspect of IS-IS. I shall be obliged to get an early help in this respones. Thanking in advance for all the responses. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From sprevidi@cisco.com Tue Jul 31 15:58:11 2001 From: sprevidi@cisco.com (stefano previdi) Date: Tue, 31 Jul 2001 16:58:11 +0200 Subject: [Isis-wg] Dual IS-IS In-Reply-To: Message-ID: <4.3.2.7.2.20010731165502.03b00e38@brussels.cisco.com> At 16:48 31/07/2001, Sachidananda K wrote: >Hello, > >I have some doubts related to the the working of dual IS-IS. > >My question: >Is the link state database maintained seperately for both OSI addresses >and IP addresses or is it one and the same. Topology database and shortest path tree computation is a matter of implementation as long as the Dijkstra algorithm is used consistently across the whole area/domain. You may want to have different topologies for different address families (IPv4, IPv6, OSI, ucast/mcast, QoS, ...). s. >I am not aware of any standard or draft giving any clue about this. Please >help me understand this aspect of IS-IS. > >I shall be obliged to get an early help in this respones. > >Thanking in advance for all the responses. >Sachi > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jparker@axiowave.com Tue Jul 31 16:07:41 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 31 Jul 2001 11:07:41 -0400 Subject: [Isis-wg] Dual IS-IS Message-ID: > Is the link state database maintained seperately for both OSI > addresses and IP addresses or is it one and the same. > > Sachi The link state database exchange and storage mechanism is agnostic about the contents of PDUs. IP and OSI information can live in the same Link State PDU. No attempt is made to determine the domain of such information until the SPF algorithm inspects the PDUs. The SPF computation is described in section 3.10 of RFC 1195, http://ietf.org/rfc/rfc1195.txt - jeff parker - axiowave networks From aravindravikumar@yahoo.com Tue Jul 31 16:49:39 2001 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Tue, 31 Jul 2001 08:49:39 -0700 (PDT) Subject: [Isis-wg] ISIS-BGP interaction In-Reply-To: <20010730194305.A9649CAB72@prattle.redback.com> Message-ID: <20010731154939.80126.qmail@web11206.mail.yahoo.com> --0-1805583877-996594579=:79826 Content-Type: text/plain; charset=us-ascii Thanks for the reply,I would to like get some more clarification on the issue I tried to retrive the document that you have specified. But it seems that it is not currently available.I had read rfc 1745,but it speaks only about the interaction of OSPF with BGP/IDRP.But what I would like to know is that is there any well defined reference document which describes the interaction between ISIS and BGP IN the charter of Inter-Domain Routing (idr) working group there is a reference to BGP/IDRP -- OSPF Interactions .It is said that this document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP - OSPF interactions, and IDRP - IS-IS interaction documents. >From what I infer This has been published as rfc 1745.I believe that the two references mentioned as BGP - OSPf interactions and IDRP -ISIS interactions are RFC1403 and"The Technical Design for Routeing Information Exchange between ISIS and IDRP" (Oran, D., Rekhter, Y., Hares, S.) respectievely Since I am interesred in knowing about ISIS -BGP interaction ,I felt that the ISIS-IDRP interaction document will be useful.But I was unable to get the document and I think, the document you are mentioning is also about OSPF-BGP/IDRP interaction More specifcally my questions are In an ASBR which uses BGP as the EGP and ISIS as the IGP, How does BGP learn about the destinations that are reachable inside this autonomous sytem How does the ISIS obtain information about AS external destinations Aravind Naiming Shen wrote: http://www.ietf.org/IESG/actions.html BGP4/IDRP for IP---OSPF Interaction (Historic) ] ]Hi, ] ]Is there any standard document, defining the interaction between integrated I SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was tha t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha t the status of ISIS-BGP interaction document is unknown and it needs to be pub lished as as draft\rfc.Can I get more information on this issue. ] ]Aravind ] - Naiming --------------------------------- Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --0-1805583877-996594579=:79826 Content-Type: text/html; charset=us-ascii

 Thanks for the reply,I would to like get some more clarification on the issue

I tried to retrive the document that you have specified. But it seems that it is not currently available.I had read rfc 1745,but it speaks only about the interaction of OSPF with BGP/IDRP.But what I would like to know is that is there any well defined reference document which describes the interaction between ISIS and BGP

IN  the charter of Inter-Domain Routing (idr) working group there is a reference to
BGP/IDRP -- OSPF Interactions .It is said that this document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP - OSPF interactions, and IDRP - IS-IS interaction documents.

From what I infer This has been published as rfc 1745.I believe that the two references mentioned as BGP - OSPf interactions and IDRP -ISIS interactions are RFC1403 and"The Technical Design for Routeing Information Exchange between ISIS and IDRP" (Oran, D., Rekhter, Y., Hares, S.)  respectievely

 Since I am interesred in knowing about ISIS -BGP interaction ,I felt that the ISIS-IDRP interaction document will be useful.But I was unable to get the document and I think, the document you are mentioning is also about OSPF-BGP/IDRP interaction

More specifcally my questions are

In an ASBR which uses BGP as the EGP and ISIS as the IGP,

How does BGP learn about the destinations that are reachable inside this  autonomous sytem

 How does the ISIS obtain information about AS external destinations

Aravind

Naiming Shen <naiming@redback.com> wrote:


http://www.ietf.org/IESG/actions.html


BGP4/IDRP for IP---OSPF Interaction (Historic)

]
]Hi,
]
]Is there any standard document, defining the interaction between integrated I
SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone
through the minutes of ISIS working group .The strange thing I noticed was tha
t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha
t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha
t the status of ISIS-BGP interaction document is unknown and it needs to be pub
lished as as draft\rfc.Can I get more information on this issue.
]
]Aravind
]

- Naiming


Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/ --0-1805583877-996594579=:79826-- From jlearman@cisco.com Tue Jul 31 18:05:33 2001 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 31 Jul 2001 13:05:33 -0400 Subject: [Isis-wg] Dual IS-IS In-Reply-To: Message-ID: <4.3.2.7.2.20010731125657.01ea8588@dingdong.cisco.com> From an external perspective, the LSP database for OSI and IP is integrated -- that is, the LSPs can carry both types of information, and the ordering rules apply to IS and ES Neighbors options without regard for protocol, and the IS and ES Neighbors options do not indicate which protocol they apply to (according to RFC 1195, that is handled by the "protocols supported" options in conjunction with the deployment rules). And an IS is required to save all LSPs verbatim -- at least they must appear to do so from external behavior, e.g., when sending another system's LSP to a neighbor because of the information in the neighbor's SNPs. While some system may choose to place certain IP information in different LSP numbers than OSI information, there are limitations to what they could do because of special requirements for LSP zero -- you can't have an OSI LSP zero and an IP LSP zero unless you're running completely separate instances of ISIS (and let's not go there, because this is not an advanced course). Regards, Jeff Opinions expressed are not necessarily those of my employer, and I am not working in IS-IS at Cisco. At 10:48 AM 7/31/2001, Sachidananda K wrote: >Hello, > >I have some doubts related to the the working of dual IS-IS. > >My question: >Is the link state database maintained seperately for both OSI addresses and IP addresses or is it one and the same. I am not aware of any standard or draft giving any clue about this. Please help me understand this aspect of IS-IS. > >I shall be obliged to get an early help in this respones. > >Thanking in advance for all the responses. >Sachi > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From naamato@nexthop.com Tue Jul 31 20:11:16 2001 From: naamato@nexthop.com (Nick Amato) Date: Tue, 31 Jul 2001 15:11:16 -0400 Subject: [Isis-wg] comment on hmac-03 Message-ID: <20010731151116.B325@wooj.nexthop.com> It is my opinion that section 2.1 of draft-ietf-isis-hmac-03.txt needs clarification. If a router restarts when it's time to use a new key, let's first assume it rolls over its link, area and domain keys. In this case the rolling-over router will not become adjacent with neighbors using the old link key and thus will not receive its old LSP. Section 2.1 seems to refer to the case where a router changes only, for example, its area key and not its link key. In this case the rolling-over router may become adjacent with neighbor(s) that are still using the old area key. This case seems more like a misconfiguration to me as an IS is allowed to accept more than a single key at once. Nick Amato NextHop Technologies From naiming@redback.com Wed Aug 1 01:23:37 2001 From: naiming@redback.com (Naiming Shen) Date: Tue, 31 Jul 2001 17:23:37 -0700 Subject: [Isis-wg] comment on hmac-03 In-Reply-To: Mail from Nick Amato dated Tue, 31 Jul 2001 15:11:16 EDT <20010731151116.B325@wooj.nexthop.com> Message-ID: <20010801002337.5B4D31DCC6A@prattle.redback.com> ] ]It is my opinion that section 2.1 of draft-ietf-isis-hmac-03.txt ]needs clarification. ] ]If a router restarts when it's time to use a new key, let's first assume ]it rolls over its link, area and domain keys. In this case the rolling-over ]router will not become adjacent with neighbors using the old link key and ]thus will not receive its old LSP. ] ]Section 2.1 seems to refer to the case where a router changes only, ]for example, its area key and not its link key. In this case the ]rolling-over router may become adjacent with neighbor(s) that are ]still using the old area key. ] ]This case seems more like a misconfiguration to me as an IS is allowed ]to accept more than a single key at once. ] An implementation of ISIS authentication does not have to use a single key for the whole box. Actually each link can have it's own keys, and even on each routing level of the link. Users may want to do authentication only on the LSP packets but not other ISIS packets. Or a user may want to do simple authentication on one link and hmac on the others. But you are right, if the whole box uses a single key to rollover for all ISIS packets, the case in 2.1 should not occur. thanks. ]Nick Amato ]NextHop Technologies ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From naiming@redback.com Wed Aug 1 01:36:09 2001 From: naiming@redback.com (Naiming Shen) Date: Tue, 31 Jul 2001 17:36:09 -0700 Subject: [Isis-wg] comment on hmac-03 In-Reply-To: Mail from Naiming Shen dated Tue, 31 Jul 2001 17:23:37 PDT <20010801002337.5B4D31DCC6A@prattle.redback.com> Message-ID: <20010801003609.3E5444BA21A@prattle.redback.com> Actually, even if the whole box uses a single key, this problem can still occur. The section 2.1 is talking about a case where a key(assume for all the isis packets) is rolled over at time X, and ISIS process of router A restarted at that time. All the adjacencies should still come up fine to use the new key. But the router can not send out it's LSP out since it's neighbors still have A's old LSP(which has higher seq #), but router A can't advance it's seq# because it can not authenticate the old LSP it's neighbors send it back. ] ] ] ]It is my opinion that section 2.1 of draft-ietf-isis-hmac-03.txt ] ]needs clarification. ] ] ] ]If a router restarts when it's time to use a new key, let's first assume ] ]it rolls over its link, area and domain keys. In this case the rolling-ove r ] ]router will not become adjacent with neighbors using the old link key and ] ]thus will not receive its old LSP. ] ] ] ]Section 2.1 seems to refer to the case where a router changes only, ] ]for example, its area key and not its link key. In this case the ] ]rolling-over router may become adjacent with neighbor(s) that are ] ]still using the old area key. ] ] ] ]This case seems more like a misconfiguration to me as an IS is allowed ] ]to accept more than a single key at once. ] ] ] ]An implementation of ISIS authentication does not have to use a single ]key for the whole box. Actually each link can have it's own keys, and ]even on each routing level of the link. Users may want to do authentication ]only on the LSP packets but not other ISIS packets. Or a user may want to ]do simple authentication on one link and hmac on the others. But you are ]right, if the whole box uses a single key to rollover for all ISIS packets, ]the case in 2.1 should not occur. ] ]thanks. ] ] ]Nick Amato ] ]NextHop Technologies ] ]_______________________________________________ ] ]Isis-wg mailing list - Isis-wg@external.juniper.net ] ]http://external.juniper.net/mailman/listinfo/isis-wg ] ]- Naiming - Naiming From prz@redback.com Wed Aug 1 01:45:47 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 31 Jul 2001 17:45:47 -0700 Subject: [Isis-wg] comment on hmac-03 References: <20010801003609.3E5444BA21A@prattle.redback.com> Message-ID: <3B67513B.48E61147@redback.com> Naiming Shen wrote: > Actually, even if the whole box uses a single key, this problem can > still occur. > > The section 2.1 is talking about a case where a key(assume for all > the isis packets) is rolled over at time X, and ISIS process of router A > restarted at that time. All the adjacencies should still come up fine > to use the new key. But the router can not send out it's LSP out since > it's neighbors still have A's old LSP(which has higher seq #), but > router A can't advance it's seq# because it can not authenticate the > old LSP it's neighbors send it back. well, isn't the idea of a 'roll-over' that you accept both keys for a period of time? And during this period of time all LSPs with the old key should time out and any other possible information authenticated by this key should also vanish so obviously roll-over period >> LSP lifetime. Also you must be able within ISIS to hold both keys and when you receive a piece of information, try new key and then old key. Given that, what's the problem exactly ? -- tony From naamato@nexthop.com Wed Aug 1 03:43:51 2001 From: naamato@nexthop.com (Nick Amato) Date: Tue, 31 Jul 2001 22:43:51 -0400 Subject: [isis-wg] comment on hmac-03 Message-ID: <20010731224351.A25225@wooj.nexthop.com> > > Actually, even if the whole box uses a single key, this problem can > > still occur. > > > > The section 2.1 is talking about a case where a key(assume for all > > the isis packets) is rolled over at time X, and ISIS process of router A > > restarted at that time. All the adjacencies should still come up fine > > to use the new key. But the router can not send out it's LSP out since > > it's neighbors still have A's old LSP(which has higher seq #), but > > router A can't advance it's seq# because it can not authenticate the > > old LSP it's neighbors send it back. > > well, isn't the idea of a 'roll-over' that you accept both keys for a period > of time? And during this period of time all LSPs with the old key should > time out and any other possible information authenticated by this key > should also vanish so obviously roll-over period >> LSP lifetime. > Also you must be able within ISIS to hold both keys > and when you receive a piece of information, try new key and then old > key. Given that, what's the problem exactly ? Just to be clear, multiple-key 'roll-over' is, according to the draft, an optional part of this authentication (...the router MAY check a set of passwords when verifying the Authentication value). The problem I was addressing is that section 2.1 is unclear. It should not apply to a router that implements 'roll-over' as you define it above, rather to a case where a router can become adjacent with N neighbors but cannot authenticate LSP packets from any of them. Whether the router restarts or not is irrelevant. Also for L1, CSNs use the same key as LSPs, so I'm not sure if it's even useful to talk about LSPs here since, potentially, the router may not be able to authenticate CSNs from the DISs (or have other routers authenticate its CSN if it is a DIS on a circuit). Nick From naiming@redback.com Wed Aug 1 04:38:43 2001 From: naiming@redback.com (Naiming Shen) Date: Tue, 31 Jul 2001 20:38:43 -0700 Subject: [isis-wg] comment on hmac-03 In-Reply-To: Mail from Nick Amato dated Tue, 31 Jul 2001 22:43:51 EDT <20010731224351.A25225@wooj.nexthop.com> Message-ID: <20010801033843.509A04BA21A@prattle.redback.com> ] ]> > Actually, even if the whole box uses a single key, this problem can ]> > still occur. ]> > ]> > The section 2.1 is talking about a case where a key(assume for all ]> > the isis packets) is rolled over at time X, and ISIS process of router A ]> > restarted at that time. All the adjacencies should still come up fine ]> > to use the new key. But the router can not send out it's LSP out since ]> > it's neighbors still have A's old LSP(which has higher seq #), but ]> > router A can't advance it's seq# because it can not authenticate the ]> > old LSP it's neighbors send it back. ]> ]> well, isn't the idea of a 'roll-over' that you accept both keys for a perio d ]> of time? And during this period of time all LSPs with the old key should ]> time out and any other possible information authenticated by this key ]> should also vanish so obviously roll-over period >> LSP lifetime. ]> Also you must be able within ISIS to hold both keys ]> and when you receive a piece of information, try new key and then old ]> key. Given that, what's the problem exactly ? ] ]Just to be clear, multiple-key 'roll-over' is, according to the draft, an ]optional part of this authentication (...the router MAY check a set ]of passwords when verifying the Authentication value). Tony was right that in a multiple-key 'rollover', if the old key is kept around long enough, this case should not happen. This can happen if in the 'rollover', the new key replaces the old key, or the old key is not kept long enough. Or this can happen with a single key, all the routers are configured to use authentication at time X, one router crashes right after X, and in this case, there is no "old" key. ] ]The problem I was addressing is that section 2.1 is unclear. It ]should not apply to a router that implements 'roll-over' as you ]define it above, rather to a case where a router can become adjacent ]with N neighbors but cannot authenticate LSP packets from any of them. ]Whether the router restarts or not is irrelevant. ] ]Also for L1, CSNs use the same key as LSPs, so I'm not sure if it's ]even useful to talk about LSPs here since, potentially, the router ]may not be able to authenticate CSNs from the DISs (or have other routers ]authenticate its CSN if it is a DIS on a circuit). I'm not sure what's this to do with csns or dis. this was not saying LSPs are using a diff key. let's try the following case with just two routers: A and B, they use authentication for all packets. before time X, they use key1, after time X, they use key2. At time X, both A and B switches auth key from key1 into key2, and A's ISIS process restarted. A and B then re-establish the adjacency with the key2, they can also exchange the SNPs using the key2, there is no problem of that. A now has a LSP starts from seq# of 1. when A sends this LSP to B, B rejects this, and send the A's old LSP back to A(with the key1). If B does not have multiple-key implemented or B timedout the key1 too soon, then the old LSP with key1 is rejected because of failing authentication. B will not get A's new LSP until this old LSP of A timed out. ] ]Nick - Naiming From naiming@redback.com Wed Aug 1 04:50:02 2001 From: naiming@redback.com (Naiming Shen) Date: Tue, 31 Jul 2001 20:50:02 -0700 Subject: [isis-wg] comment on hmac-03 In-Reply-To: Mail from Naiming Shen dated Tue, 31 Jul 2001 20:38:43 PDT <20010801033843.509A04BA21A@prattle.redback.com> Message-ID: <20010801035002.A155A1DCC63@prattle.redback.com> ] ]At time X, both A and B switches auth key from key1 into key2, and A's ]ISIS process restarted. A and B then re-establish the adjacency with ]the key2, they can also exchange the SNPs using the key2, there is no ]problem of that. A now has a LSP starts from seq# of 1. when A sends ]this LSP to B, B rejects this, and send the A's old LSP back to A(with ]the key1). If B does not have multiple-key implemented or B timedout typo here ^ (should be A) ^ ( A also ) ]the key1 too soon, then the old LSP with key1 is rejected because of ]failing authentication. B will not get A's new LSP until this old LSP ]of A timed out. - Naiming From naamato@nexthop.com Wed Aug 1 05:24:07 2001 From: naamato@nexthop.com (Nick Amato) Date: Wed, 1 Aug 2001 00:24:07 -0400 Subject: [isis-wg] comment on hmac-03 In-Reply-To: <20010801035002.A155A1DCC63@prattle.redback.com>; from naiming@redback.com on Tue, Jul 31, 2001 at 08:50:02PM -0700 References: <20010801035002.A155A1DCC63@prattle.redback.com> Message-ID: <20010801002407.B25225@wooj.nexthop.com> On Tue, Jul 31, 2001 at 08:50:02PM -0700, Naiming Shen wrote: > ] > ]At time X, both A and B switches auth key from key1 into key2, and A's > ]ISIS process restarted. A and B then re-establish the adjacency with > ]the key2, they can also exchange the SNPs using the key2, there is no > ]problem of that. A now has a LSP starts from seq# of 1. when A sends > ]this LSP to B, B rejects this, and send the A's old LSP back to A(with > ]the key1). If B does not have multiple-key implemented or B timedout > > typo here ^ (should be A) ^ ( A also ) > > ]the key1 too soon, then the old LSP with key1 is rejected because of > ]failing authentication. B will not get A's new LSP until this old LSP > ]of A timed out. > I agree with this example (LSPs use the authentication of the originator rather than the transmitter of the LSP PDU). Section 2.1 should probably indicate, like your example, the problem exists if the router does not implement multiple keys or the old key is timed out too quickly or forgotten rather than after the router restarts, just for clarity. The router may remember its old key if the configuration was in non-volatile storage. :) Nick From naiming@redback.com Wed Aug 1 06:33:38 2001 From: naiming@redback.com (Naiming Shen) Date: Tue, 31 Jul 2001 22:33:38 -0700 Subject: [isis-wg] comment on hmac-03 In-Reply-To: Mail from Nick Amato dated Wed, 01 Aug 2001 00:24:07 EDT <20010801002407.B25225@wooj.nexthop.com> Message-ID: <20010801053338.D68EF4BA215@prattle.redback.com> ] ]I agree with this example (LSPs use the authentication of the originator ]rather than the transmitter of the LSP PDU). ] ]Section 2.1 should probably indicate, like your example, the problem ]exists if the router does not implement multiple keys or the old ]key is timed out too quickly or forgotten rather than after the ]router restarts, just for clarity. Agreed. It would be nice to spell it out. Anyway, it should be taken care of at the protocol implementation level. Use one key or multiple keys, how long to keep the keys, those are configuration issues. ]The router may remember its old ]key if the configuration was in non-volatile storage. :) I said "ISIS process restarted", not router restarted, so nvram is not needed here:-) thanks. ] ]Nick - Naiming From amrendras@future.futsoft.com Wed Aug 1 08:02:43 2001 From: amrendras@future.futsoft.com (andy) Date: Wed, 1 Aug 2001 12:32:43 +0530 Subject: [Isis-wg] query Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C11A86.0FE4FE90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi list, I have encountered a peculiar behaviour in Cisco-2600 series router. When i enable authentication at domain level or area level, the LSPs generated have authentication information in them . However the CSNP packets and PSNP packets generated by CISCO do not have this authentication information. This is causing authentication failure. Due to which the routes are not learnt by cisco router and test router. However even if one CSNP packet is allowed to be processed by the test router then the routes are exchanged and installed in both Cisco's and the test router's main routing table. My question is should there be authentication information in CSNP as well as PSNP packets when i have enabled authentication at the domain or the Area level? please reply as soon as possible thanks and regards amrendras sharma ( Future software ltd, Chennai, India) ------=_NextPart_000_0015_01C11A86.0FE4FE90 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IisHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCAABAAwAGAAAAAMACAEB A5AGAIAGAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAABgAAAHF1ZXJ5AAAAAgFxAAEAAAAWAAAAAcEaVuCMUdqZgIY3EdWN/wAQWob+ogAAAgEdDAEA AAAiAAAAU01UUDpBTVJFTkRSQVNARlVUVVJFLkZVVFNPRlQuQ09NAAAACwABDgAAAABAAAYOAPT7 vVYawQECAQoOAQAAABgAAAAAAAAAtObTPAuA1BGNVQAQWob+osKAAAALAB8OAQAAAAIBCRABAAAA 1wIAANMCAACIBAAATFpGdZcEeMADAAoAcmNwZzEyNRYyAPgLYG4OEDAzM08B9wKkA+MCAGNoCsBz 8GV0MCAHEwKDAFADVV8HbQKDDlAD1RF1fQqBdkkIkHdrC4BkNAxgYwcAUAsDC7UgaGkgbFkEAHQs CqIKgEkWwGHYdmUgCfAFoHUCMASQoQmAIGEgcAWQdRcAqQrBYmUX0WkIYSALgAwgQwQABaAtMjYw XxFQESAIgQQgA2B1GIEu8wrjCoBXaAnwGiAYEQGgWmwYAGEboBxxdA3gYe8doAIgGNAFQGQDcRox HRBvF/ADIAWxCsBlGOAe0yxCIB1hIExTUAQgIP5nCfAEkB3QGLEX0x1NC4AdAhByAMAiVSASbSAu cRdUSG93HuEFwCAiQ9hTTlAY8ADQaxEwBCCbAHAYwFAlKiDIYnkaUBBJU0NPHlEgbm9/BUAX0x1g BAAhryK4G+BUdyjyKQEdwHUAkA8gHT5m7wtwCkAJcCPlRApQIBAoMP53FtAQ4CATG4MlwQlwKEPv HRAKwAIwJ4JjGnIbdSXTvy8BBUAbhiRWHuEckWYfIP8g4CUKKzIHQAkAJHAxUSgw9xmQGPADYGMH kBEgJ3MgIs8xeSASI3MuymV4EOEPIP8YsiXxC4AXIDRxGLEaMQbg+x1gGlQnJcQ2LTqxHoMbgl8r sgGRHRAj5RdUTSegcU8KUBcgImMEIHNoCGBsvzsDL1E1ISk/IsslE2EEIP8kcDSAQkImKy4wHIMX 1Rzy/xjBHV8gIh5lBbEgIgcQH4a+PxdUC1AfgBEgG3BlC1AzJ6BCUXNvHgIEIHBvvQQQaR0BF1Qd YABwayXEnQlwZwsRELA9iWFtCXA/FYAhAD8CCsAAwBdUKCBeRhugLSFJUQGAdy9CbGx0ZBdFIKBD HHEc4GnbIABPZkkVgAcwKSCgG/X/PXgWMRIRC/AVoD2EE9MMARdR+lPlFOEAVXAACwAAgAggBgAA AAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMA B4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAA/cQEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUA AAEAAAAEAAAAOS4wAAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwARgAggBgAAAAAA wAAAAAAAAEYAAAAABoUAAAAAAAADABKACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAG4AI IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAcgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAA AAADAB6ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAALTm0zwLgNQRjVUA EFqG/qICAfoPAQAAABAAAAC05tM8C4DUEY1VABBahv6iAgH7DwEAAABNAAAAAAAAADihuxAF5RAa obsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcbWFpbFxtYWls Ym94LnBzdAAAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAA8AAAAPE5FQkJJTkZGTEVQR0lKTEtQ RkNDSUVCQUlMQUEuYW1yZW5kcmFzQGZ1dHVyZS5mdXRzb2Z0LmNvbT4AAwAGECHtIpYDAAcQyQIA AAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISUxJU1QsSUhBVkVFTkNPVU5URVJFREFQRUNV TElBUkJFSEFWSU9VUklOQ0lTQ08tMjYwMFNFUklFU1JPVVRFUldIRU5JRU5BQkxFQVVUSEVOVElD QVRJT05BVERPTUFJTkxFAAAAAKd7 ------=_NextPart_000_0015_01C11A86.0FE4FE90-- From omer@cwnt.com Wed Aug 1 10:01:34 2001 From: omer@cwnt.com (Omer Sali) Date: Wed, 1 Aug 2001 12:01:34 +0300 Subject: [Isis-wg] hmac-md5 interoperability in ISIS Message-ID: Hi, RFC 2104 (HMAC: Keyed-Hashing for Message Authentication) says : "The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function." Note that L is 16 for MD5. My questions are: 1) Is there a common padding of passwords less than 16 bytes to be used by all ISIS implementors? Avoiding to use a common padding clearly prevents interoperability between vendors. 2) Do all vendors use the same procedure for authenticating the PDUs? Are there any known implementations not using the procedure as described in draft-ietf-isis-hmac-03? Thanks, Omer From sprevidi@cisco.com Wed Aug 1 13:46:43 2001 From: sprevidi@cisco.com (stefano previdi) Date: Wed, 01 Aug 2001 14:46:43 +0200 Subject: [Isis-wg] query In-Reply-To: Message-ID: <4.3.2.7.2.20010801144457.00b61af8@brussels.cisco.com> At 09:02 01/08/2001, andy wrote: >hi list, >I have encountered a peculiar behaviour in Cisco-2600 series router. >When i enable authentication at domain level or area level, the LSPs >generated have authentication information in them . >However the CSNP packets and PSNP packets generated by CISCO do not have >this authentication information. This is causing authentication failure. >Due to which the routes are not learnt by cisco router and test router. >However even if one CSNP packet is allowed to be processed by the test >router then the routes are exchanged and installed in both Cisco's and the >test router's main routing table. > >My question is should there be authentication information in CSNP as well as >PSNP packets when i have enabled authentication at the domain or the Area >level? it's a cisco specific issue...not ietf one... I'll take it offline. s. >please reply as soon as possible >thanks and regards > >amrendras sharma >( Future software ltd, > Chennai, > India) > > > > From jparker@axiowave.com Wed Aug 1 15:10:24 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 1 Aug 2001 10:10:24 -0400 Subject: [Isis-wg] query Message-ID: > I have encountered a peculiar behaviour in (Company C) series router. > When i enable authentication at domain level or area level, the LSPs > generated have authentication information in them . To quote Claude Raines: "I'm shocked: shocked to hear that there is a missmatch between specifications and implementations." Since the behavior by company C is long standing and well know, you may find there is a setting in vendor T's equipment that will cut a bit of slack to routers from company C. There may not be such a setting yet, but any test which flunks the majority of boxes deployed may need to be modified to include a "reality" setting. - jeff parker - axiowave networks From darrinw@nixc.net Wed Aug 1 17:11:36 2001 From: darrinw@nixc.net (Darrin Walton) Date: Wed, 1 Aug 2001 16:11:36 +0000 Subject: [Isis-wg] query In-Reply-To: ; from amrendras@future.futsoft.com on Wed, Aug 01, 2001 at 12:32:43PM +0530 References: Message-ID: <20010801161136.N9871@nixc.net> On Wed, Aug 01, 2001 at 12:32:43PM +0530, andy wrote: |+ hi list, |+ I have encountered a peculiar behaviour in Cisco-2600 series router. |+ When i enable authentication at domain level or area level, the LSPs |+ generated have authentication information in them . |+ However the CSNP packets and PSNP packets generated by CISCO do not have |+ this authentication information. This is causing authentication failure. I thought the RFC stated this was optional, not mandatory. Cisco's webpage however does say the PSNP packets should have authentication. I ran into this awhile ago, and Cisco has said they have fixed this issue, as it was causing us other problems. I'm not sure what the other router vendor you're using, but what you could do is disable the domain or area authentication, and enable hello-authentication on each interface. -- darrin walton, darrinw@nixc.net From sprevidi@cisco.com Wed Aug 1 18:50:10 2001 From: sprevidi@cisco.com (stefano previdi) Date: Wed, 01 Aug 2001 19:50:10 +0200 Subject: [Isis-wg] query In-Reply-To: <20010801161136.N9871@nixc.net> References: Message-ID: <4.3.2.7.2.20010801194858.01a40ed8@brussels.cisco.com> At 18:11 01/08/2001, Darrin Walton wrote: >On Wed, Aug 01, 2001 at 12:32:43PM +0530, andy wrote: > |+ hi list, > |+ I have encountered a peculiar behaviour in Cisco-2600 series router. > |+ When i enable authentication at domain level or area level, the LSPs > |+ generated have authentication information in them . > |+ However the CSNP packets and PSNP packets generated by CISCO do not have > |+ this authentication information. This is causing authentication failure. > >I thought the RFC stated this was optional, not mandatory. Cisco's >webpage however does say the PSNP packets should have authentication. > >I ran into this awhile ago, and Cisco has said they have fixed this issue, >as it was causing us other problems. > >I'm not sure what the other router vendor you're using, but what you >could do is disable the domain or area authentication, and enable >hello-authentication on each interface. I replied offline to this problem but since other people seems to be interested...yes, the problem has been fixed. Get in touch with me for details. s. From prz@redback.com Wed Aug 1 20:44:12 2001 From: prz@redback.com (Tony Przygienda) Date: Wed, 01 Aug 2001 12:44:12 -0700 Subject: [Isis-wg] query References: <4.3.2.7.2.20010801194858.01a40ed8@brussels.cisco.com> Message-ID: <3B685C0C.EC03AA96@redback.com> stefano previdi wrote: > >I'm not sure what the other router vendor you're using, but what you > >could do is disable the domain or area authentication, and enable > >hello-authentication on each interface. > > I replied offline to this problem but since other people seems to > be interested...yes, the problem has been fixed. Get in touch with > me for details. > Stefano, thanks for clearing it up. Original reaction has been correct, this is not the forum to wash dirty laundries or praise specific implementations unless it affects the protocol specs ... thanks -- tony From prz@redback.com Thu Aug 2 01:19:15 2001 From: prz@redback.com (Tony Przygienda) Date: Wed, 01 Aug 2001 17:19:15 -0700 Subject: [Isis-wg] agenda for London ... Message-ID: <3B689C83.9B895DDE@redback.com> 10min Administrativa x draft status x new RFCs 15min draft-hermelin-ext-lsp-frags Amir 15min draft-ietf-isis-transient Danny 20min draft-shand-isis-restart Mike 20min draft-ietf-isis-wg-multi-topology Naiming 15min draft-ietf-isis-auth-anti-replay Alex 5min draft-ietf-isis-wg-tlv-codepoints Tony P. Any other open issues to be discussed at the end after this agenda thanks -- tony From naamato@nexthop.com Thu Aug 2 01:40:19 2001 From: naamato@nexthop.com (Nick Amato) Date: Wed, 1 Aug 2001 20:40:19 -0400 Subject: [Isis-wg] minor conflict between cksum and hmac Message-ID: <20010801204019.A323@wooj.nexthop.com> Just a minor thing: draft-ietf-isis-wg-snp-checksum-02.txt states that an implementation MUST either omit the optional checksum or set it to zero when also including, for example, an MD5 signature in an SN PDU. The hmac draft states that the implementation MUST "not include" the checksum TLV. Either will work. The latter is a bit ambiguous; it would be nice to make them consistent. Nick From Internet-Drafts@ietf.org Tue Jul 24 11:29:25 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 24 Jul 2001 06:29:25 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-tlv-codepoints-00.txt Message-ID: <200107241029.GAA05870@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-00.txt Pages : Date : 23-Jul-01 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-00.txt 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-00.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-00.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: <20010723140425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-tlv-codepoints-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140425.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Tue Jul 24 11:29:25 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 24 Jul 2001 06:29:25 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-tlv-codepoints-00.txt Message-ID: <200107241029.GAA05870@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-00.txt Pages : Date : 23-Jul-01 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-00.txt 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-00.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-00.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: <20010723140425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-tlv-codepoints-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140425.I-D@ietf.org> --OtherAccess-- --NextPart-- From naiming@redback.com Fri Aug 3 10:56:49 2001 From: naiming@redback.com (Naiming Shen) Date: Fri, 03 Aug 2001 02:56:49 -0700 Subject: [Isis-wg] new version of draft-shen-isis-ospf-p2p-over-lan-01.txt In-Reply-To: Mail from Alex Zinin dated Sat, 28 Jul 2001 02:51:54 PDT <12140487778.20010728025154@nexsi.com> Message-ID: <20010803095649.A04631DCC62@prattle.redback.com> Here is a newer version of p2p-over-lan draft, missed ietf submission, the text has not been formatted correctly. Please review and comment. thanks. - Naiming Network Working Group Naiming Shen Internet Draft Acee Lindem Expiration Date: February 2001 Jenny Yuan File name: draft-shen-isis-ospf-p2p-over-lan-01.txt Redback Networks Alex Zinin Nexsi Systems Russ White Stefano Previdi Cisco Systems August 2001 Point-to-point operation over LAN in link-state routing protocols draft-shen-isis-ospf-p2p-over-lan-01.txt 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. Shen, Zinin, et al Expires February 2001 [Page 1] INTERNET DRAFT P2P OVER LAN August 2001 1. Introduction Point-to-point and broadcast are the two predominant circuit types used by link state routing protocols such as IS-IS [ref1] [ref2] and OSPF [ref3]. They are treated differently with respect to establishing neighbor adjacencies, flooding of link-state information, representation of the topology, SPF calculation and protocol packets. The most important differences are that broadcast circuits utilize the concept of a designated router and are represented topologically as virtual nodes in the network topology graph. Compared with broadcast circuits, point-to-point circuits afford more straightforward IGP operation. There is no designated router involved and there is no representation of the pseudo-node or network LSA in the link state database. For ISIS, there also is no periodic database synchronization. Conversely, if there are more than two routers on the LAN media, the traditional view of the broadcast circuit will reduce the routing information in the network. When there are only two routers on the LAN, it makes more sense to treat the connection between the two routers as a point-to-point circuit. This document describes the mechanism to allow link state routing protocols to operate using point-to-point connections over a LAN under this condition. Some implications related to forwarding IP packets on this type of circuit are also discussed. We will refer to this as a p2p-over-lan circuit in this document. 2. Motivation Even though a broadcast circuit is meant to handle more than two devices, there are cases where only two routers are connected over either the physical or logical LAN segment: 1. The media itself is being used for point-to-point operation between two routers. This is mainly for long-haul operation. 2. There are only two routers on the physical LAN. 3. There are only two routers on a virtual LAN (vLAN). In any of the above cases, the link state routing protocols will normally still treat the media as a broadcast circuit. Hence, they will have the overhead involved with protocol LAN operation without the benefits of reducing routing information and optimized flooding. Being able to treat a LAN as a point-to-point circuit provides the benefit of reduction in the amount of information routing protocols must carry and manage. DR/DIS election can be omitted. Flooding can be done as in p2p links without the need of using "LSA reflection" by the DR in OSPF or periodic CSNPs in ISIS. Also, if a broadcast segment wired as a point-to-point link can be treated as a point-to-point link, only the connection between the two routers would need to be advertised as a topological entity. Even when there are multiple routers on the LAN an ISP may want to sub-group the routers into multiple vLANs since this allows them to assign different costs to IGP neighbors. When there are only two routers in some of the vLANs, this LAN can be viewed by the IGP as a mesh of point-to-point connections. As a side benefit, unnumbered interface can also be applied over p2p-over-lan circuits. The advantages of unnumbered point-to-point links are obvious in the current IP addressing environment where addresses are a scarce resource. Separating the concept of network type from media type will allow LANs, e.g. ethernet, to be unnumbered and realize the IP address space savings. Another advantage is in simpler network management and configuration. Shen, Zinin, et al Expires February 2001 [Page 2] INTERNET DRAFT P2P OVER LAN August 2001 3. IP multi-access subnets When an IP network includes multi-access segments, each segment is usually assigned a separate subnet and each router connected to it is assigned a distinct IP address within that subnet. The role of the IP address assigned to a multi-access interface can be outlined as follows: 1. Source IP address - The interface address can be used by the router as the source IP address in locally originated IP packets destined for that subnet or having a best path next hop on that subnet. 2. Destination IP address - The interface address can be used by other devices in the network as a destination address for packets to router applications (examples include telnet, SMTP, TFTP, OSPF, BGP, etc). 3. Next-hop identifier - If other routers connected to the same segment need to forward traffic through the router, the corresponding routes in their routing tables will include the router's interface IP address. This address will be used to find the router's MAC address using the ARP protocol. Effectively, the interface IP addresses help other routers find the data-link layer details that are required to specify the destination of the encapsulating data-link frame when it is sent on the segment. The IP addressing scheme includes an option that allows the administrators to not assign any subnets to point-to-point links (links connecting only two devices and using protocols like PPP, SLIP or HDLC for IP encapsulation). This is possible, because the routers do not need next-hop identifiers on point-to-point links (there is only one destination for any transmission), and an interface independent IP address can be used as the source and destination. Using the unnumbered option for a point-to-point link essentially makes it a purely topological entity used only to reach other destinations. 4. Point-to-point connection over LAN media The idea is very simple: provide a configuration mechanism to inform the IGP that the circuit is type point-to-point irrespective of the physical media type. For the IGP, this implies that it will send protocol packets with the appropriate point-to-point information and expects to receive protocol packets as they would be received on a point-to-point circuit. Over LAN media, the MAC header must contain the correct multicast MAC address to be received by the other side of the connection. For vLAN environments, the MAC header must also contain the proper vLAN ID. In order to allow LAN links used to connect only two routers to be treated as unnumbered point-to-point interfaces, the MAC address resolution and nexthop IP address issues need to be addressed. 4.1 Operation of IS-IS This p2p-over-lan circuit extension for IS-IS is only concerned in pure IP routing and forwarding operation. Since the physically circuit is a broadcast one, the IS-IS protocol packets need to have MAC addresses for this p2p-over-lan circuit. From link layer point of view, those packets are IS-IS LAN packets. The Multi-destination address including AllISs, AllL1ISs and AllL2ISs defined in [ref1] can be used for link layer encapsulation, the use of AllISs is recommended. The circuit needs to have IP address(es) and the p2p IIH over this circuit MUST include the IP interface address(es) as defined in [ref2]. The IP address(es) can be numbered or unnumbered. 4.2 Operation of OSPF OSPF routers supporting the capabilities described herein should support an additional interface configuration parameter specifying the interface topology type. For a LAN (i.e., broadcast capable) interface, the interface may be viewed as a point-to-point interface. Both routers on the LAN will simply join the AllSPFRouters (224.0.0.5) multicast group and send all OSPF packets to 224.0.0.5. This is identical to operation over a physical point-to-point link as described in sections 8.1 and 8.2 of [ref3]. Shen, Zinin, et al Expires February 2001 [Page 3] INTERNET DRAFT P2P OVER LAN August 2001 4.3 IP forwarding and ARP Unlike normal point-to-point IGP circuit, the IP nexthop for the routes using this p2p-over-lan circuit as an outbound interface is not optional. The IP nexthop address has to be a valid interface or internal address on the adjacent router. This address is used by local router to obtain the MAC address for IP packet forwarding. Proxy ARP has to be enabled if the address is not the adjacent interface IP address. In the case where unnumbered IP addresses are used for p2p-over-lan circuit, the source IP address of ARP request and the target interface IP address are usually on different subnets. The ARP should reply only if this is a p2p-over-lan circuit and the source IP address of the ARP request is the same as the neighbor's interface IP address at the other end. The neighbor's address is learned from IGP hello exchanges over this circuit. 4.4 Other MAC address resolution mechanisms In more general cases while p2p-over-lan circuit is used as an unnumbered link, other MAC address resolution mechanisms are needed for IP packet forwarding. For example, if link-state IGP is not configured over this p2p-over-lan link, or Proxy ARP is not enabled on the circuit. The following techniques can be used to acquire the MAC address and/or the next-hop IP address of the remote device on an unnumbered point-to-point LAN link. 1. Static configuration. A router can be statically configured with the MAC address that should be used as the destination MAC address when sending data out of the interface. 2. MAC address gleaning. If a dynamic routing protocol is running between the routers connected to the link, the MAC address of the remote device can be taken from a data-link frame carrying a packet of the corresponding routing protocol. 3. ARP for reference IP address. When a point-to-point link is configured as unnumbered, the router usually associates with it a "reference IP address", that is used as the source IP address in the packets originated for the unnumbered interface. When such an address is known to a router, the router may announce its MAC address by sending a gratuitous ARP message. This solution will also help in the situations where routers calculate the next-hop addresses for the routes through point-to-point interfaces. Since the source IP address in the received routing protocol packet is used as the next- hop address in the route, forwarding an IP packet along such a route will lead to an ARP request submission on the LAN link that will be answered by the remote device. 4. Broadcast/multicast/proprietary. 4.5 Detection of mis-configuration With this p2p-over-lan extension, the difference between a LAN and a point-to-point circuit can be made purely by configuration. It is important to implement the mechanisms for early detection of mis-configuration. If the circuit is configured as point-to-point type and receives LAN hello packets, the router MUST discard the incoming packets; If the circuit is a LAN type and receive point-to-point hello packets, it MUST discard the incoming packets. If the system ID or the router ID of incoming hello packet does not match the system ID or the router ID of already established adjacency over this p2p-over-lan circuit, it MUST discard the packet. The implementation should offer logging and debugging information of the above events. 5. Compatibility considerations Both routers on a LAN must support the p2p-over-lan extension and both must have the LAN segment configured as a p2p-over-lan circuit for successful operation. Both routers MAY also support one of the above listed methods for mapping ip addresses on the link to MAC address, and MUST support proxy ARP on the link. If a proprietary method of IP address to MAC address resolution is used by one router, both routers must be capable of using the same method. Otherwise, the link should be configured as a standard LAN link, with traditional IGP LAN models used. 6. Scalability and deployment considerations There is obvious advantage to use this extension on the LANs that are connected back-to-back or only contain two routers. However, there are tradeoffs when modeling a LAN as multiple vLANs and using this extension since one does sacrifice the inherent scalability benefits of multi-access networks. In general, it will increase the link-state database size, the amount of packets flooded and the route calculation overhead. Network design engineers should carefully balance between the associated overhead. The scalability impact is less of a concern if all the vLANs are within a single OSPF area or ISIS level. Deployment of the described technique brings noticeable benefits from the perspective of IP address usage, the network management and the router configuration. Note, however, that use of the IP unnumbered option for point-to-point LAN links inherits the same problems as those present for serial links, i.e., not being able to ping or monitor a specific interface between routers. 7. Security Issues This document does not introduce any new security issues to ISIS or OSPF. For ARP to support unnumbered IP interface addresses, it needs to verify the p2p-over-lan circuit type described in this document and to verify the ARP packet source interface address to match the IGP adjacency interface IP address. This is due to normal ARP sanity check for common subnet can not be applied in this case. Shen, Zinin, et al Expires February 2001 [Page 4] INTERNET DRAFT P2P OVER LAN August 2001 8. Acknowledgments TBA. 9. References [ref1] 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. [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual Environments. INTERNET-RFC, Internet Engineering Task Force, December 1990. [ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet Engineering Task Force, 1998. 10. Authors' Addresses Naiming Shen Redback Networks 350 Holger Way San Jose, CA, 95134 USA naiming@redback.com Acee Lindem Redback Networks 102 Carric Bend Court Apex, NC 27502 USA acee@redback.com Jenny Yuan Redback Networks 350 Holger Way San Jose, CA, 95134 USA jenny@redback.com Alex Zinin Nexsi Systems 1959 Concourse Drive San Jose, CA 95131 azinin@nexsi.com Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 e-mail: riw@cisco.com Stefano Previdi Cisco Systems, Inc. De Kleetlaan 6A 1831 Diegem - Belgium email: sprevidi@cisco.com Shen, Zinin, et al Expires February 2001 [Page 5] From mshand@cisco.com Fri Aug 3 11:06:53 2001 From: mshand@cisco.com (mike shand) Date: Fri, 03 Aug 2001 11:06:53 +0100 Subject: [Isis-wg] draft-shand-isis-restart-01.txt Message-ID: <4.3.2.7.2.20010803110538.01e24170@jaws.cisco.com> I haven't seen the announcement go by on IETF-announce yet, but the updated version of isis-restart is there now. http://www.ietf.org/internet-drafts/draft-shand-isis-restart-01.txt Mike From Alex Zinin Fri Aug 3 12:12:41 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 3 Aug 2001 04:12:41 -0700 Subject: [Isis-wg] New version of the anti-replay draft. Message-ID: <70401748293.20010803041241@nexsi.com> Folks, Below is the new version of the document. This includes type-133 sub-TLV format as suggested by Hannes and Tony, the CSN sub-TLV (GenID + SN), separate for each packet type, the Key ID sub-TLV, and using link-level keys for SNPs. This seems to be a good enough approximation to start the discussion. I'll also do some slides in London. -- Alex Zinin Network Working Group Alex Zinin Internet Draft Nexsi Systems Expiration Date: February 2002 August 2001 File name: draft-zinin-isis-auth-anti-replay-00.txt Protecting ISIS from replay attacks draft-zinin-isis-auth-anti-replay-00.txt 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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. Abstract This document describes an additional mechanism for ISIS cryptographic authentication that protects ISIS networks from simple packet replay attacks. 1 Motivation The cryptographic authentication mechanism for [ISIS], described in [HMAC] provides basic authentication functionality sufficient for the majority of situations. However, this mechanism does not protect ISIS networks from the replay attacks that can be performed by the attacker if it has direct access to a broadcast segment within an ISIS domain. Zinin [Page 1] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 Because the mechanism described in [HMAC] does not include the notion of "cryptographic sequence number", an attacker can easily replay previously recorded ISIS packets. Examples of these attacks include replaying an empty (listing no neighbor IS) IIH packets and thus causing routers on the segment to destroy the adjacencies with a specific router, replaying CSNP packets and thus artificially attracting ISIS traffic (LSPs) to the segment's DIS, and so on. When used periodically, these attacks can cause global instability in an ISIS domain. This document defines a simple mechanism, similar to the one proposed for the OSPF protocol in [ETIENNE], to protect an ISIS network from the replay attacks by introducing Cryptographic Sequence Number and Generation ID into ISIS packets. The method is compatible with the existing implementations of [HMAC]. In addition to the Cryptographic Sequence Numbers, the document defines transmission of the cryptographic Key IDs that help routers identify the key to be used for authentication when multiple keys are active during the key transition period. It must be noted that the described mechanism does not attempt to increase purely cryptographic strength of the ISIS authentication mechanism, but rather addresses the problems inside [HMAC]. 2 Proposed Solution Both the Cryptographic Sequence Number and the key ID are introduced into the ISIS packets as sub-TLVs of the TLV type-133. The type-133 TLV is considered to be a part of text T while calculating the HMAC- MD5 digest as defined in [HMAC] (i.e., the type-133 TLV is covered by the digest to prevent spoofing of the values inside the TLV). Sub- TLVs are formatted as described in [ISIS-TE]. This document defines the following sub-TLVs: Type Length (octets) Name 1 8 Cryptographic Sequence Number (CSN) 2 2 Cryptographic Key ID (CKID) [HMAC] specifies that ISIS Sequence Number Packets should be authenticated using the area-level authentication key. In order to prevent attacks based on replaying packets recorded on a different network segment, the implementations are encouraged to support SNP authentication using the link-level key. Note that this requires proper configuration on all routers attached to a network segment. This version of the document does not specify the use of the CSN sub- TLV in ISIS LSPs. Instead, the existing LSP Sequence Number and Zinin [Page 2] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 associated LSP processing procedures are used, with the reservations described in [HMAC]. Note, however, that CKID sub-TLV can be used in all ISIS packets, including LSPs. Implementations not supporting described extensions should ignore the TLVs defined herein. 2.1 Cryptographic Sequence Number sub-TLV. The CSN sub-TLV contains the following data: 2 octets of Generation ID 4 octets of Sequence Number A single instance of the Generation ID is maintained by each ISIS process, initially set to zero, and incremented each time the ISIS module is restarted (e.g., when the router reboots). The Generation ID prevents replay attacks using recorded packets from the previous incarnation of the ISIS process. This document does not specify the exact method of storing the value of the Generation ID across the ISIS module or router restarts, however, it is anticipated that the implementations will use some type of non-volatile memory (flash memory, hard disk, etc.) for this purpose. Each ISIS module also maintains a single instance of the Sequence Number for each {interface, packet-type} combination. The Sequence Number is initially set to zero, and incremented each time a packet of the associated type is sent on the associated interface. Maintaining separate Sequence Numbers for different packet types allows the receiving router to diverge the packet processing paths without affecting the authentication properties of the protocol. The document does not specify the procedure for the situations where the Sequence Number for a specific {interface, packet-type} combination reaches its maximum. A possible approach would be to increase the Generation ID on the router and reset Sequence Number values on all interfaces. 2.1.1 Sending ISIS Packets with CSN sub-TLV When constructing an ISIS packet authenticated using [HMAC], the router may include the CSN sub-TLV in the type-133 TLV. If the TLV is included, it should be considered a part of the text for the digest calculation. After the packet has been sent, the implementation must increase the associated Sequence Number. 2.1.2 Receiving ISIS Packets with CSN sub-TLV Zinin [Page 3] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 ISIS implementations supporting described extensions should maintain the received Generation ID and Sequence Number for each {interface, neighbor, packet-type} combination. These values should be set to zero when a new neighbor data structure is created. When receiving an HMAC-authenticated ISIS packet with a type-133 TLV, the router performs the following checks (if the packet is not HMAC- authenticated, but contains the type-133 TLV, the type-133 TLV should be ignored). 1. If the CSN sub-TLV is present, compare the values found in the TLV with the values in the neighbor data structure (for a specific packet type) as described below. a) If the received Generation ID is less than the locally recorded value, the packet should be ignored. b) Otherwise, if the received Generation ID is greater than the locally recorded value, the Sequence Number should not be checked and step d) should be performed. c) Otherwise, if the received Generation ID is equal to the locally recorded value and the received Sequence Number is not greater than the locally recorded value, the packet should be ignored. d) Perform the packet verification procedure as described in [HMAC] and update the neighbor data structure with the received Generation ID and Sequence Number. 2. If the ISIS packet is authenticated using [HMAC], does not contain the CSN sub-TLV, and the router is configured to perform CSN verification on the receiving interface, the ISIS packet should be ignored. Otherwise (the router is not configured to perform CSN verification), the packet should be authenticated as described in [HMAC]. 2.2 Cryptographic Key ID Sub-TLV The CKID Sub-TLV contains the 16-bit ID of the key that was used to authenticate the packet. Depending on the type and level of the packet, the key ID identifies a specific area or link level authentication key when multiple keys are active at the same time. 2.2.1 Sending Packets with CKID sub-TLV When constructing an HMAC-authenticated packet, a router may include the CKID sub-TLV in the type-133 TLV. If included, the CKID sub-TLV Zinin [Page 4] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 should contain the ID of the key that is used to authenticate the packet. 2.2.2 Receiving Packets with CKID sub-TLV When receiving an HMAC-authenticated PDU with the CKID sub-TLV, the receiving router should locate the key associated with the received key ID and use it for the packet authentication procedure. If the receiving router cannot find the key with specified ID or if the key is not active, the received PDU should be ignored. If the CKID sub- TLV is not present in the PDU, the procedures defined in [HMAC] should be followed (i.e., the CKID sub-TLV does not have to be included for an HMAC-signed ISIS packet to be considered authentic, instead it gives the receiving router a "hint" about the key that should be used for authentication when multiple keys are present). This document does not specify the key management procedure, however, the routers need to agree on the key IDs for the packets to be authenticated correctly. 3 Compatibility Issues Implementations not supporting described extensions will ignore the TLVs defined in this document. Also, implementations supporting the new TLVs will interoperate with implementation using [HMAC] only unless explicitly configured to perform sequence number verification, which is expected to be done when all routers on a segment support described mechanism. 4 Security issues This document describes a mechanism that improves security of the ISIS protocol. 5 Acknowledgements The author would like to thank Hannes Gredler, Tony Przygienda, Ran Atkinson, David Hudek and the rest of the ISIS working group for valuable feedback on this document. 6 References [ISIS] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992. [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication" Zinin [Page 5] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt. [ETIENNE] Jerome Etienne. "Proposal to fix OSPF cryptographic authentication flaws". [ISIS-TE] Li, T., Henk Smit. "IS-IS extensions for Traffic Engineering". Work in progress. June 2001. draft-ietf-isis- traffic-03.txt 7 Author's address Alex Zinin Nexsi Systems 1959 Concourse Drive San Jose, CA 95131 azinin@nexsi.com Zinin [Page 6] From Alex Zinin Fri Aug 3 21:33:39 2001 From: Alex Zinin (Alex Zinin) Date: Fri, 3 Aug 2001 13:33:39 -0700 Subject: [Isis-wg] New version of the anti-replay draft. In-Reply-To: <70401748293.20010803041241@nexsi.com> References: <70401748293.20010803041241@nexsi.com> Message-ID: <103313634.20010803133339@nexsi.com> Folks, One thing that I'd like to be discussed is using CSNs in LSPs. The document does not specify this, but I think this needs attention. My opinion is LSP's native sequence number is not good enough (we lose the state when the LSP is purged, the SN space is reused each reload, etc.), and addressing all packet types but one does not make much sense since all packets are the same from the replaying perspective, the only difference is consequences. A possible approach would be (I mentioned this on the list already) to authenticate LSPs at the link level, i.e., using the link key and CSN, make sure CSNs are not taken into consideration when deciding which LSP is more recent, and ref_cnt the keys to make sure they're not freed when they become inactive, or ISIS is disabled on the interface (or the interface is removed), but there are LSPs that still need the key for periodic verification (btw, this part is not spelled out in HMAC either). Comments are welcome. -- Alex Zinin Friday, August 03, 2001, 4:12:41 AM, Alex Zinin wrote: > Folks, > Below is the new version of the document. This includes > type-133 sub-TLV format as suggested by Hannes and Tony, the > CSN sub-TLV (GenID + SN), separate for each packet type, > the Key ID sub-TLV, and using link-level keys for SNPs. > This seems to be a good enough approximation to start > the discussion. > I'll also do some slides in London. From prz@redback.com Fri Aug 3 21:49:21 2001 From: prz@redback.com (Tony Przygienda) Date: Fri, 03 Aug 2001 13:49:21 -0700 Subject: [Isis-wg] agenda for London ... References: <3B689C83.9B895DDE@redback.com> Message-ID: <3B6B0E50.6F2F4A3C@redback.com> small revision, we'll have > 10min Administrativa > x draft status > x new RFCs > > 15min draft-hermelin-ext-lsp-frags Amir > 15min draft-ietf-isis-transient Danny > 20min draft-shand-isis-restart Mike > 20min draft-ietf-isis-wg-multi-topology Naiming 15min draft-shen-isis-ospf-p2p-over-lan-01 ? > > 15min draft-ietf-isis-auth-anti-replay Alex > 5min draft-ietf-isis-wg-tlv-codepoints Tony P. > > Any other open issues to be discussed at the end after > this agenda unless anybody objects since technically this draft didn't make the cut-off date (but it's not the only one). thanks -- tony From selvarajr@www.com Sat Aug 4 03:27:44 2001 From: selvarajr@www.com (R Selvaraj) Date: Fri, 3 Aug 2001 19:27:44 -0700 Subject: [Isis-wg] Doubt regarding Default Informatoin Originate Message-ID: <200108040227.TAA19291@mail4.bigmailbox.com> Hi, I would like to know the advantage of originating default information in L1 LSPs. Since Att bit itself is sufficient for finding default route in a L1 area then what is the significant of originating default informaton in L1 LSPs. Pls let me clarified. Thanks, Selva. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com From sprevidi@cisco.com Sun Aug 5 16:04:33 2001 From: sprevidi@cisco.com (stefano previdi) Date: Sun, 05 Aug 2001 17:04:33 +0200 Subject: [Isis-wg] Doubt regarding Default Informatoin Originate In-Reply-To: <200108040227.TAA19291@mail4.bigmailbox.com> Message-ID: <4.3.2.7.2.20010804082031.0367a538@brussels.cisco.com> At 04:27 04/08/2001, R Selvaraj wrote: >Hi, > >I would like to know the advantage of originating default information in >L1 LSPs. Since Att bit itself is sufficient for finding default route in a >L1 area then what is the significant of originating default informaton in >L1 LSPs. >Pls let me clarified. there are many reasons why you prefer to have an IP-specific default route: - your network is a single level-1 area. - your AS boundary is a level-1 router and you want to use it as default exit point. - ATT bit is only set based on clns information while an IP default route can be advertised based on IP information. - probably other good reasons... s. From Manav Bhatia" Hi, OSPF and ISIS are both very similar in a lot of respects and i wanted to know as to which protocol scales better when deployed as an IGP ? Secondly, with the coming of IPv6 which protocol holds a better future. If we are using OSPF then we will have to write a completely new protocol and our IPv4/IPv6 transition router running a dual stack will have to run both the copies of OSPF .. This can be avoided with ISIS wherein we have 20 byte address field length. Any help on this would be very much appreciated. Thanks and Regards, Manav "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From swatirstogi@yahoo.com Mon Aug 6 06:07:46 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Sun, 5 Aug 2001 22:07:46 -0700 (PDT) Subject: [Isis-wg] Help Reqd ! Message-ID: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Hi, I am new to this protocol and i am going thru the RFC 1142 and am facing the following problems :- (1) What does rfc 1142 mean by "adjaceny" .. Is it an interface on which the packets are sent ?? If yes, then what is a link ? (2) What is a circuit ? (3) I was going through the presentation given by Dave Katz where he compares OSPF and ISIS. What is troubling me is the fact that in one of his slides he says that OSPF runs over IP while ISIS runs besides IP. Now in Dual ISIS we encapsulate our ISIS packet over the IP. So we are still using IP. (4) As far as i understand we send CSNPs to list the sequence numbers of one or more LSPs operating ... and as an ACK. Why do we then send Partial SNPs ?? Thanks and regards, Swati Rastogi __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From Manav Bhatia" Message-ID: <0f6501c11e53$76dfecb0$da046c6b@Manav> > (1) What does rfc 1142 mean by "adjaceny" .. Is it an > interface on which the packets are sent ?? If yes, > then what is a link ? AFAIK adjacencies tell me what all routers/systems are connected to my router. Link refers to the actual hardware interface. > (2) What is a circuit ? Adjacencies can be of many types .. end system,L1 or L2 reachable address prefixes. Within each type based we have circuit ID which differentiaties as to whether it is a non broadcast circuit OR broadcast circuit when running level 1 decision process . .etc (Refer to 7.2.7 rfc 1142) > (3) I was going through the presentation given by Dave > Katz where he compares OSPF and ISIS. What is > troubling me is the fact that in one of his slides he > says that OSPF runs over IP while ISIS runs besides > IP. Now in Dual ISIS we encapsulate our ISIS packet > over the IP. So we are still using IP. No Idea ! > (4) As far as i understand we send CSNPs to list the > sequence numbers of one or more LSPs operating ... and > as an ACK. Why do we then send Partial SNPs ?? CSNPs are routing packets sent out of the designated router (on a LAN) to summarize all the LSPs in its database. These are recieved by other direct neighbouring ISs on the LAN and are used to maintain synchronization of link state databases amongst all ISs.The synchronization procedure is different on LANs and point to point links. On a point to point link, all the LSPs transmitted must be explicitly acknowledged by a Partial SNP from the other router. Unacknowledged LSPs are retransmitted. Regards, Manav Bhatia _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From rameshrr@future.futsoft.com Mon Aug 6 13:37:20 2001 From: rameshrr@future.futsoft.com (Rayapureddi Ramesh) Date: Mon, 6 Aug 2001 18:07:20 +0530 Subject: [Isis-wg] Reg: Over Load bit Message-ID: <000f01c11e74$8abe2000$1305a8c0@future.futsoft.com> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C11EA2.A47AEFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, ISO/IEC FCD 10589 ISIS Standardis saying that "As a result of network misconfiguration, or certain transitory conditions, it is possible that there may be insufficient resources available to store the a received Link State PDU. When this occurs, an IS needs to take certain steps to ensure that if its LSP database becomes inconsistent with other IS's, that these ISs do not rely on forwarding paths through the overloaded IS". Take an example.. R1-----------------R2--------------------R3 | | | | | | R4------------------R5 Here R1 forward to R2 if any packet destined to routers R3, R4 and R5 by considering the forwarding path through R2 (i.e since R1 have route to R3, R4 and R5 with R2 as next hop). If R2 advertises an LSP with Overload Bit set, then R1 should not forward to R2 if any packet destined to R3, R4 and R5 since here R1 will not consider forwarding path through R2 (i.e it will not install routes to R3, R4 and R5 with next hop as R2). Am I correct?. Here my doubt is---- will this applicable to IP information (in LSP packet) also OR only to OSI information only while processing the LSPs received from overloaded IS?. Please clarify doubt. Regards, Ramesh ------=_NextPart_000_0010_01C11EA2.A47AEFE0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhcMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCAAGABIABwAAAAEAAAEB A5AGAFwHAAAjAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAEwAAAFJlZzogT3ZlciBMb2FkIGJpdAAAAgFxAAEAAAAWAAAAAcEedIkZ7plDYoo6EdWsAABQ 2rspVAAAAgEdDAEAAAAhAAAAU01UUDpSQU1FU0hSUkBGVVRVUkUuRlVUU09GVC5DT00AAAAACwAB DgAAAABAAAYOAH6vfHQewQECAQoOAQAAABgAAAAAAAAAoiDoO2Fn1BGqzQBQ2rspVMKAAAADABQO AQAAAAsAHw4BAAAAAgEJEAEAAAC9AwAAuQMAAMIGAABMWkZ19/rHcwMACgByY3BnMTI1FjIA+Atg bg4QMDMzTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0DGAOYwBQCwMLtSBIaSwH CqIKhAqASVNPL0mARUMgRkNEIA9A8DU4OSAUwBTABgABkIcSgAsRBAAgc2F5C4CYZyB0EPAFQCJB BCBEYSAJcHN1bAVAbyhmIG4RMHcFsGsghm0EAAWgbmZpZwhwtRdwaQIgLBhgBcBjBJBfAZALgBdA GcAAgXQFsHnvGmACIBagGeJzGiAbQBxQqQQgcG8EEGkCYGUXRN8XUASQHTAAwBuAYh0wC4D/GCAB IA3gCJACMBfyCGEacN0XwXYLcAtgHRNvFtAbUU8dMh0wF+IacGl2CYAgLkwLgBkAFjF0HTBQRLBV LiBXHbAa0WgWsfhvY2MIcBwxA5EWARig7wmABCAggQGQax0wGnYgsPxlcCTDCfAYICDjF3EGkMMc UQQgTFNQIBZwAZH+YREgHjEFoAeCC4AZUQCQfyXhHxED8BdQGGAdohXRJ18cMR1WKEEUwAQgZCCQ blsqEBfxbBuAAiAgAhByvncWghchCrAXUCTBaANgrHVnKfAhEm8hwHIJAG5hAQAh4BTAIiLgFApU QyUiA5FleGFtC1BldC4uFAQgMbAxVzJJUmQxLTNOUjIzTzQiM/cx7zbfMkZ8N284FTXfOw//N/85 DzofP088Pz1PPl9Dj20yxTQ0rzRANRQKFARI/x3CMyAspiByNFAnIgBwG4D9CrBjJTAFQAEAILAL gCHR3yCBLeEigBEQB/AzGiBFAO8kESHgRkAxsGIbgwCQBIEfFxQdMCy9LbdIsShpLv8dMACQKQBH sxDwIcBKdEhzX0sbKcNIsSgwGJF4BUBoeG9wKTFGFGUYgFHCZH8ukRngESAXwQOgJ6Ipw0/5LpUg QhxhESEqsiMhR9H+c1JwGDAh4CvySA9JH0ok30sMTyQds0fRA/BsAyAr8v9MJk0fTi4cYVv3HnEB kFwR/0qDJMNQnynwUiZR4jRQUqZZFARBbRXQG5FyIXF0Nj9jG0eDbRuAK8B1Yp8cckUyL3Vb8yNT YXALUPsN4CA2SSfAC4AssQDAGeLXTsFUtFkEKRfQbB9gVVDuUixxLFEggU8V8GjbayP2dyNgHSFw A2AfoU8hTMS/J6EEICF3A1IufGSsUB0gfSgyYwtgBoFl5WMbFARSfGVnCxEcMHM1MOAHkGi/Qm91 33bvMkUUBBHhAHkQAAAAAwAJWQMAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA AoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUA AD9xAQADAAiACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAC4AIIAYAAAAAAMAAAAAAAABG AAAAAAGFAAAAAAAAHgASgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAFoAI IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAXgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAA AAALAHuACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAIB+A8BAAAAEAAAAKIg6DthZ9QRqs0A UNq7KVQCAfoPAQAAABAAAACiIOg7YWfUEarNAFDauylUAgH7DwEAAABQAAAAAAAAADihuxAF5RAa obsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5OVFxtYWlsXHJh bWVzaHJyLnBzdAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDBBMjIwRTgzQjYx NjdENDExQUFDRDAwNTBEQUJCMjk1NDg0RDAyODAwAAAAAAMABhAR6qD2AwAHEL0DAAADABAQAAAA AAMAERAAAAAAHgAIEAEAAABlAAAASEksSVNPL0lFQ0ZDRDEwNTg5SVNJU1NUQU5EQVJESVNTQVlJ TkdUSEFUIkFTQVJFU1VMVE9GTkVUV09SS01JU0NPTkZJR1VSQVRJT04sT1JDRVJUQUlOVFJBTlNJ VE9SWUNPTgAAAABHyw== ------=_NextPart_000_0010_01C11EA2.A47AEFE0-- From jlearman@cisco.com Mon Aug 6 13:51:21 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 6 Aug 2001 08:51:21 -0400 Subject: [Isis-wg] ISIS and OSPF References: <0d8a01c11e2f$9e855940$da046c6b@Manav> Message-ID: <007401c11e78$b9c9bf40$8c02530a@sevsisters> ----- Original Message ----- From: Manav Bhatia To: Sent: Monday, August 06, 2001 12:23 AM Subject: [Isis-wg] ISIS and OSPF > Hi, > OSPF and ISIS are both very similar in a lot of respects and i wanted to > know as to which protocol scales better when deployed as an IGP ? > Secondly, with the coming of IPv6 which protocol holds a better future. If > we are using OSPF then we will have to write a completely new protocol and > our IPv4/IPv6 transition router running a dual stack will have to run both > the copies of OSPF .. This can be avoided with ISIS wherein we have 20 byte > address field length. I don't know enough about OSPF to answer your questions. However, the address length of IS-IS isn't much of a help because it is always an OSI address (NSAP), not an IP address, and every router that is operating IS-IS has an NSAP. IPV6 can be supported in IS-IS for the same reasons that IPV4 could be -- because new reachability information can be added in the form of new TLV-encoded options. I would guess that this is equally true for OSPF, although it may be necessary to continue to give each OSPF router an IPV4 address with certain uniqueness requirements. Regards, Jeff > Any help on this would be very much appreciated. > > Thanks and Regards, > Manav > > "C is not a big language, and is not well served by a big book." -- K&R2 > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From jlearman@cisco.com Mon Aug 6 14:05:31 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 6 Aug 2001 09:05:31 -0400 Subject: [Isis-wg] Help Reqd ! References: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Message-ID: <007501c11e78$ba1daba0$8c02530a@sevsisters> ----- Original Message ----- From: Swati Rastogi To: Sent: Monday, August 06, 2001 1:07 AM Subject: [Isis-wg] Help Reqd ! > Hi, > I am new to this protocol and i am going thru the RFC > 1142 and am facing the following problems :- These terms are defined in ISO 10589, which must be read for a thorough understanding of IS-IS. > (1) What does rfc 1142 mean by "adjaceny" .. Is it an > interface on which the packets are sent ?? If yes, > then what is a link ? An adjacency is a (circuit, l2 address) pair identifying a means of reaching an immediate neighbor. So, an adjacency is like a neighbor, except that you can have multiple adjacencies to a single neighbor, e.g., if it has to L2 addresses on one link or two links between you and it. > (2) What is a circuit ? A link. > (3) I was going through the presentation given by Dave > Katz where he compares OSPF and ISIS. What is > troubling me is the fact that in one of his slides he > says that OSPF runs over IP while ISIS runs besides > IP. Now in Dual ISIS we encapsulate our ISIS packet > over the IP. So we are still using IP. Nope. The encapsulation does not change; IS-IS runs directly over the link layer and does not use IP or OSI layer 3 addressing in communications between neighbors. > (4) As far as i understand we send CSNPs to list the > sequence numbers of one or more LSPs operating ... and > as an ACK. Why do we then send Partial SNPs ?? As ACKs on point-to-point links. The rules are different for point-to-point links and broadcast links and I don't have the details on the top of my head, but in general, PSNPs are used as ACKs, and CSNPs are used periodically. > Thanks and regards, > Swati Rastogi > > > > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From sprevidi@cisco.com Mon Aug 6 14:09:10 2001 From: sprevidi@cisco.com (stefano previdi) Date: Mon, 06 Aug 2001 15:09:10 +0200 Subject: [Isis-wg] Reg: Over Load bit In-Reply-To: <000f01c11e74$8abe2000$1305a8c0@future.futsoft.com> Message-ID: <4.3.2.7.2.20010806150002.0338dfd8@brussels.cisco.com> At 14:37 06/08/2001, Rayapureddi Ramesh wrote: >Hi, > >ISO/IEC FCD 10589 ISIS Standardis saying that "As a result of network >misconfiguration, or certain transitory conditions, it is possible that >there may be insufficient resources available to store the a received Link >State PDU. When this occurs, an IS needs to take certain steps to ensure >that if its LSP database becomes inconsistent with other IS's, that these >ISs do not rely on forwarding paths through the overloaded IS". > >Take an example.. > > R1-----------------R2--------------------R3 > | | > | | > | | > R4------------------R5 > > >Here R1 forward to R2 if any packet destined to routers R3, R4 and R5 by >considering the forwarding path through R2 (i.e since R1 have route to R3, >R4 and R5 with R2 as next hop). > >If R2 advertises an LSP with Overload Bit set, then R1 should not forward to >R2 if any packet destined to R3, R4 and R5 since here R1 will not consider >forwarding path through R2 (i.e it will not install routes to R3, R4 and R5 >with next hop as R2). > >Am I correct?. yes. >Here my doubt is---- >will this applicable to IP information (in LSP packet) also OR only to OSI >information only while processing the LSPs received from overloaded IS?. When running SPF, you don't move into the TENT list the neighbors of a node if such node has the overload-bit set. Therefore you won't continue to build the sub-tree after the overload-bit-node. This means that any route advertised by nodes downstream to the overload-bit-node will simply be never calculated, no matter their address family. s. From Manav Bhatia" <007401c11e78$b9c9bf40$8c02530a@sevsisters> Message-ID: <123401c11e7a$a8e5cb40$da046c6b@Manav> Thanks Jeff for the reply ! > of new TLV-encoded options. I would guess that this is equally true for > OSPF, although it may be necessary to continue to give each OSPF router > an IPV4 address with certain uniqueness requirements. But the very reason why IPv6 is coming into picture is the paucity of IPv4 addresses. So if OSPF has to support unique IPv4 addresses then how can it work in an IPv6 environment ? Secondly, in the present scenario (IPv4) which is considreded as a better IGP .. in terms of scalability ? Regards, Manav _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Larmer@CommSense.Net Mon Aug 6 14:52:48 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Mon, 6 Aug 2001 09:52:48 -0400 Subject: [Isis-wg] Help Reqd ! In-Reply-To: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Message-ID: > Hi, > I am new to this protocol and i am going thru the RFC > 1142 and am facing the following problems :- > > (1) What does rfc 1142 mean by "adjaceny" .. Is it an > interface on which the packets are sent ?? If yes, > then what is a link ? >From an IS perspective, a directly attached IS neighbour becomes an adjacency if the Broadcast or Non-Broadcast initialization process succeeds between the 2 neighbours. This includes IIH PDU Acceptance Tests, Area Address Tests, Adjacency Tests and Adjacency Communication Tests. Once a FULL adjacency has been formed, the 2 IS neighbours will exchange routing information. > (2) What is a circuit ? A circuit references a link level connection, which connects at least 2 IS neighbours together so they may form an adjacency. Circuit-IDs identify individual links for purposes of path pruning and detection of 2-way communication. > (3) I was going through the presentation given by Dave > Katz where he compares OSPF and ISIS. What is > troubling me is the fact that in one of his slides he > says that OSPF runs over IP while ISIS runs besides > IP. Now in Dual ISIS we encapsulate our ISIS packet > over the IP. So we are still using IP. What Dave means here is that OSPF control packets are encapsulated in IP packets. Whereas IS-IS control packets are encapsulated in CLNS packets. Both OSPF and ISIS forward Data packets in their native format, IP packets for IP data and CLNS packets for OSI data. A Dual ISIS will forward both IP and CLNS Data packets. > (4) As far as i understand we send CSNPs to list the > sequence numbers of one or more LSPs operating ... and > as an ACK. Why do we then send Partial SNPs ?? This is dependant upon the link type, Broadcast (LAN) or Non-Broadcast (Point-to-Point). On a Broadcast circuit we elect a Designated Router for purposes of synchronizing the LSP Databases amongst a common set of LAN ISs. The DR periodically advertises the state of its LSP Database to the rest of the LAN via CSNPs. If a CSNP does not contain a particular LSP, which another IS on the LAN currently possesses in its LSP Database, the detecting IS will flood that LSP onto the LAN. However, if the CSNP contains a LSP reference to an LSP, which is not present in an adjacent LAN IS LSP Database, that detecting IS will send a PSNP requesting that particular LSP. The DR, upon receipt of the PSNP, will then flood that LSP onto the given LAN. On a Non-Broadcast circuit, CSNPs are sent at initialization and/or during circuit restart. This lets the adjacent IS know what the remote IS possesses in its LSP database(s). Both sides of the link set the SRMflag for all LSPs contained within their respective LSP databases prior to sending the CSNPs (there are some rules which apply). The CSNP LSP Entries are then processed to determine if the LSP Databases are synchronized. CSNP referenced LSP Entries which are non-referenced or newer in the remote LSP Database are requested via a PSNP and/or transmitted as a result of the SRMflag being set. CSNP referenced LSP Entries which are non-existent or older in the remote LSP Database are updated by the local IS as a result of receiving a PSNP request or as a result of the SRMflag being set (one in the same). No action is taken for CSNP referenced LSP Entries which are the same (no PSNP sent, just clear the SRMflag, receipt of the same LSP is equal to receipt of a PSNP acknowledgement). Once an LSP has been received on a non-broadcast link, a PSNP is sent as an acknowledgement to that LSP. Hope this helps? Cheers, Ken Larmer From jlearman@cisco.com Mon Aug 6 15:08:03 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 06 Aug 2001 10:08:03 -0400 Subject: [Isis-wg] ISIS and OSPF In-Reply-To: <123401c11e7a$a8e5cb40$da046c6b@Manav> References: <0d8a01c11e2f$9e855940$da046c6b@Manav> <007401c11e78$b9c9bf40$8c02530a@sevsisters> Message-ID: <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.com> At 09:21 AM 8/6/2001, Manav Bhatia wrote: >Thanks Jeff for the reply ! >> of new TLV-encoded options. I would guess that this is equally true for >> OSPF, although it may be necessary to continue to give each OSPF router >> an IPV4 address with certain uniqueness requirements. >But the very reason why IPv6 is coming into picture is the paucity of IPv4 >addresses. So if OSPF has to support unique IPv4 addresses then how can it >work in an IPv6 environment ? First, I'm making a guess about OSPF. Let's wait and see what someone with more OSPF knowledge says. Second, there will be many more end systems than routers, so if only routers have IPV4 addresses, then there may be an order of magnitude or two of growth before the problem becomes critical again. Also, I said that there were uniqueness requirements, but I don't know precisely what these uniqueness requirements are. It is likely that routers belonging to one AS can use local IP addresses that are unique only within that AS. >Secondly, in the present scenario (IPv4) which is considreded as a better >IGP .. in terms of scalability ? Can't help you there! Studies that I have done with IS-IS indicate that it is surprisingly scalable in terms of bandwidth usage, even with relatively unreliable routers with short MTBFs (like days!). The practical limit of IS-IS is probably related to its two-level hierarchy rather than N-level hierarchy. Radia Perlman has ideas on how it could be extended to support that, but so far there is little interest. Evidently the scalability limits of IS-IS have not been reached, or else those who run IS-IS and have scalability issues are not making themselves heard on this forum. The biggest problem with scalability will probably be how long it takes to stabilize after a topology change. The greater the span of the sub-domain (area or routing domain), the greater the time. Multi-level IS-IS could be used to improve this, in hierarchical topologies that could take advantage of it. Regards, Jeff >Regards, >Manav > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com From chris@bravara.com Mon Aug 6 03:32:21 2001 From: chris@bravara.com (Chris Flores) Date: Sun, 5 Aug 2001 21:32:21 -0500 Subject: [Isis-wg] Help Reqd ! In-Reply-To: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Message-ID: My response is in-line. I hope it helps. Thanks. Chris -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Swati Rastogi Sent: Monday, August 06, 2001 12:08 AM To: isis-wg@spider.juniper.net Subject: [Isis-wg] Help Reqd ! Hi, I am new to this protocol and i am going thru the RFC 1142 and am facing the following problems :- (1) What does rfc 1142 mean by "adjaceny" .. Is it an interface on which the packets are sent ?? If yes, then what is a link ? cf: The IS-IS protocol builds (and maintains) adjacencies between IS's or routers. A pair of neighboring IS's are said to be adjacent after they exchange CNSPs and synchronize their databases. A separate adjacency is created for each neighbor (on a circuit) and for each level of routing (on broadcast media). A link is a communication path between two neighbors. (2) What is a circuit ? (3) I was going through the presentation given by Dave Katz where he compares OSPF and ISIS. What is troubling me is the fact that in one of his slides he says that OSPF runs over IP while ISIS runs besides IP. Now in Dual ISIS we encapsulate our ISIS packet over the IP. So we are still using IP. cf: See RFC 1195. The IS-IS PDUs are transmitted directly over the underlying link layer services without the need for mutual encapsulation. (4) As far as i understand we send CSNPs to list the sequence numbers of one or more LSPs operating ... and as an ACK. Why do we then send Partial SNPs ?? cf: A PSNP is used to request the latest LSP from another IS. In addition, the PSNP is an ACK for the receipt of a new LSP. http://external.juniper.net/mailman/listinfo/isis-wg From swatirstogi@yahoo.com Mon Aug 6 16:02:38 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Mon, 6 Aug 2001 20:32:38 +0530 Subject: [Isis-wg] Doubt on L2 router Message-ID: <134a01c11e88$d917b680$da046c6b@Manav> Hi All, In OSPF if the designated router fails then the backup designated router takes over and all of this is done automatically. But in ISIS we have a router configured as a L2 router drilled in the profiles. What would happen if this router goes down for some reason ? Since this is the only link via which the routers inside this area can communicate to the outside world. Does it imply that the routers are now blackholed ! This would imply that the protocol has a single point of failure .. Regards, Swati Rastogi _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jlearman@cisco.com Mon Aug 6 16:01:46 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 06 Aug 2001 11:01:46 -0400 Subject: [Isis-wg] Help Reqd ! In-Reply-To: References: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Message-ID: <4.3.2.7.2.20010806105246.01f1af10@dingdong.cisco.com> At 09:52 AM 8/6/2001, Ken Larmer wrote: >> Hi, >> I am new to this protocol and i am going thru the RFC >> 1142 and am facing the following problems :- >> >> (1) What does rfc 1142 mean by "adjaceny" .. Is it an >> interface on which the packets are sent ?? If yes, >> then what is a link ? > > From an IS perspective, a directly attached IS neighbour becomes an >adjacency if the Broadcast or Non-Broadcast initialization process succeeds >between the 2 neighbours. This includes IIH PDU Acceptance Tests, Area >Address Tests, Adjacency Tests and Adjacency Communication Tests. Once a >FULL adjacency has been formed, the 2 IS neighbours will exchange routing >information. Well put. Don't forget that end systems can also have adjacencies, although this may be less important for IP than for OSI, where it is critical. >> (2) What is a circuit ? > >A circuit references a link level connection, which connects at least 2 IS >neighbours together so they may form an adjacency. Circuit-IDs identify >individual links for purposes of path pruning and detection of 2-way >communication. Again, End System adjacencies can appear on a circuit, even if there are no other ISs on the link. This may be of no importance for an IP-only router. >> (3) I was going through the presentation given by Dave >> Katz where he compares OSPF and ISIS. What is >> troubling me is the fact that in one of his slides he >> says that OSPF runs over IP while ISIS runs besides >> IP. Now in Dual ISIS we encapsulate our ISIS packet >> over the IP. So we are still using IP. > >What Dave means here is that OSPF control packets are encapsulated in IP >packets. Whereas IS-IS control packets are encapsulated in CLNS packets. >Both OSPF and ISIS forward Data packets in their native format, IP packets >for IP data and CLNS packets for OSI data. A Dual ISIS will forward both IP >and CLNS Data packets. Be careful when you read "encapsulated in CLNS packets". It is absolutely correct, but does NOT mean that they are encapsulated in CLNP packets. It does mean that they are OSI connectionless layer three packets and therefore begin with a Network Layer Protocol ID (variously called NPID, NLPI, or NLPID). After that first octet, IS-IS and CLNP headers have little in common. Regards, Jeff >> (4) As far as i understand we send CSNPs to list the >> sequence numbers of one or more LSPs operating ... and >> as an ACK. Why do we then send Partial SNPs ?? > >This is dependant upon the link type, Broadcast (LAN) or Non-Broadcast >(Point-to-Point). > >On a Broadcast circuit we elect a Designated Router for purposes of >synchronizing the LSP Databases amongst a common set of LAN ISs. The DR >periodically advertises the state of its LSP Database to the rest of the LAN >via CSNPs. If a CSNP does not contain a particular LSP, which another IS on >the LAN currently possesses in its LSP Database, the detecting IS will flood >that LSP onto the LAN. However, if the CSNP contains a LSP reference to an >LSP, which is not present in an adjacent LAN IS LSP Database, that detecting >IS will send a PSNP requesting that particular LSP. The DR, upon receipt of >the PSNP, will then flood that LSP onto the given LAN. > >On a Non-Broadcast circuit, CSNPs are sent at initialization and/or during >circuit restart. This lets the adjacent IS know what the remote IS possesses >in its LSP database(s). Both sides of the link set the SRMflag for all LSPs >contained within their respective LSP databases prior to sending the CSNPs >(there are some rules which apply). The CSNP LSP Entries are then processed >to determine if the LSP Databases are synchronized. CSNP referenced LSP >Entries which are non-referenced or newer in the remote LSP Database are >requested via a PSNP and/or transmitted as a result of the SRMflag being >set. CSNP referenced LSP Entries which are non-existent or older in the >remote LSP Database are updated by the local IS as a result of receiving a >PSNP request or as a result of the SRMflag being set (one in the same). No >action is taken for CSNP referenced LSP Entries which are the same (no PSNP >sent, just clear the SRMflag, receipt of the same LSP is equal to receipt of >a PSNP acknowledgement). Once an LSP has been received on a non-broadcast >link, a PSNP is sent as an acknowledgement to that LSP. > >Hope this helps? > >Cheers, >Ken Larmer > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Manav Bhatia" Message-ID: <135c01c11e8b$4f403560$da046c6b@Manav> If a single level 2 router looses connectivity to the level 2 backbone then this router will indicate in its L1 routing packets that it is not "attached", thereby allowing level 1 routers in the area to route traffic for outside of the area to a different L2 router. Level 1 routers therfore route traffic to destinations outside of their area only to L2 routers which indicate in their level 1 LSPs that they are "attached" Coming back to your question .. yes the networks get blackholed ! There is no provision for use of L1 routers to repair a level 2 partition ! Hope this helps Manav ----- Original Message ----- From: "Swati Rastogi" To: "isis-wg" Sent: Monday, August 06, 2001 8:32 PM Subject: [Isis-wg] Doubt on L2 router > Hi All, > In OSPF if the designated router fails then the backup designated router > takes over and all of this is done automatically. But in ISIS we have a > router configured as a L2 router drilled in the profiles. What would happen > if this router goes down for some reason ? Since this is the only link via > which the routers inside this area can communicate to the outside world. > Does it imply that the routers are now blackholed ! > > This would imply that the protocol has a single point of failure .. > > Regards, > Swati Rastogi > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jlearman@cisco.com Mon Aug 6 16:45:21 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 06 Aug 2001 11:45:21 -0400 Subject: [Isis-wg] Doubt on L2 router In-Reply-To: <134a01c11e88$d917b680$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010806113921.01ecee58@dingdong.cisco.com> At 11:02 AM 8/6/2001, Swati Rastogi wrote: >Hi All, >In OSPF if the designated router fails then the backup designated router >takes over and all of this is done automatically. But in ISIS we have a >router configured as a L2 router drilled in the profiles. What would happen >if this router goes down for some reason ? Since this is the only link via >which the routers inside this area can communicate to the outside world. >Does it imply that the routers are now blackholed ! Are you confusing "designated router" with "L2 router"? In IS-IS, they're separate -- there is one L1 designated router on a LAN, and the election is automatic. On a LAN with more than one L2 router, there is also one L2 DR, and it is elected in the same way. If your L1 area has only one router connecting it to other areas, then you have a single point of failure that has nothing to do with IS-IS. If your area has multiple connections to other areas, then you don't. (There is also a practical requirement that your L2 routers are connected within your area, either directly or by L2 routers, if your area is used for transit routes between other areas.) >This would imply that the protocol has a single point of failure .. > >Regards, >Swati Rastogi > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Larmer@CommSense.Net Mon Aug 6 18:58:26 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Mon, 6 Aug 2001 13:58:26 -0400 Subject: [Isis-wg] Doubt on L2 router In-Reply-To: <4.3.2.7.2.20010806113921.01ecee58@dingdong.cisco.com> Message-ID: > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman > Sent: Monday, August 06, 2001 11:45 AM > To: Swati Rastogi > Cc: isis-wg > Subject: Re: [Isis-wg] Doubt on L2 router > > > At 11:02 AM 8/6/2001, Swati Rastogi wrote: > >Hi All, > >In OSPF if the designated router fails then the backup designated router > >takes over and all of this is done automatically. But in ISIS we have a > >router configured as a L2 router drilled in the profiles. What > would happen > >if this router goes down for some reason ? Since this is the > only link via > >which the routers inside this area can communicate to the outside world. > >Does it imply that the routers are now blackholed ! > > Are you confusing "designated router" with "L2 router"? > In IS-IS, they're separate -- there is one L1 designated router > on a LAN, and the election is automatic. On a LAN with > more than one L2 router, there is also one L2 DR, and > it is elected in the same way. > > If your L1 area has only one router connecting it to other > areas, then you have a single point of failure that has > nothing to do with IS-IS. If your area has multiple > connections to other areas, then you don't. (There is > also a practical requirement that your L2 routers are > connected within your area, either directly or by L2 > routers, if your area is used for transit routes between > other areas.) Of course, as with most things in life, there are exceptions. If you have an IS, which has multiple L1 IS instances configured, in order to get between L1 instances, some vendors set the Attached bit in the L1 LSP (LSP Number = 0) which they generate. While this allows for connectivity between L1 areas (each L1 IS instance is a separate L1 area "Sub-Domain"), it does not take into account some of the basic rules Jeff mentioned for setting the attached bit. That is, the attached bit will be set, regardless of whether or not your L2 Instance is connected to another L2 area. As a consequence, you may be able to get between L1 instances, but you may not be able to get outside of the physical router you are connected to if the L2 backbone is not contiguous. Or, you may take a less than desirable path to your destination because the "nearest L2 router" may contain a less desirable route. This is why it may make more sense in some situations to advertise an IP default route instead of relying on the "Attached Bit". Cheers, Ken Larmer From Alex Zinin Tue Aug 7 02:41:29 2001 From: Alex Zinin (Alex Zinin) Date: Tue, 7 Aug 2001 02:41:29 +0100 Subject: [Isis-wg] ISIS and OSPF In-Reply-To: <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.com> References: <0d8a01c11e2f$9e855940$da046c6b@Manav> <007401c11e78$b9c9bf40$8c02530a@sevsisters> <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.com> Message-ID: <64955986.20010807024129@nexsi.com> Manav, Regarding IPv6 support in OSPF, we have RFC2740 (so-called OSPFv3) for this purpose. There, each router needs to be assigned a unique 32-bit RID, but this does not mean that each router needs a unique IPv4 address. RID is just an unsigned integer with no addressing semantic. Regarding the scalability comparison, you'll have to ask the vendor you're using, as it depends on the actual implementations rather than the properties of the protocols. -- Alex Zinin Monday, August 06, 2001, 3:08:03 PM, Jeff Learman wrote: > At 09:21 AM 8/6/2001, Manav Bhatia wrote: >>Thanks Jeff for the reply ! >>> of new TLV-encoded options. I would guess that this is equally true for >>> OSPF, although it may be necessary to continue to give each OSPF router >>> an IPV4 address with certain uniqueness requirements. >>But the very reason why IPv6 is coming into picture is the paucity of IPv4 >>addresses. So if OSPF has to support unique IPv4 addresses then how can it >>work in an IPv6 environment ? > First, I'm making a guess about OSPF. Let's wait and see what someone > with more OSPF knowledge says. Second, there will be many more end > systems than routers, so if only routers have IPV4 addresses, then > there may be an order of magnitude or two of growth before the problem > becomes critical again. Also, I said that there were uniqueness > requirements, but I don't know precisely what these uniqueness > requirements are. It is likely that routers belonging to one > AS can use local IP addresses that are unique only within that AS. >>Secondly, in the present scenario (IPv4) which is considreded as a better >>IGP .. in terms of scalability ? > Can't help you there! Studies that I have done with IS-IS indicate > that it is surprisingly scalable in terms of bandwidth usage, even > with relatively unreliable routers with short MTBFs (like days!). > The practical limit of IS-IS is probably related to its two-level > hierarchy rather than N-level hierarchy. Radia Perlman has ideas > on how it could be extended to support that, but so far there is > little interest. Evidently the scalability limits of IS-IS have not > been reached, or else those who run IS-IS and have scalability > issues are not making themselves heard on this forum. > The biggest problem with scalability will probably be how long it > takes to stabilize after a topology change. The greater the span > of the sub-domain (area or routing domain), the greater the time. > Multi-level IS-IS could be used to improve this, in hierarchical > topologies that could take advantage of it. > Regards, > Jeff >>Regards, >>Manav >> >> >> >>_________________________________________________________ >>Do You Yahoo!? >>Get your free @yahoo.com address at http://mail.yahoo.com > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From swatirstogi@yahoo.com Tue Aug 7 03:27:37 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Tue, 7 Aug 2001 07:57:37 +0530 Subject: [Isis-wg] ISIS and OSPF References: <0d8a01c11e2f$9e855940$da046c6b@Manav> <007401c11e78$b9c9bf40$8c02530a@sevsisters> <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.com> <64955986.20010807024129@nexsi.com> Message-ID: <139801c11ee8$907c8490$da046c6b@Manav> Hi Alex, Would this imply that OSPF is "as much ready" as ISIS for IPv6. If the IGP being used is OSPF then we will have to run two copies on the dual IP stack transition router ..but as i understood with ISIS we can work with a single copy of IGP running on the box. If we run two instances of OSPF then we face the problems of resource struggle, processor overheads, etc. What I always thought was that ISIS might prove handy in such a situation. Regards, Swati Rastogi ----- Original Message ----- From: "Alex Zinin" To: "Jeff Learman" Cc: "Manav Bhatia" ; Sent: Tuesday, August 07, 2001 7:11 AM Subject: Re: [Isis-wg] ISIS and OSPF > Manav, > > Regarding IPv6 support in OSPF, we have RFC2740 (so-called OSPFv3) > for this purpose. There, each router needs to be assigned a unique > 32-bit RID, but this does not mean that each router needs a unique > IPv4 address. RID is just an unsigned integer with no addressing > semantic. > > Regarding the scalability comparison, you'll have to ask the vendor > you're using, as it depends on the actual implementations rather than > the properties of the protocols. > > -- > Alex Zinin > > Monday, August 06, 2001, 3:08:03 PM, Jeff Learman wrote: > > > At 09:21 AM 8/6/2001, Manav Bhatia wrote: > >>Thanks Jeff for the reply ! > >>> of new TLV-encoded options. I would guess that this is equally true for > >>> OSPF, although it may be necessary to continue to give each OSPF router > >>> an IPV4 address with certain uniqueness requirements. > >>But the very reason why IPv6 is coming into picture is the paucity of IPv4 > >>addresses. So if OSPF has to support unique IPv4 addresses then how can it > >>work in an IPv6 environment ? > > > First, I'm making a guess about OSPF. Let's wait and see what someone > > with more OSPF knowledge says. Second, there will be many more end > > systems than routers, so if only routers have IPV4 addresses, then > > there may be an order of magnitude or two of growth before the problem > > becomes critical again. Also, I said that there were uniqueness > > requirements, but I don't know precisely what these uniqueness > > requirements are. It is likely that routers belonging to one > > AS can use local IP addresses that are unique only within that AS. > > >>Secondly, in the present scenario (IPv4) which is considreded as a better > >>IGP .. in terms of scalability ? > > > Can't help you there! Studies that I have done with IS-IS indicate > > that it is surprisingly scalable in terms of bandwidth usage, even > > with relatively unreliable routers with short MTBFs (like days!). > > The practical limit of IS-IS is probably related to its two-level > > hierarchy rather than N-level hierarchy. Radia Perlman has ideas > > on how it could be extended to support that, but so far there is > > little interest. Evidently the scalability limits of IS-IS have not > > been reached, or else those who run IS-IS and have scalability > > issues are not making themselves heard on this forum. > > > The biggest problem with scalability will probably be how long it > > takes to stabilize after a topology change. The greater the span > > of the sub-domain (area or routing domain), the greater the time. > > Multi-level IS-IS could be used to improve this, in hierarchical > > topologies that could take advantage of it. > > > Regards, > > Jeff > > > > >>Regards, > >>Manav > >> > >> > >> > >>_________________________________________________________ > >>Do You Yahoo!? > >>Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Alex Zinin Tue Aug 7 11:25:46 2001 From: Alex Zinin (Alex Zinin) Date: Tue, 7 Aug 2001 11:25:46 +0100 Subject: [Isis-wg] ISIS and OSPF In-Reply-To: <139801c11ee8$907c8490$da046c6b@Manav> References: <0d8a01c11e2f$9e855940$da046c6b@Manav> <007401c11e78$b9c9bf40$8c02530a@sevsisters> <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.com> <64955986.20010807024129@nexsi.com> <139801c11ee8$907c8490$da046c6b@Manav> Message-ID: <1361300630.20010807112546@nexsi.com> Swati, > Hi Alex, > Would this imply that OSPF is "as much ready" as ISIS for IPv6. Shoot higher, OSPFv3 is already deployed. > If the IGP > being used is OSPF then we will have to run two copies on the dual IP stack > transition router .. Yes, if you need the same box to route both IPv4 and IPv6, you'll have to have OSPFv2 and OSPFv3 running on it. > but as i understood with ISIS we can work with a single > copy of IGP running on the box. Correct. > If we run two instances of OSPF then we face the problems of resource > struggle, processor overheads, etc. For some reason, this does not scare me much. Routers already run multiple instances of an IGP. Also, think about an IGP running together with BGP. This does not mean, however, that I do not see the difference between one process vs 2 processes. > What I always thought was that ISIS might prove handy in such a situation. The fact that ISIS uses L2 as the transport has its pros and its cons. One of its beauties is that the basic mechanisms (interface, neighbor LSDB maintenance, etc.) are completely independent from the L3 semantics. Same beauty can byte you sometimes though, but there ain't no such thing as a free lunch. :) Alex. From cmartin@gnilink.net Tue Aug 7 22:44:08 2001 From: cmartin@gnilink.net (Martin, Christian) Date: Tue, 7 Aug 2001 17:44:08 -0400 Subject: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt Message-ID: <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.com> Folks, I have some comments on the draft that I'd like to address with the WG. I apologize for cutting this so close to the meeting, but this is the first chance I've had to address it. A while back I began considering how IS-IS could be made to support PTP behavior over BMA networks. The driving force behind this was primarily the ability to assign arbitrary, per-neighbor metric information to individual neighbors. A second benefit would be the elimination of pseudonode exposion when a large amount of PTP LAN links were used to interconnect routers. I sent an email detailing the need to the WG, but there was little response. Some notable vendors also displayed little interest. The only suggestion I received, in fact, was to use PPPoE! After reviewing the draft, I have some concern about the utility of the proposal, and whether or not it satisfies a real need. While it does have merit and will help in many situations, the scope should be expanded to address some more complex situations. Comments of course are welcome. In regards to OSPF: OSPF currently supports NBMA networks. What we are attempting to do here is create PtMP (of where MP can be P if there are only two nodes on a LAN) networks out of BMA networks in order to support PTP type behavior, from a Djiktsra perspective, correct? This is in OSPF today. You can build NBNA networks on LANs and specify neighbors explicitly, with associated metrics. The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion based on the configured neighbor IP. As I see it, the only benefit the draft provides is the elimination of DR election (and the corresponding elimination of pseudonodes on PTP links), which can be done by making the interface point-to-multipoint (although requiring configuration). The major vendors support this feature today (I use it!). In regards to IS-IS: This was the tricky part, as there was nothing in 10589 or 1195 (or any subsequent draft) that proposes how to do this. Furthermore, the interaction between CLNS and IP makes the address resolution issue a bit trickier. Anyway, here is what I was thinking of. 1) Create support for point-to-multipoint in IS-IS. This has some additional benefit outside of the scope of LANs, as it allows the protocol to be used on real NBMA networks like Frame Relay and ATM. The way to do this is either cumbersome for the vendor or cumbersome for the operator. It also may break the current separation between subnetwork-dependent and independent functions, which may not sit well with ISO (or some IETF members). Let's address 802.3 networks first. As I see it, ISIS Hellos should be sent as PTP hellos. This means sending them to a MAC address and an interface. The interface is then made point-to-multipoint. For each configured adjacency, assign a circuit ID based on the current mechanism in 10589. The PTP hellos must be encapsulated in 802.3 frames, of course, but they should be unicast. CSNP should not be sent every 10 seconds, but rather in response to SRM flag changes, etc. Every router knows how to forward traffic across a LAN without passing it through the DIS, based on SNPA information from adjacencies. Forwarding would be still based on SNPA information, which is easily extracted from the configured MAC address of the neighbor (hence, the adjacency). An additional feature could be to address the neighbors based on NSAP, and then use ES-IS or some other address resolution mechanism to determine the MAC address. Either way, forwarding is an issue local to the router, and should not be much of an issue. This is where the 'cumbersome-ness' shifts. As far as switched WANs, the same principles could be applied. However, there is the issue of mapping NSAPs to layer 2 circuit IDs (DLCIs, VCCs, etc) that isn't addressed outside of X.25 in ISO (AFAIK). This may be too much of an undertaking, although it may be worth consideration if there is sufficient interest. Some possiblilities would be to use static mapping of NSAPs to l2cid, which is common today, and then specifiy the neighbor, the interface, and the metric. Finally, this information could be extended to support draft-ietf-isis-traffic-03.txt, by including link coloring, reserved bandwidth, etc, although the RSVP piece becomes trickier in the way it is encoded on LANs and in the way one reserves bandwidth across virtual adjacencies in a shared media environment. Either way, they are workable issues, and should be addressed given the growing ubiquity of TE-extension support. In summary: 1) Keep the changes at the subnetwork-dependent layer as much as possible, i.e., make IS-IS think that a LAN link is a PTP link (or a collection of PtP links). This makes the modifications easier, development-wise. 2) Allow for both directly connected routers using LAN media as well as directed adjacencies across BMA networks for metric adjustment. 3) If the specification is about removing DR election (which as it stands now, it is), state this explicitly. I still think this does not address all the issues, particlularly, the use of switches as media termination and router hubbing devices. 4) Optionally allow IS-IS to use NSAP addresses as neighbors and build some kind of address resolution mechanism to direct PTP hellos to the appropriate MAC address. 5) Allow per neighbor metric adjustment, and possibly pseudolink coloring and reservable/reserved BW info. 6) Optionally consider mechanisms to build NBMA support into IS-IS for switched WAN media. PtMP mode would be best, although it requires additional flooding, etc. NBMA mode, as in OSPF, is nice but may be difficult to do in most cases (except for SMDS) ~8^> 7) If it is desired to just turn a LAN link into a PTP link, then this is fine. However, if what I propose is acceptable, then the error checking portion of the draft needs to be modified to check for PtMP behavior first. Finally, I would think that OSPF implementation modifications should be submitted separately to the OSPF-WG, and not to the IS-IS WG. As stated earlier, a good deal of the desired functionality specified in the draft is already specified in RFC 2328 and later versions, so it may be unnecessary. Sorry this is so late - you may treat these comments as my contribution to the London meeting, in absentia of course. ;) Best Regards, -chris From swatirstogi@yahoo.com Tue Aug 7 16:06:26 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Tue, 7 Aug 2001 20:36:26 +0530 Subject: [Isis-wg] OSI ?? Message-ID: <000801c11f9a$4c189a70$da046c6b@Manav> Hi All, This is slightly off-track but any help in this regard will be really very much appreciated. Here goes my long list of doubts (1) Is CLNP (OSI) analogous to IP (TCP/IP) .. If so then why have i never come across a CLNP packet format (analogy .. we have IP packet formats) (2) Routing is making sure that a packet reaches the destination safe 'n sound .. while a routing protocol ensures that the out of the available paths choosing the best one. So if ISIS runs along IP then who is taking care of the "routing" aspect i.e taking the packet from the source to the destination. ISIS is a routing protocol and its job shud be to just choose the optimal path .. once its done that it can then hand over the packet to CLNP for forwarding .. So where did i loose the track ?? (3) In my transport layer i could be running tp0, tp1, tp2 etc. How does the routing module know which transport layer to forward the packet to. There is only 1 byte field "SEL" aka selector in the NSAP addressing .. is this used to determine this ?? To summarize .. how when a module recvs a packet from the data link layer determines whether to use CONP or CLNP in the networking layer and then later which transport layer protocol is to be used in the transport layer! Which transport layer protocol does ISIS use ?? Please Help .. i am very confused with all the OSI terminology ! Thanks and Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Alex Zinin Wed Aug 8 05:32:11 2001 From: Alex Zinin (Alex Zinin) Date: Wed, 8 Aug 2001 05:32:11 +0100 Subject: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt In-Reply-To: <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.com> References: <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.com> Message-ID: <15966485551.20010808053211@nexsi.com> Christian, A comment regarding OSPF---essentially, we're not changing anything in OSPF, we're only saying an implementation should be able to treat LAN link as a p2p network type. Your suggestion to implement p2mp in ISIS might make sense in a generic context, however, it would introduce unnecessary complexity to the p2p lan case, which is addressed simply by (again) treating the link as p2p (and hence automagically sending p2p iih's, using psnps, etc.) and agreeing on the MAC address. I think if there's enough interest in p2mp in ISIS, it should be addressed separately. Wrt the merits of the draft, it's not only eliminating DR/DIS election, it is also reducing the number of LSAs/LSPs in the domain, some flooding benefits, using ip unnumbered, etc. If you see any problems that are not addressed within the context of the draft, please elaborate. Regarding a separate OSPF doc, I don't see the critical mass of changes in OSPF (in fact, there are none) to justify splitting of a complete document. Thanks, -- Alex Zinin Tuesday, August 07, 2001, 10:44:08 PM, Martin, Christian wrote: > Folks, > I have some comments on the draft that I'd like to address with the WG. I > apologize for cutting this so close to the meeting, but this is the first > chance I've had to address it. > A while back I began considering how IS-IS could be made to support PTP > behavior over BMA networks. The driving force behind this was primarily the > ability to assign arbitrary, per-neighbor metric information to individual > neighbors. A second benefit would be the elimination of pseudonode exposion > when a large amount of PTP LAN links were used to interconnect routers. I > sent an email detailing the need to the WG, but there was little response. > Some notable vendors also displayed little interest. The only suggestion I > received, in fact, was to use PPPoE! After reviewing the draft, I have some > concern about the utility of the proposal, and whether or not it satisfies a > real need. While it does have merit and will help in many situations, the > scope should be expanded to address some more complex situations. Comments > of course are welcome. > In regards to OSPF: > OSPF currently supports NBMA networks. What we are attempting to do here is > create PtMP (of where MP can be P if there are only two nodes on a LAN) > networks out of BMA networks in order to support PTP type behavior, from a > Djiktsra perspective, correct? This is in OSPF today. You can build NBNA > networks on LANs and specify neighbors explicitly, with associated metrics. > The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion > based on the configured neighbor IP. As I see it, the only benefit the > draft provides is the elimination of DR election (and the corresponding > elimination of pseudonodes on PTP links), which can be done by making the > interface point-to-multipoint (although requiring configuration). The major > vendors support this feature today (I use it!). > In regards to IS-IS: > This was the tricky part, as there was nothing in 10589 or 1195 (or any > subsequent draft) that proposes how to do this. Furthermore, the > interaction between CLNS and IP makes the address resolution issue a bit > trickier. Anyway, here is what I was thinking of. > 1) Create support for point-to-multipoint in IS-IS. This has some > additional benefit outside of the scope of LANs, as it allows the protocol > to be used on real NBMA networks like Frame Relay and ATM. The way to do > this is either cumbersome for the vendor or cumbersome for the operator. It > also may break the current separation between subnetwork-dependent and > independent functions, which may not sit well with ISO (or some IETF > members). Let's address 802.3 networks first. > As I see it, ISIS Hellos should be sent as PTP hellos. This means sending > them to a MAC address and an interface. The interface is then made > point-to-multipoint. For each configured adjacency, assign a circuit ID > based on the current mechanism in 10589. The PTP hellos must be > encapsulated in 802.3 frames, of course, but they should be unicast. CSNP > should not be sent every 10 seconds, but rather in response to SRM flag > changes, etc. > Every router knows how to forward traffic across a LAN without passing it > through the DIS, based on SNPA information from adjacencies. Forwarding > would be still based on SNPA information, which is easily extracted from the > configured MAC address of the neighbor (hence, the adjacency). An > additional feature could be to address the neighbors based on NSAP, and then > use ES-IS or some other address resolution mechanism to determine the MAC > address. Either way, forwarding is an issue local to the router, and should > not be much of an issue. This is where the 'cumbersome-ness' shifts. > As far as switched WANs, the same principles could be applied. However, > there is the issue of mapping NSAPs to layer 2 circuit IDs (DLCIs, VCCs, > etc) that isn't addressed outside of X.25 in ISO (AFAIK). This may be too > much of an undertaking, although it may be worth consideration if there is > sufficient interest. Some possiblilities would be to use static mapping of > NSAPs to l2cid, which is common today, and then specifiy the neighbor, the > interface, and the metric. > Finally, this information could be extended to support > draft-ietf-isis-traffic-03.txt, by including link coloring, reserved > bandwidth, etc, although the RSVP piece becomes trickier in the way it is > encoded on LANs and in the way one reserves bandwidth across virtual > adjacencies in a shared media environment. Either way, they are workable > issues, and should be addressed given the growing ubiquity of TE-extension > support. > In summary: > 1) Keep the changes at the subnetwork-dependent layer as much as possible, > i.e., make IS-IS think that a LAN link is a PTP link (or a collection of PtP > links). This makes the modifications easier, development-wise. > 2) Allow for both directly connected routers using LAN media as well as > directed adjacencies across BMA networks for metric adjustment. > 3) If the specification is about removing DR election (which as it stands > now, it is), state this explicitly. I still think this does not address all > the issues, particlularly, the use of switches as media termination and > router hubbing devices. > 4) Optionally allow IS-IS to use NSAP addresses as neighbors and build some > kind of address resolution mechanism to direct PTP hellos to the appropriate > MAC address. > 5) Allow per neighbor metric adjustment, and possibly pseudolink coloring > and reservable/reserved BW info. > 6) Optionally consider mechanisms to build NBMA support into IS-IS for > switched WAN media. PtMP mode would be best, although it requires > additional flooding, etc. NBMA mode, as in OSPF, is nice but may be > difficult to do in most cases (except for SMDS) ~8^> > 7) If it is desired to just turn a LAN link into a PTP link, then this is > fine. However, if what I propose is acceptable, then the error checking > portion of the draft needs to be modified to check for PtMP behavior first. > Finally, I would think that OSPF implementation modifications should be > submitted separately to the OSPF-WG, and not to the IS-IS WG. As stated > earlier, a good deal of the desired functionality specified in the draft is > already specified in RFC 2328 and later versions, so it may be unnecessary. > Sorry this is so late - you may treat these comments as my contribution to > the London meeting, in absentia of course. ;) > Best Regards, > -chris > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From cmartin@gnilink.net Wed Aug 8 06:53:07 2001 From: cmartin@gnilink.net (Martin, Christian) Date: Wed, 8 Aug 2001 01:53:07 -0400 Subject: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt Message-ID: <94B9091E1149D411A45C00508BACEB359CDCF2@entmail.gnilink.com> Alex, Thanks for the response. Comments inline... > Christian, > > A comment regarding OSPF---essentially, we're not changing > anything in OSPF, we're only saying an implementation should > be able to treat LAN link as a p2p network type. Understood. > > Your suggestion to implement p2mp in ISIS might make sense in a > generic context, however, it would introduce unnecessary > complexity to the p2p lan case, which is addressed simply > by (again) treating the link as p2p (and hence automagically > sending p2p iih's, using psnps, etc.) and agreeing on > the MAC address. This is one of the benefits I see. I was hoping it could be extended to the more general case. It is not uncommon for routers to be connected via switches to other routers in an attempt to minimize port costs and maximize bandwidth. If you connect 10 routers to a switch (in the same VLAN of course), all costs (to the pseudonode) are the same. Directed adjacencies (while more complex, configuration-wise) are a cost effective way of adjusting metrics without using dedicated, PTP links )or VLANs). > I think if there's enough interest in p2mp in ISIS, it should > be addressed separately. Perhaps this should be the case. I can generate a draft and submit it separately. Care to collaborate? > Wrt the merits of the draft, it's not only eliminating > DR/DIS election, it is also reducing the number of LSAs/LSPs in > the domain, some flooding benefits, using ip unnumbered, etc. Many network operators feel that IP unnumbered presents several operational drawbacks, particularly when troubleshooting link problems. I for one am not opposed to it, but I could not convince my Ops staff that there was enough merit in reducing IP usage to justify the reduction in operational utility of addressed links (for pinging, traceroute, ER-LSPs, etc). Nevertheless, others may have this requirement, so I am not diametrically opposed to it. Either way, you mention this, so I am ok with it. > If you see any problems that are not addressed within the > context of the draft, please elaborate. I don't disagree with anything in the draft - I just think that it is fairly specific in scope. By expanding the scope to a more generic case, a specification and subsequent implementations would not need additional rewrites to cover other requirements. For what it's worth, the draft does do some nice things ( things that caused me to scrap GigE for POP interconnect in favor of POS - at a higher cost per Mb ). I was just thinking that some additional work would yield an IS-IS implementation that covered the generic case. > Regarding a separate OSPF doc, I don't see the critical mass > of changes in OSPF (in fact, there are none) to justify splitting > of a complete document. I do not write code for a vendor, so I cannot in fairness speak to this directly. But I would think that the OSPF-WG would be interested in this work, as it does require an implementation to treat a LAN as PTP - which may not be trivial. Just a thought. > > Thanks, > Thanks, as well. -chris From Manav Bhatia" Message-ID: <011301c11fe4$34096500$da046c6b@Manav> > > (1) Is CLNP (OSI) analogous to IP (TCP/IP) .. If so then why have i never > come across a CLNP packet format (analogy .. we have IP packet formats) Refer to ISO/IEC 8473, Section 7 > (2) Routing is making sure that a packet reaches the destination safe 'n > sound .. while a routing protocol ensures that the out of the available > paths choosing the best one. So if ISIS runs along IP then who is taking > care of the "routing" aspect i.e taking the packet from the source to the > destination. ISIS is a routing protocol and its job shud be to just choose > the optimal path .. once its done that it can then hand over the packet to > CLNP for forwarding .. So where did i loose the track ?? ISIS protocol is designed to work in close conjunction with ISO 8473 and ISO 9542. The latter is used to establish connectivity and reachability between end systems and Intermediate systems. Data is carried by ISO 8473. It provides connectionless mode network service. > (3) In my transport layer i could be running tp0, tp1, tp2 etc. How does the > routing module know which transport layer to forward the packet to. There is > only 1 byte field "SEL" aka selector in the NSAP addressing .. is this used > to determine this ?? For ISIS you dont access the upper transport layer .. and hence you dont need to know that .. I hope i am right .. SEL byte is always zero for Intermediate systems > To summarize .. how when a module recvs a packet from the data link layer > determines whether to use CONP or CLNP in the networking layer and then > later which transport layer protocol is to be used in the transport layer! The OSI pdu has a "network layer protocol identifier" parameter in its fixed part .. which probably tells about whether its CLNP or CONP. > > Which transport layer protocol does ISIS use ?? It wont be running on top of any transport layer. > > Please Help .. i am very confused with all the OSI terminology ! Regards, Manav Bhatia > > Thanks and Regards, > Swati > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From swatirstogi@yahoo.com Wed Aug 8 09:53:17 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Wed, 8 Aug 2001 14:23:17 +0530 Subject: [Isis-wg] OSI ?? References: <000801c11f9a$4c189a70$da046c6b@Manav> <011301c11fe4$34096500$da046c6b@Manav> Message-ID: <018801c11fe7$95230050$da046c6b@Manav> > > (2) Routing is making sure that a packet reaches the destination safe 'n > > sound .. while a routing protocol ensures that the out of the available > > paths choosing the best one. So if ISIS runs along IP then who is taking > > care of the "routing" aspect i.e taking the packet from the source to the > > destination. ISIS is a routing protocol and its job shud be to just choose > > the optimal path .. once its done that it can then hand over the packet to > > CLNP for forwarding .. So where did i loose the track ?? > > ISIS protocol is designed to work in close conjunction with ISO 8473 and ISO > 9542. The latter is used to establish connectivity and reachability between > end systems and Intermediate systems. Data is carried by ISO 8473. It > provides connectionless mode network service. > Does it imply that all ISIS PDUs like L1 lan/p2p IIS Hello, L1/2 LSPs, L1/2 CSNPs, L1/2 PSNPs form the data part in the ISO 8473 data PDU ? Quoting Jeff . . " Be careful when you read "encapsulated in CLNS packets". It is absolutely correct, but does NOT mean that they are encapsulated in CLNP packets. It does mean that they are OSI connectionless layer three packets and therefore begin with a Network Layer Protocol ID (variously called NPID, NLPI, or NLPID). After that first octet, IS-IS and CLNP headers have little in common." He says that ISIS packets are not encapsulated in CLNP packets .. Moreover he also mentions that ISIS and CLNP headers have a little in common except for NLPID ? Does it imply that there will be different values in NLPID for CLNP,CONP and ISIS packets ?? Pl. clarify Thanks and Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From sachidananda_k@hotmail.com Wed Aug 8 15:23:14 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Wed, 08 Aug 2001 14:23:14 +0000 Subject: [Isis-wg] Doubts on Traffic Engineering Message-ID: Hello, I have some doubts related to the traffic engineering related draft associated with IS - IS. According to the Draft draft-ietf-isis-traffic-03.txt, certain TLVs are modified to add Information on traffic Engineering. These are: 1. IS Reachability TLV 2. IP Reachability TLV My questions: Queries Regarding the Extended IS Reachability TLV ------------------------------------------------------------- 1. Sub TLV: 3 Description: Administrative Group Query: a. Who assigns the Adminstrative Group for the Router. Is it a configurable parameter ? b. Is this sub-TLV a must or optional ? ------------------------------------------------------------- 2. Sub TLV: 9, 10 & 11 Query: a. How do we come to know about the Maximum Link bandwidth of the Link ? b. Are there any Functional Computation for this purpose ? c. Or can this be included as a configurable Parameter? d. Is this sub-TLV a must or optional ? -------------------------------------------------------------- 3. Sub TLV: 18 Description: Traffic Engineering Default metric Query: a. Is this a configurable Parameter ? b. Is this sub-TLV optional or must ? ------------------------------------------------------------ Queries Regarding Extended IP Reachability TLV Are there any sub-TLVs defined for this TLV after the publishing of the draft ? ------------------------------------------------------------ I was also wondering if the implementation compliant with this draft is to transmit all the TLVs (IP internal reachibility, IP external reachibility and IP extended reachibility) or should it transmit either 2 or 1 of these depending on circumstances. Can you please suggest any standard/draft that answers all my questions if at all there is any. I shall be obliged to receive early response. Thanking you in advance for all the responses. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From sachidananda_k@hotmail.com Wed Aug 8 15:55:30 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Wed, 08 Aug 2001 14:55:30 +0000 Subject: [Isis-wg] Adjacency type Message-ID: Hello, I have some doubts related to the adjacency type. According to my understanding there are 3 different types of adjacencies: ES adjacency; L1 adjacency; and L2 adjacency. My question is: Let me take a setup consisting of 3 IS: A, B and C. where:- IS B is a L1/L2 IS. IS A is L1 only IS. IS c is L2 only IS. If c is adjacent to B, then the adjacency type between B and C should be L2 adjacency. If A is adjacent to B, then should the adjacency type be L2 adjacency or should it be L1 adjacenc? I shall be obliged to get my doubt clarified. Thanking you in advance for all the responses received. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From sachidananda_k@hotmail.com Wed Aug 8 15:57:40 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Wed, 08 Aug 2001 14:57:40 +0000 Subject: [Isis-wg] Doubts on adjacency type Message-ID: Hello, I have some doubts related to the adjacency type. According to my understanding there are 3 different types of adjacencies: ES adjacency; L1 adjacency; and L2 adjacency. Let me take a setup consisting of 3 IS: A, B and C. where:- IS B is a L1/L2 IS. IS A is L1 only IS. IS c is L2 only IS. If c is adjacent to B, then the adjacency type between B and C should be L2 adjacency. My question is: If A is adjacent to B, then should the adjacency type be L2 adjacency or should it be L1 adjacenc? I shall be obliged to get my doubt clarified. Thanking you in advance for all the responses received. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From tgol@laurelnetworks.com Wed Aug 8 16:08:30 2001 From: tgol@laurelnetworks.com (Tayfun Gol) Date: Wed, 08 Aug 2001 11:08:30 -0400 Subject: [Isis-wg] Doubts on adjacency type References: Message-ID: <3B7155EE.36CBCB40@laurelnetworks.com> Sachidananda K wrote: > Hello, > > I have some doubts related to the adjacency type. According to my > understanding there are 3 different types of adjacencies: ES adjacency; L1 > adjacency; and L2 adjacency. > > Let me take a setup consisting of 3 IS: A, B and C. > where:- > IS B is a L1/L2 IS. > IS A is L1 only IS. > IS c is L2 only IS. > If c is adjacent to B, then the adjacency type between B and C should be L2 > adjacency. > > My question is: > If A is adjacent to B, then should the adjacency type be L2 adjacency or > should it be L1 adjacenc? > It will be an L1 adjacency ( of course in case there is at least one area address in common ) -- Tayfun Gol > > I shall be obliged to get my doubt clarified. > Thanking you in advance for all the responses received. > Sachi > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From sachidananda_k@hotmail.com Wed Aug 8 16:20:51 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Wed, 08 Aug 2001 15:20:51 +0000 Subject: [Isis-wg] Doubts on adjacency type Message-ID: Hello, I have some doubts related to the adjacency type. According to my understanding there are 3 different types of adjacencies: ES adjacency; L1 adjacency; and L2 adjacency. Let me take a setup consisting of 3 IS: A, B and C. where:- IS B is a L1/L2 IS. IS A is L1 only IS. IS c is L2 only IS. If c is adjacent to B, then the adjacency type between B and C should be L2 adjacency. My question is: If A is adjacent to B, then should the adjacency type be L2 adjacency or should it be L1 adjacency? I shall be obliged to get my doubt clarified. Thanking you in advance for all the responses received. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From dave.humphrey@virgin.net Wed Aug 8 16:21:01 2001 From: dave.humphrey@virgin.net (Dave Humphrey) Date: Wed, 8 Aug 2001 16:21:01 +0100 Subject: [Isis-wg] Adjacency type In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Following your example. C will make a L2 adjancency with B. A will make an L1 adjacency with B. A cannot make L2 adjacencies it is not configured to do so. Basically a box with an interface configured to work at both levels will make adjacencies with other box's at the levels at which they are configured. On a LAN a box will generate L1 and L2 hellos separately to find adjacencies. On a p2p circuit there is only one hello type and the circuit type field is used to determine whether the advertiser can make an L1, L2 or both adjacency. Dave Humphrey - -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Sachidananda K Sent: 08 August 2001 15:56 To: isis-wg@spider.juniper.net Subject: [Isis-wg] Adjacency type Hello, I have some doubts related to the adjacency type. According to my understanding there are 3 different types of adjacencies: ES adjacency; L1 adjacency; and L2 adjacency. My question is: Let me take a setup consisting of 3 IS: A, B and C. where:- IS B is a L1/L2 IS. IS A is L1 only IS. IS c is L2 only IS. If c is adjacent to B, then the adjacency type between B and C should be L2 adjacency. If A is adjacent to B, then should the adjacency type be L2 adjacency or should it be L1 adjacenc? I shall be obliged to get my doubt clarified. Thanking you in advance for all the responses received. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBO3FXZdDzf3p4iWAnEQIJnQCgofZJgZnU1y+lASNS7x9TkzabxeoAnisH hYFsXTqDHRU9XH2aKXhUU6eY =QMV0 -----END PGP SIGNATURE----- From jlearman@cisco.com Wed Aug 8 18:40:33 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 08 Aug 2001 13:40:33 -0400 Subject: [Isis-wg] OSI ?? In-Reply-To: <000801c11f9a$4c189a70$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010808112629.00ba85f0@dingdong.cisco.com> Swati, At 11:06 AM 8/7/2001, Swati Rastogi wrote: >Hi All, >This is slightly off-track but any help in this regard will be really very >much appreciated. > >Here goes my long list of doubts > >(1) Is CLNP (OSI) analogous to IP (TCP/IP) .. If so then why have i never >come across a CLNP packet format (analogy .. we have IP packet formats) Yes, CLNP provides very similar services to IP. You don't see packet formats everywhere because it never became popular -- mostly because of the incredible success of IP. >(2) Routing is making sure that a packet reaches the destination safe 'n >sound .. while a routing protocol ensures that the out of the available >paths choosing the best one. So if ISIS runs along IP then who is taking >care of the "routing" aspect i.e taking the packet from the source to the >destination. IS-IS sends its packets directly over the link layer -- IP is not involved. There are two exceptions to this, (a) partition repair tunneling and (b) Integrated IS-IS over IP tunnels. (a) didn't work until a rather recent correction, and (b) was never popular. Ignore both of these until you have everything else VERY well understood. >ISIS is a routing protocol and its job shud be to just choose >the optimal path .. once its done that it can then hand over the packet to >CLNP for forwarding .. So where did i loose the track ?? You are correct and that's how it works. >(3) In my transport layer i could be running tp0, tp1, tp2 etc. How does the >routing module know which transport layer to forward the packet to. There is >only 1 byte field "SEL" aka selector in the NSAP addressing .. is this used >to determine this ?? >To summarize .. how when a module recvs a packet from the data link layer >determines whether to use CONP or CLNP in the networking layer and then >later which transport layer protocol is to be used in the transport layer! These are not IS-IS questions, so I will reply separately. >Which transport layer protocol does ISIS use ?? None, as mentioned above. >Please Help .. i am very confused with all the OSI terminology ! You're not the first! >Thanks and Regards, >Swati >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Wed Aug 8 18:42:05 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 08 Aug 2001 13:42:05 -0400 Subject: [Isis-wg] OSI ?? In-Reply-To: <018801c11fe7$95230050$da046c6b@Manav> References: <000801c11f9a$4c189a70$da046c6b@Manav> <011301c11fe4$34096500$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010808113114.01d74cb8@dingdong.cisco.com> At 04:53 AM 8/8/2001, Swati Rastogi wrote: >> > (2) Routing is making sure that a packet reaches the destination safe 'n >> > sound .. while a routing protocol ensures that the out of the available >> > paths choosing the best one. So if ISIS runs along IP then who is taking >> > care of the "routing" aspect i.e taking the packet from the source to >the >> > destination. ISIS is a routing protocol and its job shud be to just >choose >> > the optimal path .. once its done that it can then hand over the packet >to >> > CLNP for forwarding .. So where did i loose the track ?? >> >> ISIS protocol is designed to work in close conjunction with ISO 8473 and >ISO >> 9542. The latter is used to establish connectivity and reachability >between >> end systems and Intermediate systems. Data is carried by ISO 8473. It >> provides connectionless mode network service. >> >Does it imply that all ISIS PDUs like L1 lan/p2p IIS Hello, L1/2 LSPs, L1/2 >CSNPs, L1/2 PSNPs form the data part in the ISO 8473 data PDU ? >Quoting Jeff . . No, none of these are carried in the data part of the 8473 data PDU. >" Be careful when you read "encapsulated in CLNS packets". It is absolutely >correct, but does NOT mean that they are encapsulated in CLNP packets. It >does mean that they are OSI connectionless layer three packets and therefore >begin with a Network Layer Protocol ID (variously called NPID, NLPI, or >NLPID). After that first octet, IS-IS and CLNP headers have little in >common." > >He says that ISIS packets are not encapsulated in CLNP packets .. Moreover >he also mentions that ISIS and CLNP headers have a little in common except >for NLPID ? >Does it imply that there will be different values in NLPID for CLNP,CONP and >ISIS packets ?? Yes, except for CONS, which is more complicated (remember, the network access protocol for CONS is X.25, and there is no standard protocol to implement X.25 in the service provider's network). CLNP is 0x81, ESIS is 0x82, ISIS is 0x83, IDRP has 0x84 (but doesn't use it), and Network Layer Security Protocol (ISO NLSP) uses 0x85. Jeff From Larmer@CommSense.Net Wed Aug 8 18:42:00 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Wed, 8 Aug 2001 13:42:00 -0400 Subject: [Isis-wg] OSI ?? In-Reply-To: <000801c11f9a$4c189a70$da046c6b@Manav> Message-ID: Hi, Let me try to explain the difference between CLNS (Connection-Less Network Service) and CONS (Connection-Oriented Network Service). Furthermore, I will attempt to explain their use with IS-IS (OSI only) and I will then attempt to tie their use with Integrated IS-IS (Dual OSI and IP). One must remember that OSI was conceived in the 1980s by Digital with its primary reason being to increase DECnet Phase IV address space. Thus, Digital designed DECnet Phase V, which in turn spawned the better part of OSI. In the 1980s the predominate LAN technology was Ethernet and the predominate WAN technology was X.25. Ethernet circuits are considered to be Connection-Less, while X.25 networks are considered to be Connection-Oriented. The difference being that when an ES wants to transmit a data packet across an Ethernet, it simply sends it to the destination or to the default router. There is no need to establish a prior connection because all MTU sizes should be the same and there is no need to negotiate flow-control below the transport layer. However, on an X.25 network, an ES or IS must setup the connection to the remote DTE prior to transmission of data packets. X.25 has many negotiable options for data transfer, there are really no defaults, per say! So, CONS was employed as a mechanism for communicating with ISO-8208 X.25 packet switch networks to facilitate call setup, parameter negotiation, circuit maintenance and call teardown. SNDCF (Sub-Network Dependent Convergence Functions) are utilized by the OSI network layer to communicate with the X.25 PLP (Packet Level Protocol) for execution of these DTE functions. Through this CONS mechanism, we can setup, maintain and teardown SVCs between X.25 DTEs. Furthermore, since X.25 already possessed a method for guaranteed delivery (LAPB – Link Access Procedure Balanced) at the datalink DTE<>DCE and packet sequencing at the X.25 network layer DTEDTE, there is no need to sequence packets at the transport layer when using a CONS network. So, most applications (both of them :^) use OSI TP0 or TP2 for an OSI Transport mechanism across CONS networks. TP0 and TP2 are much like UDP. Ethernet on the other hand does not require call establishment prior to transport of data. So, CLNS is used to communicate across this type of network. Since there is no guaranteed delivery mechanism with Ethernet (Broadcast circuits for that matter), we need to make sure we use a higher-layer to guarantee delivery of packets. This is where OSI TP4 comes into play. OSI TP4 is much like TCP in that it sequences packets and basically guarantees their delivery. Now, how does this tie into CLNP (Connection-Less Network Protocol) and the format of OSI packets? Well, both CONS and CLNS networks transfer OSI data in CLNP packet formats. On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 formatted ethernet frames. The data portion of an IEEE 802.3 frame, which is carrying OSI data, must have as its first octet a value of 128 (81 hex) = OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS control packet. This first octet is referred to as the NLPID (Network Layer Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD (Intradomain Routing Protocol Discriminator) for IS-IS control packets. This is how the packet is passed up the stack to the proper network layer entity. On a CONS X.25 network, OSI packets are exchanged as USER DATA contained within the X.25- PLP. Again, the first octet in the user data portion of an X.25 packet, must have as its first octet a value of 128 (81 hex) = OSI data packet. ES-IS and IS-IS are not normally run over an X.25 circuit. Instead most implementations of OSI/X.25 only allow for SVCs or DED (Dynamically Established Datalinks). In most cases, the OSI network layer uses X.121 addresses (X.25 DTE addresses), extracted from X.121 formatted NSAPs to signal the correct DTE for the call setup to the remote DTE. Another reason for not running ES-IS or IS-IS over an X.25 network is because some PSNs charge by the packet. Static routes are much cheaper. An IS-IS OSI-only router will exchange IS-IS and ES-IS control data encapsulated in a CLNP packet. An IS-IS OSI-only router will also forward OSI data in a CLNP packet. An Integrated IS-IS IP-only router will exchange IS-IS control data encapsulated in a CLNP packet. An IS-IS IP-only router will forward IP data in an IP encapsulated packet. It will NOT exchange any ES-IS control data nor will it forward any OSI data, just IP data in its native format. An Integrated IS-IS Dual router will act as both an OSI-only router and IP-only router. Finally, the SEL (Selector) portion of an NSAP, though not defined by any ISO docs in this manner, was used by Digital to signal the Network layer of a DECnet Phase V system to send this packet to either the NSP (DECnet Phase IV transport) or OSI Transport. Hope this helps? Cheers, Ken Larmer From naiming@redback.com Wed Aug 8 19:08:24 2001 From: naiming@redback.com (Naiming Shen) Date: Wed, 08 Aug 2001 11:08:24 -0700 Subject: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt In-Reply-To: Mail from "Martin, Christian" dated Tue, 07 Aug 2001 17:44:08 EDT <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.com> Message-ID: <20010808180824.B0A80F2C4B@prattle.redback.com> Martin, some comments inline, thanks. ]Folks, ] ]I have some comments on the draft that I'd like to address with the WG. I ]apologize for cutting this so close to the meeting, but this is the first ]chance I've had to address it. ] ]A while back I began considering how IS-IS could be made to support PTP ]behavior over BMA networks. The driving force behind this was primarily the ]ability to assign arbitrary, per-neighbor metric information to individual ]neighbors. A second benefit would be the elimination of pseudonode exposion ]when a large amount of PTP LAN links were used to interconnect routers. I ]sent an email detailing the need to the WG, but there was little response. ]Some notable vendors also displayed little interest. The only suggestion I ]received, in fact, was to use PPPoE! After reviewing the draft, I have some ]concern about the utility of the proposal, and whether or not it satisfies a ]real need. While it does have merit and will help in many situations, the ]scope should be expanded to address some more complex situations. Comments ]of course are welcome. ] ]In regards to OSPF: ] ]OSPF currently supports NBMA networks. What we are attempting to do here is ]create PtMP (of where MP can be P if there are only two nodes on a LAN) ]networks out of BMA networks in order to support PTP type behavior, from a ]Djiktsra perspective, correct? This is in OSPF today. You can build NBNA ]networks on LANs and specify neighbors explicitly, with associated metrics. ]The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion ]based on the configured neighbor IP. As I see it, the only benefit the ]draft provides is the elimination of DR election (and the corresponding ]elimination of pseudonodes on PTP links), which can be done by making the ]interface point-to-multipoint (although requiring configuration). The major ]vendors support this feature today (I use it!). no comments on OSPF;-) ] ]In regards to IS-IS: ] ]This was the tricky part, as there was nothing in 10589 or 1195 (or any ]subsequent draft) that proposes how to do this. Furthermore, the ]interaction between CLNS and IP makes the address resolution issue a bit ]trickier. Anyway, here is what I was thinking of. general comment is that, this draft is an ietf draft, we are trying to solve some real problems on today's Internet, no attempt is made here trying to tie this into clns and make it so complicated so no prograss will be made for years to come. This draft only needs some very simple changes(almost no changes to the existing protocols) and make the p2p over LAN work for the IP protocol. it's so simple that it's almost emberassing to make it as an Internet draft:-) For most of the current router implementations, the major change proposed from this draft is to add a configuration knob. that's probably it. ] ]1) Create support for point-to-multipoint in IS-IS. This has some ]additional benefit outside of the scope of LANs, as it allows the protocol ]to be used on real NBMA networks like Frame Relay and ATM. The way to do ]this is either cumbersome for the vendor or cumbersome for the operator. It ]also may break the current separation between subnetwork-dependent and ]independent functions, which may not sit well with ISO (or some IETF ]members). Let's address 802.3 networks first. My feeling is this, isis does not have NBMA for so long since OSPF has "invented" it, with atm/frame relay "legacy" services less popular these days, i don't see a requirement to do this in ISIS for now. Even with OSPF, as i remember when i was with previous companies, we alwasy "advise" customers to use point-to-point when link-state protocols are used for obvious reasons the problems NBMA has. Yes, we can develop the nbma for isis, then adapt the nbma for the LAN, but don't think it's worth the effort. ] ]As I see it, ISIS Hellos should be sent as PTP hellos. This means sending ]them to a MAC address and an interface. The interface is then made ]point-to-multipoint. For each configured adjacency, assign a circuit ID ]based on the current mechanism in 10589. The PTP hellos must be ]encapsulated in 802.3 frames, of course, but they should be unicast. CSNP ]should not be sent every 10 seconds, but rather in response to SRM flag ]changes, etc. ] ]Every router knows how to forward traffic across a LAN without passing it ]through the DIS, based on SNPA information from adjacencies. Forwarding ]would be still based on SNPA information, which is easily extracted from the ]configured MAC address of the neighbor (hence, the adjacency). An ]additional feature could be to address the neighbors based on NSAP, and then ]use ES-IS or some other address resolution mechanism to determine the MAC ]address. Either way, forwarding is an issue local to the router, and should ]not be much of an issue. This is where the 'cumbersome-ness' shifts. ] ]As far as switched WANs, the same principles could be applied. However, ]there is the issue of mapping NSAPs to layer 2 circuit IDs (DLCIs, VCCs, ]etc) that isn't addressed outside of X.25 in ISO (AFAIK). This may be too ]much of an undertaking, although it may be worth consideration if there is ]sufficient interest. Some possiblilities would be to use static mapping of ]NSAPs to l2cid, which is common today, and then specifiy the neighbor, the ]interface, and the metric. ] ]Finally, this information could be extended to support ]draft-ietf-isis-traffic-03.txt, by including link coloring, reserved ]bandwidth, etc, although the RSVP piece becomes trickier in the way it is ]encoded on LANs and in the way one reserves bandwidth across virtual ]adjacencies in a shared media environment. Either way, they are workable ]issues, and should be addressed given the growing ubiquity of TE-extension ]support. when a circuit is a p2p-over-lan, it's just an p2p circuit to IGP, nothing says it can't carry TE TLV in it's LSPs. ] ]In summary: ] ]1) Keep the changes at the subnetwork-dependent layer as much as possible, ]i.e., make IS-IS think that a LAN link is a PTP link (or a collection of PtP ]links). This makes the modifications easier, development-wise. this draft only lets level-3 IGP knows this interface is a "p2p", no one else needs to know that. So the IGP thinks this is a p2p interface, and lower layer thinks(actually it is) a broadcast interface, that's it. ] ]2) Allow for both directly connected routers using LAN media as well as ]directed adjacencies across BMA networks for metric adjustment. ] ]3) If the specification is about removing DR election (which as it stands ]now, it is), state this explicitly. I still think this does not address all ]the issues, particlularly, the use of switches as media termination and ]router hubbing devices. well, it's a p2p circuit to IGP, no DR is needed, there is no need to explitely say that no DR election is needed on a p2p circuit. DR is only relavernt to IGP, not to layer two or below. I don't see how using a switch in the middle will change anything, swich is a layer two device, and we don't change anything on layer two here. ] ]4) Optionally allow IS-IS to use NSAP addresses as neighbors and build some ]kind of address resolution mechanism to direct PTP hellos to the appropriate ]MAC address. if you mean to include mac address resolution for clns, we don't try to do this here. ] ]5) Allow per neighbor metric adjustment, and possibly pseudolink coloring ]and reservable/reserved BW info. metric you of course can adjust, it's an isis circuit. color or other TE attributes is the same as normal p2p interface. you can do that too. ] ]6) Optionally consider mechanisms to build NBMA support into IS-IS for ]switched WAN media. PtMP mode would be best, although it requires ]additional flooding, etc. NBMA mode, as in OSPF, is nice but may be ]difficult to do in most cases (except for SMDS) ~8^> not in this draft, someone else can try. ] ]7) If it is desired to just turn a LAN link into a PTP link, then this is ]fine. However, if what I propose is acceptable, then the error checking ]portion of the draft needs to be modified to check for PtMP behavior first. not sure what error checking needs to be done, no ptmp attempt is being made. ] ]Finally, I would think that OSPF implementation modifications should be ]submitted separately to the OSPF-WG, and not to the IS-IS WG. As stated ]earlier, a good deal of the desired functionality specified in the draft is ]already specified in RFC 2328 and later versions, so it may be unnecessary. we can only submit into one working group, doesn't make sense to break this draft into isis, ospf, arp, etc seperate portions. the change on OSPF of this draft is that: NO CHANGE AT ALL. we can't find arp working group. so it goes into isis working group;-) ] ]Sorry this is so late - you may treat these comments as my contribution to ]the London meeting, in absentia of course. ;) appreciate for your comments. thanks. ] ]Best Regards, ] -chris ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From swatirstogi@yahoo.com Wed Aug 8 20:14:46 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Thu, 9 Aug 2001 00:44:46 +0530 Subject: [Isis-wg] Thanks ! Message-ID: <00a101c1203e$641910b0$da046c6b@Manav> Hi All, I am very grateful to James Carlson, Jeff Learman and Ken Larmer for all the help they offered to me and the personal guidance .. as a result of which i am able to understand most of the concepts which i was unable to grasp since a last few months ! Thanks a lot ! With warm regards, Swati Rastogi _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From ginsberg@pluris.com Wed Aug 8 20:51:20 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 8 Aug 2001 12:51:20 -0700 Subject: [Isis-wg] OSI ?? Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A5E1@avalon.pluris.com> Ken - This is a good summary. A few minor corrections/clarifications. As has been mentioned in other responses, but is worth reemphasis, IS-IS PDUs are NOT encapsulated in CLNP PDUs as your text states below. IS-IS (as well as ES-IS) are run directly over the link layer. They can be de-multiplexed from CLNP PDUs by the initial byte in the NPDU - which is a Network Layer Protocol Identifier(NLPID) in all three cases: CLNP - 0x81(129) ES-IS - 0x82(130) IS-IS - 0x83(131) As far as the SEL byte is concerned, it should be intuitively thought of as an ID for the network layer user. The NSAP associated with a network layer user most often bears a close relationship to the network entity title(NET) assigned to the Layer 3 protocol. (Although strict interpretation of ISO addressing allows for a user NSAP to bear virtually no relationship to the NET this is not commonly encountered and is, frankly, too bizarre to be discussed.) So, if the NET assigned consisted of: Area address: 49 System ID: 1111.2222.3333 Selector: 00 (Always) then a network layer user on that box would have an NSAP which differed only in the selector (i.e. 49.1111.2222.3333.xx). There is no set of universally assigned values for the SEL byte. SEL's are assigned within an administrative domain or by industry agreement. For example, SONET(Bellcore/Telcordia) specifications assigned: 01 - OSI transport AF - TL1 Address Resolution Protocol (I think I remember that value correctly...) In order for OSI transport layers to successfully communicate within a SONET domain, these values would have to be used consistently. In this context, DEC's use of the selector byte to direct NPDUs to the appropriate transport layer is quite appropriate and consistent with OSI addressing semantics. Les > > Hi, > > Let me try to explain the difference between CLNS > (Connection-Less Network > Service) and CONS (Connection-Oriented Network Service). > Furthermore, I will > attempt to explain their use with IS-IS (OSI only) and I will > then attempt > to tie their use with Integrated IS-IS (Dual OSI and IP). > > One must remember that OSI was conceived in the 1980s > by Digital with its > primary reason being to increase DECnet Phase IV address space. Thus, > Digital designed DECnet Phase V, which in turn spawned the > better part of > OSI. In the 1980s the predominate LAN technology was Ethernet and the > predominate WAN technology was X.25. Ethernet circuits are > considered to be > Connection-Less, while X.25 networks are considered to be > Connection-Oriented. > > The difference being that when an ES wants to transmit a data > packet across > an Ethernet, it simply sends it to the destination or to the > default router. > There is no need to establish a prior connection because all MTU sizes > should be the same and there is no need to negotiate > flow-control below the > transport layer. However, on an X.25 network, an ES or IS > must setup the > connection to the remote DTE prior to transmission of data > packets. X.25 has > many negotiable options for data transfer, there are really > no defaults, per > say! > > So, CONS was employed as a mechanism for communicating > with ISO-8208 X.25 > packet switch networks to facilitate call setup, parameter > negotiation, > circuit maintenance and call teardown. SNDCF (Sub-Network Dependent > Convergence Functions) are utilized by the OSI network layer > to communicate > with the X.25 PLP (Packet Level Protocol) for execution of these DTE > functions. Through this CONS mechanism, we can setup, > maintain and teardown > SVCs between X.25 DTEs. > > Furthermore, since X.25 already possessed a method for > guaranteed delivery > (LAPB - Link Access Procedure Balanced) at the datalink > DTE<>DCE and packet > sequencing at the X.25 network layer DTEDTE, there is > no need to > sequence packets at the transport layer when using a CONS > network. So, most > applications (both of them :^) use OSI TP0 or TP2 for an OSI Transport > mechanism across CONS networks. TP0 and TP2 are much like UDP. > > Ethernet on the other hand does not require call > establishment prior to > transport of data. So, CLNS is used to communicate across this type of > network. Since there is no guaranteed delivery mechanism with Ethernet > (Broadcast circuits for that matter), we need to make sure we use a > higher-layer to guarantee delivery of packets. This is where > OSI TP4 comes > into play. OSI TP4 is much like TCP in that it sequences packets and > basically guarantees their delivery. > > Now, how does this tie into CLNP (Connection-Less > Network Protocol) and the > format of OSI packets? Well, both CONS and CLNS networks > transfer OSI data > in CLNP packet formats. > > On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 > formatted ethernet frames. The data portion of an IEEE 802.3 > frame, which is > carrying OSI data, must have as its first octet a value of > 128 (81 hex) = > OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 > hex) IS-IS > control packet. This first octet is referred to as the NLPID > (Network Layer > Protocol Identifier) for ES-IS and OSI data and error packets > and as IRPD > (Intradomain Routing Protocol Discriminator) for IS-IS > control packets. This > is how the packet is passed up the stack to the proper > network layer entity. > > On a CONS X.25 network, OSI packets are exchanged as > USER DATA contained > within the X.25- PLP. Again, the first octet in the user data > portion of an > X.25 packet, must have as its first octet a value of 128 (81 > hex) = OSI data > packet. ES-IS and IS-IS are not normally run over an X.25 > circuit. Instead > most implementations of OSI/X.25 only allow for SVCs or DED > (Dynamically > Established Datalinks). In most cases, the OSI network layer > uses X.121 > addresses (X.25 DTE addresses), extracted from X.121 > formatted NSAPs to > signal the correct DTE for the call setup to the remote DTE. > Another reason > for not running ES-IS or IS-IS over an X.25 network is > because some PSNs > charge by the packet. Static routes are much cheaper. > > An IS-IS OSI-only router will exchange IS-IS and ES-IS > control data > encapsulated in a CLNP packet. An IS-IS OSI-only router will > also forward > OSI data in a CLNP packet. An Integrated IS-IS IP-only router > will exchange > IS-IS control data encapsulated in a CLNP packet. An IS-IS > IP-only router > will forward IP data in an IP encapsulated packet. It will > NOT exchange any > ES-IS control data nor will it forward any OSI data, just IP > data in its > native format. An Integrated IS-IS Dual router will act as > both an OSI-only > router and IP-only router. > > Finally, the SEL (Selector) portion of an NSAP, though > not defined by any > ISO docs in this manner, was used by Digital to signal the > Network layer of > a DECnet Phase V system to send this packet to either the NSP > (DECnet Phase > IV transport) or OSI Transport. > > Hope this helps? > > Cheers, > Ken Larmer > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From jharper@cisco.com Wed Aug 8 21:09:25 2001 From: jharper@cisco.com (John Harper) Date: Wed, 08 Aug 2001 13:09:25 -0700 Subject: [Isis-wg] OSI ?? In-Reply-To: References: <000801c11f9a$4c189a70$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010808130016.079c0860@jaws.cisco.com> This seems to be a rather inaccurate portrayal of the way it really was. I'm sure nobody cares, but I thought I'd correct it a little anyway. (I was chair of the OSI Network Layer group during the time it was doing all this, as well as running the lower layers of the DECnet/OSI architecture, so I really was There). First, OSI was conceived long before DEC latched onto it - in the late 70s, whilst our decision to adopt it was made in 1984. Our rationale was that if not, SNA would take over the world. If OSI achieved anything at all, it was to delay SNA for long enough that TCP/IP did in fact take over the world - meeting all the objectives that we at DEC had for OSI, even if all the actual protocols were different. Incidentally our original ideas for DECnet were to have 64-bit addresses. The OSI (NSAP) address format was a horrible compromise to accomodate the world views of both the phone companies and the data networking people (us and the tiny TCP/IP community at the time). CONS and CLNS were completely different religious views of the world. CONS came from the phone companies and from the view that X.25 was the centre of the universe, and everything else should look like it. CLNS of course came from the data networking community. Either of them had standards to allow it to operate over all kinds of subnetwork (OSI jargon), including both LANs and WANs such as X.25 and ISDN. (ISO/IEC 8881 tells you how to make a LAN look like an X.25 network, should you ever want to). In practice CONS collapsed under the combined weight of its own complexity and the general incompetence of its protagonists, and has never seen even a serious attempt to implement it, never mind deploy it. Incidentally CONS most definitely does (did) NOT transport data using CLNP packets. It used all kinds of complicated interworking arrangements at subnetwork boundaries precisely to avoid this approach, which was anethema to the CONS religion. As several people have already said, IS-IS does NOT use CLNP to carry its packets, nor does ES-IS. I happen to think this was an excellent decision, although John Moy certainly disagrees with me. John At 13:42 08/08/2001 -0400, Ken Larmer wrote: >Hi, > > Let me try to explain the difference between CLNS > (Connection-Less Network >Service) and CONS (Connection-Oriented Network Service). Furthermore, I will >attempt to explain their use with IS-IS (OSI only) and I will then attempt >to tie their use with Integrated IS-IS (Dual OSI and IP). > > One must remember that OSI was conceived in the 1980s by Digital > with its >primary reason being to increase DECnet Phase IV address space. Thus, >Digital designed DECnet Phase V, which in turn spawned the better part of >OSI. In the 1980s the predominate LAN technology was Ethernet and the >predominate WAN technology was X.25. Ethernet circuits are considered to be >Connection-Less, while X.25 networks are considered to be >Connection-Oriented. > >The difference being that when an ES wants to transmit a data packet across >an Ethernet, it simply sends it to the destination or to the default router. >There is no need to establish a prior connection because all MTU sizes >should be the same and there is no need to negotiate flow-control below the >transport layer. However, on an X.25 network, an ES or IS must setup the >connection to the remote DTE prior to transmission of data packets. X.25 has >many negotiable options for data transfer, there are really no defaults, per >say! > > So, CONS was employed as a mechanism for communicating with > ISO-8208 X.25 >packet switch networks to facilitate call setup, parameter negotiation, >circuit maintenance and call teardown. SNDCF (Sub-Network Dependent >Convergence Functions) are utilized by the OSI network layer to communicate >with the X.25 PLP (Packet Level Protocol) for execution of these DTE >functions. Through this CONS mechanism, we can setup, maintain and teardown >SVCs between X.25 DTEs. > >Furthermore, since X.25 already possessed a method for guaranteed delivery >(LAPB ­ Link Access Procedure Balanced) at the datalink DTE<>DCE and packet >sequencing at the X.25 network layer DTEDTE, there is no need to >sequence packets at the transport layer when using a CONS network. So, most >applications (both of them :^) use OSI TP0 or TP2 for an OSI Transport >mechanism across CONS networks. TP0 and TP2 are much like UDP. > > Ethernet on the other hand does not require call establishment > prior to >transport of data. So, CLNS is used to communicate across this type of >network. Since there is no guaranteed delivery mechanism with Ethernet >(Broadcast circuits for that matter), we need to make sure we use a >higher-layer to guarantee delivery of packets. This is where OSI TP4 comes >into play. OSI TP4 is much like TCP in that it sequences packets and >basically guarantees their delivery. > > Now, how does this tie into CLNP (Connection-Less Network > Protocol) and the >format of OSI packets? Well, both CONS and CLNS networks transfer OSI data >in CLNP packet formats. > >On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 >formatted ethernet frames. The data portion of an IEEE 802.3 frame, which is >carrying OSI data, must have as its first octet a value of 128 (81 hex) = >OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS >control packet. This first octet is referred to as the NLPID (Network Layer >Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD >(Intradomain Routing Protocol Discriminator) for IS-IS control packets. This >is how the packet is passed up the stack to the proper network layer entity. > > On a CONS X.25 network, OSI packets are exchanged as USER DATA > contained >within the X.25- PLP. Again, the first octet in the user data portion of an >X.25 packet, must have as its first octet a value of 128 (81 hex) = OSI data >packet. ES-IS and IS-IS are not normally run over an X.25 circuit. Instead >most implementations of OSI/X.25 only allow for SVCs or DED (Dynamically >Established Datalinks). In most cases, the OSI network layer uses X.121 >addresses (X.25 DTE addresses), extracted from X.121 formatted NSAPs to >signal the correct DTE for the call setup to the remote DTE. Another reason >for not running ES-IS or IS-IS over an X.25 network is because some PSNs >charge by the packet. Static routes are much cheaper. > > An IS-IS OSI-only router will exchange IS-IS and ES-IS control data >encapsulated in a CLNP packet. An IS-IS OSI-only router will also forward >OSI data in a CLNP packet. An Integrated IS-IS IP-only router will exchange >IS-IS control data encapsulated in a CLNP packet. An IS-IS IP-only router >will forward IP data in an IP encapsulated packet. It will NOT exchange any >ES-IS control data nor will it forward any OSI data, just IP data in its >native format. An Integrated IS-IS Dual router will act as both an OSI-only >router and IP-only router. > > Finally, the SEL (Selector) portion of an NSAP, though not > defined by any >ISO docs in this manner, was used by Digital to signal the Network layer of >a DECnet Phase V system to send this packet to either the NSP (DECnet Phase >IV transport) or OSI Transport. > >Hope this helps? > >Cheers, >Ken Larmer > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Wed Aug 8 23:08:23 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 08 Aug 2001 18:08:23 -0400 Subject: [Isis-wg] OSI ?? In-Reply-To: References: <000801c11f9a$4c189a70$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010808141857.01dc2c78@dingdong.cisco.com> At 01:42 PM 8/8/2001, Ken Larmer wrote: >Hi, > > Let me try to explain the difference between CLNS (Connection-Less Network >Service) and CONS (Connection-Oriented Network Service). Furthermore, I will >attempt to explain their use with IS-IS (OSI only) and I will then attempt >to tie their use with Integrated IS-IS (Dual OSI and IP). > > One must remember that OSI was conceived in the 1980s by Digital with its >primary reason being to increase DECnet Phase IV address space. Thus, >Digital designed DECnet Phase V, which in turn spawned the better part of >OSI. In the 1980s the predominate LAN technology was Ethernet and the >predominate WAN technology was X.25. Ethernet circuits are considered to be >Connection-Less, while X.25 networks are considered to be >Connection-Oriented. > >The difference being that when an ES wants to transmit a data packet across >an Ethernet, it simply sends it to the destination or to the default router. >There is no need to establish a prior connection because all MTU sizes >should be the same and there is no need to negotiate flow-control below the >transport layer. However, on an X.25 network, an ES or IS must setup the >connection to the remote DTE prior to transmission of data packets. X.25 has >many negotiable options for data transfer, there are really no defaults, per >say! > > So, CONS was employed as a mechanism for communicating with ISO-8208 X.25 >packet switch networks to facilitate call setup, parameter negotiation, >circuit maintenance and call teardown. SNDCF (Sub-Network Dependent >Convergence Functions) are utilized by the OSI network layer to communicate >with the X.25 PLP (Packet Level Protocol) for execution of these DTE >functions. Through this CONS mechanism, we can setup, maintain and teardown >SVCs between X.25 DTEs. Warning: SNDCF is usually used to mean the way CLNS operates over a particular kind of data-link, and most commonly for the specific case of CLNP over X.25 (where CLNP is using X.25 as a link level protocol -- sort of like tunneling). >Furthermore, since X.25 already possessed a method for guaranteed delivery >(LAPB ­ Link Access Procedure Balanced) at the datalink DTE<>DCE and packet >sequencing at the X.25 network layer DTEDTE, there is no need to >sequence packets at the transport layer when using a CONS network. So, most >applications (both of them :^) use OSI TP0 or TP2 for an OSI Transport >mechanism across CONS networks. TP0 and TP2 are much like UDP. Not quite. CLTP is like UDP; they both provide a connectionless service. TP0 and TP2 are simpler protocols than TP4 or IP, but provide connection-oriented services over a network that is already connection-oriented, and therefore are simpler than TP4 or TCP, as Ken says. > Ethernet on the other hand does not require call establishment prior to >transport of data. So, CLNS is used to communicate across this type of >network. Since there is no guaranteed delivery mechanism with Ethernet >(Broadcast circuits for that matter), we need to make sure we use a >higher-layer to guarantee delivery of packets. This is where OSI TP4 comes >into play. OSI TP4 is much like TCP in that it sequences packets and >basically guarantees their delivery. True, except that there is a provision for X.25-CONS over LLC3, which is on Ethernet. Fortunately not very popular. > Now, how does this tie into CLNP (Connection-Less Network Protocol) and the >format of OSI packets? Well, both CONS and CLNS networks transfer OSI data >in CLNP packet formats. False. The protocol used to provide CONS is X.25, and involves no CLNP packets. CLNP can operate over X.25, but CONS is not involved. >On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 >formatted ethernet frames. The data portion of an IEEE 802.3 frame, which is >carrying OSI data, must have as its first octet a value of 128 (81 hex) = >OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS >control packet. This first octet is referred to as the NLPID (Network Layer >Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD >(Intradomain Routing Protocol Discriminator) for IS-IS control packets. IDRP is the inTER-domain routing protocol, not inTRA-domain, which is IS-IS. IDRP serves the same role as BGP does for IP, and like BGP is a distance-vector protocol, not a link-state protocol. >This >is how the packet is passed up the stack to the proper network layer entity. > > On a CONS X.25 network, OSI packets are exchanged as USER DATA contained >within the X.25- PLP. Again, the first octet in the user data portion of an >X.25 packet, must have as its first octet a value of 128 (81 hex) = OSI data >packet. This is true only when running CLNS over X.25, and the NLPID is really considered part of the CLNS PDU, according to the specs. (When I say CLNS in this context, I mean CLNP, ES-IS, or IS-IS.) >ES-IS and IS-IS are not normally run over an X.25 circuit. >Instead most implementations of OSI/X.25 only allow for SVCs or DED >(Dynamically Established Datalinks). Really? >In most cases, the OSI network layer uses X.121 >addresses (X.25 DTE addresses), extracted from X.121 formatted NSAPs to >signal the correct DTE for the call setup to the remote DTE. Another reason >for not running ES-IS or IS-IS over an X.25 network is because some PSNs >charge by the packet. Static routes are much cheaper. > > An IS-IS OSI-only router will exchange IS-IS and ES-IS control data >encapsulated in a CLNP packet. ES-IS and IS-IS packets are NOT exchanged in CLNP packets. >An IS-IS OSI-only router will also forward >OSI data in a CLNP packet. An Integrated IS-IS IP-only router will exchange >IS-IS control data encapsulated in a CLNP packet. IS-IS packets are NOT exchanged in CLNP packets. >An IS-IS IP-only router >will forward IP data in an IP encapsulated packet. It will NOT exchange any >ES-IS control data nor will it forward any OSI data, just IP data in its >native format. An Integrated IS-IS Dual router will act as both an OSI-only >router and IP-only router. > > Finally, the SEL (Selector) portion of an NSAP, though not defined by any >ISO docs in this manner, was used by Digital to signal the Network layer of >a DECnet Phase V system to send this packet to either the NSP (DECnet Phase >IV transport) or OSI Transport. True, the NSEL was not identified in ISO network layer addressing, CLNP, or ES-IS specs. It was discussed in NIST OIW agreements. Finally, though, IS-IS mandated that the final octet of an NSAP would not be used in routing decisions, except at the destination end system. Jeff From jlearman@cisco.com Wed Aug 8 23:14:54 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 08 Aug 2001 18:14:54 -0400 Subject: [Isis-wg] OSI ?? In-Reply-To: <17C81AD1F1FED411991E006008F6D1CAA5A5E1@avalon.pluris.com> Message-ID: <4.3.2.7.2.20010808180904.01e115d0@dingdong.cisco.com> At 03:51 PM 8/8/2001, Les Ginsberg wrote: >In this context, DEC's use of the selector byte to direct NPDUs to the >appropriate transport layer is quite appropriate and consistent with OSI >addressing semantics. Yes, although it doesn't permit many of the capabilities offered by these protocols, such as multiplexing CLTP and TP2-4 on the same CONS connection, or negotiating the transport protocol from TP2 to TP0. Anyway, while it's allowable to use the NSEL to address a particular transport protocol engine, it's not necessary. TP0, TP1, TP2, TP3, TP4, and CLTP can be implemented in the same protocol engine and share the same NSEL. Jeff From jlearman@cisco.com Wed Aug 8 23:18:31 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 08 Aug 2001 18:18:31 -0400 Subject: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt In-Reply-To: <20010808180824.B0A80F2C4B@prattle.redback.com> References: <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.com> Message-ID: <4.3.2.7.2.20010808144950.01f08c28@dingdong.cisco.com> At 02:08 PM 8/8/2001, Naiming Shen wrote: >My feeling is this, isis does not have NBMA for so long since OSPF has >"invented" it, with atm/frame relay "legacy" services less popular >these days, i don't see a requirement to do this in ISIS for now. >Even with OSPF, as i remember when i was with previous companies, >we alwasy "advise" customers to use point-to-point when link-state >protocols are used for obvious reasons the problems NBMA has. >Yes, we can develop the nbma for isis, then adapt the nbma for the >LAN, but don't think it's worth the effort. ISO 8473-1988 defined "general topology" networks, which are non-broadcast, multiple-access networks. X.25 is an example, and connectionless networks can be GT networks. IS-IS does not support exchange of routing information over GT networks unless they are modeled as collections of statically enabled point-to-point links. I don't know why, but perhaps it was because X.25 was the only prevalent GT network at the time, and it didn't make sense to have an SVC when exchanging periodic PDUs. Using an IGP over GT net certainly makes more sense for connectionless than for connection-oriented. Jeff From Manav Bhatia" I have a small doubt . . (i) NSAP is an OSI equivalent of an IP address in a TCP/IP network. Is SNAP address equivalent of the ethernet address in the data link layer if its a 802.2 ntwrk ? Rgds, Manav "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From swatirstogi@yahoo.com Thu Aug 9 07:26:13 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Thu, 9 Aug 2001 11:56:13 +0530 Subject: [Isis-wg] Area Architecture Message-ID: <033f01c1209c$319fae60$da046c6b@Manav> Hi, In OSPF it is said that the areas are bound to the interfaces and that the OSPF area boundaries fall within a router. This statement is not very clear and it gets more confusing when its said that in ISIS, area boundaries is on a link rather than in the router. What is bothering me is the fact that in ISIS also its only on the interface basis that i say that the particular link is L1 or L2. Let me explain . . A, B are both cisco routers A --------------------- B (L1/L2) (L1) A and B are both in the same area Configuration of router A would be interface loopback0 ip address 192.168.1.1 255.255.255.255 ! interface Pos2/0/0 ip address 192.168.16.1 255.255.255.0 ip router isis isis circuit-type-level-2 ! Fastethernet4/0/0 ip address 192.168.11.1 255.255.255.0 ip router isis isis circuit-type-level-1 ! router isis net 49.0001.1921.6800.1001.00 (1) If we look at the profile definition then here also we have defined the areas on the interfaces basis .. saying that 192.168.16/24 is my L2 while 192.168.11/24 is L1. (2) Will all of the LSPs recvd on any one of the interfaces be known to the other ? Router configuration of Router B interface loopback0 ip address 192.168.1.2 255.255.255.255 ! interface Fastethernet0/0 ip address 192.168.11.2 255.255.255.0 ip router isis isis circuit-type-level-1 ! router isis net 49.0001.1921.6800.1002 (1) Here on the 192.168.1/24 interface both the routers are running L1 level routing .. So is ISIS not interface based ?? Please explain . . Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Manav Bhatia" The LAN toplogy looks smthg like this .. O O | | ________|__________|______ | | (A) | | O O--> interface defined as L1 ^---- another interface defined as L2 (1) Suppose the IS A has the highest priority .. then can a single Intermediate system be both a LAN L1 Designated IS and a LAN L2 Designated IS. (2) Will this pseudonode be known by the ID (6 bytes in the NSAP address) of the designated IS followed by some pseudonode ID assigned by the designated IS ? Regards, Manav "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From srikrishna_nh@yahoo.co.in Thu Aug 9 10:20:45 2001 From: srikrishna_nh@yahoo.co.in (=?iso-8859-1?q?sudhir=20dskjf?=) Date: Thu, 9 Aug 2001 10:20:45 +0100 (BST) Subject: [Isis-wg] Routing or forwarding Message-ID: <20010809092045.79428.qmail@web8101.in.yahoo.com> hi all, The Dual Is-Is performs routing i.e to calculate the optimal path or it forwards packets also? I have this doubt because i read that the IS-IS uses the services of the data link directly. Can a routing protocol make use of a lower layer services or the Is-IS protocol makes use of CLNP or Ip for forwarding. thanks in advance srikrishna ____________________________________________________________ Do You Yahoo!? Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com. From sprevidi@cisco.com Thu Aug 9 10:25:17 2001 From: sprevidi@cisco.com (stefano previdi) Date: Thu, 09 Aug 2001 11:25:17 +0200 Subject: [Isis-wg] Area Architecture In-Reply-To: <033f01c1209c$319fae60$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010809111542.00b48c50@brussels.cisco.com> At 08:26 09/08/2001, Swati Rastogi wrote: >Hi, >In OSPF it is said that the areas are bound to the interfaces and that the >OSPF area boundaries fall within a router. This statement is not very clear >and it gets more confusing when its said that in ISIS, area boundaries is on >a link rather than in the router. this because the router itself is configured as part of one area. What you did in your example below is that you forced (through some interface configuration commands) the router to establish a specific adjacency level. But this doesn't mean that the router is part of more areas. The router is still part of one area. s. >What is bothering me is the fact that in >ISIS also its only on the interface basis that i say that the particular >link is L1 or L2. >Let me explain . . >A, B are both cisco routers > >A --------------------- B >(L1/L2) (L1) > >A and B are both in the same area > >Configuration of router A would be > >interface loopback0 >ip address 192.168.1.1 255.255.255.255 >! >interface Pos2/0/0 >ip address 192.168.16.1 255.255.255.0 >ip router isis >isis circuit-type-level-2 >! >Fastethernet4/0/0 >ip address 192.168.11.1 255.255.255.0 >ip router isis >isis circuit-type-level-1 >! >router isis >net 49.0001.1921.6800.1001.00 > >(1) If we look at the profile definition then here also we have defined the >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 while >192.168.11/24 is L1. >(2) Will all of the LSPs recvd on any one of the interfaces be known to the >other ? > >Router configuration of Router B > >interface loopback0 >ip address 192.168.1.2 255.255.255.255 >! >interface Fastethernet0/0 >ip address 192.168.11.2 255.255.255.0 >ip router isis >isis circuit-type-level-1 >! >router isis >net 49.0001.1921.6800.1002 > >(1) Here on the 192.168.1/24 interface both the routers are running L1 level >routing .. So is ISIS not interface based ?? > >Please explain . . > >Regards, >Swati > > > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From sprevidi@cisco.com Thu Aug 9 10:28:05 2001 From: sprevidi@cisco.com (stefano previdi) Date: Thu, 09 Aug 2001 11:28:05 +0200 Subject: [Isis-wg] L1/L2 Designated Router In-Reply-To: <036101c120a0$77cdd980$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010809111256.0390ef08@brussels.cisco.com> At 08:56 09/08/2001, Manav Bhatia wrote: >The LAN toplogy looks smthg like this .. > > O O > | | > ________|__________|______ > | | (A) > | | > O O--> interface defined as L1 > ^---- another interface defined as L2 > >(1) Suppose the IS A has the highest priority .. then can a single >Intermediate system be both a LAN L1 Designated IS and a LAN L2 Designated >IS. yes. >(2) Will this pseudonode be known by the ID (6 bytes in the NSAP address) of >the designated IS followed by some pseudonode ID assigned by the designated >IS ? yes, if your router is DIS for both levels, you will have two distinct pseudonodes. Pseudodone ID is part of LSP-ID: 6-bytes lsp-id 1-byte pseudonode-id 1-byte fragment number s. From truskows@cisco.com Thu Aug 9 14:55:27 2001 From: truskows@cisco.com (Mike Truskowski) Date: Thu, 09 Aug 2001 6:55:27 PDT Subject: [Isis-wg] Area Architecture In-Reply-To: <4.3.2.7.2.20010809111542.00b48c50@brussels.cisco.com>; from "stefano previdi" at Aug 9, 101 3:50 am Message-ID: <200108091355.GAA25129@diablo.cisco.com> Swati, First of all you are discussing the actions of a protocol and trying to relate them to how a router is configured. This is hard to do..... Consider a processor with I/O ports attached. For OSPF, when the processor runs OSPF each I/O port must be told that it is running OSPF and "which" area it is in. For ISIS, when the processor runs ISIS it is given an area address by default within the NET. Now when an I/O port is enabled for ISIS they belong to the same area as the processor or instance of ISIS Consider a simple example using 1 NET. So with a router... you configure the router to start ISIS by saying "router isis" but you also must tell this router his NET. router isis net 490001xxxxssssss00 Now when you enable an interface the interface is in this area by default....490001xxxx. mike > > At 08:26 09/08/2001, Swati Rastogi wrote: > >Hi, > >In OSPF it is said that the areas are bound to the interfaces and that the > >OSPF area boundaries fall within a router. This statement is not very clear > >and it gets more confusing when its said that in ISIS, area boundaries is on > >a link rather than in the router. > > this because the router itself is configured as part of one area. > What you did in your example below is that you forced (through some > interface configuration commands) the router to establish a specific > adjacency level. But this doesn't mean that the router is part of > more areas. The router is still part of one area. > > s. > > > >What is bothering me is the fact that in > >ISIS also its only on the interface basis that i say that the particular > >link is L1 or L2. > >Let me explain . . > >A, B are both cisco routers > > > >A --------------------- B > >(L1/L2) (L1) > > > >A and B are both in the same area > > > >Configuration of router A would be > > > >interface loopback0 > >ip address 192.168.1.1 255.255.255.255 > >! > >interface Pos2/0/0 > >ip address 192.168.16.1 255.255.255.0 > >ip router isis > >isis circuit-type-level-2 > >! > >Fastethernet4/0/0 > >ip address 192.168.11.1 255.255.255.0 > >ip router isis > >isis circuit-type-level-1 > >! > >router isis > >net 49.0001.1921.6800.1001.00 > > > >(1) If we look at the profile definition then here also we have defined the > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 while > >192.168.11/24 is L1. > >(2) Will all of the LSPs recvd on any one of the interfaces be known to the > >other ? > > > >Router configuration of Router B > > > >interface loopback0 > >ip address 192.168.1.2 255.255.255.255 > >! > >interface Fastethernet0/0 > >ip address 192.168.11.2 255.255.255.0 > >ip router isis > >isis circuit-type-level-1 > >! > >router isis > >net 49.0001.1921.6800.1002 > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 level > >routing .. So is ISIS not interface based ?? > > > >Please explain . . > > > >Regards, > >Swati > > > > > > > > > > > >_________________________________________________________ > >Do You Yahoo!? > >Get your free @yahoo.com address at http://mail.yahoo.com > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Larmer@CommSense.Net Thu Aug 9 15:47:46 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 9 Aug 2001 10:47:46 -0400 Subject: [Isis-wg] OSI ?? In-Reply-To: <4.3.2.7.2.20010808141857.01dc2c78@dingdong.cisco.com> Message-ID: Thanks for all the corrections :^) I have a very bad habit of calling all OSI packets CLNP, when they are clearly not! Furthermore, I apologize if I miss-represented the evolution of OSI! Just a couple of comments and I'll fade away! Jeff, I believe you meant to say X.25 over ethernet is LLC2 not LLC3. Please correct me if I'm wrong. BTW, Digital had a lot of customers running this hack. I also realize you can run IS-IS over a X.25 PVC on one IS-IS implementation I know of. My comment was simply stating that this is not a common practice. Jeff, please help me here, I made the following statement: >Now, how does this tie into CLNP (Connection-Less Network Protocol) and the >format of OSI packets? Well, both CONS and CLNS networks transfer OSI data >in CLNP packet formats. Your response: >False. The protocol used to provide CONS is X.25, and involves >no CLNP packets. CLNP can operate over X.25, but CONS is not involved. What is the format? CONS is used establish the connection and IS-IS does the forwarding. I know I didn't state that, but is that true? Jeff, please help me here, I made the following statement: >On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 >formatted ethernet frames. The data portion of an IEEE 802.3 frame, which is >carrying OSI data, must have as its first octet a value of 128 (81 hex) = >OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS >control packet. This first octet is referred to as the NLPID (Network Layer >Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD >(Intradomain Routing Protocol Discriminator) for IS-IS control packets. Your response: >IDRP is the inTER-domain routing protocol, not inTRA-domain, which is >IS-IS. IDRP serves the same role as BGP does for IP, and like BGP is >a distance-vector protocol, not a link-state protocol. Jeff, did you mean IDRPI (Inter-Domain Routing Protocol Information) from RFC 1195. My statement refers to ISO-10589 control packets, the first octet of which is the IRPD (Intradomain Routing Protocol Discriminator)field. Of course, we could throw another 1,000 acronyms into OSI so it would be a bit more confusing. I believe that this open discussion is good for this working group. Much to often I see questions go unanswered because many folks do not have all the right answers or the ones that do are too busy to respond. I would rather see this type of discussion, than have a bunch of folks who are to afraid to respond because they may get some portion of their response wrong. This stuff is extremely complex and needs many minds to get the facts 100% correct. Just my thoughts! Cheers, Ken From swatirstogi@yahoo.com Thu Aug 9 15:58:05 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Thu, 9 Aug 2001 20:28:05 +0530 Subject: [Isis-wg] Area Architecture References: <200108091355.GAA25129@diablo.cisco.com> Message-ID: <00d601c120e3$b3f24a70$da046c6b@Manav> Mike, If this is so then I am having problems visualizing as to how we can assign multiple addresses to an IS. For i always thought that area addresses are assigned per interface basis. There is this line in the rfc 1195 which says .. "A level 1 router will refuse to become a neighbor with a node whose area addresses do not overlap its area address." This creates a confusion too .. Consider the topology as shown below. A ----- B ------ C (l1) (l2) (l1) A & B are in the same area while C is in a different area. A and C are L1 routers and B is an L2 only. Firstly .. is this configuration possible ?? Secondly .. B and C are in different areas so how does the adjaceny go up ?? Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I thought that B should then be L1/L2 I know i am being miserable .. but please help! Thanks in advance .. Swati ----- Original Message ----- From: "Mike Truskowski" To: "stefano previdi" Cc: ; Sent: Thursday, August 09, 2001 7:25 PM Subject: Re: [Isis-wg] Area Architecture > Swati, > First of all you are discussing the actions of a protocol > and trying to relate them to how a router is configured. > This is hard to do..... > > Consider a processor with I/O ports attached. > > For OSPF, when the processor runs OSPF each I/O port > must be told that it is running OSPF and "which" area > it is in. > > For ISIS, when the processor runs ISIS it is given > an area address by default within the NET. Now > when an I/O port is enabled for ISIS they belong > to the same area as the processor or instance of ISIS > > Consider a simple example using 1 NET. > So with a router... you configure the router to > start ISIS by saying "router isis" but you also > must tell this router his NET. > > router isis > net 490001xxxxssssss00 > > Now when you enable an interface the interface is in > this area by default....490001xxxx. > > mike > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > >Hi, > > >In OSPF it is said that the areas are bound to the interfaces and that the > > >OSPF area boundaries fall within a router. This statement is not very clear > > >and it gets more confusing when its said that in ISIS, area boundaries is on > > >a link rather than in the router. > > > > this because the router itself is configured as part of one area. > > What you did in your example below is that you forced (through some > > interface configuration commands) the router to establish a specific > > adjacency level. But this doesn't mean that the router is part of > > more areas. The router is still part of one area. > > > > s. > > > > > > >What is bothering me is the fact that in > > >ISIS also its only on the interface basis that i say that the particular > > >link is L1 or L2. > > >Let me explain . . > > >A, B are both cisco routers > > > > > >A --------------------- B > > >(L1/L2) (L1) > > > > > >A and B are both in the same area > > > > > >Configuration of router A would be > > > > > >interface loopback0 > > >ip address 192.168.1.1 255.255.255.255 > > >! > > >interface Pos2/0/0 > > >ip address 192.168.16.1 255.255.255.0 > > >ip router isis > > >isis circuit-type-level-2 > > >! > > >Fastethernet4/0/0 > > >ip address 192.168.11.1 255.255.255.0 > > >ip router isis > > >isis circuit-type-level-1 > > >! > > >router isis > > >net 49.0001.1921.6800.1001.00 > > > > > >(1) If we look at the profile definition then here also we have defined the > > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 while > > >192.168.11/24 is L1. > > >(2) Will all of the LSPs recvd on any one of the interfaces be known to the > > >other ? > > > > > >Router configuration of Router B > > > > > >interface loopback0 > > >ip address 192.168.1.2 255.255.255.255 > > >! > > >interface Fastethernet0/0 > > >ip address 192.168.11.2 255.255.255.0 > > >ip router isis > > >isis circuit-type-level-1 > > >! > > >router isis > > >net 49.0001.1921.6800.1002 > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 level > > >routing .. So is ISIS not interface based ?? > > > > > >Please explain . . > > > > > >Regards, > > >Swati > > > > > > > > > > > > > > > > > >_________________________________________________________ > > >Do You Yahoo!? > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From truskows@cisco.com Thu Aug 9 16:19:00 2001 From: truskows@cisco.com (Mike Truskowski) Date: Thu, 09 Aug 2001 8:19:00 PDT Subject: [Isis-wg] Area Architecture In-Reply-To: <00d601c120e3$b3f24a70$da046c6b@Manav>; from "Swati Rastogi" at Aug 9, 101 7:58 am Message-ID: <200108091519.IAA24299@diablo.cisco.com> I don't mind answering questions but I want to know who you work for. In my email I stated that I would give a simple example. see below... > > Mike, > If this is so then I am having problems visualizing as to how we can assign > multiple addresses to an IS. For i always thought that area addresses are > assigned per interface basis. > There is this line in the rfc 1195 which says .. "A level 1 router will > refuse to become a neighbor with a node whose area addresses do not overlap > its area address." This creates a confusion too .. Consider the topology as > shown below. > > A ----- B ------ C > (l1) (l2) (l1) > > A & B are in the same area while C is in a different area. > A and C are L1 routers and B is an L2 only. > > Firstly .. is this configuration possible ?? This is not a valid topology "if" the lines connecting them is serial links. If so put B into the same are by saying: router isis net 12 net 11 If you want to the the following with an ethernet... B (11) | ------------- | | A(12) C(12) Then this works as long as either A or C is L1/L2 and B is L2. A and C will create a L1 adjacency. C and B will create a L2 adjacency. If A wants to send a packet to B then the router will be A-to-C-to-B... following the L2 route. A will pick C because C having the adjacency with B will have access to external areas. Then the L1 instance on C will set the ATT bit telling A that C has a path. During SPF time A will set C as the next hop out to forward packets outside the area. > Secondly .. B and C are in different areas so how does the adjaceny go up ?? The adjacency in this case will not come up. A and C are L1 in area 11. B is in 12. No level 1 adjacency because they must be in the same area. No level 2 because only B is level 2. If you change, say C, to be L1/L2 then there will be an adjacency between B & C. A will be black holed. Alone and unreachable. > Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I > thought that B should then be L1/L2 See above. Mike > > I know i am being miserable .. but please help! > > Thanks in advance .. > > Swati > > ----- Original Message ----- > From: "Mike Truskowski" > To: "stefano previdi" > Cc: ; > Sent: Thursday, August 09, 2001 7:25 PM > Subject: Re: [Isis-wg] Area Architecture > > > > Swati, > > First of all you are discussing the actions of a protocol > > and trying to relate them to how a router is configured. > > This is hard to do..... > > > > Consider a processor with I/O ports attached. > > > > For OSPF, when the processor runs OSPF each I/O port > > must be told that it is running OSPF and "which" area > > it is in. > > > > For ISIS, when the processor runs ISIS it is given > > an area address by default within the NET. Now > > when an I/O port is enabled for ISIS they belong > > to the same area as the processor or instance of ISIS > > > > Consider a simple example using 1 NET. > > So with a router... you configure the router to > > start ISIS by saying "router isis" but you also > > must tell this router his NET. > > > > router isis > > net 490001xxxxssssss00 > > > > Now when you enable an interface the interface is in > > this area by default....490001xxxx. > > > > mike > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > >Hi, > > > >In OSPF it is said that the areas are bound to the interfaces and that > the > > > >OSPF area boundaries fall within a router. This statement is not very > clear > > > >and it gets more confusing when its said that in ISIS, area boundaries > is on > > > >a link rather than in the router. > > > > > > this because the router itself is configured as part of one area. > > > What you did in your example below is that you forced (through some > > > interface configuration commands) the router to establish a specific > > > adjacency level. But this doesn't mean that the router is part of > > > more areas. The router is still part of one area. > > > > > > s. > > > > > > > > > >What is bothering me is the fact that in > > > >ISIS also its only on the interface basis that i say that the > particular > > > >link is L1 or L2. > > > >Let me explain . . > > > >A, B are both cisco routers > > > > > > > >A --------------------- B > > > >(L1/L2) (L1) > > > > > > > >A and B are both in the same area > > > > > > > >Configuration of router A would be > > > > > > > >interface loopback0 > > > >ip address 192.168.1.1 255.255.255.255 > > > >! > > > >interface Pos2/0/0 > > > >ip address 192.168.16.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-2 > > > >! > > > >Fastethernet4/0/0 > > > >ip address 192.168.11.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1001.00 > > > > > > > >(1) If we look at the profile definition then here also we have defined > the > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 > while > > > >192.168.11/24 is L1. > > > >(2) Will all of the LSPs recvd on any one of the interfaces be known to > the > > > >other ? > > > > > > > >Router configuration of Router B > > > > > > > >interface loopback0 > > > >ip address 192.168.1.2 255.255.255.255 > > > >! > > > >interface Fastethernet0/0 > > > >ip address 192.168.11.2 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1002 > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 > level > > > >routing .. So is ISIS not interface based ?? > > > > > > > >Please explain . . > > > > > > > >Regards, > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mbartell@cisco.com Thu Aug 9 16:53:19 2001 From: mbartell@cisco.com (Micah Bartell) Date: Thu, 09 Aug 2001 10:53:19 -0500 Subject: [Isis-wg] SNAP & NSAP In-Reply-To: <01fa01c1208c$c5d0a4a0$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010809104554.02cb3620@cactus.cisco.com> SNAP? That refers to a data link encapsulation for Ethernet, it is an extension of the 802.2 protocol. Are you sure you are not referring to SNPA, which is Subnetwork Point of Attachment? This is the same as the MAC address. /mpb At 10:05 08/09/2001 +0530, Manav Bhatia wrote: >I have a small doubt . . > >(i) NSAP is an OSI equivalent of an IP address in a TCP/IP network. >Is SNAP address equivalent of the ethernet address in the data link layer if >its a 802.2 ntwrk ? > >Rgds, >Manav > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mbartell@cisco.com Thu Aug 9 16:59:38 2001 From: mbartell@cisco.com (Micah Bartell) Date: Thu, 09 Aug 2001 10:59:38 -0500 Subject: [Isis-wg] Routing or forwarding In-Reply-To: <20010809092045.79428.qmail@web8101.in.yahoo.com> Message-ID: <4.3.2.7.2.20010809105526.02ab0210@cactus.cisco.com> Or are you talking about IS-IS fowarding LSP's? Because IS-IS runs directly over the data link, it would not make use of CLNS or IP for it's forwarding. Some other protocols do make use of other L3 protocols for forwarding routing information, such as OSPF making use of IP. Is this what you were looking for? /mpb At 10:20 08/09/2001 +0100, sudhir dskjf wrote: >hi all, >The Dual Is-Is performs routing i.e to calculate the >optimal path or it forwards packets also? >I have this doubt because i read that the IS-IS uses >the services of the data link directly. Can a routing >protocol make use of a lower layer services or the >Is-IS protocol makes use of CLNP or Ip for forwarding. > >thanks in advance >srikrishna > >____________________________________________________________ >Do You Yahoo!? >Send a newsletter, share photos & files, conduct polls, organize chat >events. Visit http://in.groups.yahoo.com. >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From swatirstogi@yahoo.com Thu Aug 9 17:10:42 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Thu, 9 Aug 2001 21:40:42 +0530 Subject: Fw: [Isis-wg] Area Architecture Message-ID: <002501c120ed$d92e4230$da046c6b@Manav> Pl. see my comments inline .. > Hi Mike, > I am working in a startup company and we are trying to develop the entire > tcp/ip stack. I have to look after the integrated ISIS .. this is my second > job .. prior to this i was working on BGP for a firm known as Tata > Consultancy Services (TCS) .. > > Regards, > Swati Rastogi > > ----- Original Message ----- > From: "Mike Truskowski" > To: "Swati Rastogi" > Cc: ; > Sent: Thursday, August 09, 2001 8:49 PM > Subject: Re: [Isis-wg] Area Architecture > > > > I don't mind answering questions but I want to know > > who you work for. > > > > > > A ----- B ------ C > > > (l1) (l2) (l1) > > > > > > A & B are in the same area while C is in a different area. > > > A and C are L1 routers and B is an L2 only. > > > > > > Firstly .. is this configuration possible ?? > > This is not a valid topology "if" the lines connecting > > them is serial links. If so put B into the same are by > > saying: > > router isis > > net 12 > > net 11 > > > > If you want to the the following with an ethernet... > > > > B (11) > > | > > ------------- > > | | > > A(12) C(12) > > > > Then this works as long as either A or C is L1/L2 and > > B is L2. > > > > A and C will create a L1 adjacency. Can i have L1 adjaceny between ISs in differet areas ! How !?!?! AFAIK i mentioned that A & B are in the same area while C is in some other area. > > C and B will create a L2 adjacency. I think you got the routers wrong ! Your figure above says that B is L1 then how can it have L2 adjaceny with B ??? > > If A wants to send a packet to B then the router will > > be A-to-C-to-B... following the L2 route. Why A and B are in same areas .. !?!? I think you had smthg else in mind and you have written something else .. could you please check that ! Regards, Swati > > > > A will pick C because C having the adjacency with B will > > have access to external areas. Then the L1 instance on > > C will set the ATT bit telling A that C has a path. > > During SPF time A will set C as the next hop out to forward > > packets outside the area. > > > > > Secondly .. B and C are in different areas so how does the adjaceny go > up ?? > > The adjacency in this case will not come up. > > A and C are L1 in area 11. B is in 12. > > No level 1 adjacency because they must be in the same area. > > No level 2 because only B is level 2. > > If you change, say C, to be L1/L2 then there will be > > an adjacency between B & C. A will be black holed. Alone > > and unreachable. > > > > > Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I > > > thought that B should then be L1/L2 > > See above. > > > > Mike > > > > > > > > > > I know i am being miserable .. but please help! > > > > > > Thanks in advance .. > > > > > > Swati > > > > > > ----- Original Message ----- > > > From: "Mike Truskowski" > > > To: "stefano previdi" > > > Cc: ; > > > Sent: Thursday, August 09, 2001 7:25 PM > > > Subject: Re: [Isis-wg] Area Architecture > > > > > > > > > > Swati, > > > > First of all you are discussing the actions of a protocol > > > > and trying to relate them to how a router is configured. > > > > This is hard to do..... > > > > > > > > Consider a processor with I/O ports attached. > > > > > > > > For OSPF, when the processor runs OSPF each I/O port > > > > must be told that it is running OSPF and "which" area > > > > it is in. > > > > > > > > For ISIS, when the processor runs ISIS it is given > > > > an area address by default within the NET. Now > > > > when an I/O port is enabled for ISIS they belong > > > > to the same area as the processor or instance of ISIS > > > > > > > > Consider a simple example using 1 NET. > > > > So with a router... you configure the router to > > > > start ISIS by saying "router isis" but you also > > > > must tell this router his NET. > > > > > > > > router isis > > > > net 490001xxxxssssss00 > > > > > > > > Now when you enable an interface the interface is in > > > > this area by default....490001xxxx. > > > > > > > > mike > > > > > > > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > > > >Hi, > > > > > >In OSPF it is said that the areas are bound to the interfaces and > that > > > the > > > > > >OSPF area boundaries fall within a router. This statement is not > very > > > clear > > > > > >and it gets more confusing when its said that in ISIS, area > boundaries > > > is on > > > > > >a link rather than in the router. > > > > > > > > > > this because the router itself is configured as part of one area. > > > > > What you did in your example below is that you forced (through some > > > > > interface configuration commands) the router to establish a specific > > > > > adjacency level. But this doesn't mean that the router is part of > > > > > more areas. The router is still part of one area. > > > > > > > > > > s. > > > > > > > > > > > > > > > >What is bothering me is the fact that in > > > > > >ISIS also its only on the interface basis that i say that the > > > particular > > > > > >link is L1 or L2. > > > > > >Let me explain . . > > > > > >A, B are both cisco routers > > > > > > > > > > > >A --------------------- B > > > > > >(L1/L2) (L1) > > > > > > > > > > > >A and B are both in the same area > > > > > > > > > > > >Configuration of router A would be > > > > > > > > > > > >interface loopback0 > > > > > >ip address 192.168.1.1 255.255.255.255 > > > > > >! > > > > > >interface Pos2/0/0 > > > > > >ip address 192.168.16.1 255.255.255.0 > > > > > >ip router isis > > > > > >isis circuit-type-level-2 > > > > > >! > > > > > >Fastethernet4/0/0 > > > > > >ip address 192.168.11.1 255.255.255.0 > > > > > >ip router isis > > > > > >isis circuit-type-level-1 > > > > > >! > > > > > >router isis > > > > > >net 49.0001.1921.6800.1001.00 > > > > > > > > > > > >(1) If we look at the profile definition then here also we have > defined > > > the > > > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my > L2 > > > while > > > > > >192.168.11/24 is L1. > > > > > >(2) Will all of the LSPs recvd on any one of the interfaces be > known to > > > the > > > > > >other ? > > > > > > > > > > > >Router configuration of Router B > > > > > > > > > > > >interface loopback0 > > > > > >ip address 192.168.1.2 255.255.255.255 > > > > > >! > > > > > >interface Fastethernet0/0 > > > > > >ip address 192.168.11.2 255.255.255.0 > > > > > >ip router isis > > > > > >isis circuit-type-level-1 > > > > > >! > > > > > >router isis > > > > > >net 49.0001.1921.6800.1002 > > > > > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running > L1 > > > level > > > > > >routing .. So is ISIS not interface based ?? > > > > > > > > > > > >Please explain . . > > > > > > > > > > > >Regards, > > > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > > > >Do You Yahoo!? > > > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > > > >_______________________________________________ > > > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > _______________________________________________ > > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > > > > > _________________________________________________________ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From mbartell@cisco.com Thu Aug 9 17:13:14 2001 From: mbartell@cisco.com (Micah Bartell) Date: Thu, 09 Aug 2001 11:13:14 -0500 Subject: [Isis-wg] Area Architecture In-Reply-To: <00d601c120e3$b3f24a70$da046c6b@Manav> References: <200108091355.GAA25129@diablo.cisco.com> Message-ID: <4.3.2.7.2.20010809110059.02d03cc0@cactus.cisco.com> At 20:28 08/09/2001 +0530, Swati Rastogi wrote: >Mike, >If this is so then I am having problems visualizing as to how we can assign >multiple addresses to an IS. For i always thought that area addresses are >assigned per interface basis. NSAP's are applied per node, while IP addresses are applied per interface. If we assign multiple NSAP's to a single node, that "area" is actually the union of those area addresses. >There is this line in the rfc 1195 which says .. "A level 1 router will >refuse to become a neighbor with a node whose area addresses do not overlap >its area address." If a router is an L1-Only router and receives an IIH from a neighbor with a different Area Address, it will not form an adjacency. >This creates a confusion too .. Consider the topology as >shown below. > >A ----- B ------ C >(l1) (l2) (l1) > >A & B are in the same area while C is in a different area. >A and C are L1 routers and B is an L2 only. > >Firstly .. is this configuration possible ?? If A is L1-Only, and B is L2-Only, what level of adjacency would they form? If C is in a different are, but is L1-Only, what level of adjacency would it form with B, which is L2-Only? This would be a broken design. Make A L1-Only, B L1L2, and C L1L2 and everything works fine. >Secondly .. B and C are in different areas so how does the adjaceny go up ?? It will only go up if you allow them to form L2 adjacencies. >Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. No. > I >thought that B should then be L1/L2 Yes, you need to allow adjacency usage L1, with B being an L1L2 router. >I know i am being miserable .. but please help! > >Thanks in advance .. > >Swati > >----- Original Message ----- >From: "Mike Truskowski" >To: "stefano previdi" >Cc: ; >Sent: Thursday, August 09, 2001 7:25 PM >Subject: Re: [Isis-wg] Area Architecture > > > > Swati, > > First of all you are discussing the actions of a protocol > > and trying to relate them to how a router is configured. > > This is hard to do..... > > > > Consider a processor with I/O ports attached. > > > > For OSPF, when the processor runs OSPF each I/O port > > must be told that it is running OSPF and "which" area > > it is in. > > > > For ISIS, when the processor runs ISIS it is given > > an area address by default within the NET. Now > > when an I/O port is enabled for ISIS they belong > > to the same area as the processor or instance of ISIS > > > > Consider a simple example using 1 NET. > > So with a router... you configure the router to > > start ISIS by saying "router isis" but you also > > must tell this router his NET. > > > > router isis > > net 490001xxxxssssss00 > > > > Now when you enable an interface the interface is in > > this area by default....490001xxxx. > > > > mike > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > >Hi, > > > >In OSPF it is said that the areas are bound to the interfaces and that >the > > > >OSPF area boundaries fall within a router. This statement is not very >clear > > > >and it gets more confusing when its said that in ISIS, area boundaries >is on > > > >a link rather than in the router. > > > > > > this because the router itself is configured as part of one area. > > > What you did in your example below is that you forced (through some > > > interface configuration commands) the router to establish a specific > > > adjacency level. But this doesn't mean that the router is part of > > > more areas. The router is still part of one area. > > > > > > s. > > > > > > > > > >What is bothering me is the fact that in > > > >ISIS also its only on the interface basis that i say that the >particular > > > >link is L1 or L2. > > > >Let me explain . . > > > >A, B are both cisco routers > > > > > > > >A --------------------- B > > > >(L1/L2) (L1) > > > > > > > >A and B are both in the same area > > > > > > > >Configuration of router A would be > > > > > > > >interface loopback0 > > > >ip address 192.168.1.1 255.255.255.255 > > > >! > > > >interface Pos2/0/0 > > > >ip address 192.168.16.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-2 > > > >! > > > >Fastethernet4/0/0 > > > >ip address 192.168.11.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1001.00 > > > > > > > >(1) If we look at the profile definition then here also we have defined >the > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 >while > > > >192.168.11/24 is L1. > > > >(2) Will all of the LSPs recvd on any one of the interfaces be known to >the > > > >other ? > > > > > > > >Router configuration of Router B > > > > > > > >interface loopback0 > > > >ip address 192.168.1.2 255.255.255.255 > > > >! > > > >interface Fastethernet0/0 > > > >ip address 192.168.11.2 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1002 > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 >level > > > >routing .. So is ISIS not interface based ?? > > > > > > > >Please explain . . > > > > > > > >Regards, > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Manav Bhatia" Message-ID: <004901c120ef$78f5ece0$da046c6b@Manav> I think what Sudhir meant was that if IS-IS just performs the routing functions then who forwards these packets (ISIS) to the underlying network .. since it is not supposed to be running on top of any networking layer protocol ! Manav ----- Original Message ----- From: "Micah Bartell" To: "sudhir dskjf" Cc: Sent: Thursday, August 09, 2001 9:29 PM Subject: Re: [Isis-wg] Routing or forwarding > Or are you talking about IS-IS fowarding LSP's? Because IS-IS runs > directly over the data link, it would not make use of CLNS or IP for it's > forwarding. Some other protocols do make use of other L3 protocols for > forwarding routing information, such as OSPF making use of IP. > > Is this what you were looking for? > > /mpb > > At 10:20 08/09/2001 +0100, sudhir dskjf wrote: > >hi all, > >The Dual Is-Is performs routing i.e to calculate the > >optimal path or it forwards packets also? > >I have this doubt because i read that the IS-IS uses > >the services of the data link directly. Can a routing > >protocol make use of a lower layer services or the > >Is-IS protocol makes use of CLNP or Ip for forwarding. > > > >thanks in advance > >srikrishna > > > >____________________________________________________________ > >Do You Yahoo!? > >Send a newsletter, share photos & files, conduct polls, organize chat > >events. Visit http://in.groups.yahoo.com. > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From truskows@cisco.com Thu Aug 9 17:20:20 2001 From: truskows@cisco.com (Mike Truskowski) Date: Thu, 09 Aug 2001 9:20:20 PDT Subject: Fw: [Isis-wg] Area Architecture In-Reply-To: <002501c120ed$d92e4230$da046c6b@Manav>; from "Swati Rastogi" at Aug 9, 101 9:12 am Message-ID: <200108091620.JAA16521@diablo.cisco.com> Swati, Yep, I got it wrong... I answered the questions for the following topology. A----B----C (11) (12) (11). A and C in same area = 11 B in area 12 A and C are L1 only B is L1/L2. I will go back an reply properly to what you sent the first time... mike > > > Pl. see my comments inline .. > > > Hi Mike, > > I am working in a startup company and we are trying to develop the entire > > tcp/ip stack. I have to look after the integrated ISIS .. this is my > second > > job .. prior to this i was working on BGP for a firm known as Tata > > Consultancy Services (TCS) .. > > > > Regards, > > Swati Rastogi > > > > ----- Original Message ----- > > From: "Mike Truskowski" > > To: "Swati Rastogi" > > Cc: ; > > Sent: Thursday, August 09, 2001 8:49 PM > > Subject: Re: [Isis-wg] Area Architecture > > > > > > > I don't mind answering questions but I want to know > > > who you work for. > > > > > > > > > A ----- B ------ C > > > > (l1) (l2) (l1) > > > > > > > > A & B are in the same area while C is in a different area. > > > > A and C are L1 routers and B is an L2 only. > > > > > > > > Firstly .. is this configuration possible ?? > > > This is not a valid topology "if" the lines connecting > > > them is serial links. If so put B into the same are by > > > saying: > > > router isis > > > net 12 > > > net 11 > > > > > > If you want to the the following with an ethernet... > > > > > > B (11) > > > | > > > ------------- > > > | | > > > A(12) C(12) > > > > > > Then this works as long as either A or C is L1/L2 and > > > B is L2. > > > > > > A and C will create a L1 adjacency. > > Can i have L1 adjaceny between ISs in differet areas ! > How !?!?! > > AFAIK i mentioned that A & B are in the same area while C is in some other > area. > > > > C and B will create a L2 adjacency. > > I think you got the routers wrong ! > Your figure above says that B is L1 then how can it have L2 adjaceny with B > ??? > > > > If A wants to send a packet to B then the router will > > > be A-to-C-to-B... following the L2 route. > > Why A and B are in same areas .. !?!? > > I think you had smthg else in mind and you have written something else .. > could you please check that ! > > Regards, > Swati > > > > > > > > A will pick C because C having the adjacency with B will > > > have access to external areas. Then the L1 instance on > > > C will set the ATT bit telling A that C has a path. > > > During SPF time A will set C as the next hop out to forward > > > packets outside the area. > > > > > > > Secondly .. B and C are in different areas so how does the adjaceny go > > up ?? > > > The adjacency in this case will not come up. > > > A and C are L1 in area 11. B is in 12. > > > No level 1 adjacency because they must be in the same area. > > > No level 2 because only B is level 2. > > > If you change, say C, to be L1/L2 then there will be > > > an adjacency between B & C. A will be black holed. Alone > > > and unreachable. > > > > > > > Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I > > > > thought that B should then be L1/L2 > > > See above. > > > > > > Mike > > > > > > > > > > > > > > I know i am being miserable .. but please help! > > > > > > > > Thanks in advance .. > > > > > > > > Swati > > > > > > > > ----- Original Message ----- > > > > From: "Mike Truskowski" > > > > To: "stefano previdi" > > > > Cc: ; > > > > Sent: Thursday, August 09, 2001 7:25 PM > > > > Subject: Re: [Isis-wg] Area Architecture > > > > > > > > > > > > > Swati, > > > > > First of all you are discussing the actions of a protocol > > > > > and trying to relate them to how a router is configured. > > > > > This is hard to do..... > > > > > > > > > > Consider a processor with I/O ports attached. > > > > > > > > > > For OSPF, when the processor runs OSPF each I/O port > > > > > must be told that it is running OSPF and "which" area > > > > > it is in. > > > > > > > > > > For ISIS, when the processor runs ISIS it is given > > > > > an area address by default within the NET. Now > > > > > when an I/O port is enabled for ISIS they belong > > > > > to the same area as the processor or instance of ISIS > > > > > > > > > > Consider a simple example using 1 NET. > > > > > So with a router... you configure the router to > > > > > start ISIS by saying "router isis" but you also > > > > > must tell this router his NET. > > > > > > > > > > router isis > > > > > net 490001xxxxssssss00 > > > > > > > > > > Now when you enable an interface the interface is in > > > > > this area by default....490001xxxx. > > > > > > > > > > mike > > > > > > > > > > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > > > > >Hi, > > > > > > >In OSPF it is said that the areas are bound to the interfaces and > > that > > > > the > > > > > > >OSPF area boundaries fall within a router. This statement is not > > very > > > > clear > > > > > > >and it gets more confusing when its said that in ISIS, area > > boundaries > > > > is on > > > > > > >a link rather than in the router. > > > > > > > > > > > > this because the router itself is configured as part of one area. > > > > > > What you did in your example below is that you forced (through > some > > > > > > interface configuration commands) the router to establish a > specific > > > > > > adjacency level. But this doesn't mean that the router is part of > > > > > > more areas. The router is still part of one area. > > > > > > > > > > > > s. > > > > > > > > > > > > > > > > > > >What is bothering me is the fact that in > > > > > > >ISIS also its only on the interface basis that i say that the > > > > particular > > > > > > >link is L1 or L2. > > > > > > >Let me explain . . > > > > > > >A, B are both cisco routers > > > > > > > > > > > > > >A --------------------- B > > > > > > >(L1/L2) (L1) > > > > > > > > > > > > > >A and B are both in the same area > > > > > > > > > > > > > >Configuration of router A would be > > > > > > > > > > > > > >interface loopback0 > > > > > > >ip address 192.168.1.1 255.255.255.255 > > > > > > >! > > > > > > >interface Pos2/0/0 > > > > > > >ip address 192.168.16.1 255.255.255.0 > > > > > > >ip router isis > > > > > > >isis circuit-type-level-2 > > > > > > >! > > > > > > >Fastethernet4/0/0 > > > > > > >ip address 192.168.11.1 255.255.255.0 > > > > > > >ip router isis > > > > > > >isis circuit-type-level-1 > > > > > > >! > > > > > > >router isis > > > > > > >net 49.0001.1921.6800.1001.00 > > > > > > > > > > > > > >(1) If we look at the profile definition then here also we have > > defined > > > > the > > > > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my > > L2 > > > > while > > > > > > >192.168.11/24 is L1. > > > > > > >(2) Will all of the LSPs recvd on any one of the interfaces be > > known to > > > > the > > > > > > >other ? > > > > > > > > > > > > > >Router configuration of Router B > > > > > > > > > > > > > >interface loopback0 > > > > > > >ip address 192.168.1.2 255.255.255.255 > > > > > > >! > > > > > > >interface Fastethernet0/0 > > > > > > >ip address 192.168.11.2 255.255.255.0 > > > > > > >ip router isis > > > > > > >isis circuit-type-level-1 > > > > > > >! > > > > > > >router isis > > > > > > >net 49.0001.1921.6800.1002 > > > > > > > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are > running > > L1 > > > > level > > > > > > >routing .. So is ISIS not interface based ?? > > > > > > > > > > > > > >Please explain . . > > > > > > > > > > > > > >Regards, > > > > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > > > > >Do You Yahoo!? > > > > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > > > > > >_______________________________________________ > > > > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > > > _______________________________________________ > > > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > > > > _________________________________________________________ > > > > Do You Yahoo!? > > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From truskows@cisco.com Thu Aug 9 17:27:39 2001 From: truskows@cisco.com (Mike Truskowski) Date: Thu, 09 Aug 2001 9:27:39 PDT Subject: [Isis-wg] Area Architecture In-Reply-To: <00d601c120e3$b3f24a70$da046c6b@Manav>; from "Swati Rastogi" at Aug 9, 101 7:54 am Message-ID: <200108091627.JAA22658@diablo.cisco.com> Swati, Second try ... here goes with your topology below. > > Mike, > If this is so then I am having problems visualizing as to how we can assign > multiple addresses to an IS. For i always thought that area addresses are > assigned per interface basis. > There is this line in the rfc 1195 which says .. "A level 1 router will > refuse to become a neighbor with a node whose area addresses do not overlap > its area address." This creates a confusion too .. Consider the topology as > shown below. > > A ----- B ------ C > (l1) (l2) (l1) L1 L2 L1 > > A & B are in the same area while C is in a different area. > A and C are L1 routers and B is an L2 only. > > Firstly .. is this configuration possible ?? It is possible but will not work. L1 adjacencies are separate from L2 adjacencies. So A and B need a L1 adj. but can not because B is not L1. C can not talk to B because they are in different areas and they need a L2 adj. So C needs to be L1/L2. This works: A--------B-----------C area 1 1 2 L1 L1/L2 L2/L1 > Secondly .. B and C are in different areas so how does the adjaceny go up ?? It does not. C must be L2. They there will be only a L2 adj. No L1 adj. > Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I > thought that B should then be L1/L2 B must be L1/L2 for A to talk to it. The discussion I had before was actually more detailed but the topology was also different. Match the discussion with the topology I replied with and you will have a couple of scenarios to play iwth. Mike > > I know i am being miserable .. but please help! > > Thanks in advance .. > > Swati > > ----- Original Message ----- > From: "Mike Truskowski" > To: "stefano previdi" > Cc: ; > Sent: Thursday, August 09, 2001 7:25 PM > Subject: Re: [Isis-wg] Area Architecture > > > > Swati, > > First of all you are discussing the actions of a protocol > > and trying to relate them to how a router is configured. > > This is hard to do..... > > > > Consider a processor with I/O ports attached. > > > > For OSPF, when the processor runs OSPF each I/O port > > must be told that it is running OSPF and "which" area > > it is in. > > > > For ISIS, when the processor runs ISIS it is given > > an area address by default within the NET. Now > > when an I/O port is enabled for ISIS they belong > > to the same area as the processor or instance of ISIS > > > > Consider a simple example using 1 NET. > > So with a router... you configure the router to > > start ISIS by saying "router isis" but you also > > must tell this router his NET. > > > > router isis > > net 490001xxxxssssss00 > > > > Now when you enable an interface the interface is in > > this area by default....490001xxxx. > > > > mike > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > >Hi, > > > >In OSPF it is said that the areas are bound to the interfaces and that > the > > > >OSPF area boundaries fall within a router. This statement is not very > clear > > > >and it gets more confusing when its said that in ISIS, area boundaries > is on > > > >a link rather than in the router. > > > > > > this because the router itself is configured as part of one area. > > > What you did in your example below is that you forced (through some > > > interface configuration commands) the router to establish a specific > > > adjacency level. But this doesn't mean that the router is part of > > > more areas. The router is still part of one area. > > > > > > s. > > > > > > > > > >What is bothering me is the fact that in > > > >ISIS also its only on the interface basis that i say that the > particular > > > >link is L1 or L2. > > > >Let me explain . . > > > >A, B are both cisco routers > > > > > > > >A --------------------- B > > > >(L1/L2) (L1) > > > > > > > >A and B are both in the same area > > > > > > > >Configuration of router A would be > > > > > > > >interface loopback0 > > > >ip address 192.168.1.1 255.255.255.255 > > > >! > > > >interface Pos2/0/0 > > > >ip address 192.168.16.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-2 > > > >! > > > >Fastethernet4/0/0 > > > >ip address 192.168.11.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1001.00 > > > > > > > >(1) If we look at the profile definition then here also we have defined > the > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 > while > > > >192.168.11/24 is L1. > > > >(2) Will all of the LSPs recvd on any one of the interfaces be known to > the > > > >other ? > > > > > > > >Router configuration of Router B > > > > > > > >interface loopback0 > > > >ip address 192.168.1.2 255.255.255.255 > > > >! > > > >interface Fastethernet0/0 > > > >ip address 192.168.11.2 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1002 > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 > level > > > >routing .. So is ISIS not interface based ?? > > > > > > > >Please explain . . > > > > > > > >Regards, > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From swatirstogi@yahoo.com Thu Aug 9 18:16:42 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Thu, 9 Aug 2001 22:46:42 +0530 Subject: [Isis-wg] Area Architecture References: <200108091355.GAA25129@diablo.cisco.com> <4.3.2.7.2.20010809110059.02d03cc0@cactus.cisco.com> Message-ID: <005e01c120f7$24a6d9d0$da046c6b@Manav> > >If this is so then I am having problems visualizing as to how we can assign > >multiple addresses to an IS. For i always thought that area addresses are > >assigned per interface basis. > > NSAP's are applied per node, while IP addresses are applied per interface. > > If we assign multiple NSAP's to a single node, that "area" is actually the > union of those area addresses. Can you please expound on the above point .. As i understand node refers to an IS .. Are you implying that one IS can be in multiple areas ?? Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From marelines@yahoo.com Thu Aug 9 18:25:33 2001 From: marelines@yahoo.com (Mareline Sheldon) Date: Thu, 9 Aug 2001 22:55:33 +0530 Subject: [Isis-wg] Levels and adjacencies Message-ID: <006901c120f8$6000adc0$da046c6b@Manav> Hi everybody, I am Mareline Sheldon and am new to this mailing list. I was looking around the mail archieves and was glad that i found some because what is being discussed here is exactly what i am looking for .. Here i go .. Say i am a L1/L2 router and i have a L1 adjacency with router A and L2 adjaceny with router B. I will in principle then be only flooding L1 LSPs to A and L2 LSPs to B. And if i have a L1/L2 adjacency with IS C .. then i shall be flooding both ?? True ?? But i have a feeling .. that i cant have L1/L2 adjaceny with some IS ?? /mary -- Nipon Datacom _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Anand@ambernetworks.com Thu Aug 9 18:27:03 2001 From: Anand@ambernetworks.com (Anand Ammundi) Date: Thu, 9 Aug 2001 10:27:03 -0700 Subject: [Isis-wg] Routing or forwarding Message-ID: <9F4704BE89F7D4118A0F0002B328C36CA0F68B@usa04.ambernetworks.com> A routing protocol is part of the control plane...it merely provides the required information to the data plane for the forwarding to take place. As far as getting the control packets themselves across, since IS-IS (and OSPF for that matter) are not sending out their PDU's beyond 1 hop, the receiving peer will know to send the PDU up the stack to ISIS based on the protocol ID's (0xFEFE or 0x0021 etc)...actually, it is not really a "taken for granted" thing...for example, say over a POS link, you have 2 different PDU's ... 1) PPP-IP 2) PPP-ISIS assuming that software forwarding is a thing of the past, in case 1) the data plane will make a forwarding decision based on the DST_ADDR and either send it to CPU or forward it directly...for case 2), there explicitly has to be special handling in the data plane, to send this to CPU (stack) as a terminating packet...note that this handling is implicitly taken care of for say OSPF or BGP since they are on top of IP. hope this answers your question anand ps: Though I don't think the spec has anything against ISIS running over IP, but I doubt if there are any such implementations on the field. -----Original Message----- From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] Sent: Thursday, August 09, 2001 9:22 AM To: sudhir dskjf; Micah Bartell Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Routing or forwarding I think what Sudhir meant was that if IS-IS just performs the routing functions then who forwards these packets (ISIS) to the underlying network .. since it is not supposed to be running on top of any networking layer protocol ! Manav ----- Original Message ----- From: "Micah Bartell" To: "sudhir dskjf" Cc: Sent: Thursday, August 09, 2001 9:29 PM Subject: Re: [Isis-wg] Routing or forwarding > Or are you talking about IS-IS fowarding LSP's? Because IS-IS runs > directly over the data link, it would not make use of CLNS or IP for it's > forwarding. Some other protocols do make use of other L3 protocols for > forwarding routing information, such as OSPF making use of IP. > > Is this what you were looking for? > > /mpb > > At 10:20 08/09/2001 +0100, sudhir dskjf wrote: > >hi all, > >The Dual Is-Is performs routing i.e to calculate the > >optimal path or it forwards packets also? > >I have this doubt because i read that the IS-IS uses > >the services of the data link directly. Can a routing > >protocol make use of a lower layer services or the > >Is-IS protocol makes use of CLNP or Ip for forwarding. > > > >thanks in advance > >srikrishna > > > >____________________________________________________________ > >Do You Yahoo!? > >Send a newsletter, share photos & files, conduct polls, organize chat > >events. Visit http://in.groups.yahoo.com. > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Thu Aug 9 17:29:14 2001 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 09 Aug 2001 12:29:14 -0400 Subject: [Isis-wg] OSI ?? In-Reply-To: References: <4.3.2.7.2.20010808141857.01dc2c78@dingdong.cisco.com> Message-ID: <4.3.2.7.2.20010809115859.00baeb10@dingdong.cisco.com> At 10:47 AM 8/9/2001, Ken Larmer wrote: >Thanks for all the corrections :^) > >I have a very bad habit of calling all OSI packets CLNP, when they are >clearly not! Furthermore, I apologize if I miss-represented the evolution of >OSI! > >Just a couple of comments and I'll fade away! > >Jeff, I believe you meant to say X.25 over ethernet is LLC2 not LLC3. Please >correct me if I'm wrong. BTW, Digital had a lot of customers running this >hack. OOPS! You're right, LLC2 is connection-oriented LLC. LLC3 was from MAP (GM's manufacturing automation protocol). >I also realize you can run IS-IS over a X.25 PVC on one IS-IS implementation >I know of. My comment was simply stating that this is not a common practice. You can also run it over an SVC, as long as it is statically assigned, rather than than one that comes up and goes down >Jeff, please help me here, I made the following statement: > >>Now, how does this tie into CLNP (Connection-Less Network Protocol) and the >>format of OSI packets? Well, both CONS and CLNS networks transfer OSI data >>in CLNP packet formats. > >Your response: > >>False. The protocol used to provide CONS is X.25, and involves >>no CLNP packets. CLNP can operate over X.25, but CONS is not involved. > >What is the format? CONS is used establish the connection and IS-IS does the >forwarding. I know I didn't state that, but is that true? IS-IS never does forwarding. It's just a routing protocol, which derives routing information for the use of the network layer data protocol, which forwards the data. IS-IS was designed for use with CLNP, and then extended for use with IP. It has never been standardized for use with CONS. CONS itself, like CLNS itself, is an abstract service definition and does not impose a protocol. There are other specifications that state how to provide CONS using X.25 as a network access protocol. (The actual network delivery protocol and routing protocols for X.25 are not standard, because it's the X.25 service provider's job -- in this case the X.25 service provider is a company or national organization. They can do whatever they want, as long as they provide a service that can be interfaced to using X.25.) >Jeff, please help me here, I made the following statement: > >>On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 >>formatted ethernet frames. The data portion of an IEEE 802.3 frame, which >is >>carrying OSI data, must have as its first octet a value of 128 (81 hex) = >>OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS >>control packet. This first octet is referred to as the NLPID (Network Layer >>Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD >>(Intradomain Routing Protocol Discriminator) for IS-IS control packets. > >Your response: > >>IDRP is the inTER-domain routing protocol, not inTRA-domain, which is >>IS-IS. IDRP serves the same role as BGP does for IP, and like BGP is >>a distance-vector protocol, not a link-state protocol. > >Jeff, did you mean IDRPI (Inter-Domain Routing Protocol Information) from >RFC 1195. My statement refers to ISO-10589 control packets, the first octet >of which is the IRPD (Intradomain Routing Protocol Discriminator)field. Of >course, we could throw another 1,000 acronyms into OSI so it would be a bit >more confusing. No, I wasn't referring to IDRPI. IDRP stands for "Interdomain Routeing Protocol", which is like BGP. The first octet of an OSI connectionless network layer protocol packet isthe NLPI, "Network layer protocol ID", aka NPID or NLPID. I don't recall an IRPD (I thought that was a transposition on your part), so my response was non-sequitur. Where is that IRDP defined? >I believe that this open discussion is good for this working group. Much to >often I see questions go unanswered because many folks do not have all the >right answers or the ones that do are too busy to respond. I would rather >see this type of discussion, than have a bunch of folks who are to afraid to >respond because they may get some portion of their response wrong. This >stuff is extremely complex and needs many minds to get the facts 100% >correct. > >Just my thoughts! > >Cheers, >Ken From mbartell@cisco.com Thu Aug 9 18:51:33 2001 From: mbartell@cisco.com (Micah Bartell) Date: Thu, 09 Aug 2001 12:51:33 -0500 Subject: [Isis-wg] Area Architecture In-Reply-To: <005e01c120f7$24a6d9d0$da046c6b@Manav> References: <200108091355.GAA25129@diablo.cisco.com> <4.3.2.7.2.20010809110059.02d03cc0@cactus.cisco.com> Message-ID: <4.3.2.7.2.20010809125054.02184ae8@cactus.cisco.com> No, I am saying that an area can have multiple area addresses. /mpb At 22:46 08/09/2001 +0530, Swati Rastogi wrote: > > >If this is so then I am having problems visualizing as to how we can >assign > > >multiple addresses to an IS. For i always thought that area addresses are > > >assigned per interface basis. > > > > NSAP's are applied per node, while IP addresses are applied per interface. > > > > If we assign multiple NSAP's to a single node, that "area" is actually the > > union of those area addresses. > >Can you please expound on the above point .. >As i understand node refers to an IS .. Are you implying that one IS can be >in multiple areas ?? > >Regards, >Swati > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com From tgol@laurelnetworks.com Thu Aug 9 19:02:42 2001 From: tgol@laurelnetworks.com (Tayfun Gol) Date: Thu, 09 Aug 2001 14:02:42 -0400 Subject: [Isis-wg] Levels and adjacencies References: <006901c120f8$6000adc0$da046c6b@Manav> Message-ID: <3B72D042.A8FD5308@laurelnetworks.com> Mareline Sheldon wrote: > Hi everybody, > I am Mareline Sheldon and am new to this mailing list. I was looking around > the mail archieves and was glad that i found some because what is being > discussed here is exactly what i am looking for .. Here i go .. > > Say i am a L1/L2 router and i have a L1 adjacency with router A and L2 > adjaceny with router B. I will in principle then be only flooding L1 LSPs to > A and L2 LSPs to B. That is true. > > And if i have a L1/L2 adjacency with IS C .. then i shall be flooding both > ?? > > True ?? > You can have L1/L2 adjacency with a router over a point to point link if both levels are enabled on both routers' interfaces ( and an area address in common for L1 ) and in this case you will be flooding both L1 and L2 LSPs. For multiaccess links, there will be a seperate adjacency per enabled level. Hope this helps... Tayfun Gol > > > But i have a feeling .. that i cant have L1/L2 adjaceny with some IS ?? > > /mary > > -- > Nipon Datacom > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Larmer@CommSense.Net Thu Aug 9 19:44:23 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 9 Aug 2001 14:44:23 -0400 Subject: [Isis-wg] OSI ?? In-Reply-To: <4.3.2.7.2.20010809115859.00baeb10@dingdong.cisco.com> Message-ID: Sorry Jeff, I just have a couple more questions? > IS-IS never does forwarding. It's just a routing protocol, which > derives routing information for the use of the network layer data > protocol, which forwards the data. Jeff, please help me out here, I am really confused! You stated that IS-IS never does forwarding. I understand that it never does forwarding of IP packets, but what about CLNP, does this still hold true? > IS-IS was designed for use with CLNP, and then extended for use with > IP. It has never been standardized for use with CONS. Jeff, ISO-10589 states the following, which I thought pertained to CONS circuits? Please help to clear this up for me??? ISO 8208 subnetworks 8.3.1 Network layer protocols The way in which the underlying service assumed by ISO 8473 is provided for ISO 8208 subnetworks is described in clause 8 of ISO 8473. This defines a set of Subnetwork Dependent Convergence Functions (SNDCFs) that relate the service provided by specific individual ISO International Standard subnetworks to the abstract "underlying service" defined in 5.5 of ISO 8473. In particular 8.4.3 describes the Subnetwork Dependent Convergence Functions used with ISO 8208 Subnetworks. Use of ISO 8473 subnetwork dependent convergence functions SVCs shall be established according to the procedures defined in the ISO 8208 Subnetwork Dependent Convergence Functions of ISO 8473 (this may be on system management action or on arrival of data depending on the type of circuit). The Call Request shall contain a Protocol Discriminator specifying ISO 8473 in the first octet of Call Userdata. > No, I wasn't referring to IDRPI. IDRP stands for "Interdomain Routeing > Protocol", which is like BGP. The first octet of an OSI connectionless > network layer protocol packet isthe NLPI, "Network layer protocol ID", aka > NPID or NLPID. I don't recall an IRPD (I thought that was a transposition > on your part), so my response was non-sequitur. Where is that > IRDP defined? Jeff, are you talking about the DSAP/SSAP of an IEEE 802.3 packet? The IDRP (83) is what identifies an IS-IS packet within an IEEE 802.3 ethernet frame. Cheers, Ken From ginsberg@pluris.com Thu Aug 9 22:57:48 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Thu, 9 Aug 2001 14:57:48 -0700 Subject: [Isis-wg] OSI ?? Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A5ED@avalon.pluris.com> > > No, I wasn't referring to IDRPI. IDRP stands for > "Interdomain Routeing > > Protocol", which is like BGP. The first octet of an OSI > connectionless > > network layer protocol packet isthe NLPI, "Network layer > protocol ID", aka > > NPID or NLPID. I don't recall an IRPD (I thought that was > a transposition > > on your part), so my response was non-sequitur. Where is that > > IRDP defined? > > Jeff, are you talking about the DSAP/SSAP of an IEEE 802.3 > packet? The IDRP > (83) is what identifies an IS-IS packet within an IEEE 802.3 > ethernet frame. > What Jeff is referring to here is: [IS10747] ISO/IEC IS 10747 - Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993. This was OSI's version of an Inter-Domain routing protocol - referred to as IDRP. It was assigned NLPID 0x84 for its PDUs. BGP4 used this an a reference in its development. I don't believe there is any active work on IDRP - but I could be mistaken there. Other folks are undoubtedly more knowledgeable on that score. In terms of an 802.3 packet, an OSI frame - which includes CLNP, ES-IS, and IS-IS PDUs will have the following format: Destination MAC address: 6 bytes Source MAC address: 6 bytes Length: 2 bytes LLC1 Header 3 bytes consisting of: DSAP: 0xFE SSAP: 0xFE Type: 0x3 (Unnumbered Information) Following these 17 bytes will be the start of the payload (or NPDU). The first byte of that payload will be the NLPID of the PDU which is used to identify the protocol: 0x81 CLNS 0x82 ES-IS 0x83 IS-IS 0x84 IDRP Les From Manav Bhatia" Hi, The general structure of the NSAP structure as defined in RFC 1629 (6.2.1) gives the length of system Identifier to be varying from 1-8 octets. The length of the source ID for all the IS-IS PDUs as given in the rfc 1142 is 6 octets. Now if i have a system ID of 8 octets .. how do i map this into 6 octets in my IS-IS PDUs ?? Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From marelines@yahoo.com Fri Aug 10 07:42:45 2001 From: marelines@yahoo.com (Mareline Sheldon) Date: Fri, 10 Aug 2001 12:12:45 +0530 Subject: [Isis-wg] Manual Adjacencies Message-ID: <004101c12167$af70fc10$da046c6b@Manav> The RFC 1142 (7.3.3.1) says "NOTE - Manual End system Adjacencies shall not be included in a level 1 LSPs issued on behalf of a pseudonode, since that would presuppose that all Intermediate systems on a broadcast subnetwork had the same set of manual adjacencies as defined in the ciruit" This is not very clear .. if it is not done so then how do manual adjacencies get advertised on a psedonode ? Please help! /Mary _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From manigandanm@rediffmail.com Fri Aug 10 11:23:04 2001 From: manigandanm@rediffmail.com (Selvam Murugesan) Date: 10 Aug 2001 10:23:04 -0000 Subject: [Isis-wg] doubts on IS-IS topology and addressing Message-ID: <20010810102304.7652.qmail@mailweb24.rediffmail.com> Hi, I need a small clarification on the IS-IS topology and addressing form= ats. = 1. Is it must for Level-1 IS to have a adjacency maintained with a Level-= 2 IS or can the Level-1 IS communicate with a Level-2 IS via Level-1 IS? 2.Regarding the ISO DCC addressing format adopted for Is-IS addresses usi= ng semi-octet decimal digits representation, the DSP is allocated 0-35 di= gits. Assuming CFI =3D1 (single digit), then CDI =3D 3digits,ESI =3D 31 d= igits, which adds up the total digits in the DSP to 35 digits. How is SEL= field of the DSP accomodated in this case? Kindly help me on this reagrds Thanks in advance Regards Manigandan _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm From Manav Bhatia" Message-ID: <014801c1218c$46aaeef0$da046c6b@Manav> >1. Is it must for Level-1 IS to have a adjacency maintained with a >Level-2 IS or can the Level-1 IS communicate with a Level-2 IS via >Level-1 IS? When a L1 IS receives a packet, it examines the destination address in the network layer header. If its within its area then routes based on the ID portion of the address. Otherwise, the IS forwards the packet to the closest level 2 IS and if an entry does not exist for it then the packet is either dropped or forwarded to some default IS designated for such purposes. Thus a level 1 IS can communicate with a level 2 IS via a level 1 IS acting as a gateway to the "last resort" ! -- manav _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jparker@axiowave.com Fri Aug 10 15:07:37 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 10 Aug 2001 10:07:37 -0400 Subject: [Isis-wg] Routing or forwarding Message-ID: > ps: Though I don't think the spec has anything against ISIS > running over IP, but I doubt if there are any such > implementations on the field. A bit of history on this... There -was- a draft proposal to run ISIS over IP. A number of reasons were put forward for this, including allowing larger LSPs (let IP handle fragmentation) and avoiding something refered to as the "ATM cell tax" that came about if you needed to multiplex two protocols over ATM, and the resulting effect of requiring two ATM cells to hols a TCP Ack. There were folks who implemented this encapsulation. The chief driving force for seemed to be avoiding the cell tax: there were doubts that adding a second layer of fragmentation was a good thing. An alternative proposal to deal with the cell tax was proposed which encodes both IP and ISIS traffic "raw", and demultiplexes based on the difference between the first nibble of the NLPID for ISIS (0x8) and the version number for IP (0x4 or 0x6). This proposal seems to have aged off the list, but gathered support from several vendors. - jeff parker - axiowave networks From jlearman@cisco.com Fri Aug 10 15:49:16 2001 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 10 Aug 2001 10:49:16 -0400 Subject: [Isis-wg] Manual Adjacencies In-Reply-To: <004101c12167$af70fc10$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010810103859.099300d0@dingdong.cisco.com> First, don't rely on RFC 1142, which is a DRAFT standard. There were changes to it before it became ISO 10589, which is what you need to implement. However, this text didn't change -- manual adjacencies must be placed in the LSP of the system that the manual adjacency is configured on, not in the pseudonode LSP. Jeff At 02:42 AM 8/10/2001, Mareline Sheldon wrote: >The RFC 1142 (7.3.3.1) says "NOTE - Manual End system Adjacencies shall not >be included in a level 1 LSPs issued on behalf of a pseudonode, since that >would presuppose that all Intermediate systems on a broadcast subnetwork had >the same set of manual adjacencies as defined in the ciruit" > >This is not very clear .. if it is not done so then how do manual >adjacencies get advertised on a psedonode ? > >Please help! > >/Mary > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Fri Aug 10 15:50:29 2001 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 10 Aug 2001 10:50:29 -0400 Subject: [Isis-wg] NSAP Structure In-Reply-To: <00b701c12159$82d704a0$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010810102634.01e98e18@dingdong.cisco.com> Friends don't let friends use 8-byte system IDs ;-) RFC 1142 is the draft standard. One of the wonderful things that the ISO committee did was to permit the system ID to be 1-8 bytes, making our lives more enjoyable and increasing employment security for software engineers. The ID size must be constant throughout a routing domain. You need to implement ISO 10589, not the draft standard. Regards, Jeff At 12:55 AM 8/10/2001, Manav Bhatia wrote: >Hi, >The general structure of the NSAP structure as defined in RFC 1629 (6.2.1) >gives the length of system Identifier to be varying from 1-8 octets. >The length of the source ID for all the IS-IS PDUs as given in the rfc 1142 >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this into >6 octets in my IS-IS PDUs ?? > >Regards, >Manav Bhatia > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mbartell@cisco.com Fri Aug 10 16:05:40 2001 From: mbartell@cisco.com (Micah Bartell) Date: Fri, 10 Aug 2001 10:05:40 -0500 Subject: [Isis-wg] NSAP Structure In-Reply-To: <4.3.2.7.2.20010810102634.01e98e18@dingdong.cisco.com> References: <00b701c12159$82d704a0$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010810100359.02c37b98@cactus.cisco.com> To the best of my knowledge, no one has implemented anything but 6 byte systemID's. Also, the sourceID is systemID Length +1. Area addresses however are implemented variable length. /mpb At 10:50 08/10/2001 -0400, Jeff Learman wrote: >Friends don't let friends use 8-byte system IDs ;-) > >RFC 1142 is the draft standard. One of the wonderful things that >the ISO committee did was to permit the system ID to be 1-8 bytes, >making our lives more enjoyable and increasing employment security >for software engineers. The ID size must be constant throughout >a routing domain. > >You need to implement ISO 10589, not the draft standard. > >Regards, >Jeff > >At 12:55 AM 8/10/2001, Manav Bhatia wrote: > >Hi, > >The general structure of the NSAP structure as defined in RFC 1629 (6.2.1) > >gives the length of system Identifier to be varying from 1-8 octets. > >The length of the source ID for all the IS-IS PDUs as given in the rfc 1142 > >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this into > >6 octets in my IS-IS PDUs ?? > > > >Regards, > >Manav Bhatia > > > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > > > > > >_________________________________________________________ > >Do You Yahoo!? > >Get your free @yahoo.com address at http://mail.yahoo.com > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Manav Bhatia" <4.3.2.7.2.20010810100359.02c37b98@cactus.cisco.com> Message-ID: <02ee01c121af$517a5690$da046c6b@Manav> > To the best of my knowledge, no one has implemented anything but 6 byte > systemID's. But its defined in the RFC .. so there is no garuntee that all systems IDs will fall under 6 bytes ! > > Also, the sourceID is systemID Length +1. Is the +1 for the SEL byte ?? I dont think the SEL byte is included in defining the unique ID of the IS i.e. Source ID ! > > Area addresses however are implemented variable length. Area addresses may computed as (total length - (system ID +1) ) I read it somewhere but its not exactly flashing me where .. Manav > > /mpb > > > At 10:50 08/10/2001 -0400, Jeff Learman wrote: > > >Friends don't let friends use 8-byte system IDs ;-) > > > >RFC 1142 is the draft standard. One of the wonderful things that > >the ISO committee did was to permit the system ID to be 1-8 bytes, > >making our lives more enjoyable and increasing employment security > >for software engineers. The ID size must be constant throughout > >a routing domain. > > > >You need to implement ISO 10589, not the draft standard. > > > >Regards, > >Jeff > > > >At 12:55 AM 8/10/2001, Manav Bhatia wrote: > > >Hi, > > >The general structure of the NSAP structure as defined in RFC 1629 (6.2.1) > > >gives the length of system Identifier to be varying from 1-8 octets. > > >The length of the source ID for all the IS-IS PDUs as given in the rfc 1142 > > >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this into > > >6 octets in my IS-IS PDUs ?? > > > > > >Regards, > > >Manav Bhatia > > > > > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > > > > > > > > > >_________________________________________________________ > > >Do You Yahoo!? > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From tgol@laurelnetworks.com Fri Aug 10 16:13:22 2001 From: tgol@laurelnetworks.com (Tayfun Gol) Date: Fri, 10 Aug 2001 11:13:22 -0400 Subject: [Isis-wg] Three way handshake draft Message-ID: <3B73FA12.C3FFA5D9@laurelnetworks.com> I was wondering why this draft got expired. Looking at the mail archives, it just passed away silently. Does anybody have an idea? Thanks in advance... -- Tayfun Gol From mbartell@cisco.com Fri Aug 10 16:19:42 2001 From: mbartell@cisco.com (Micah Bartell) Date: Fri, 10 Aug 2001 10:19:42 -0500 Subject: [Isis-wg] NSAP Structure In-Reply-To: <02ee01c121af$517a5690$da046c6b@Manav> References: <00b701c12159$82d704a0$da046c6b@Manav> <4.3.2.7.2.20010810100359.02c37b98@cactus.cisco.com> Message-ID: <4.3.2.7.2.20010810101720.022678b0@cactus.cisco.com> Let me clarify. The sourceID is IDlength (systemID) for LSP's. For SNP's, it is IDlength+1, the +1 is a zero circuit ID. /mpb At 20:45 08/10/2001 +0530, Manav Bhatia wrote: > > To the best of my knowledge, no one has implemented anything but 6 byte > > systemID's. > >But its defined in the RFC .. so there is no garuntee that all systems IDs >will fall under 6 bytes ! > > > > > Also, the sourceID is systemID Length +1. > >Is the +1 for the SEL byte ?? >I dont think the SEL byte is included in defining the unique ID of the IS >i.e. Source ID ! > > > > > Area addresses however are implemented variable length. > >Area addresses may computed as (total length - (system ID +1) ) >I read it somewhere but its not exactly flashing me where .. > >Manav > > > > > /mpb > > > > > > At 10:50 08/10/2001 -0400, Jeff Learman wrote: > > > > >Friends don't let friends use 8-byte system IDs ;-) > > > > > >RFC 1142 is the draft standard. One of the wonderful things that > > >the ISO committee did was to permit the system ID to be 1-8 bytes, > > >making our lives more enjoyable and increasing employment security > > >for software engineers. The ID size must be constant throughout > > >a routing domain. > > > > > >You need to implement ISO 10589, not the draft standard. > > > > > >Regards, > > >Jeff > > > > > >At 12:55 AM 8/10/2001, Manav Bhatia wrote: > > > >Hi, > > > >The general structure of the NSAP structure as defined in RFC 1629 >(6.2.1) > > > >gives the length of system Identifier to be varying from 1-8 octets. > > > >The length of the source ID for all the IS-IS PDUs as given in the rfc >1142 > > > >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this >into > > > >6 octets in my IS-IS PDUs ?? > > > > > > > >Regards, > > > >Manav Bhatia > > > > > > > >"C is not a big language, and is not well served by a big book." -- >K&R2 > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com From truskows@cisco.com Fri Aug 10 16:22:53 2001 From: truskows@cisco.com (Mike Truskowski) Date: Fri, 10 Aug 2001 8:22:53 PDT Subject: [Isis-wg] NSAP Structure In-Reply-To: <02ee01c121af$517a5690$da046c6b@Manav>; from "Manav Bhatia" at Aug 10, 101 8:14 am Message-ID: <200108101522.IAA06224@diablo.cisco.com> See below... > > > To the best of my knowledge, no one has implemented anything but 6 byte > > systemID's. > > But its defined in the RFC .. so there is no garuntee that all systems IDs > will fall under 6 bytes ! Look, the systemID can be, by ISO, 1-8 bytes. If you want to code for 1-8 bytes.. fine... but what Micah and Jeff are telling you is that the "world" uses 6 byte ids and this is consistant domain wide. > > > > > Also, the sourceID is systemID Length +1. systemID = 6 nsel =1 everything else in front of this is the area address. mwt > > Is the +1 for the SEL byte ?? > I dont think the SEL byte is included in defining the unique ID of the IS > i.e. Source ID ! > > > > > Area addresses however are implemented variable length. > > Area addresses may computed as (total length - (system ID +1) ) > I read it somewhere but its not exactly flashing me where .. > > Manav > > > > > /mpb > > > > > > At 10:50 08/10/2001 -0400, Jeff Learman wrote: > > > > >Friends don't let friends use 8-byte system IDs ;-) > > > > > >RFC 1142 is the draft standard. One of the wonderful things that > > >the ISO committee did was to permit the system ID to be 1-8 bytes, > > >making our lives more enjoyable and increasing employment security > > >for software engineers. The ID size must be constant throughout > > >a routing domain. > > > > > >You need to implement ISO 10589, not the draft standard. > > > > > >Regards, > > >Jeff > > > > > >At 12:55 AM 8/10/2001, Manav Bhatia wrote: > > > >Hi, > > > >The general structure of the NSAP structure as defined in RFC 1629 > (6.2.1) > > > >gives the length of system Identifier to be varying from 1-8 octets. > > > >The length of the source ID for all the IS-IS PDUs as given in the rfc > 1142 > > > >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this > into > > > >6 octets in my IS-IS PDUs ?? > > > > > > > >Regards, > > > >Manav Bhatia > > > > > > > >"C is not a big language, and is not well served by a big book." -- > K&R2 > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From rsaluja@nortelnetworks.com Fri Aug 10 16:28:25 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Fri, 10 Aug 2001 11:28:25 -0400 Subject: [Isis-wg] Three way handshake draft References: <3B73FA12.C3FFA5D9@laurelnetworks.com> Message-ID: <3B73FD99.4573767E@nortelnetworks.com> Tayfun Gol wrote: > I was wondering why this draft got expired. Looking at the mail > archives, it just passed away silently. Does anybody have an idea? > > Thanks in advance... > > -- > > Tayfun Gol > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg Tayfun, Three way handshake draft passed last call in January and was submitted to IESG for information RFC. The draft's expiry date was January 2001 and hence was probably removed from IETF drafts page. Thanks, Rajesh -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From manigandanm@rediffmail.com Fri Aug 10 16:55:07 2001 From: manigandanm@rediffmail.com (Selvam Murugesan) Date: 10 Aug 2001 15:55:07 -0000 Subject: [Isis-wg] Appropriate standard document for implemention of ISIS Message-ID: <20010810155507.6235.qmail@mailweb32.rediffmail.com> Hi, = I have a confusion on which version of the below stated ISO 10589 st= andards to follow for implementing the ISIS protocol? Which of this has t= he bug-free specifications of this standard? = 1. ISO/IEC 10589:1992 = 2. ISO/IEC 10589:1992/Cor 1:1993 3. ISO/IEC 10589:1992/Cor 2:1996 4. ISO/IEC 10589:1992/Cor 3:1996 5. ISO/IEC 10589:1992/Amd 1:1996 Implementation conformance statement pro= formas 6. ISO/IEC 10589:1992/Amd 2:1999 Extensions for group composition and rel= ated MST multicast routeing. Please help!!! Thanks in advance Regards, Selvam _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm From jparker@axiowave.com Fri Aug 10 17:26:15 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 10 Aug 2001 12:26:15 -0400 Subject: [Isis-wg] NSAP Structure Message-ID: > > To the best of my knowledge, no one has implemented > > anything but 6 byte systemID's. > > But its defined in the RFC .. so there is no garuntee that > all systems IDs will fall under 6 bytes ! You will be within the letter of the spec if you release a version of IS-IS that uses something other than 6 bytes. However, you will have trouble interoperating with any one else, and thus trouble deploying such gear. It is like one of those amusing laws that are left on the books that everyone knows enough to ignore. Unfortunately for those attempting to learn the protocol from the spec, the spec includes facts that just aren't so. This issue pops up on the list from time to time, and serves as a shibboleth. - jeff parker - axiowave networks From mnvbhatia@yahoo.com Fri Aug 10 17:34:06 2001 From: mnvbhatia@yahoo.com (Manav Bhatia) Date: Fri, 10 Aug 2001 09:34:06 -0700 (PDT) Subject: [Isis-wg] NSAP Structure In-Reply-To: Message-ID: <20010810163406.63633.qmail@web14913.mail.yahoo.com> Thanks a lot for clearing this up ! --- Jeff Parker wrote: > > > To the best of my knowledge, no one has implemented > > > anything but 6 byte systemID's. > > > > But its defined in the RFC .. so there is no garuntee that > > all systems IDs will fall under 6 bytes ! > > You will be within the letter of the spec if you release > a version of IS-IS that uses something other than 6 bytes. > However, you will have trouble interoperating with any > one else, and thus trouble deploying such gear. > > It is like one of those amusing laws that are left on the > books that everyone knows enough to ignore. Unfortunately > for those attempting to learn the protocol from the spec, > the spec includes facts that just aren't so. > > This issue pops up on the list from time to time, and > serves as a shibboleth. > > - jeff parker > - axiowave networks __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From Manav Bhatia" Hi All, In the Level 1 Link State PDU there is a field IS TYPE. It has two bits where bit 1 set indicates that it is a L1 IS and bit 2 set indicates that it is a L2 IS. The other combinations are unused. What should i set if the IS is L1/L2 ? Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jparker@axiowave.com Fri Aug 10 19:22:13 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 10 Aug 2001 14:22:13 -0400 Subject: [Isis-wg] Area Architecture Message-ID: > > Are you implying that one IS can be > > in multiple areas ?? > No, I am saying that an area can have multiple area addresses. > > /mpb This does sound puzzling, but has a useful application. If you have two ISIS areas, A and B, that you wish to combine into one, you can do this by going to all the routers in area A, one by one, and adding area B. Two routers that share a common area will form an association. This forms a large area with all routers in B, and some in B as well as A. The administrator can now go around and remove area A from all routers. The result is that neither Area A nor Area B are ever split up, even though only one router is changed at a time. There is provision in the spec for configuring a router a third area. This is akin to giving a loan officer a heart. It does the them no good, and just confuses the rest of us. - jeff parker - axiowave networks PS Many of the questions that have appeared on the list in the last week are addressed in Radia Perlman's "Interconnections". Even if you have a copy of the first edition, she wouldn't mind if you rushed out to buy a copy of the new edition. Not only is this an excellent (the only?) source on ISIS, she stoops to discuss OSPF, Bridging, and many other topics. From jparker@axiowave.com Fri Aug 10 20:04:59 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 10 Aug 2001 15:04:59 -0400 Subject: [Isis-wg] doubts on IS-IS topology and addressing Message-ID: > 1. Is it must for Level-1 IS to have a adjacency maintained > with a Level-2 IS or can the Level-1 IS communicate with a > Level-2 IS via Level-1 IS? No, yes. In the figure below, IS A can communicate with IS C via IS B. L1 A ====== L1/2 B ==== L2 C > 2.Regarding the ISO DCC addressing format adopted for Is-IS > addresses using semi-octet decimal digits representation, the > DSP is allocated 0-35 digits. Assuming CFI =1 (single digit), > then CDI = 3digits,ESI = 31 digits, which adds up the total > digits in the DSP to 35 digits. How is SEL field of the DSP > accomodated in this case? > > Manigandan There is a great deal of structure embedded in the ISO area field. However, the good news is that routers that don't need to route OSI traffic don't need to pay attention to this, and can treat the addresses as opaque tokens. Likewise, an OSPF area is formated like IP addresses, but is not interpreted as such. - jeff parker - axiowave networks From ginsberg@pluris.com Fri Aug 10 21:23:27 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Fri, 10 Aug 2001 13:23:27 -0700 Subject: [Isis-wg] Appropriate standard document for implemention of I SIS Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A5F1@avalon.pluris.com> The documents below form a complementary set. The corrigenda include corrections to the text in the 1992 standard. The amendments are additions to the original text. So you must take into account all of the documents. In addition, I would strongly recommend that you utilize the latest second edition draft of ISO 10589, which is freely available from: ftp.cisco.com/pub/rfc/ISO/ ISO10589v2-2001-07-04.pdf Although this draft has yet to be formally approved by ISO, it has virtually completed its public review and is unlikely to undergo further significant revision. It incorporates all of the corrigenda and amendments into a single document - and includes some additional corrections which have never been published in any corrigenda. In addition, it is currently freely available during the review period - something which may not last. (ISO does not routinely make specs available for free) Of course none of this addresses IP specific extensions. For that you will have to consult the plethora of RFCs, drafts, and (in some cases) expired drafts - a list of (most of)which can be found on this group's webpage. I doubt that a specification of a protocol as complex as IS-IS will ever be 100% defect free - this also contributes to job security for protocol designers/implementors. Les -----Original Message----- From: Selvam Murugesan To: isis-wg@spider.juniper.net Sent: 8/10/01 8:55 AM Subject: [Isis-wg] Appropriate standard document for implemention of ISIS Hi, I have a confusion on which version of the below stated ISO 10589 standards to follow for implementing the ISIS protocol? Which of this has the bug-free specifications of this standard? 1. ISO/IEC 10589:1992 2. ISO/IEC 10589:1992/Cor 1:1993 3. ISO/IEC 10589:1992/Cor 2:1996 4. ISO/IEC 10589:1992/Cor 3:1996 5. ISO/IEC 10589:1992/Amd 1:1996 Implementation conformance statement proformas 6. ISO/IEC 10589:1992/Amd 2:1999 Extensions for group composition and related MST multicast routeing. Please help!!! Thanks in advance Regards, Selvam _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From jparker@axiowave.com Fri Aug 10 21:43:59 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 10 Aug 2001 16:43:59 -0400 Subject: [Isis-wg] draft-shand-isis-restart Message-ID: Mike - I have a comment and a couple of questions about your draft, http://search.ietf.org/internet-drafts/draft-shand-isis-restart-01.txt 1) There was a great deal of concern during the discussions of OSPF restart and again about ISIS restart that we should not restart with the routing tables from a router that has crashed. However, there is still benefit in a proposal such as yours. If a router detects memory corruption in a routing task, it may wish to invalidate the route table before crashing so the restart mechanism is not used on reboot. Adding this as a suggestion may aleviate some concerns. However, a bug in the telnet task need not affect the route table. With a good memory architecture, the telnet task may be unable to affect the route table. 2) Assume that you are doing a controlled reboot of a router which takes longer than 30 seconds to reboot. Would you consider sending out hello messages that extend the hold time to cover the expected reboot time? That is, sending out hello messages with a hold time that matches the expected reboot time, rather than sticking with the previous value used. The issue of unreliable transmission arises, but your scheme doesn't require everything to go perfectly to reduce the amount of churn. 3) In your presentation of the draft on Wednesday, you made the observation that since the CSNP was not acknowledged, you needed to add a bit to the restart protocol to acknowledge the CSNP. Is the problem of the unreliable CSNP general enough that a general solution is called for? There are applications in bringing up p2p networks, in more restricted flooding topologies, etc. that would benefit from a reliable CSNP. The CSNP could include a sequence number, and the acknowledgement could be a Hello or an SNP with the right sequence number. (You could even return the CSNP rcvd) Negotiating this capacity could be done dynamically in hello packets, so the sender would know if it was worth resending the CSNP. - jeff parker - axiowave networks - diagnostic: someone who doesn't believe in two gods From srikrishna_nh@yahoo.co.in Mon Aug 13 09:29:19 2001 From: srikrishna_nh@yahoo.co.in (=?iso-8859-1?q?sudhir=20dskjf?=) Date: Mon, 13 Aug 2001 09:29:19 +0100 (BST) Subject: [Isis-wg] pseudonode Message-ID: <20010813082919.91929.qmail@web8101.in.yahoo.com> hi all, i am having some trouble understanding the concept of pseudonode. As far as i have understood pseudonode is the lan itself. but to which system the attached systems report their links. maybe the question is a bit trivial. any help is appreciated. thanks in advance srikrishna ____________________________________________________________ Do You Yahoo!? Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com. From swatirstogi@yahoo.com Mon Aug 13 09:41:13 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Mon, 13 Aug 2001 14:11:13 +0530 Subject: [Isis-wg] Pseudonode Message-ID: <008501c123d3$c37aef90$da046c6b@Manav> Please help me in figureing out as to how IS-IS operates on a lan. The DR is selected from the number of ISs on the LAN and all the ISs convey the info that they are connected to the pseudonode to the DR only. All manual adjacencies are advertised by the individual ISs only .. i.e this information is multicasted on the LAN. The DR knows which all ISs are there on the lan and its only this information which is included in its CSNP .. PSNPs are issued by the individual ISs as an acknowledgment or when they see that their database differs from that of the DR. Is this correct ?? The reason why the DR is elected is to reduce the number of adjacencies maintained at each end of the IS ? With warm regards, Swati Rastogi _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Manav Bhatia" Hi All, I am referring to ISO/IEC 10589:2001 (E) and in Section 7.3.15.1 ("Action on receipt of the link state PDU") section 9b it says "If the source S of the LSP is an IS or pseudonode for which all but the last octet are equal to the systemID of the receiving IS, and the recveiving IS does not have that LSP in its database .. " My question is that how can an IS receive an LSP issued by itself ?? Please comment. Thanks and Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jparker@axiowave.com Mon Aug 13 15:04:25 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 13 Aug 2001 10:04:25 -0400 Subject: [Isis-wg] A doubt Message-ID: > My question is that how can an IS receive an LSP issued by itself ?? > > Manav Bhatia Here are two scenarios in which a router will receive an LSP with it's SystemId that it has not originated. 1) If router A reboots, there may still be copies of LSPs from the previous run. These will continue to be flooded around the network until the originating router trumps them. 2) It is also possible to have missconfigured a network to have two routers with the same system Id. The protocol deals with the first but is not designed to cope with the second. - jeff parker - axiowave networks From jparker@axiowave.com Mon Aug 13 15:37:21 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 13 Aug 2001 10:37:21 -0400 Subject: [Isis-wg] Pseudonode Message-ID: > The DR is selected from the number of ISs on the LAN and all > the ISs convey the info that they are connected to the > pseudonode to the DR only. All manual adjacencies are > advertised by the individual ISs only .. i.e this > information is multicasted on the LAN. So far so good... > The DR knows which all ISs are there > on the lan and its only this information which is included in > its CSNP .. There are two distinct things that the LAN DIS (DR) does 1) Sending periodic CSNPs to keep members of the LAN in sync 2) Acts as representative of the LAN to reduce the amount of adjacencies advertised in LSPs. The CSNP is merely a description of what the sender has in it's LSP database, and has no relation to which IS's are on the LAN. > PSNPs are issued by the individual ISs as an > acknowledgment or when they see > that their database differs from that of the DR. Right. You can use these to "pull" an LSP that you have learned about through a CSNP. - jeff parker - axiowave networks From prz@redback.com Mon Aug 13 22:32:52 2001 From: prz@redback.com (Tony Przygienda) Date: Mon, 13 Aug 2001 14:32:52 -0700 Subject: [Isis-wg] Three way handshake draft References: <3B73FA12.C3FFA5D9@laurelnetworks.com> <3B73FD99.4573767E@nortelnetworks.com> Message-ID: <3B784784.806519E3@redback.com> Rajesh Saluja wrote: > Tayfun Gol wrote: > > > I was wondering why this draft got expired. Looking at the mail > > archives, it just passed away silently. Does anybody have an idea? > > > > Thanks in advance... > > Tayfun (hope you're settling ok in Pitt ;-), there are multiple drafts hanging in last step (look @ upcoming ISIS WG minutes) that were dependent on some TLV number assignment clarification. Given the tlv-codepoints draft that can be referenced now, they should be updated and be avaialble as RFC any minute now ... thanks -- tony From aravindravikumar@yahoo.com Tue Jul 31 16:13:49 2001 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Tue, 31 Jul 2001 08:13:49 -0700 (PDT) Subject: [Isis-wg] ISIS-BGP interaction In-Reply-To: <20010730194305.A9649CAB72@prattle.redback.com> Message-ID: <20010731151349.73282.qmail@web11206.mail.yahoo.com> --0-1920075302-996592429=:73267 Content-Type: text/plain; charset=us-ascii Thanks for your reply,but I would like get more information on the issue I tried to retrive the document that you have specified. But it seems that it is not currently available.I had read rfc 1745,but it speaks only about the interaction of OSPF with BGP/IDRP.But what I would like to know is that is there any well defined reference document which describes the interaction between ISIS and BGP IN the charter of Inter-Domain Routing (idr) working group there is a reference to BGP/IDRP -- OSPF Interactions .It is said that this document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP - OSPF interactions, and IDRP - IS-IS interaction documents. >From what I infer This has been published as rfc 1745.I think that the two references mentioned as BGP - OSPf interactions and IDRP -ISIS interactions are RFC1403 and "The Technical Design for Routeing Information Exchange between ISIS and IDRP" (Oran, D., Rekhter, Y., Hares, S.) respectievely Since I am interesred in knowing about ISIS -BGP interaction ,I felt that the ISIS-IDRP interaction document will be useful.But I was unable to get the above mentioned document. Aravind Naiming Shen wrote: http://www.ietf.org/IESG/actions.html BGP4/IDRP for IP---OSPF Interaction (Historic) ] ]Hi, ] ]Is there any standard document, defining the interaction between integrated I SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was tha t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha t the status of ISIS-BGP interaction document is unknown and it needs to be pub lished as as draft\rfc.Can I get more information on this issue. ] ]Aravind ] - Naiming --------------------------------- Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --0-1920075302-996592429=:73267 Content-Type: text/html; charset=us-ascii

Thanks for your reply,but I would like get more information on the issue

 I tried to retrive the document that you have specified. But it seems that it is not currently available.I had read rfc 1745,but it speaks only about the interaction of OSPF with BGP/IDRP.But what I would like to know is that is there any well defined reference document which describes the interaction between ISIS and BGP

IN  the charter of Inter-Domain Routing (idr) working group there is a reference to
BGP/IDRP -- OSPF Interactions .It is said that this document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP - OSPF interactions, and IDRP - IS-IS interaction documents.

From what I infer This has been published as rfc 1745.I think that the two references mentioned as BGP - OSPf interactions and IDRP -ISIS interactions are RFC1403 and "The Technical Design for Routeing Information Exchange between ISIS and IDRP" (Oran, D., Rekhter, Y., Hares, S.)  respectievely

 Since I am interesred in knowing about ISIS -BGP interaction ,I felt that the ISIS-IDRP interaction document will be useful.But I was unable to get the above mentioned document.

Aravind

  Naiming Shen <naiming@redback.com> wrote:


http://www.ietf.org/IESG/actions.html


BGP4/IDRP for IP---OSPF Interaction (Historic)

]
]Hi,
]
]Is there any standard document, defining the interaction between integrated I
SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone
through the minutes of ISIS working group .The strange thing I noticed was tha
t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha
t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha
t the status of ISIS-BGP interaction document is unknown and it needs to be pub
lished as as draft\rfc.Can I get more information on this issue.
]
]Aravind
]

- Naiming


Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/ --0-1920075302-996592429=:73267-- From Radia Perlman - Boston Center for Networking Tue Jul 31 16:22:04 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Tue, 31 Jul 2001 11:22:04 -0400 (EDT) Subject: [Isis-wg] Dual IS-IS Message-ID: <200107311522.LAA17445@bcn.East.Sun.COM> From: "Sachidananda K" Is the link state database maintained seperately for both OSI addresses and IP addresses or is it one and the same. Although this is really an implementation issue rather than a protocol issue, I assume the link state database is "one and the same". An LSP basically says "I, router R1, have neighbors R2, R3, and R4, and the IP addresses I'm connected to are x, y, and z, and the CLNP addresses I can reach are A and B". So the same LSP can contain information about multiple address families. One could put information for different address families into different LSP fragments, but I don't see any reason to. The forwarding table is another issue. I'd think it would be more convenient to have separate forwarding tables for each address family, rather than a single lookup engine that would be able to process multiple types of addresses. Are there still networks with both types of addresses? Radia From rcheh@rcn.com Sat Aug 4 04:01:27 2001 From: rcheh@rcn.com (Raymond Cheh) Date: Fri, 3 Aug 2001 23:01:27 -0400 Subject: [Isis-wg] Doubt regarding Default Informatoin Originate References: <200108040227.TAA19291@mail4.bigmailbox.com> Message-ID: <003f01c11c91$c4d1bd40$c05a2c42@rcheh> That may be useful when one wants to specify a preferred default gateway rather than using the closest attached L12 router. Packets will use the router advertising the default gateway (because that is a route match) before using the ATT bit. Raymond Cheh ----- Original Message ----- From: "R Selvaraj" To: Cc: Sent: Friday, August 03, 2001 10:27 PM Subject: [Isis-wg] Doubt regarding Default Informatoin Originate > Hi, > > I would like to know the advantage of originating default information in L1 LSPs. Since Att bit itself is sufficient for finding default route in a L1 area then what is the significant of originating default informaton in L1 LSPs. > Pls let me clarified. > > Thanks, > Selva. > > > > ------------------------------------------------------------ > WWW.COM - Where the Web Begins! http://www.www.com > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From acee@redback.com Wed Aug 8 19:41:02 2001 From: acee@redback.com (Acee Lindem) Date: Wed, 08 Aug 2001 14:41:02 -0400 Subject: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt References: <20010808180824.B0A80F2C4B@prattle.redback.com> Message-ID: <3B7187BE.5D719B01@redback.com> Naiming Shen wrote: > > Martin, > some comments inline, thanks. > > ]Folks, > ] > ]I have some comments on the draft that I'd like to address with the WG. I > ]apologize for cutting this so close to the meeting, but this is the first > ]chance I've had to address it. > ] > ]A while back I began considering how IS-IS could be made to support PTP > ]behavior over BMA networks. The driving force behind this was primarily the > ]ability to assign arbitrary, per-neighbor metric information to individual > ]neighbors. A second benefit would be the elimination of pseudonode exposion > ]when a large amount of PTP LAN links were used to interconnect routers. I > ]sent an email detailing the need to the WG, but there was little response. > ]Some notable vendors also displayed little interest. The only suggestion I > ]received, in fact, was to use PPPoE! After reviewing the draft, I have some > ]concern about the utility of the proposal, and whether or not it satisfies a > ]real need. While it does have merit and will help in many situations, the > ]scope should be expanded to address some more complex situations. Comments > ]of course are welcome. > ] > ]In regards to OSPF: > ] > ]OSPF currently supports NBMA networks. What we are attempting to do here is > ]create PtMP (of where MP can be P if there are only two nodes on a LAN) > ]networks out of BMA networks in order to support PTP type behavior, from a > ]Djiktsra perspective, correct? This is in OSPF today. You can build NBNA > ]networks on LANs and specify neighbors explicitly, with associated metrics. > ]The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion > ]based on the configured neighbor IP. As I see it, the only benefit the > ]draft provides is the elimination of DR election (and the corresponding > ]elimination of pseudonodes on PTP links), which can be done by making the > ]interface point-to-multipoint (although requiring configuration). The major > ]vendors support this feature today (I use it!). Martin, As you suggest, OSPF P2P over LAN is similiar to OSPF P2MP and they offer many of the same advantages. The arguments (which some may consider weak) for OSPF P2P over LAN are: 1. It allows a LAN or vLAN that is being used as P2P link to be viewed and configured as one. 2. It allows for unnumbered operation of a LAN or vLAN being used as P2P link. 3. It offers a unified view of the LAN or vLAN across OSPF and ISIS (since ISIS does not have P2MP). Thanks, -- Acee From Manav Bhatia" ISO/IEC 10589 says in section 8.4.2 that "LAN IIH PDUs shall be padded so that the SNSDU containing the IIH PDU as a length of atleast maxsize - 1 octets where maxsize for level 1/2 IIH PDUs is the maximum of - dataLinkBlockSize - originatingL1/2LSPBufferSize" This as i understand, is done to ensure that the adjaceny will only be formed between systems which are capable of exchanging PDUs of length up to maxsize octets. Consider the following scenario. The network is in a congested state and we are bringing up the IS-IS system. All ISs will multicast these max sized IIH packets which will only serve to aggravate the already congested network. Instead of multicasting max sized packets why dont we simply multicast packets and include an additional field where we mention the maximum block size each IS supports. The lower value can always be accepted. This is similiar to how the value of hold timers in BGP is negotiated. Has anyone given a thought to this. Please comment. Thanks and Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Manav Bhatia" Errata .. Please replace "multicast" with "broadcast" Regards, Manav ----- Original Message ----- From: "Manav Bhatia" To: Sent: Tuesday, August 14, 2001 9:44 AM Subject: IIH PDU exchange > ISO/IEC 10589 says in section 8.4.2 that "LAN IIH PDUs shall be padded so > that the SNSDU containing the IIH PDU as a length of atleast maxsize - 1 > octets where maxsize for level 1/2 IIH PDUs is the maximum of > - dataLinkBlockSize > - originatingL1/2LSPBufferSize" > > This as i understand, is done to ensure that the adjaceny will only be > formed between systems which are capable of exchanging PDUs of length up to > maxsize octets. > > Consider the following scenario. > > The network is in a congested state and we are bringing up the IS-IS system. > All ISs will multicast these max sized IIH packets which will only serve to > aggravate the already congested network. Instead of multicasting max sized > packets why dont we simply multicast packets and include an additional field > where we mention the maximum block size each IS supports. The lower value > can always be accepted. This is similiar to how the value of hold timers in > BGP is negotiated. > > Has anyone given a thought to this. > > Please comment. > > Thanks and Regards, > Manav Bhatia > > > > "C is not a big language, and is not well served by a big book." -- K&R2 > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From manigandanm@rediffmail.com Tue Aug 14 05:57:48 2001 From: manigandanm@rediffmail.com (Selvam Murugesan) Date: 14 Aug 2001 04:57:48 -0000 Subject: [Isis-wg] trivial doubt on LSP number and sequence number Message-ID: <20010814045748.19143.qmail@mailweb29.rediffmail.com> Hi, i have a simple doubt.What is the difference between a LSP number of = LSP ID field in the ISIS LSP PDU and Sequence number field? = = Thanks in advance Manigandan M _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm From Manav Bhatia" Message-ID: <01d701c12487$5743a380$da046c6b@Manav> Because a link state PDU is limited in size to RecieveLSPBufferSize, it may not be possible to include information of all neighboring systems in a single LSP. So a system issues multiple Lisps to convey this information. Each LSP carries the same sourceID field but sets its own LSP number field individually. This allows the distribution of topology updates to be pipelined. The other end recognizes that they have a common originating source because they all use the same sourceID. Generally adjacencies are assigned to particular LSP numbers. (Ref. 7.3.4.4 ISO/IEC 10589). On the other hand, sequence numbers are used to determine the latest information. Suppose u have some LSP in your database and you receive another update for the same link state. How do you differentiate between the two .. how do you check whether the one you are receiving is the new one .. or the one you have in your database is the latest ?? This is where the sequence numbers come in. Looking at the sequence number you can tell which LSP is the more recent one. Obviously the higher the sequence number, more recent your LSP is ! hope it helps clears smthg .. Manav ----- Original Message ----- From: "Selvam Murugesan" To: Sent: Tuesday, August 14, 2001 10:27 AM Subject: [Isis-wg] trivial doubt on LSP number and sequence number Hi, i have a simple doubt.What is the difference between a LSP number of LSP ID field in the ISIS LSP PDU and Sequence number field? Thanks in advance Manigandan M _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From sachidananda_k@hotmail.com Tue Aug 14 16:06:06 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Tue, 14 Aug 2001 15:06:06 +0000 Subject: [Isis-wg] SNPA or IP Message-ID: Hello, According to the RFC 1195, the OSI addresses may be derived from the IP address or the ethernet address. When it is derived from the IP address, the next hop in the IP routing table can be entered as the IP address of the next hop. Whereas if the it is derived from the ethernet address, what do we enter in the IP routing table? I think this a major concern for the Dual IS-IS for the reason that if the in IP the address resolution is dine by ARP in the DLL. Please clarify my doubt in this regard. Thanking you in advance for all the responses. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From jparker@axiowave.com Tue Aug 14 16:46:08 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 14 Aug 2001 11:46:08 -0400 Subject: [Isis-wg] IIH PDU exchange Message-ID: > "LAN IIH PDUs shall be padded... > > Consider the following scenario: The network is in a > congested state and we are bringing up [all] the IS-IS > system[s]. > > Manav Bhatia Manav - There are periodic dicussions on the list about the utility of the padding, and I won't rehash those here. If you have so many IS-IS routers that periodic hello packets are a big problem, then I suspect the LSP exchange that will start once the adjacencies come up will have a greater effect. - jeff parker From dhudek@ma.ultranet.com Tue Aug 14 23:35:56 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Tue, 14 Aug 2001 15:35:56 -0700 Subject: [Isis-wg] ISIS as Pack Mule? Message-ID: <3B79A7CB.D886703@ma.ultranet.com> For various reasons, there would appear to be a growing trend of having ISIS act as a convenient flooding mechanism for conveying different types of information that is essentially a "dont-care" for ISIS itself. Draft RFCs call for data to be added to LSPs that may be of interest to other entities, such as GMPLS or a constraint based SPF, but would not make any difference to a normal ISIS default metric SPF run. When that dont-care data changes within an LSP, a straightforward implementation that compares a modified checksum and/or does a simple byte-wise comparison on received LSPs (as mentioned in 10589) would detect that LSP data had changed, and schedule what will turn out to be an unnecessary SPF run. Even if ISIS would prefer not send updated LSPs very frequently if only non-ISIS data changes, there will be pressure to act in a timely fashion from the point of view of the other entities to convey their changed and changing data rapidly. If this dont-care data changes frequently there would be frequent unnecessary SPF runs (gated by whatever SPF pacing scheme one uses). As more types of dont-care data is loaded aboard LSPs over time, the liklihood of frequent dont-care changes increases. Of course, a receiver could actually intelligently parse each received LSP that differs, comparing fields against the earlier version, and decide for itself if the changes warrant an SPF run, but that seems like a lot of unnecessary extra work given that the originator of an LSP ought to know why they are changing it in the first place and could just simply let everyone else know. I was wondering about the effect of adding a new TLV in which the originator could convey that info. It might be as simple as a yes/no whether or not any change from the LSP with previous seqnum actually mattered to ISIS, or as complex as indicating which entity(ies) might be interested in the change, or something in-between. At first blush, it seems like it would improve scalability, with the only down-side being some security issues (however, none seem insurmountable). Folks can continue to load up ISIS with data only meaningful to other entities, and the extra burden would be generally limited to the flooding aspect, not also unnecessary SPF runs or extra parsing/comparisons. ISIS could even act more responsively to dont-care data changes, updating LSPs somewhat more frequently since their effect would be somewhat mitigated. So of course, the question arises, what's the horrible fatal flaw that's not jumping out just yet? :-) Is this something worth pursuing? Thanks, dave h dhudek@ma.ultranet.com From prz@redback.com Tue Aug 14 21:21:19 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 14 Aug 2001 13:21:19 -0700 Subject: [Isis-wg] ISIS as Pack Mule? References: <3B79A7CB.D886703@ma.ultranet.com> Message-ID: <3B79883E.90DC6C77@redback.com> David Hudek wrote: > For various reasons, there would appear to be a growing > trend of having ISIS act as a convenient flooding mechanism > for conveying different types of information that is > essentially a "dont-care" for ISIS itself. Draft RFCs call > for data to be added to LSPs that may be of interest to other > entities, such as GMPLS or a constraint based SPF, but would > not make any difference to a normal ISIS default metric SPF run. > > When that dont-care data changes within an LSP, a straightforward > implementation that compares a modified checksum and/or does a simple > byte-wise comparison on received LSPs (as mentioned in 10589) would > detect that LSP data had changed, and schedule what will turn out to be > an unnecessary SPF run. Even if ISIS would prefer not send updated LSPs > very frequently if only non-ISIS data changes, there will be pressure to > act in a timely fashion from the point of view of the other > entities to convey their changed and changing data rapidly. > If this dont-care data changes frequently there would be frequent > unnecessary SPF runs (gated by whatever SPF pacing scheme one uses). > As more types of dont-care data is loaded aboard LSPs over time, the > liklihood of frequent dont-care changes increases. > > Of course, a receiver could actually intelligently parse > each received LSP that differs, comparing fields against the earlier > version, and decide for itself if the changes warrant an SPF run, > but that seems like a lot of unnecessary extra work given > that the originator of an LSP ought to know why they are > changing it in the first place and could just simply let everyone > else know. > > I was wondering about the effect of adding a new TLV in which > the originator could convey that info. It might be as simple as > a yes/no whether or not any change from the LSP with previous > seqnum actually mattered to ISIS, or as complex as indicating > which entity(ies) might be interested in the change, or something > in-between. The above has been proposed for PNNI years ago which had a somehow similar problem (lots of QoS metrics that when changed will not necessarily trigger computations) and it has not been well received due to several reasons. One of them being that to do things well you need basically a bitfield @ every TLV, sub-TLV, sub-subTLV level which is not very convienent and leads to a complex, easily broken representation. The other problem being that just missing one of those something-changed-bits can lead to catastrophic failures easily that are very hard to track down. Philosophically, it is not a good idea to put redundant data into the protocol messages since you have to account for behavior when the data contradicts itself. Messy stuff ... At least one leading vendor implemented the 'smart parse & figure out changes' thing and it worked very well without a lot of CPU overhead. Yes, some tricky code is involved but that's how protocol implementors make their living and vendors differentiate themselves ... I guess I'm saying my initial reaction is that's an implementation specific thing which we don't govern in the workgroup normally. thanks -- tony From tgol@laurelnetworks.com Tue Aug 14 22:28:45 2001 From: tgol@laurelnetworks.com (Tayfun Gol) Date: Tue, 14 Aug 2001 17:28:45 -0400 Subject: [Isis-wg] SNPA or IP References: Message-ID: <3B79980D.2E7ECD6B@laurelnetworks.com> Sachidananda K wrote: > Hello, > > According to the RFC 1195, the OSI addresses may be derived from the IP > address or the ethernet address. > > When it is derived from the IP address, the next hop in the IP routing table > can be entered as the IP address of the next hop. > Sachi, the OSI address is not used to derive the next hop IP address for adjacenct routers. It simply serves the purpose of uniquely identifiying a router from others in a topology. ( This is where you can derive the router's system ID which will be part of the LSP ID for the LSPs the router will generate, you can think of an IS-IS router's system ID analogous to an OSPF router's router ID. ) A router can resolve the next hop IP addresses for its adjacenct routers via the IP interface address TLV sent in the IIH PDUs and populate the routing table accordingly. Hope this helps... Tayfun Gol > > Whereas if the it is derived from the ethernet address, what do we enter in > the IP routing table? I think this a major concern for the Dual IS-IS for > the reason that if the in IP the address resolution is dine by ARP in the > DLL. > > Please clarify my doubt in this regard. > Thanking you in advance for all the responses. > Sachi > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From tgol@laurelnetworks.com Tue Aug 14 22:31:35 2001 From: tgol@laurelnetworks.com (Tayfun Gol) Date: Tue, 14 Aug 2001 17:31:35 -0400 Subject: [Isis-wg] SNPA or IP References: <3B79980D.2E7ECD6B@laurelnetworks.com> Message-ID: <3B7998B7.70641D11@laurelnetworks.com> Tayfun Gol wrote: > Sachidananda K wrote: > > > Hello, > > > > According to the RFC 1195, the OSI addresses may be derived from the IP > > address or the ethernet address. > > > > When it is derived from the IP address, the next hop in the IP routing table > > can be entered as the IP address of the next hop. > > > > Sachi, the OSI address is not used to derive the next hop IP address for > adjacenct routers. It simply serves the purpose of uniquely identifiying a > router from others in a topology. ( This is where you can derive the router's > system ID which will be part of the LSP ID for the LSPs the router will > generate, you can think of an IS-IS router's system ID analogous to an > OSPF router's router ID. ) > To clarify further, this is at least the case for IP routing if this is all you are concerned about, OSI address surely serves other purposes for OSI forwarding but I am assuming that's not what you are wondering.. > > A router can resolve the next hop IP addresses for its adjacenct routers via > the IP interface address TLV sent in the IIH PDUs and populate the routing > table accordingly. > > Hope this helps... > > Tayfun Gol > > > > > Whereas if the it is derived from the ethernet address, what do we enter in > > the IP routing table? I think this a major concern for the Dual IS-IS for > > the reason that if the in IP the address resolution is dine by ARP in the > > DLL. > > > > Please clarify my doubt in this regard. > > Thanking you in advance for all the responses. > > Sachi > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg From prz@redback.com Tue Aug 14 22:33:31 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 14 Aug 2001 14:33:31 -0700 Subject: [Isis-wg] tlv codepoints ... Message-ID: <3B79992B.9E287E89@redback.com> new version not submitted yet. Will wait 1-2 days on comments before putting out. numbers are _not_ sorted on purpose thanks -- tony Internet Engineering Task Force T. Przygienda INTERNET DRAFT Redback Aug 2001 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 Feb 2002 [Page 1] Internet Draft TLV Codepoints Aug 2001 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 TE IIS Neigh. 22 n y n IETF-draft MT-ISN 222 n y n IETF-draft LSPBufferSize 14 y? y n ISO 10589 Rev 2 Draft DECnet Phase IV 42 ? ? ? DEC (ancient) IP Int. Reach 128 n y n RFC 1195 IPv6 IP. Reach 236 n y n IETF-draft Prot. Supported 129 y y n RFC 1195 M-Topologies 229 y y n IETF-draft 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 IPv6 Intf. Addr. 232 y y n IETF-draft 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 MT IP. Reach 235 n y n IETF-draft Dynamic Name 137 n y n RFC 2763 3-Way hellos 240 y n n IETF-draft Przygienda Expires Feb 2002 [Page 2] Internet Draft TLV Codepoints Aug 2001 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 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. 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 Feb 2002 [Page 3] From ginsberg@pluris.com Wed Aug 15 00:04:08 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Tue, 14 Aug 2001 16:04:08 -0700 Subject: [Isis-wg] tlv codepoints ... Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A60A@avalon.pluris.com> Tony - The LSPBuffersize option is NOT included in IIH PDUs. So the definition should look like: LSPBufferSize 14 n y n ISO 10589 Draft Also, while I do not object to some other ordering scheme than straight numerical, I haven't figured out the algorithm you used to order/group the TLVs. Is this one of those pattern recognition tests? Or do you simply feel that chaos is a good thing? Les > -----Original Message----- > From: Tony Przygienda [mailto:prz@redback.com] > Sent: Tuesday, August 14, 2001 2:34 PM > To: isis-wg@juniper.net > Subject: [Isis-wg] tlv codepoints ... > > > new version not submitted yet. Will wait 1-2 days on comments before > putting out. numbers are _not_ sorted on purpose > > thanks > > -- tony > > > > > Internet Engineering Task Force T. > Przygienda > INTERNET DRAFT > Redback > > Aug 2001 > 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 Feb 2002 > [Page 1] > > > Internet Draft TLV Codepoints > Aug 2001 > > 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 > TE IIS Neigh. 22 n y n IETF-draft > MT-ISN 222 n y n IETF-draft > > > LSPBufferSize 14 y? y n ISO 10589 > Rev 2 Draft > > DECnet Phase IV 42 ? ? ? DEC (ancient) > > > IP Int. Reach 128 n y n RFC 1195 > IPv6 IP. Reach 236 n y n IETF-draft > > > Prot. Supported 129 y y n RFC 1195 > M-Topologies 229 y y n IETF-draft > > > 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 > IPv6 Intf. Addr. 232 y y n IETF-draft > > > 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 > MT IP. Reach 235 n y n IETF-draft > > > Dynamic Name 137 n y n RFC 2763 > 3-Way hellos 240 y n n IETF-draft > > > > Przygienda Expires Feb 2002 > [Page 2] > > Internet Draft TLV Codepoints > Aug 2001 > > 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 > > 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. > > > > 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 Feb 2002 > [Page 3] > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From amir@cwnt.com Wed Aug 15 12:54:43 2001 From: amir@cwnt.com (Amir Hermelin) Date: Wed, 15 Aug 2001 14:54:43 +0300 Subject: [Isis-wg] draft-hermelin-ext-lsp-frags-02.txt Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C12581.12689795 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, here's a new version of the draft. The main change is the ability to modify the SPF, and include adjacency info in extended LSPs. As you recall, this was discussed a little in the list and somewhat turned down; however, in the last IETF meeting it was agreed that SPF modification is acceptable. The modified mechanism still supports extending LSPs without needed SPF modification. Abstract This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. -- Amir Hermelin Charlotte's Web Networks Inc. ------_=_NextPart_001_01C12581.12689795 Content-Type: text/plain; name="draft-hermelin-ext-lsp-frags-02.txt" Content-Transfer-Encoding: base64 Content-Description: draft-hermelin-ext-lsp-frags-02.txt Content-Disposition: attachment; filename="draft-hermelin-ext-lsp-frags-02.txt" DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBbWlyIEhlcm1lbGluDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBDaGFybG90dGUncyBXZWIgTmV0d29ya3MNCkV4cGlyYXRpb24g RGF0ZTogRmVicnVhcnkgMjAwMg0KDQoNCiAgICBFeHRlbmRpbmcgdGhlIE51bWJlciBvZiBJUy1J UyBMU1AgRnJhZ21lbnRzIEJleW9uZCB0aGUgMjU2IExpbWl0DQoNCiAgICAgICAgICAgICAgICAg IGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0DQoNCg0KU3RhdHVzDQoNCiAgIFRo aXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFu Y2Ugd2l0aA0KICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3Jr aW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1 dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoNCiAgIFRoZSBsaXN0IG9mIEludGVy bmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAi TVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4g dGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBS RkMgMjExOSBbQkNQMTRdLg0KDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGEgc3lzdGVtIHRvIG9yaWdpbmF0ZQ0KICAgbW9y ZSB0aGFuIDI1NiBMU1AgZnJhZ21lbnRzLCBhIGxpbWl0IHNldCBieSB0aGUgb3JpZ2luYWwgSW50 ZXJtZWRpYXRlDQogICBTeXN0ZW0gdG8gSW50ZXJtZWRpYXRlIFN5c3RlbSAoSVMtSVMpIFJvdXRp bmcgcHJvdG9jb2wsIGFzIGRlc2NyaWJlZA0KICAgaW4gSVNPIDEwNTg5LiAgVGhpcyBtZWNoYW5p c20gY2FuIGJlIHVzZWQgaW4gSVAtb25seSwgT1NJLW9ubHksIGFuZA0KICAgZHVhbCByb3V0ZXJz Lg0KDQoNCg0KDQoNCg0KDQpBLiBIZXJtZWxpbiAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0IERyYWZ0ICAgICBk cmFmdC1oZXJtZWxpbi1leHQtbHNwLWZyYWdzLTAyLnR4dCAgICAgICBBdWd1c3QgMjAwMQ0KDQoN CjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgSW4gdGhlIElTLUlTIHByb3RvY29sLCBhIHN5c3RlbSBm bG9vZHMgaXRzIGxpbmstc3RhdGUgaW5mb3JtYXRpb24gaW4NCiAgIExpbmsgU3RhdGUgUHJvdG9j b2wgRGF0YSBVbml0cywgb3IgTFNQcyBmb3Igc2hvcnQuICBUaGVzZSBsb2dpY2FsDQogICBMU1Bz IGNhbiBiZWNvbWUgcXVpdGUgbGFyZ2UsIHRoZXJlZm9yZSB0aGUgcHJvdG9jb2wgc3BlY2lmaWVz IGEgbWVhbnMNCiAgIG9mIGZyYWdtZW50aW5nIHRoaXMgaW5mb3JtYXRpb24gaW50byBtdWx0aXBs ZSBMU1AgZnJhZ21lbnRzLiAgVGhlDQogICBudW1iZXIgb2YgZnJhZ21lbnRzIGEgc3lzdGVtIGNh biBnZW5lcmF0ZSBpcyBsaW1pdGVkIGJ5IElTTyAxMDU4OQ0KICAgW0lTSVMtSVNPXSB0byAyNTYg ZnJhZ21lbnRzLCB3aGVyZSBlYWNoIGZyYWdtZW50J3Mgc2l6ZSBpcyBhbHNvDQogICBsaW1pdGVk LiAgSGVuY2UsIHRoZXJlIGlzIGEgbGltaXQgb24gdGhlIGFtb3VudCBvZiBsaW5rLXN0YXRlDQog ICBpbmZvcm1hdGlvbiBhIHN5c3RlbSBjYW4gZ2VuZXJhdGUuDQoNCiAgIEEgbnVtYmVyIG9mIGZh Y3RvcnMgY2FuIGNvbnRyaWJ1dGUgdG8gZXhjZWVkaW5nIHRoaXMgbGltaXQ6DQogICAgIC0gIElu dHJvZHVjdGlvbiBvZiBuZXcgVExWcyBhbmQgc3ViLVRMVnMgdG8gYmUgaW5jbHVkZWQgaW4gTFNQ cy4NCiAgICAgLSAgVGhlIHVzZSBvZiBMU1BzIHRvIHByb3BhZ2F0ZSB2YXJpb3VzIHR5cGVzIG9m IGluZm9ybWF0aW9uIChzdWNoDQogICAgIGFzIHRyYWZmaWMtZW5naW5lZXJpbmcgaW5mb3JtYXRp b24pLg0KICAgICAtICBUaGUgZ3Jvd2luZyBzaXplIG9mIHJvdXRlIHRhYmxlcyBhbmQgQVMgdG9w b2xvZ2llcy4NCiAgICAgLSAgRmluZXIgZ3JhbnVsYXJpdHkgcm91dGluZywgYW5kIHRoZSBhYmls aXR5IHRvIGluamVjdCBleHRlcm5hbA0KICAgICByb3V0ZXMgaW50byBhcmVhcyBbRE9NQUlOLVdJ REVdLg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSB0byByZWxheCB0 aGUgbGltaXQgb24gdGhlIG51bWJlcg0KICAgb2YgTFNQIGZyYWdtZW50cy4NCg0KDQoxLjEgIERl ZmluaXRpb25zIG9mIENvbW1vbmx5IFVzZWQgVGVybXMNCg0KICAgVGhpcyBzZWN0aW9uIHByb3Zp ZGVzIGRlZmluaXRpb25zIGZvciB0ZXJtcyB0aGF0IGFyZSB1c2VkIHRocm91Z2hvdXQNCiAgIHRo ZSB0ZXh0Lg0KDQogICAgIE9yaWdpbmF0aW5nIFN5c3RlbQ0KICAgICAgICBBIHJvdXRlciBydW5u aW5nIHRoZSBJUy1JUyBwcm90b2NvbC4NCg0KICAgICBPcmlnaW5hbCBzeXN0ZW0taWQNCiAgICAg ICAgVGhlIHN5c3RlbS1pZCBvZiBhbiBPcmlnaW5hdGluZyBTeXN0ZW0uDQoNCiAgICAgRXh0ZW5k ZWQgc3lzdGVtLWlkDQogICAgICAgIEFuIGFkZGl0aW9uYWwgc3lzdGVtLWlkIHRoYXQgaXMgYXNz aWduZWQgYnkgdGhlIG5ldHdvcmsNCiAgICAgICAgYWRtaW5pc3RyYXRvci4gIEVhY2ggZXh0ZW5k ZWQgc3lzdGVtLWlkIGFsbG93cyBnZW5lcmF0aW9uIG9mIDI1Ng0KICAgICAgICBhZGRpdGlvbmFs LCBvciBleHRlbmRlZCwgTFNQIGZyYWdtZW50cy4gIFRoZSBleHRlbmRlZCBzeXN0ZW0taWQsDQog ICAgICAgIGxpa2UgdGhlIG9yaWdpbmFsIHN5c3RlbS1pZCwgbXVzdCBiZSB1bmlxdWUgdGhyb3Vn aG91dCB0aGUNCiAgICAgICAgcm91dGluZyBkb21haW4uDQoNCiAgICAgVmlydHVhbCBTeXN0ZW0N CiAgICAgICAgVGhlIHN5c3RlbSwgaWRlbnRpZmllZCBieSBhbiBleHRlbmRlZCBzeXN0ZW0taWQs IGFkdmVydGlzZWQgYXMNCiAgICAgICAgb3JpZ2luYXRpbmcgdGhlIGV4dGVuZGVkIExTUCBmcmFn bWVudHMuICBUaGVzZSBmcmFnbWVudHMgc3BlY2lmeQ0KICAgICAgICB0aGUgZXh0ZW5kZWQgc3lz dGVtLWlkIGluIHRoZWlyIExTUCBJRHMuDQoNCiAgICAgT3JpZ2luYWwgTFNQDQoNCg0KDQpBLiBI ZXJtZWxpbiAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAwMiAgICAgICAgICAgICAg ICAgW1BhZ2UgMl0NCgwNCkludGVybmV0IERyYWZ0ICAgICBkcmFmdC1oZXJtZWxpbi1leHQtbHNw LWZyYWdzLTAyLnR4dCAgICAgICBBdWd1c3QgMjAwMQ0KDQoNCiAgICAgICAgQW4gTFNQIHVzaW5n IHRoZSBvcmlnaW5hbCBzeXN0ZW0taWQgaW4gaXRzIExTUCBJRC4NCg0KICAgICBFeHRlbmRlZCBM U1ANCiAgICAgICAgQW4gTFNQIHVzaW5nIGFuIGV4dGVuZGVkIHN5c3RlbS1pZCBpbiBpdHMgTFNQ IElELg0KDQogICAgIExTUCBzZXQNCiAgICAgICAgQSBncm91cCBvZiBMU1AgZnJhZ21lbnRzIGNv bnN0aXR1dGluZyBhIGxvZ2ljYWwgTFNQLiAgVGhlc2UNCiAgICAgICAgc2hhcmUgYSBzcGVjaWZp YyBzeXN0ZW0taWQgYW5kIHBzZXVkb25vZGUgbnVtYmVyLCBhbmQgZGlmZmVyDQogICAgICAgIG9u bHkgaW4gdGhlaXIgTFNQIChvciBmcmFnbWVudCkgbnVtYmVyLg0KDQogICAgIEV4dGVuZGVkIExT UCBzZXQNCiAgICAgICAgQSBncm91cCBvZiBMU1AgZnJhZ21lbnRzIHVzaW5nIGFuIGV4dGVuZGVk IHN5c3RlbS1pZCwgYW5kDQogICAgICAgIG9yaWdpbmF0ZWQgYnkgdGhlIE9yaWdpbmF0aW5nIFN5 c3RlbS4gIFRoZXNlIGZyYWdtZW50cyBhcHBlYXIgdG8NCiAgICAgICAgb3RoZXIgcm91dGVycyBh cyBoYXZpbmcgYmVlbiBvcmlnaW5hdGVkIGJ5IHRoZSBWaXJ0dWFsIFN5c3RlbQ0KICAgICAgICBp ZGVudGlmaWVkIGJ5IGFuIGV4dGVuZGVkIHN5c3RlbS1pZC4NCg0KICAgICBFeHRlbnNpb24tY2Fw YWJsZSBJUw0KICAgICAgICBBbiBJUyBpbXBsZW1lbnRpbmcgdGhpcyBleHRlbnNpb24uDQoNCg0K MS4yICBPcGVyYXRpb24gTW9kZXMNCg0KICAgVHdvIGFkbWluaXN0cmF0aXZlIG9wZXJhdGlvbiBt b2RlcyBhcmUgcHJvdmlkZWQ6DQoNCiAgICAgICAtIE9wZXJhdGlvbiBNb2RlIDEgcHJvdmlkZXMg YmVoYXZpb3IgdGhhdCBhbGxvd3MgcHJldmlvdXMNCiAgICAgICBpbXBsZW1lbnRhdGlvbnMgdG8g Y29ycmVjdGx5IHByb2Nlc3MgdGhlIGV4dGVuZGVkIGZyYWdtZW50DQogICAgICAgaW5mb3JtYXRp b24sIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbnMgdG8gdGhlIFNQRiBhbGdvcml0aG0uDQogICAg ICAgVGhpcyBtb2RlIGhhcyBzb21lIHJlc3RyaWN0aW9ucyBvbiB3aGF0IG1heSBiZSBhZHZlcnRp c2VkIGluIHRoZQ0KICAgICAgIGV4dGVuZGVkIExTUCBmcmFnbWVudHMuICBOYW1lbHksIG9ubHkg bGVhZiBpbmZvcm1hdGlvbiBtYXkgYmUNCiAgICAgICBhZHZlcnRpc2VkIGluIHRoZSBleHRlbmRl ZCBMU1BzLg0KDQogICAgICAgLSAgT3BlcmF0aW9uIE1vZGUgMiBleHRlbmRzIHRoZSBwcmV2aW91 cyBtb2RlIGFuZCByZWxheGVzIGl0cw0KICAgICAgIGFkdmVydGlzZW1lbnQgcmVzdHJpY3Rpb25z LiAgQW55IGxpbmstc3RhdGUgaW5mb3JtYXRpb24gbWF5IGJlDQogICAgICAgYWR2ZXJ0aXNlZCBp biB0aGUgZXh0ZW5kZWQgTFNQcy4gIEhvd2V2ZXIsIGl0IG1hbmRhdGVzIGEgY2hhbmdlDQogICAg ICAgdG8gdGhlIFNQRiBhbGdvcml0aG0sIGluIGEgd2F5IHRoYXQgaXNuJ3QgY29tcGF0aWJsZSB3 aXRoDQogICAgICAgcHJldmlvdXMgaW1wbGVtZW50YXRpb25zLiAgQW4gTDEgYXJlYSwgb3IgdGhl IEwyIGRvbWFpbiwgY2Fubm90DQogICAgICAgYmUgc3dpdGNoZWQgb3ZlciB0byB3b3JrIGluIE1v ZGUgMiwgdW50aWwgYWxsIHJvdXRlcnMgaW4gdGhhdA0KICAgICAgIGRvbWFpbiBoYXZlIGJlZW4g dXBncmFkZWQuDQoNCiAgIFRoZXNlIG1vZGVzIG1heSBiZSBjb25maWd1cmVkIHBlciBsZXZlbC4g IFRoZXJlIGlzIG5vIHJlc3RyaWN0aW9uDQogICB0aGF0IGFuIEwxL0wyIElTIG9wZXJhdGVzIGlu IHRoZSBzYW1lIG1vZGUsIGZvciBib3RoIEwxIGFuZCBMMi4NCg0KDQoxLjMgIE92ZXJ2aWV3DQoN CiAgIFVzaW5nIGFkZGl0aW9uYWwgc3lzdGVtLWlkcyBhc3NpZ25lZCBieSB0aGUgYWRtaW5pc3Ry YXRvciwgdGhlDQogICBPcmlnaW5hdGluZyBTeXN0ZW0gY2FuIGFkdmVydGlzZSB0aGUgZXhjZXNz IGxpbmstc3RhdGUgaW5mb3JtYXRpb24gaW4NCg0KDQoNCkEuIEhlcm1lbGluICAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50 ZXJuZXQgRHJhZnQgICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0ICAgICAg IEF1Z3VzdCAyMDAxDQoNCg0KICAgZXh0ZW5kZWQgTFNQcyB1bmRlciB0aGVzZSBleHRlbmRlZCBz eXN0ZW0taWRzLiAgSXQgd291bGQgZG8gc28gYXMgaWYNCiAgIG90aGVyIHJvdXRlcnMsIG9yICJW aXJ0dWFsIFN5c3RlbXMiLCB3ZXJlIGFkdmVydGlzaW5nIHRoaXMNCiAgIGluZm9ybWF0aW9uLiAg VGhlc2UgZXh0ZW5kZWQgTFNQcyB3aWxsIGFsc28gaGF2ZSB0aGUgc3BlY2lmaWVkIGxpbWl0DQog ICBvbiB0aGVpciBMU1AgZnJhZ21lbnRzOyBob3dldmVyLCB0aGUgT3JpZ2luYXRpbmcgU3lzdGVt IG1heSBnZW5lcmF0ZQ0KICAgZXh0ZW5kZWQgTFNQcyB1bmRlciBudW1lcm91cyBWaXJ0dWFsIFN5 c3RlbXMuDQoNCiAgIFR3byBuZXcgVExWcyBhcmUgaW50cm9kdWNlZDogdGhlIEV4dGVuZGVkIENh cGFiaWxpdGllcyAoRUMpIFRMViBhbmQNCiAgIHRoZSBTaG9ydC1DaXJjdWl0IElTIE5laWdoYm9y IChTQy1JU04pIFRMVi4gIFRoZXNlIFRMVnMgYXJlIG5lY2Vzc2FyeQ0KICAgdG8gY29ycmVjdGx5 IG9wZXJhdGUgaW4gT3BlcmF0aW9uIE1vZGUgMiwgYnV0IGFyZSBhZHZlcnRpc2VkIGJ5IGFsbA0K ICAgZXh0ZW5zaW9uLWNhcGFibGUgSVNzLCByZWdhcmRsZXNzIG9mIHRoZSBtb2RlIHRoZXkgb3Bl cmF0ZS4NCg0KICAgRm9yIE9wZXJhdGlvbiBNb2RlIDEsIDAtY29zdCBhZGphY2VuY2llcyBhcmUg YWR2ZXJ0aXNlZCBmcm9tIHRoZQ0KICAgT3JpZ2luYXRpbmcgU3lzdGVtIHRvIGl0cyBWaXJ0dWFs IFN5c3RlbShzKS4gIE5vIGFkamFjZW5jaWVzIChvdGhlcg0KICAgdGhhbiBiYWNrIHRvIHRoZSBP cmlnaW5hdGluZyBTeXN0ZW0pIGFyZSBhZHZlcnRpc2VkIGluIHRoZSBleHRlbmRlZA0KICAgTFNQ cy4gIEFzIGEgY29uc2VxdWVuY2UsIHRoZSBWaXJ0dWFsIFN5c3RlbXMgYXJlICdzdHViJywgbWVh bmluZyB0aGV5DQogICBjYW4gb25seSBiZSByZWFjaGVkIHRocm91Z2ggdGhlaXIgT3JpZ2luYXRp bmcgU3lzdGVtLiAgVGhlcmVmb3JlLA0KICAgb2xkZXIgaW1wbGVtZW50YXRpb25zIGRvIG5vdCBu ZWVkIHRvIG1vZGlmeSB0aGVpciBTUEYgY29tcHV0YXRpb24gaW4NCiAgIG9yZGVyIHRvIGNvcnJl Y3RseSBwcm9jZXNzIHRoZXNlIGV4dGVuZGVkIExTUHMuDQoNCiAgIEZvciBib3RoIG1vZGVzLCBz aG9ydC1jaXJjdWl0IGFkamFjZW5jaWVzIGFyZSBhZHZlcnRpc2VkIGJldHdlZW4gdGhlDQogICBP cmlnaW5hdGluZyBTeXN0ZW0gYW5kIGl0cyBWaXJ0dWFsIFN5c3RlbShzKS4gIEV4dGVuc2lvbi1j YXBhYmxlIElTcw0KICAgY2FuIHRoZW4gdXNlIHRoaXMgaW5mb3JtYXRpb24gZHVyaW5nIHRoZWly IFNQRiwgYW5kIGNhbiBjb21iaW5lIHRoZQ0KICAgb3JpZ2luYWwgYW5kIGV4dGVuZGVkIExTUHMg aW50byBvbmUgc2luZ2xlIGxvZ2ljYWwgTFNQLg0KDQogICBOb3RlLCB0aGF0IGluIGVpdGhlciBt b2RlLCBubyBjb25uZWN0aW9ucyBhcmUgYWR2ZXJ0aXNlZCBiZXR3ZWVuIHR3bw0KICAgVmlydHVh bCBTeXN0ZW1zLg0KDQoNCjIuMCAgRXh0ZW5kZWQgQ2FwYWJpbGl0aWVzIFRMVg0KDQogICBUaGUg cHJvcG9zZWQgRXh0ZW5kZWQgQ2FwYWJpbGl0aWVzIFRMViBhbGxvd3MgYSByb3V0ZXIgdG8gYWR2 ZXJ0aXNlDQogICBzdXBwb3J0IGZvciB0aGlzIGV4dGVuc2lvbiwgYXMgd2VsbCBhcyBvdGhlciBj YXBhYmlsaXRpZXMgdGhhdCBtaWdodA0KICAgYmUgcHJvdmlkZWQgaW4gdGhlIGZ1dHVyZS4gIFRo aXMgVExWIE1VU1QgYXBwZWFyIG9ubHkgaW4gTFNQIE51bWJlcg0KICAgMDsgaXQgU0hPVUxEIGJl IGlnbm9yZWQgd2hlbiBlbmNvdW50ZXJlZCBpbiBvdGhlciBMU1AgZnJhZ21lbnRzLg0KDQogICBU aGUgdHlwZSBvZiB0aGUgRXh0ZW5kZWQgQ2FwYWJpbGl0aWVzIFRMViBpcyAyMy4gIFRoZSBib2R5 IGNvbnRhaW5zDQogICBvbmx5IHN1Yi1UTFZzLCBpbiB0aGUgZm9ybToNCiAgICAgMC0yNTUgb2N0 ZXRzIG9mIHN1Yi1UTFZzLA0KICAgICAgICB3aGVyZSBlYWNoIHN1Yi1UTFYgY29uc2lzdHMgb2Yg YSBzZXF1ZW5jZSBvZg0KICAgICAgICAgICAxIG9jdGV0IG9mIHN1Yi10eXBlDQogICAgICAgICAg IDEgb2N0ZXQgb2YgbGVuZ3RoDQogICAgICAgICAgIDAtMjUzIG9jdGV0cyBvZiB2YWx1ZQ0KDQog ICBUaGlzIGJvZHkgY2FuIG9ubHkgYXBwZWFyIG9uY2Ugd2l0aGluIGEgVExWOyB0aGVyZWZvcmUs IHRoZSB0b3RhbA0KICAgbGVuZ3RoIG9mIHRoZSBzdWItVExWcyBjYW4gYmUgaW5mZXJyZWQgZnJv bSB0aGUgbGVuZ3RoIG9mIHRoZSBUTFYNCiAgIGl0c2VsZi4gIFRoaXMgVExWIG1heSBiZSByZXBl YXRlZCBtdWx0aXBsZSB0aW1lcywgdG8gZGVzY3JpYmUgbW9yZQ0KICAgaW5mb3JtYXRpb24gdGhh biBjYW4gZml0IGluIGEgc2luZ2xlIFRMVi4NCg0KDQoNCkEuIEhlcm1lbGluICAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50 ZXJuZXQgRHJhZnQgICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0ICAgICAg IEF1Z3VzdCAyMDAxDQoNCg0KICAgSW4gYWRkaXRpb24sIGEgbmV3IHN1Yi1UTFYgZm9yIHRoZSBF eHRlbmRlZCBDYXBhYmlsaXRpZXMgVExWIGlzDQogICBwcm9wb3NlZCBoZXJlLiAgVGhpcyBpcyB0 aGUgRXh0ZW5kZWQgTFNQIEZyYWdtZW50cyBDYXBhYmlsaXR5IHN1Yi0NCiAgIFRMVi4gIFJvdXRl cnMgaW1wbGVtZW50aW5nIHRoaXMgZXh0ZW5zaW9uIE1VU1QgaW5jbHVkZSB0aGUgRXh0ZW5kZWQN CiAgIENhcGFiaWxpdGllcyBUTFYsIGFsb25nIHdpdGggdGhlIEV4dGVuZGVkIExTUCBGcmFnbWVu dHMgQ2FwYWJpbGl0eQ0KICAgc3ViLVRMViwgaW4gYm90aCB0aGVpciBvcmlnaW5hbCBhbmQgZXh0 ZW5kZWQgTFNQcy4NCg0KDQoyLjEgIEV4dGVuZGVkIExTUCBGcmFnbWVudHMgQ2FwYWJpbGl0eSBz dWItVExWDQoNCiAgIFRoZSBzdWItVExWIHR5cGUgaXMgMS4gIFRoZSBsZW5ndGggaXMgMSBvY3Rl dCwgY29uc2lzdGluZyBvZiBmbGFncy4NCg0KICAgICAweDAxICBPcGVyYXRpb24gTW9kZSAyDQoN CiAgICAgICBUaGlzIGZsYWcgaXMgc2V0IGlmIHRoZSBJUyBpcyBvcGVyYXRpbmcgaW4gT3BlcmF0 aW9uIE1vZGUgMiwgYW5kDQogICAgICAgdW5zZXQgb3RoZXJ3aXNlLg0KDQogICAgIDB4MDIgIE9y aWdpbmF0aW5nIFN5c3RlbQ0KDQogICAgICAgVGhpcyBmbGFnIGlzIHNldCBpZiB0aGlzIExTUCBp cyBhbiBvcmlnaW5hbCBMU1AgKHRoYXQgaXMsIHRoZQ0KICAgICAgIHN5c3RlbS1pZCBpcyB0aGUg T3JpZ2luYWwgc3lzdGVtLWlkKSwgYW5kIHVuc2V0IG90aGVyd2lzZS4NCg0KDQozLjAgIFNob3J0 LUNpcmN1aXQgSVMgTmVpZ2hib3IgVExWDQoNCiAgIFRoZSBwcm9wb3NlZCBTaG9ydC1DaXJjdWl0 IElTIE5laWdoYm9yIGFsbG93cyBleHRlbnNpb24tY2FwYWJsZSBJU3MNCiAgIHRvIHJlY29nbml6 ZSBhbGwgZXh0ZW5kZWQgTFNQcyBvZiBhbiBPcmlnaW5hdGluZyBTeXN0ZW0sIGFuZCBjb21iaW5l DQogICB0aGUgb3JpZ2luYWwgYW5kIGV4dGVuZGVkIExTUHMgZm9yIHRoZSBwdXJwb3NlIG9mIFNQ RiBjb21wdXRhdGlvbi4NCg0KICAgVGhlIFNob3J0LUNpcmN1aXQgSVMgTmVpZ2hib3IgVExWIGlz IHR5cGUgMjQsIGFuZCBjb250YWlucyBhIG5ldyBkYXRhDQogICBzdHJ1Y3R1cmUsIGNvbnNpc3Rp bmcgb2Y6DQogICAgIDcgb2N0ZXRzIG9mIHN5c3RlbSBJZCBhbmQgcHNldWRvbm9kZSBudW1iZXIN CiAgICAgMSBvY3RldCBvZiBsZW5ndGggb2Ygc3ViLVRMVnMNCiAgICAgMC0yNDcgb2N0ZXRzIG9m IHN1Yi1UTFZzLA0KICAgICAgICB3aGVyZSBlYWNoIHN1Yi1UTFYgY29uc2lzdHMgb2YgYSBzZXF1 ZW5jZSBvZg0KICAgICAgICAgICAxIG9jdGV0IG9mIHN1Yi10eXBlDQogICAgICAgICAgIDEgb2N0 ZXQgb2YgbGVuZ3RoDQogICAgICAgICAgIDAtMjQ1IG9jdGV0cyBvZiB2YWx1ZQ0KDQogICBXaXRo b3V0IHN1Yi1UTFZzLCB0aGlzIHN0cnVjdHVyZSBjb25zdW1lcyA4IG9jdGV0cyBwZXIgc2hvcnQt Y2lyY3VpdA0KICAgbmVpZ2hib3IuICBUbyBpbmRpY2F0ZSBtdWx0aXBsZSBzaG9ydC1jaXRjdWl0 cywgdGhpcyBzdHJ1Y3R1cmUgY2FuIGJlDQogICByZXBlYXRlZCB3aXRoaW4gdGhlIFNob3J0LUNp cmN1aXQgSVMgTmVpZ2hib3IgVExWLiAgQSBzaW5nbGUgVExWIGNhbg0KICAgZGVzY3JpYmUgdXAg dG8gMzEgc2hvcnQtY2lyY3VpdCBuZWlnaGJvcnMuICBUaGlzIFRMViBtYXkgYmUgcmVwZWF0ZWQN CiAgIG11bHRpcGxlIHRpbWVzIHRvIGRlc2NyaWJlIG1vcmUgU0MtbmVpZ2hib3JzLg0KDQoNCjQu MCAgR2VuZXJhdGluZyBMU1BzDQoNCg0KDQoNCkEuIEhlcm1lbGluICAgICAgICAgICAgICAgRXhw aXJlcyBGZWJydWFyeSAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQg RHJhZnQgICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0ICAgICAgIEF1Z3Vz dCAyMDAxDQoNCg0KNC4xICBCb3RoIE9wZXJhdGlvbiBNb2Rlcw0KDQogICBVbmRlciBib3RoIG1v ZGVzLCB0aGUgT3JpZ2luYXRpbmcgU3lzdGVtIE1VU1QgaW5jbHVkZSBjb25uZWN0aXZpdHkNCiAg IGluZm9ybWF0aW9uIGluIGl0cyBvcmlnaW5hbCBMU1BzIHRvIGFsbCBWaXJ0dWFsIFN5c3RlbXMg Zm9yIHdoaWNoDQogICBleHRlbmRlZCBMU1BzIGFyZSBnZW5lcmF0ZWQgYnkgaXQsIGFuZCB2aWNl IHZlcnNhLiAgVGhpcyBpcyB0byBlbnN1cmUNCiAgIG90aGVyIHJvdXRlcnMgY29ycmVjdGx5IHBy b2Nlc3MgdGhlIGV4dHJhIGluZm9ybWF0aW9uIGluIHRoZWlyIFNQRg0KICAgY2FsY3VsYXRpb24u ICBUaGlzIGNvbm5lY3Rpdml0eSBpcyBhZHZlcnRpc2VkIHZpYSBhIG5ldyBTaG9ydC1DaXJjdWl0 DQogICBJUyBOZWlnaGJvciBUTFYuICBGdXJ0aGVybW9yZSwgYW4gT3JpZ2luYXRpbmcgU3lzdGVt IG11c3QgYWR2ZXJ0aXNlDQogICB3aGljaCBtb2RlIGl0IGlzIGN1cnJlbnRseSBvcGVyYXRpbmcg aW4uICBUaGlzIGlzIGRvbmUgdXNpbmcgYSBuZXcNCiAgIEV4dGVuZGVkIENhcGFiaWxpdGllcyBU TFYuDQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICB8ICBPcmlnaW5hdGluZyBTeXN0ZW0gICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg fCAgc3lzdGVtLWlkID0gUyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICgg IGV4dGVuZGVkIHN5c3RlbS1pZHMgPSBTJywgIFMnJyAgKSAgICAgICB8DQogICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgIHwgICAgL1wg ICAgICAgICAgICAgICAgICAgIHwgICAgL1wNCiAgIFNDLUlTTiB8ICAgIHwgU0MtSVNOICAgICAg IFNDLUlTTiB8ICAgIHwgU0MtSVNODQogICAgICAgICAgfCAgICB8ICAgICAgICAgICAgICAgICAg ICAgfCAgICB8DQogICAgICAgICAgXC8gICB8ICAgICAgICAgICAgICAgICAgICAgXC8gICB8DQog ICArLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAg VmlydHVhbCBTeXN0ZW0gIHwgICAgICAgfCAgVmlydHVhbCBTeXN0ZW0gIHwNCiAgIHwgIHN5c3Rl bS1pZCA9IFMnICB8ICAgICAgIHwgIHN5c3RlbS1pZCA9IFMnJyB8DQogICArLS0tLS0tLS0tLS0t LS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICBGaWd1cmUgMS4gQWR2ZXJ0 aXNpbmcgY29ubmVjdGlvbnMgdG8gVmlydHVhbCBTeXN0ZW1zIHVuZGVyIGJvdGggbW9kZXMNCg0K ICAgV2hlbiBuZXcgZXh0ZW5kZWQgTFNQIGZyYWdtZW50cyBhcmUgZ2VuZXJhdGVkLCB0aGVzZSBm cmFnbWVudHMgc2hvdWxkDQogICBiZSBnZW5lcmF0ZWQgYXMgc3BlY2lmaWVkIGluIElTTyAxMDU4 OSBbSVNJUy1JU09dLiAgRnVydGhlcm1vcmUsIGENCiAgIHN5c3RlbSBTSE9VTEQgdHJlYXQgaXRz IGV4dGVuZGVkIExTUHMgdGhlIHNhbWUgYXMgaXQgdHJlYXRzIGl0cw0KICAgb3JpZ2luYWwgTFNQ cywgd2l0aCB0aGUgZXhjZXB0aW9ucyBub3RlZCBpbiB0aGUgZm9sbG93aW5nIHNlY3Rpb25zLg0K ICAgU3BlY2lmaWNhbGx5LCBjcmVhdGluZywgZmxvb2RpbmcsIHJlbmV3aW5nLCBwdXJnaW5nIGFu ZCBhbGwgb3RoZXINCiAgIG9wZXJhdGlvbnMgYXJlIHNpbWlsYXIgZm9yIGJvdGggb3JpZ2luYWwg YW5kIGV4dGVuZGVkIExTUHMsIHVubGVzcw0KICAgc3RhdGVkIG90aGVyd2lzZS4gIFRoZSBleHRl bmRlZCBMU1BzIHdpbGwgdXNlIG9uZSBvZiB0aGUgZXh0ZW5kZWQNCiAgIHN5c3RlbS1pZHMgY29u ZmlndXJlZCBmb3IgdGhlIHJvdXRlciwgaW4gdGhlaXIgTFNQIElELg0KDQogICBFeHRlbmRlZCBM U1BzIHdpdGggbnVtYmVyIHplcm8gc2hvdWxkIGJlIHJlZ2FyZGVkIGluIHRoZSBzYW1lIHNwZWNp YWwNCiAgIG1hbm5lciBhcyBzcGVjaWZpZWQgaW4gMTA1ODkgZm9yIExTUHMgd2l0aCBudW1iZXIg emVybywgYW5kIHNob3VsZA0KICAgaW5jbHVkZSB0aGUgc2FtZSB0eXBlIG9mIGV4dHJhIGluZm9y bWF0aW9uIGFzIHNwZWNpZmllZCBpbiAxMDU4OSBhbmQNCiAgIFJGQyAxMTk1IFtJU0lTLUlQXS4g IFNvLCBmb3IgZXhhbXBsZSwgd2hlbiBhIHN5c3RlbSByZWlzc3VlcyBpdHMgTFNQDQogICBOdW1i ZXIgemVybyBkdWUgdG8gYW4gYXJlYSBhZGRyZXNzIGNoYW5nZSwgaXQgc2hvdWxkIHJlaXNzdWUg YWxsDQogICBleHRlbmRlZCBMU1BzIHdpdGggbnVtYmVyIHplcm8gYXMgd2VsbC4NCg0KICAgQW4g ZXh0ZW5kZWQgTFNQIE51bWJlciB6ZXJvIE1VU1QgYmUgZ2VuZXJhdGVkIGZvciBldmVyeSBleHRl bmRlZCBMU1ANCiAgIHNldCwgdG8gYWxsb3cgYSByb3V0ZXIncyBTUEYgY2FsY3VsYXRpb24gdG8g Y29uc2lkZXIgdGhvc2UgZnJhZ21lbnRzDQogICBpbiB0aGF0IHNldC4NCg0KDQoNCg0KQS4gSGVy bWVsaW4gICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwMDIgICAgICAgICAgICAgICAg IFtQYWdlIDZdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgZHJhZnQtaGVybWVsaW4tZXh0LWxzcC1m cmFncy0wMi50eHQgICAgICAgQXVndXN0IDIwMDENCg0KDQo0LjEuMyAgVGhlIEF0dGFjaGVkIEJp dHMNCg0KICAgVGhlIEF0dGFjaGVkIChBVFQpIGJpdHMgU0hPVUxEIGJlIHNldCB0byB6ZXJvIGZv ciBhbGwgZm91ciBtZXRyaWMNCiAgIHR5cGVzLCBvbiBhbGwgZXh0ZW5kZWQgTFNQcy4gIFRoaXMg aXMgZHVlIHRvIHRoZSBmb2xsb3dpbmc6IGlmIGENCiAgIFZpcnR1YWwgU3lzdGVtIGlzIHJlYWNo YWJsZSwgc28gaXMgaXRzIE9yaWdpbmF0aW5nIFN5c3RlbS4gIEl0IGlzDQogICBwcmVmZXJhYmxl LCB0aGVuLCB0aGF0IGFuIEwxIElTIGNob29zZXMgdGhlIE9yaWdpbmF0aW5nIFN5c3RlbSBhbmQN CiAgIG5vdCB0aGUgVmlydHVhbCBTeXN0ZW0gYXMgaXRzIG5lYXJlc3QgTDIgZXhpdCBwb2ludCwg YXMgY29ubmVjdGl2aXR5DQogICB0byB0aGUgVmlydHVhbCBTeXN0ZW0gaGFzIGEgaGlnaGVyIHBy b2JhYmlsaXR5IG9mIGJlaW5nIGxvc3QgKGENCiAgIHJlc3VsdCBvZiB0aGUgZXh0ZW5kZWQgTFNQ IG5vIGxvbmdlciBiZWluZyBhZHZlcnRpc2VkKS4gIFRoaXMgY291bGQNCiAgIGNhdXNlIHVubmVj ZXNzYXJ5IHByb2Nlc3Npbmcgb24gc29tZSBpbXBsZW1lbnRhdGlvbnMuDQoNCg0KNC4xLjQgIFRo ZSBQYXJ0aXRpb24gUmVwYWlyIEJpdA0KDQogICBUaGUgUGFydGl0aW9uIFJlcGFpciAoUCkgYml0 IFNIT1VMRCBiZSBzZXQgdG8gemVybyBvbiBhbGwgZXh0ZW5kZWQNCiAgIExTUHMuICBUaGlzIGlz IGZvciB0aGUgc2FtZSByZWFzb25zIGFzIGZvciB0aGUgQXR0YWNoZWQgYml0cy4NCg0KDQo0LjEu MSAgRVMgTmVpZ2hib3JzIFRMVg0KDQogICBJU08gMTA1ODkgW0lTSVMtSVNPXSBzZWN0aW9uIDcu My43IHNwZWNpZmllcyBpbnNlcnRpbmcgYW4gRVMgTmVpZ2hib3INCiAgIFRMViBpbiBMMSBMU1Bz LCB3aXRoIHRoZSBzeXN0ZW0gSUQgb2YgdGhlIHJvdXRlci4gIFJGQyAxMTk1IFtJU0lTLUlQXQ0K ICAgcmVsaWV2ZXMgSVAtb25seSByb3V0ZXJzIG9mIHRoaXMgcmVxdWlyZW1lbnQuICBIb3dldmVy LCBmb3Igcm91dGVycw0KICAgdGhhdCBkbyBpbnNlcnQgdGhpcyBFU04gVExWIGluIEwxIExTUHMg KHdoZXRoZXIgSVAtb25seSBvciBPU0ktDQogICBjYXBhYmxlKSwgdGhlbiBpbiBhbiBleHRlbmRl ZCBMU1AsIHRoZSBFU04gVExWIHNob3VsZCBpbmNsdWRlIHRoZQ0KICAgcmVsZXZhbnQgZXh0ZW5k ZWQgc3lzdGVtLWlkLiAgRnVydGhlcm1vcmUsIE9TSS1jYXBhYmxlIHJvdXRlcnMgc2hvdWxkDQog ICBhY2NlcHQgcGFja2V0cyBkZXN0aW5lZCBmb3IgdGhpcyBleHRlbmRlZCBzeXN0ZW0taWQuDQoN Cg0KNC4yICBPcGVyYXRpb24gTW9kZSAxIEFkZGl0aW9ucw0KDQogICBUaGUgZm9sbG93aW5nIGFk ZGl0aW9ucyBhcHBseSBvbmx5IHRvIHJvdXRlcnMgb3BlcmF0aW5nIGluIE1vZGUgMS4NCiAgIFJv dXRlcnMsIHdoaWNoIGFyZSBjb25maWd1cmVkIHRvIG9wZXJhdGUgaW4gT3BlcmF0aW9uIE1vZGUg MiwgTVVTVA0KICAgTk9UIGFwcGx5IHRoZXNlIGFkZGl0aW9ucyB0byB0aGVpciBhZHZlcnRpc2Vt ZW50cy4NCg0KICAgVW5kZXIgT3BlcmF0aW9uIE1vZGUgMSwgdGhlIGFkamFjZW5jaWVzIG11c3Qg YWxzbyBiZSBhZHZlcnRpc2VkIHVzaW5nDQogICB0aGUgc3RhbmRhcmQgbmVpZ2hib3IgVExWcy4g IFRoZSBtZXRyaWMgZm9yIHRoZXNlIGNvbm5lY3Rpb25zIE1VU1QgYmUNCiAgIHplcm8sIHNpbmNl IHRoZSBjb3N0IG9mIHJlYWNoaW5nIGEgVmlydHVhbCBTeXN0ZW0gaXMgdGhlIHNhbWUgYXMgdGhl DQogICBjb3N0IG9mIHJlYWNoaW5nIGl0cyBPcmlnaW5hdGluZyBTeXN0ZW0uDQoNCiAgIFRvIG9s ZGVyIGltcGxlbWVudGF0aW9ucywgVmlydHVhbCBTeXN0ZW1zIHdvdWxkIGFwcGVhciByZWFjaGFi bGUgb25seQ0KICAgdGhyb3VnaCB0aGVpciBPcmlnaW5hdGluZyBTeXN0ZW0sIGhlbmNlIGxvc3Mg b2YgY29ubmVjdGl2aXR5IHRvIHRoZQ0KICAgT3JpZ2luYXRpbmcgU3lzdGVtIG1lYW5zIGxvc3Mg b2YgY29ubmVjdGl2aXR5IHRvIGFsbCBvZiBpdHMNCiAgIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcg dGhhdCBhZHZlcnRpc2VkIGluIGl0cyBleHRlbmRlZCBMU1BzLg0KICAgRnVydGhlcm1vcmUsIHRo ZSBjb3N0IG9mIHJlYWNoaW5nIGluZm9ybWF0aW9uIGFkdmVydGlzZWQgaW4gbm9uLQ0KICAgZXh0 ZW5kZWQgTFNQcyBpcyB0aGUgc2FtZSBhcyB0aGUgY29zdCBvZiByZWFjaGluZyBpbmZvcm1hdGlv bg0KICAgYWR2ZXJ0aXNlZCBpbiB0aGUgbmV3IGV4dGVuZGVkIExTUHMsIHdpdGggYW4gYWRkaXRp b25hbCBob3AuDQoNCg0KDQpBLiBIZXJtZWxpbiAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0IERyYWZ0ICAgICBk cmFmdC1oZXJtZWxpbi1leHQtbHNwLWZyYWdzLTAyLnR4dCAgICAgICBBdWd1c3QgMjAwMQ0KDQoN CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8 ICBPcmlnaW5hdGluZyBTeXN0ZW0gICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgc3lz dGVtLWlkID0gUyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICggIGV4dGVu ZGVkIHN5c3RlbS1pZHMgPSBTJywgIFMnJyAgKSAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgIHwgICAgL1wgICAgICAg ICAgICAgICAgICAgIHwgICAgL1wNCiAgIGNvc3Q9MCB8ICAgIHxjb3N0PW1heC0xICAgIGNvc3Q9 MCB8ICAgIHxjb3N0PW1heC0xDQogICAgICAgICAgfCAgICB8ICAgICAgICAgICAgICAgICAgICAg fCAgICB8DQogICAgICAgICAgXC8gICB8ICAgICAgICAgICAgICAgICAgICAgXC8gICB8DQogICAr LS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgVmly dHVhbCBTeXN0ZW0gIHwgICAgICAgfCAgVmlydHVhbCBTeXN0ZW0gIHwNCiAgIHwgIHN5c3RlbS1p ZCA9IFMnICB8ICAgICAgIHwgIHN5c3RlbS1pZCA9IFMnJyB8DQogICArLS0tLS0tLS0tLS0tLS0t LS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICBGaWd1cmUgMi4gQWR2ZXJ0aXNp bmcgYWRkaXRpb25hbCBjb25uZWN0aW9ucyB0byBWaXJ0dWFsIFN5c3RlbXMgdW5kZXINCiAgIE9w ZXJhdGlvbiBNb2RlIDENCg0KICAgVW5kZXIgT3BlcmF0aW9uIE1vZGUgMSwgb25seSAibGVhZiIg aW5mb3JtYXRpb24sIGkuZS4gaW5mb3JtYXRpb24NCiAgIHRoYXQgc2VydmVzIG9ubHkgYXMgbGVh dmVzIGluIGEgc2hvcnRlc3QgcGF0aCB0cmVlLCBjYW4gYmUgYWR2ZXJ0aXNlZA0KICAgaW4gZXh0 ZW5kZWQgTFNQcy4NCg0KICAgV2hlbiBhbiBleHRlbmRlZCBMU1AgYmVsb25naW5nIHRvIGV4dGVu ZGVkIHN5c3RlbS1pZCBTJyBpcyBmaXJzdA0KICAgY3JlYXRlZCwgdGhlIG9yaWdpbmFsIExTUCBN VVNUIHNwZWNpZnkgUycgYXMgYSBuZWlnaGJvciwgd2l0aCBtZXRyaWMNCiAgIHNldCB0byB6ZXJv LiAgVGhpcyBpcyB0byBlbnN1cmUgb3RoZXIgcm91dGVycyB3aWxsIGNvbnNpZGVyIHRoZQ0KICAg ZXh0ZW5kZWQgTFNQIGluIHRoZWlyIFNQRiBjb21wdXRhdGlvbnMsIGFzIHdlbGwgYXMgY29uc2lk ZXIgdGhlIGNvc3QNCiAgIG9mIHJlYWNoaW5nIHRoZSBWaXJ0dWFsIFN5c3RlbSBTJyB0aGUgc2Ft ZSBhcyB0aGUgY29zdCBvZiByZWFjaGluZw0KICAgaXRzIE9yaWdpbmF0aW5nIFN5c3RlbS4gIEZ1 cnRoZXJtb3JlLCB0aGUgZXh0ZW5kZWQgTFNQIE1VU1Qgc3BlY2lmeQ0KICAgdGhlIG9yaWdpbmFs IHN5c3RlbS1pZCBhcyBhIG5laWdoYm9yLCB3aXRoIG1ldHJpYyBzZXQgdG8NCiAgIChNYXhMaW5r TWV0cmljIC0gMSkuICBXaGVyZSByZWxldmFudCwgdGhpcyBhZGphY2VuY3kgU0hPVUxEIGJlDQog ICBjb25zaWRlcmVkIGFzIHBvaW50LXRvLXBvaW50Lg0KDQogICBOb3RlLCB0aGF0IHRoZSByZXN0 cmljdGlvbiBzcGVjaWZpZWQgaW4gSVNPIDEwNTg5IHNlY3Rpb24gNy4yLjUNCiAgIGhvbGRzOiAg aWYgYW4gTFNQIE51bWJlciB6ZXJvIG9mIHRoZSBPcmlnaW5hdGluZyBTeXN0ZW0gaXMgbm90DQog ICBwcmVzZW50LCBub25lIG9mIHRoYXQgc3lzdGVtJ3MgbmVpZ2hib3IgZW50cmllcyB3b3VsZCBi ZSBwcm9jZXNzZWQNCiAgIGR1cmluZyBTUEYsIGhlbmNlIG5vbmUgb2YgaXRzIGV4dGVuZGVkIExT UHMgd291bGQgYmUgcHJvY2Vzc2VkIGFzDQogICB3ZWxsLg0KDQoNCjQuMi4xICBJUyBOZWlnaGJv cnMgVExWDQoNCiAgIEFuIEV4dGVuZGVkIExTUCBtdXN0IHNwZWNpZnkgb25seSB0aGUgT3JpZ2lu YXRpbmcgU3lzdGVtIGFzIGENCiAgIG5laWdoYm9yLCB3aXRoIHRoZSBtZXRyaWMgc2V0IHRvIChN YXhMaW5rTWV0cmljIC0gMSkuICBXaGVyZQ0KICAgcmVsZXZhbnQsIHRoaXMgYWRqYWNlbmN5IHNo b3VsZCBiZSBjb25zaWRlcmVkIGFzIHBvaW50LXRvLXBvaW50Lg0KICAgT3RoZXIgbmVpZ2hib3Jz IE1VU1QgTk9UIGJlIHNwZWNpZmllZCBpbiBhbiBFeHRlbmRlZCBMU1AsIGFzIHRoaXMNCiAgIHdv dWxkIG5vdCBzYXRpc2Z5IHRoZSBiaS1kaXJlY3Rpb25hbGl0eSBjaGVjayBpbiB0aGUgU1BGIGNv bXB1dGF0aW9uLg0KDQoNCg0KDQoNCkEuIEhlcm1lbGluICAgICAgICAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQgRHJhZnQg ICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0ICAgICAgIEF1Z3VzdCAyMDAx DQoNCg0KNS4gIFB1cmdpbmcgRXh0ZW5kZWQgTFNQIEZyYWdtZW50cw0KDQogICBJU08gMTA1ODkg W0lTSVMtSVNPXSBzZWN0aW9uIDcuMy40LjQgbm90ZSAyMSBzdWdnZXN0cyB0aGF0IGFuDQogICBp bXBsZW1lbnRhdGlvbiBrZWVwcyB0aGUgbnVtYmVyIG9mIExTUCBmcmFnbWVudHMgd2l0aGluIGEg Y2VydGFpbg0KICAgbGltaXQgYmFzZWQgb24gdGhlIG9wdGltYWwgKG1pbmltYWwpIG51bWJlciBv ZiBmcmFnbWVudHMgbmVlZGVkLg0KICAgU2VjdGlvbiA3LjMuNC42IGFsc28gcmVjb21tZW5kcyB0 aGF0IGFuIElTIHB1cmdlIGl0cyBlbXB0eSBMU1BzIHRvDQogICBjb25zZXJ2ZSByZXNvdXJjZXMu ICBUaGVzZSByZWNvbW1lbmRhdGlvbnMgaG9sZCBmb3IgdGhlIGV4dGVuZGVkIExTUA0KICAgZnJh Z21lbnRzIGFzIHdlbGwuICBIb3dldmVyLCBhbiBleHRlbmRlZCBMU1AgTnVtYmVyIHplcm8gc2hv dWxkIG5vdA0KICAgYmUgcHVyZ2VkIHVudGlsIGFsbCBvZiB0aGUgZnJhZ21lbnRzIGluIGl0cyBz ZXQgKGkuZS4gYmVsb25naW5nIHRvIGENCiAgIHBhcnRpY3VsYXIgZXh0ZW5kZWQgc3lzdGVtLWlk KSwgYXJlIGVtcHR5IGFzIHdlbGwuICBUaGlzIGlzIHRvIGVuc3VyZQ0KICAgaW1wbGVtZW50YXRp b25zIGNvbnNpZGVyIHRoZSBmcmFnbWVudHMgaW4gdGhlaXIgU1BGIGNvbXB1dGF0aW9ucywgYXMN CiAgIHNwZWNpZmllZCBpbiBzZWN0aW9uIDcuMi41Lg0KDQogICBXaGVuIGFsbCB0aGUgZXh0ZW5k ZWQgTFNQIGZyYWdtZW50cyBvZiBhIHBhcnRpY3VsYXIgZXh0ZW5kZWQgc3lzdGVtLQ0KICAgaWQg UycgaGF2ZSBiZWVuIHB1cmdlZCwgdGhlIE9yaWdpbmF0aW5nIFN5c3RlbSBTSE9VTEQgcmVtb3Zl IHRoZQ0KICAgbmVpZ2hib3IgaW5mb3JtYXRpb24gdG8gUycgZnJvbSBpdHMgb3JpZ2luYWwgTFNQ cyAoZm9yIGJvdGggSVMgYW5kDQogICBTaG9ydC1DaXJjdWl0KS4NCg0KDQo2LiAgTW9kaWZpY2F0 aW9ucyB0byB0aGUgU1BGDQoNCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgbW9kaWZpY2F0aW9u cyB0byB0aGUgU1BGIHJ1bm5pbmcgb24gcm91dGVycw0KICAgaW1wbGVtZW50aW5nIHRoaXMgZXh0 ZW5zaW9uLg0KDQogICBBIHJvdXRlciBvcGVyYXRpbmcgaW4gTW9kZSAxLCBhbmQgcHJvY2Vzc2lu ZyBhbiBMU1Agb2YgYW5vdGhlciByb3V0ZXINCiAgIG9wZXJhdGluZyBpbiBNb2RlIDEsIE1BWSBp Z25vcmUgdGhlc2UgbW9kaWZpY2F0aW9ucyBhbmQgcnVuIGEgbm9ybWFsDQogICBTUEYuICBUaGlz IGlzIGNvbnNpc3RlbnQgd2l0aCBvdGhlciBub24tZXh0ZW5zaW9uLWNhcGFibGUgcm91dGVycyBp bg0KICAgdGhlIG5ldHdvcmsuDQoNCiAgIEEgcm91dGVyIG9wZXJhdGluZyBpbiBNb2RlIDIsIG9y IHByb2Nlc3NpbmcgYW4gTFNQIG9mIGFub3RoZXIgcm91dGVyDQogICBvcGVyYXRpbmcgaW4gTW9k ZSAyLCBNVVNUIHJ1biB0aGUgZm9sbG93aW5nIG1vZGlmaWNhdGlvbnMgdG8gdGhlIFNQRi4NCg0K ICAgV2hlbiBjb25zaWRlcmluZyBMU1BzIG9mIGFuIGV4dGVuc2lvbi1jYXBhYmxlIElTLCB0aGUg b3JpZ2luYWwgYW5kDQogICBleHRlbmRlZCBMU1BzIGFyZSBjb21iaW5lZCB0byBmb3JtIG9uZSBs YXJnZSBsb2dpY2FsIExTUC4gIElmIHRoZSBMU1ANCiAgIGlzIE9wZXJhdGlvbmFsIE1vZGUgMSwg YW5kIHRoZXJlIGFyZSBhZGphY2VuY2llcyBiZXR3ZWVuIHRoZSBvcmlnaW5hbA0KICAgYW5kIGV4 dGVuZGVkIExTUHMsIHRoZXNlIGFyZSBpZ25vcmVkLiAgVGhpcyBjaGVjayBjb3VsZCBiZSBlYXNp bHkNCiAgIGRvbmUgKGFzIHRoZSBMU1BzIGFyZSB0aWVkIHRvZ2V0aGVyKSwgYW5kIGRvZXNuJ3Qg Y29tcGxpY2F0ZSB0aGUgU1BGLg0KDQogICBJZiB0aGUgTFNQIG51bWJlciAwIG9mIHRoZSBvcmln aW5hbCBMU1Agc2V0IGlzIG1pc3NpbmcsIGFsbCBvZiB0aGUNCiAgIExTUHMgZ2VuZXJhdGVkIGJ5 IHRoYXQgT3JpZ2luYXRpbmcgU3lzdGVtIChleHRlbmRlZCBhcyB3ZWxsKSBNVVNUIE5PVA0KICAg YmUgY29uc2lkZXJlZCBpbiB0aGUgU1BGLiAgVGhpcyBpcyBlYXNpbHkgZGV0ZXJtaW5lZCBmcm9t IHRoZQ0KICAgRXh0ZW5kZWQgQ2FwYWJpbGl0aWVzIFRMVi4gIElmIGFuIExTUCBudW1iZXIgMCBv ZiBhbiBleHRlbmRlZCBMU1Agc2V0DQogICBpcyBtaXNzaW5nLCBvbmx5IHRoYXQgTFNQIHNldCBN VVNUIE5PVCBiZSBjb25zaWRlcmVkIGluIHRoZSBTUEYuDQoNCiAgIE5vdGUsIHRoYXQgdGhlIGFi b3ZlIGJlaGF2aW9yIGlzIGNvbnNpc3RlbnQgd2l0aCBob3cgcHJldmlvdXMNCiAgIGltcGxlbWVu dGF0aW9ucyB3aWxsIGludGVycHJldCBNb2RlIDEgTFNQcy4NCg0KDQoNCg0KQS4gSGVybWVsaW4g ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwMDIgICAgICAgICAgICAgICAgIFtQYWdl IDldDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgZHJhZnQtaGVybWVsaW4tZXh0LWxzcC1mcmFncy0w Mi50eHQgICAgICAgQXVndXN0IDIwMDENCg0KDQo3LiAgRm9ybWluZyBBZGphY2VuY2llcw0KDQog ICBJdCBzaG91bGQgYmUgbm90ZWQsIHRoYXQgYW4gSVMgbXVzdCB1c2UgdGhlIHN5c3RlbS1pZCBv ZiB0aGUgTFNQIHRoYXQNCiAgIHdpbGwgaW5jbHVkZSBhIG5laWdoYm9yLCB3aGVuIGZvcm1pbmcg YW4gYWRqYWNlbmN5IHdpdGggdGhhdA0KICAgbmVpZ2hib3IuICBUaGF0IGlzLCBpZiBhIG5laWdo Ym9yIGlzIHRvIGJlIGluY2x1ZGVkIGluIGV4dGVuZGVkIExTUA0KICAgUycsIHRoZW4gUycgc2hv dWxkIGJlIHVzZWQgYXMgdGhlIHN5c3RlbS1pZCBpbiBJUyBIZWxsb3MgWzNdIGFuZCBJUy0NCiAg IElTIEhlbGxvcyB3aGVuIGZvcm1pbmcgYW4gYWRqYWNlbmN5IHdpdGggdGhhdCBuZWlnaGJvci4g IFRoaXMgaXMNCiAgIHJlZ2FyZGxlc3Mgb2YgdGhlIE9wZXJhdGlvbmFsIE1vZGUuICBPZiBjb3Vy c2UsIGluIE1vZGUgMSB0aGlzIG1lYW5zDQogICB0aGF0IG9ubHkgdGhlIG9yaWdpbmFsIHN5c3Rl bS1pZCB3aWxsIGJlIHVzZWQgd2hlbiBzZW5kaW5nIGhlbGxvcy4NCg0KDQo4LiAgVHJhbnNpdGlv bmluZyB0aGUgTmV0d29yaw0KDQogICBBcyBub3RlZCBlYXJsaWVyLCBpbiBvcmRlciB0byBjb3Jy ZWN0bHkgcnVuIGluIE9wZXJhdGlvbiBNb2RlIDIsIGFsbA0KICAgSVNzIGluIGFuIGFyZWEgbXVz dCBiZSBleHRlbnNpb24tY2FwYWJsZS4gSG93ZXZlciwgaXQgaXMgcG9zc2libGUgdG8NCiAgIHRy YW5zaXRpb24gYSBsaXZlIG5ldHdvcmssIHVzaW5nIHRoZSBmb2xsb3dpbmcgc3RlcHM6DQogICAg IC0gVXBncmFkZSB0aGUgcm91dGVycywgb25lLWJ5LW9uZSwgdG8gcnVuIHRoaXMgZXh0ZW5zaW9u IGluDQogICAgIE9wZXJhdGlvbiBNb2RlIDEuIFRoZSBvdGhlciBub24tZXh0ZW5zaW9uLWNhcGFi bGUgcm91dGVycyB3aWxsDQogICAgIGludGVyb3BlcmF0ZSBjb3JyZWN0bHkuDQogICAgIC0gV2hl biBhbGwgcm91dGVycyBhcmUgZXh0ZW5zaW9uLWNhcGFibGUsIGNvbmZpZ3VyZSB0aGVtIG9uZS1i eS1vbmUNCiAgICAgdG8gcnVuIGluIE9wZXJhdGlvbiBNb2RlIDIuICBBbGwgZXh0ZW5zaW9uLWNh cGFibGUgcm91dGVycw0KICAgICBpbnRlcm9wZXJhdGUgY29ycmVjdGx5LCByZWdhcmRsZXNzIG9m IHdoYXQgbW9kZSB0aGV5J3JlIHJ1biBpbi4NCg0KDQo5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMNCg0KICAgVGhpcyBkb2N1bWVudCByYWlzZXMgbm8gbmV3IHNlY3VyaXR5IGlzc3VlcyBmb3Ig SVMtSVMuDQoNCg0KMTAuICBBY2tub3dsZWRnbWVudHMNCg0KICAgVGhlIGF1dGhvciB3b3VsZCBs aWtlIHRvIHRoYW5rIFRvbnkgTGksIFJhZGlhIFBlcmxtYW4sIGFuZCBNaWtlIFNoYW5kDQogICBm b3IgaGVscGZ1bCBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgb24gdGhlIHN1YmplY3QuDQoNCg0K MTEuICBSZWZlcmVuY2VzDQoNCiAgIFtJU0lTLUlTT10gSVNPIDEwNTg5LCAiSW50ZXJtZWRpYXRl IFN5c3RlbSB0byBJbnRlcm1lZGlhdGUgU3lzdGVtDQogICBJbnRyYS1Eb21haW4gUm91dGVpbmcg RXhjaGFuZ2UgUHJvdG9jb2wgZm9yIHVzZSBpbiBDb25qdW5jdGlvbiB3aXRoDQogICB0aGUgUHJv dG9jb2wgZm9yIFByb3ZpZGluZyB0aGUgQ29ubmVjdGlvbmxlc3MtbW9kZSBOZXR3b3JrIFNlcnZp Y2UNCiAgIChJU08gODQ3MykiDQoNCiAgIFtJU0lTLUlQXSBSRkMgMTE5NSwgIlVzZSBvZiBPU0kg SVMtSVMgZm9yIHJvdXRpbmcgaW4gVENQL0lQIGFuZCBkdWFsDQogICBlbnZpcm9ubWVudHMiLCBS LlcuIENhbGxvbiwgRGVjLiAxOTkwDQoNCiAgIFtFUy1JU10gSVNPIDk1NDIsICJFbmQgU3lzdGVt IHRvIEludGVybWVkaWF0ZSBTeXN0ZW0gUm91dGVpbmcNCiAgIEV4Y2hhbmdlIFByb3RvY29sIGZv ciBVc2UgaW4gQ29uanVuY3Rpb24gd2l0aCB0aGUgUHJvdG9jb2wgZm9yDQoNCg0KDQpBLiBIZXJt ZWxpbiAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAwMiAgICAgICAgICAgICAgICBb UGFnZSAxMF0NCgwNCkludGVybmV0IERyYWZ0ICAgICBkcmFmdC1oZXJtZWxpbi1leHQtbHNwLWZy YWdzLTAyLnR4dCAgICAgICBBdWd1c3QgMjAwMQ0KDQoNCiAgIFByb3ZpZGluZyB0aGUgQ29ubmVj dGlvbmxlc3MtTW9kZSBOZXR3b3JrIFNlcnZpY2UgKElTTyA4NDczKSIsIE1hcmNoDQogICAxOTg4 DQoNCiAgIFtET01BSU4tV0lERV0gUkZDIDI5NjYsICJEb21haW4td2lkZSBQcmVmaXggRGlzdHJp YnV0aW9uIHdpdGggVHdvLQ0KICAgTGV2ZWwgSVMtSVMiLCBULiBMaSwgVC4gUHJ6eWdpZW5kYSwg SC4gU21pdCwgT2N0b2JlciAyMDAwDQoNCiAgIFtCQ1AxNF0gUkZDIDIxMTksICJLZXkgd29yZHMg Zm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50DQogICBMZXZlbHMiLCBTLiBC cmFkbmVyLCBNYXJjaCAxOTk3DQoNCg0KMTIuICBBdXRob3IncyBBZGRyZXNzDQoNCiAgIEFtaXIg SGVybWVsaW4NCiAgIENoYXJsb3R0ZSdzIFdlYiBOZXR3b3JrcywgSW5jLg0KICAgMiBIYSdtYWRh IFN0Lg0KICAgUE9CIDY1MA0KICAgWW9rbmVhbSwgMjA2OTINCiAgIElTUkFFTA0KDQogICBFbWFp bDogYW1pckBjd250LmNvbQ0KICAgUGhvbmU6ICs5NzIgNCA5NTkyMjAzDQogICBGYXg6ICAgKzk3 MiA0IDk1OTMzMjUNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KQS4gSGVybWVsaW4gICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIw MDIgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQo= ------_=_NextPart_001_01C12581.12689795-- From jparker@axiowave.com Thu Aug 16 20:27:44 2001 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 16 Aug 2001 15:27:44 -0400 Subject: [Isis-wg] Comments on < draft-ash-ospf-isis-congestion-control-00.txt > Message-ID: Jerry - I've been reading your draft < draft-ash-ospf-isis-congestion-control-00.txt > with interest. Here are a few editorial comments. I also have some questions about your scenarios in order to reproduce them here. I think it would be good to have a well understood stress test that reflects an interesting test case, rather than another round of line-rate forwarding or connections per second test. > b) how a node might control its workload once congestion is detected, > such as through > * the throttling of new connection setups, topology-status updates, > and Hello updates with the use of automatic congestion control mechanisms, 1) Perhaps the title should mention PNNI: I'm not sure which connection setups you would want to restrict in OSPF or ISIS. 2) I'm not sure that you really mean "throttling... Hello updates". In your next paragraph, you advocate special handling of Hello Messages to assure they go through. > * Inability to segment the network (into smaller "peer groups") to aid > in the LS protocol recovery I'm not sure what you are asking for here. There is no obstacle in either OSPF or ISIS to create small peer groups. In fact, your sample has very small (4) peer groups. Do you want to reconfigure on the fly? Do you want more levels of hierarchy? > 2.2 Vendor Analysis of Product Performance > Various vendors and service providers were asked to analyze their product > with reference to how their LS protocol recovers from a total network > failure, that is, loss of all database information in the specified > scenario. The specification of the failure presented to the vendors made > the following assumptions: > 1. 400 node network is considered > a) 100 backbone nodes > b) 3 edge nodes per backbone node (Edge single homed) > c) Each backbone node is connected to no more than 10 nodes (maximum > node adjacency is 13, which defines a sparse network) > 1. There are 101 areas > a) 1 backbone area with 100 backbone nodes > b) 100 edge areas, each with 3 nodes, all homed on the backbone peer > group > 1. 1,000,000 addresses are advertised in the network > 2. maximum node adjacency is 13 > a) sparse network I found the numbering confusing, and don't know if this is one specification or three. This might mean * 300 Edge Nodes * 100 Backbone nodes. - Each backbone node connects to 3 edge nodes - Each backbone node connects to 10 other backbone nodes - Each cluster of 3 edge nodes and backbone router forms a single unique area - Each edge node advertises 3.333K routes but other configurations are possible. I would be interested to know how your backbone routers are connected to each other. > During the study, a TSU > storm of size X is created at instant of time 100 seconds where storm-size > is defined as the number of TSUs generated during a storm. Three cases are > considered with X = 300, 600 and 900 respectively. Can you clarify who originates these 300*X packets? Is it the edge routers? What are the sizes of the packets, and what are the contents? For example, I assume that you don't simply have two versions of each edge router's topology and send one then the other. These details are probably in the paper [choudhury] cited. Is that paper publically available yet? Perhaps you could define the test you describe in enough detail to provide an interesting synthetic test of general utility. I'm sure AT&T would love to push back this test from your labs to your suppliers. If the description is clear cut enough, some of the test vendors might be able to produce equipment that could direct such a storm at a device under test. May I be the first to suggest the name "Link Adjacency Stability Test, G. Ash Switch Profiler", or LAST GASP. - jeff parker - axiowave networks From Larmer@CommSense.Net Fri Aug 17 16:04:24 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Fri, 17 Aug 2001 11:04:24 -0400 Subject: [Isis-wg] Action on receipt of LSP Message-ID: Hi, ISO-10589 states the action to take when receiving certain LSPs (Newer, Same, Older...). The specification does not state what to do when you receive a LSP, which contains the same LSPID, Sequence Number but with different Remaining Lifetime values, i.e. the LSP Database Entry has Remaining Lifetime = 0 and the received LSP has Remaining Lifetime = 1199. What should we do in this situation? Should we return the expired LSP to the source? Cheers, Ken From ehietbrink@lucent.com Fri Aug 17 16:29:20 2001 From: ehietbrink@lucent.com (Erik Hietbrink) Date: Fri, 17 Aug 2001 17:29:20 +0200 Subject: [Isis-wg] Action on receipt of LSP References: Message-ID: <3B7D3850.BBF4D8B0@lucent.com> Ken Larmer wrote: > > Hi, > > ISO-10589 states the action to take when receiving certain LSPs (Newer, > Same, Older...). The specification does not state what to do when you > receive a LSP, which contains the same LSPID, Sequence Number but with > different Remaining Lifetime values, i.e. the LSP Database Entry has > Remaining Lifetime = 0 and the received LSP has Remaining Lifetime = 1199. > What should we do in this situation? Should we return the expired LSP to the > source? > > Cheers, > Ken No, 10589, section 7.3.16.3 states "if the remaining lifetime of the received LSP is non-zero, but there is an LSP in the database with the same sequence number and zero remaining lifetime, the LSP in the database shall be considered most recent. Otherwise, the LSP with the larger sequence number shall be considered the most recent." Regards, Erik From Ravindra.Sunkad@marconi.com Fri Aug 17 16:33:32 2001 From: Ravindra.Sunkad@marconi.com (Sunkad, Ravindra) Date: Fri, 17 Aug 2001 11:33:32 -0400 Subject: [Isis-wg] Action on receipt of LSP Message-ID: <39469E08BD83D411A3D900204840EC55509980@VIE-MSGUSR-01> Ken, Here's an excerpt from 7.3.16.3 "If the Remaining Lifetime in a received LSP or in an LSP entry in a received SNP is non-zero, but there is an LSP in the database with the same sequence number and zero Remaining Lifetime, the LSP in the database shall be considered most recent. Otherwise, the PDU with the larger sequence number shall be considered the most recent." Ravi > -----Original Message----- > From: Ken Larmer [mailto:Larmer@CommSense.Net] > Sent: Friday, August 17, 2001 11:04 AM > To: Isis-Wg@Spider. Juniper. Net > Cc: Ken Larmer > Subject: [Isis-wg] Action on receipt of LSP > > > Hi, > > ISO-10589 states the action to take when receiving > certain LSPs (Newer, > Same, Older...). The specification does not state what to do when you > receive a LSP, which contains the same LSPID, Sequence Number but with > different Remaining Lifetime values, i.e. the LSP Database Entry has > Remaining Lifetime = 0 and the received LSP has Remaining > Lifetime = 1199. > What should we do in this situation? Should we return the > expired LSP to the > source? > > Cheers, > Ken > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Larmer@CommSense.Net Fri Aug 17 16:37:35 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Fri, 17 Aug 2001 11:37:35 -0400 Subject: [Isis-wg] Action on receipt of LSP In-Reply-To: <3B7D3850.BBF4D8B0@lucent.com> Message-ID: Thanks Eric, I missed that! Cheers, Ken > -----Original Message----- > From: Erik Hietbrink [mailto:ehietbrink@lucent.com] > Sent: Friday, August 17, 2001 11:29 AM > To: Ken Larmer > Cc: Isis-Wg@Spider. Juniper. Net > Subject: Re: [Isis-wg] Action on receipt of LSP > > > Ken Larmer wrote: > > > > Hi, > > > > ISO-10589 states the action to take when receiving > certain LSPs (Newer, > > Same, Older...). The specification does not state what to do when you > > receive a LSP, which contains the same LSPID, Sequence Number but with > > different Remaining Lifetime values, i.e. the LSP Database Entry has > > Remaining Lifetime = 0 and the received LSP has Remaining > Lifetime = 1199. > > What should we do in this situation? Should we return the > expired LSP to the > > source? > > > > Cheers, > > Ken > > No, 10589, section 7.3.16.3 states "if the remaining lifetime of the > received LSP is non-zero, but there is an LSP in the database with the > same sequence number and zero remaining lifetime, the LSP in the > database shall be considered most recent. Otherwise, the LSP with the > larger sequence number shall be considered the most recent." > > Regards, > Erik > From nsoma@force10networks.com Fri Aug 17 16:58:54 2001 From: nsoma@force10networks.com (Nageswara Soma) Date: Fri, 17 Aug 2001 08:58:54 -0700 Subject: [Isis-wg] Action on receipt of LSP Message-ID: <5A063B55DDB6D411937100D0B7C84E38017A6B6F@tonga.force10networks.com> What if received LSP has a different life time than the one in LSP database? Note that both life times are non-zero. I had come across such case against a test suite. It regenerated an LSP with different content with same sequence number. Thanks Nageswara > -----Original Message----- > From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] > Sent: Friday, August 17, 2001 8:34 AM > To: 'Ken Larmer'; Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > Ken, > > Here's an excerpt from 7.3.16.3 > > "If the Remaining Lifetime in a received LSP or in an LSP entry in a > received SNP is non-zero, but there is an LSP in the database > with the same > sequence number and zero Remaining Lifetime, the LSP in the > database shall > be considered most recent. Otherwise, the PDU with the > larger sequence > number shall be considered the most recent." > > Ravi > > > -----Original Message----- > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > Sent: Friday, August 17, 2001 11:04 AM > > To: Isis-Wg@Spider. Juniper. Net > > Cc: Ken Larmer > > Subject: [Isis-wg] Action on receipt of LSP > > > > > > Hi, > > > > ISO-10589 states the action to take when receiving > > certain LSPs (Newer, > > Same, Older...). The specification does not state what to > do when you > > receive a LSP, which contains the same LSPID, Sequence > Number but with > > different Remaining Lifetime values, i.e. the LSP Database Entry has > > Remaining Lifetime = 0 and the received LSP has Remaining > > Lifetime = 1199. > > What should we do in this situation? Should we return the > > expired LSP to the > > source? > > > > Cheers, > > Ken > > > > _______________________________________________ > > 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 satish@pluris.com Fri Aug 17 19:17:41 2001 From: satish@pluris.com (Satish Dattatri) Date: Fri, 17 Aug 2001 11:17:41 -0700 Subject: [Isis-wg] Action on receipt of LSP Message-ID: <17C81AD1F1FED411991E006008F6D1CAC2D7A0@avalon.pluris.com> Hi Soma, Hopefully the checksum would be different in that case also. 7.3.16.2: Now there are 2 cases the LSP being a (a) local one: bump the seq# and regenerate (b) non-local LSP: purge the LSP since there is no reliable way to tell which is more recent. I think this needs to be done also, could not find the ref in the spec: If the checksum happens also to be same then unless an implementation does a diff (either on the raw PDU or the contents)it will take it to be a duplicate reception of same LSP and ignore. On doing a diff in your case, the LSP will be purged becoz of the different content. Satish -----Original Message----- From: Nageswara Soma [mailto:nsoma@force10networks.com] Sent: Friday, August 17, 2001 8:59 AM To: Isis-Wg@Spider. Juniper. Net Subject: RE: [Isis-wg] Action on receipt of LSP What if received LSP has a different life time than the one in LSP database? Note that both life times are non-zero. I had come across such case against a test suite. It regenerated an LSP with different content with same sequence number. Thanks Nageswara > -----Original Message----- > From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] > Sent: Friday, August 17, 2001 8:34 AM > To: 'Ken Larmer'; Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > Ken, > > Here's an excerpt from 7.3.16.3 > > "If the Remaining Lifetime in a received LSP or in an LSP entry in a > received SNP is non-zero, but there is an LSP in the database > with the same > sequence number and zero Remaining Lifetime, the LSP in the > database shall > be considered most recent. Otherwise, the PDU with the > larger sequence > number shall be considered the most recent." > > Ravi > > > -----Original Message----- > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > Sent: Friday, August 17, 2001 11:04 AM > > To: Isis-Wg@Spider. Juniper. Net > > Cc: Ken Larmer > > Subject: [Isis-wg] Action on receipt of LSP > > > > > > Hi, > > > > ISO-10589 states the action to take when receiving > > certain LSPs (Newer, > > Same, Older...). The specification does not state what to > do when you > > receive a LSP, which contains the same LSPID, Sequence > Number but with > > different Remaining Lifetime values, i.e. the LSP Database Entry has > > Remaining Lifetime = 0 and the received LSP has Remaining > > Lifetime = 1199. > > What should we do in this situation? Should we return the > > expired LSP to the > > source? > > > > Cheers, > > Ken > > > > _______________________________________________ > > 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 Ravindra.Sunkad@marconi.com Fri Aug 17 20:28:12 2001 From: Ravindra.Sunkad@marconi.com (Sunkad, Ravindra) Date: Fri, 17 Aug 2001 15:28:12 -0400 Subject: [Isis-wg] Action on receipt of LSP Message-ID: <39469E08BD83D411A3D900204840EC55509984@VIE-MSGUSR-01> The "Remaining Lifetime" field is not used in checksum computation. So, it's possible that the received LSP has the same seq. no. and the same checksum (and the same contents except Rem. Life Time). In that case I would think the IS would just treat it as receiving an LSP "equal" to it's copy. Ravi > -----Original Message----- > From: Satish Dattatri [mailto:satish@pluris.com] > Sent: Friday, August 17, 2001 2:18 PM > To: 'Nageswara Soma'; Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > Hi Soma, > Hopefully the checksum would be different in that case also. > 7.3.16.2: > Now there are 2 cases the LSP being a > (a) local one: bump the seq# and regenerate > (b) non-local LSP: purge the LSP since there is no reliable way > to tell which is more recent. > > I think this needs to be done also, could not find the ref in > the spec: > If the checksum happens also to be same then unless an implementation > does a diff (either on the raw PDU or the contents)it will take it to > be a duplicate reception of same LSP and ignore. On doing a diff in > your case, the LSP will be purged becoz of the different content. > > Satish > > -----Original Message----- > From: Nageswara Soma [mailto:nsoma@force10networks.com] > Sent: Friday, August 17, 2001 8:59 AM > To: Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > What if received LSP has a different life time than > the one in LSP database? Note that both life times are non-zero. > I had come across such case against a test suite. It regenerated > an LSP with different content with same sequence number. > > Thanks > Nageswara > > > -----Original Message----- > > From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] > > Sent: Friday, August 17, 2001 8:34 AM > > To: 'Ken Larmer'; Isis-Wg@Spider. Juniper. Net > > Subject: RE: [Isis-wg] Action on receipt of LSP > > > > > > Ken, > > > > Here's an excerpt from 7.3.16.3 > > > > "If the Remaining Lifetime in a received LSP or in an LSP entry in a > > received SNP is non-zero, but there is an LSP in the database > > with the same > > sequence number and zero Remaining Lifetime, the LSP in the > > database shall > > be considered most recent. Otherwise, the PDU with the > > larger sequence > > number shall be considered the most recent." > > > > Ravi > > > > > -----Original Message----- > > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > > Sent: Friday, August 17, 2001 11:04 AM > > > To: Isis-Wg@Spider. Juniper. Net > > > Cc: Ken Larmer > > > Subject: [Isis-wg] Action on receipt of LSP > > > > > > > > > Hi, > > > > > > ISO-10589 states the action to take when receiving > > > certain LSPs (Newer, > > > Same, Older...). The specification does not state what to > > do when you > > > receive a LSP, which contains the same LSPID, Sequence > > Number but with > > > different Remaining Lifetime values, i.e. the LSP > Database Entry has > > > Remaining Lifetime = 0 and the received LSP has Remaining > > > Lifetime = 1199. > > > What should we do in this situation? Should we return the > > > expired LSP to the > > > source? > > > > > > Cheers, > > > Ken > > > > > > _______________________________________________ > > > 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 satish@pluris.com Sat Aug 18 00:29:06 2001 From: satish@pluris.com (Satish Dattatri) Date: Fri, 17 Aug 2001 16:29:06 -0700 Subject: [Isis-wg] Action on receipt of LSP Message-ID: <17C81AD1F1FED411991E006008F6D1CAC2D7A2@avalon.pluris.com> But in case of Soma's question a test suite generated a LSP with same seq# but different contents in the LSP. And you are right life time *cannot* be a factor to decide which is newer (see b in the old mail). This commonly happens when same LSP is recvd from 2 neighbor's. Satish -----Original Message----- From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] Sent: Friday, August 17, 2001 12:28 PM To: 'Satish Dattatri'; 'Nageswara Soma'; Isis-Wg@Spider. Juniper. Net Subject: RE: [Isis-wg] Action on receipt of LSP The "Remaining Lifetime" field is not used in checksum computation. So, it's possible that the received LSP has the same seq. no. and the same checksum (and the same contents except Rem. Life Time). In that case I would think the IS would just treat it as receiving an LSP "equal" to it's copy. Ravi > -----Original Message----- > From: Satish Dattatri [mailto:satish@pluris.com] > Sent: Friday, August 17, 2001 2:18 PM > To: 'Nageswara Soma'; Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > Hi Soma, > Hopefully the checksum would be different in that case also. > 7.3.16.2: > Now there are 2 cases the LSP being a > (a) local one: bump the seq# and regenerate > (b) non-local LSP: purge the LSP since there is no reliable way > to tell which is more recent. > > I think this needs to be done also, could not find the ref in > the spec: > If the checksum happens also to be same then unless an implementation > does a diff (either on the raw PDU or the contents)it will take it to > be a duplicate reception of same LSP and ignore. On doing a diff in > your case, the LSP will be purged becoz of the different content. > > Satish > > -----Original Message----- > From: Nageswara Soma [mailto:nsoma@force10networks.com] > Sent: Friday, August 17, 2001 8:59 AM > To: Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > What if received LSP has a different life time than > the one in LSP database? Note that both life times are non-zero. > I had come across such case against a test suite. It regenerated > an LSP with different content with same sequence number. > > Thanks > Nageswara > > > -----Original Message----- > > From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] > > Sent: Friday, August 17, 2001 8:34 AM > > To: 'Ken Larmer'; Isis-Wg@Spider. Juniper. Net > > Subject: RE: [Isis-wg] Action on receipt of LSP > > > > > > Ken, > > > > Here's an excerpt from 7.3.16.3 > > > > "If the Remaining Lifetime in a received LSP or in an LSP entry in a > > received SNP is non-zero, but there is an LSP in the database > > with the same > > sequence number and zero Remaining Lifetime, the LSP in the > > database shall > > be considered most recent. Otherwise, the PDU with the > > larger sequence > > number shall be considered the most recent." > > > > Ravi > > > > > -----Original Message----- > > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > > Sent: Friday, August 17, 2001 11:04 AM > > > To: Isis-Wg@Spider. Juniper. Net > > > Cc: Ken Larmer > > > Subject: [Isis-wg] Action on receipt of LSP > > > > > > > > > Hi, > > > > > > ISO-10589 states the action to take when receiving > > > certain LSPs (Newer, > > > Same, Older...). The specification does not state what to > > do when you > > > receive a LSP, which contains the same LSPID, Sequence > > Number but with > > > different Remaining Lifetime values, i.e. the LSP > Database Entry has > > > Remaining Lifetime = 0 and the received LSP has Remaining > > > Lifetime = 1199. > > > What should we do in this situation? Should we return the > > > expired LSP to the > > > source? > > > > > > Cheers, > > > Ken > > > > > > _______________________________________________ > > > 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 jgreenha@eu.uu.net Sun Aug 19 10:44:34 2001 From: jgreenha@eu.uu.net (John Greenhalgh) Date: Sun, 19 Aug 2001 09:44:34 +0000 (GMT) Subject: [Isis-wg] Initialisation question In-Reply-To: <200108111904.MAA13253@external.juniper.net> Message-ID: Hi, I'm looking through ISO 10589 and trying to understand how routers learn the link state database once adjacencies have been formed. For broadcast I gather that the CSNP from the DIS will initiate an update, but what about on point-to-point? Any pointers gladly received! TIA, John From jgreenha@eu.uu.net Sun Aug 19 13:08:26 2001 From: jgreenha@eu.uu.net (John Greenhalgh) Date: Sun, 19 Aug 2001 12:08:26 +0000 (GMT) Subject: [Isis-wg] Initialisation question In-Reply-To: <20010819133122.A12669@juniper.net> Message-ID: Thanks, Sorry I should have said that I'd read that bit, but I'm still not clear exactly what happens. I guess that once two routers are adjacent they exchange CSNPs and then send PSNPs for any LSPs they are short of or are old? Correct? Thanks, John On Sun, 19 Aug 2001, Hannes Gredler wrote: > On Sun, Aug 19, 2001 at 09:44:34AM +0000, John Greenhalgh wrote: > | Hi, > | > | I'm looking through ISO 10589 and trying to understand how routers learn > | the link state database once adjacencies have been formed. For broadcast I > | gather that the CSNP from the DIS will initiate an update, but what about > | on point-to-point? Any pointers gladly received! > > john, > > take a look at paragraph 7.3.20.2.e where it says: > > [ ... ] CSNPs are transmited on > point-to-point circuits at initialisation. > > HTH, > > /hannes > From hannes@juniper.net Sun Aug 19 12:31:22 2001 From: hannes@juniper.net (Hannes Gredler) Date: Sun, 19 Aug 2001 13:31:22 +0200 Subject: [Isis-wg] Initialisation question In-Reply-To: ; from jgreenha@eu.uu.net on Sun, Aug 19, 2001 at 09:44:34AM +0000 References: <200108111904.MAA13253@external.juniper.net> Message-ID: <20010819133122.A12669@juniper.net> On Sun, Aug 19, 2001 at 09:44:34AM +0000, John Greenhalgh wrote: | Hi, | | I'm looking through ISO 10589 and trying to understand how routers learn | the link state database once adjacencies have been formed. For broadcast I | gather that the CSNP from the DIS will initiate an update, but what about | on point-to-point? Any pointers gladly received! john, take a look at paragraph 7.3.20.2.e where it says: [ ... ] CSNPs are transmited on point-to-point circuits at initialisation. HTH, /hannes From hannes@juniper.net Sun Aug 19 15:14:18 2001 From: hannes@juniper.net (Hannes Gredler) Date: Sun, 19 Aug 2001 16:14:18 +0200 Subject: [Isis-wg] Initialisation question In-Reply-To: ; from jgreenha@eu.uu.net on Sun, Aug 19, 2001 at 12:08:26PM +0000 References: <20010819133122.A12669@juniper.net> Message-ID: <20010819161418.A12747@juniper.net> --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii correct - for your convenience i have attached a tcpdump to see what happens; /hannes On Sun, Aug 19, 2001 at 12:08:26PM +0000, John Greenhalgh wrote: | | Thanks, | | Sorry I should have said that I'd read that bit, but I'm still not | clear exactly what happens. I guess that once two routers are adjacent | they exchange CSNPs and then send PSNPs for | any LSPs they are short of or are old? Correct? | | Thanks, | John | | | On Sun, 19 Aug 2001, Hannes Gredler wrote: | | > On Sun, Aug 19, 2001 at 09:44:34AM +0000, John Greenhalgh wrote: | > | Hi, | > | | > | I'm looking through ISO 10589 and trying to understand how routers learn | > | the link state database once adjacencies have been formed. For broadcast I | > | gather that the CSNP from the DIS will initiate an update, but what about | > | on point-to-point? Any pointers gladly received! | > | > john, | > | > take a look at paragraph 7.3.20.2.e where it says: | > | > [ ... ] CSNPs are transmited on | > point-to-point circuits at initialisation. | > | > HTH, | > | > /hannes | > | | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg --PNTmBPCT7hxwcZjr Content-Type: application/octet-stream Content-Disposition: attachment; filename="hannes-isis-ppp-tcpdump.1500" Content-Transfer-Encoding: base64 1MOyoQIABAAAAAAAAAAAANwFAAAJAAAAcW7QOk9cCgAOAAAADgAAABgAAAAAAAAA/wPAIQEi AAoFBjrat2hzbtA641wKAA4AAAAOAAAAGAAAAAAAZ2j/A8AhASMACgUGOtq3aHVu0DpxXQoA DgAAAA4AAAAYAAAAAAAAAP8DwCEBJAAKBQY62rdod27QOgpeCgAOAAAADgAAABgAAAAAAGdo /wPAIQElAAoFBjrat2h5btA6l14KAA4AAAAOAAAAGAAAAAAAAAD/A8AhASYACgUGOtq3aHtu 0DovXwoADgAAAA4AAAAYAAAAAABnaP8DwCEBJwAKBQY62rdofW7QOr9fCgAOAAAADgAAABgA AAAAAAAA/wPAIQEoAAoFBjrat2h/btA6V2AKAA4AAAAOAAAAGAAAAAAAZ2j/A8AhASkACgUG Otq3aIFu0DrqYAoADgAAAA4AAAAYAAAAAAAAAP8DwCEBKgAKBQY62rdog27QOndhCgAOAAAA DgAAABgAAAAAAGdo/wPAIQErAAoFBjrat2iFbtA6E2IKAA4AAAAOAAAAGAAAAAAAAAD/A8Ah ASwACgUGOtq3aIdu0DqvYgoADgAAAA4AAAAYAAAAAABnaP8DwCEBLQAKBQY62rdoiW7QOjhj CgAOAAAADgAAABgAAAAAAAAA/wPAIQEuAAoFBjrat2iJbtA622UKAA4AAAAOAAAAGAABAAAA BAP/A8AhAi4ACgUGOtq3aIlu0DqCQwwADgAAAA4AAAAYAAEAAAAAAv8DwCEBOgAKBQY61Q/V iW7QOoxDDAAOAAAADgAAABgAAAAAAAAA/wPAIQI6AAoFBjrVD9WJbtA6xkMMAAgAAAAIAAAA GAAAAAAA////A4AhAS8ABIlu0DrOQwwACAAAAAgAAAAYAAAAAAAAAv8DgCMBMAAEiW7QOtND DAAIAAAACAAAABgAAAAAAAAB/wOCgQExAASJbtA6NUcMAAgAAAAIAAAAGAABAAAAzIT/A4Ah ATsABIlu0DpBRwwACAAAAAgAAAAYAAAAAAALIP8DgCECOwAEiW7QOl9HDAAIAAAACAAAABgA AQAAANHM/wOAIwE8AASJbtA6YkcMAAgAAAAIAAAAGAAAAAAABAr/A4AjAjwABIlu0Dp2RwwA CAAAAAgAAAAYAAEAAADMS/8DgoEBPQAEiW7QOnlHDAAIAAAACAAAABgAAAAAAAAA/wOCgQI9 AASJbtA6aEwMAAgAAAAIAAAAGAABAAAA////A4AhAi8ABIlu0DqZTAwACAAAAAgAAAAYAAEA AAAKCv8DgCMCMAAEiW7QOpxMDAAIAAAACAAAABgAAQAAAAAA/wOCgQIxAASRbtA6fc4EANgF AADYBQAAGAABAAAAZ2j/AwAjgxQBABEBAAADAAAAAACJABsF1AHwAQKBAcyEBMCoyQEBBANF AAEI/xIThATQERITiQlNNS1EdWJsaW6AGACAgIDQERIT/////wqAgIDAqMkA////AIcRAAAA ACDQERITAAAAChjAqMkD/////xSAgIAKCgwA/////BSAgIAKCgwE/////BSAgIAKCg4A//// /Ic/AAAAACDQERITAAAAFCABAQEBAAAACiACAgICAAAAFCADAwMDAAAAFB4KCgwAAAAAFB4K CgwEAAAAFB4KCg4ADAAAAAAUHgoKDAQAAAAUHgoKDgACDAAKgICAAAIAAgACABYXAAIAAgAC AAAACgwGBMCoyQEIBMCoyRQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj/AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAI/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAj/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACKcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJJu 0DrgOQMA2AUAANgFAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwXUAfABAYEBzIQE wKjJFAEEA0UAAQj/AACJAAAAAACiOsUCaQABAAEAAQAAAAAA73KQBK4AAgACAAIAAAAAARTR UgJtAAMAAwADAAAAAADzhRyACgoOAP////wKgICAAQEBAf////8KgICAAwMDA/////8KgICA wKjJAP///wCHPgAAAAAgAgICAgAAAAoeCgoMAAAAAAoeCgoMBAAAAAoeCgoOAAAAAAogAQEB AQAAAAogAwMDAwAAAAoYwKjJCgwGCAQKCgwFCyBLk9HMS5PRzEuT0cxLk9HMS5PRzEuT0cxL k9HMS5PRzAoES5PRzAkES5PRzAMEAAAEAIA8AICAgAICAgL/////CoCAgAoKDAD////8CP+A gAoKDAT////8CoCAgAoKDgD////8CoCAgMCoyQD///8AhywAAAAAIAICAgIAAAAKHgoKDAAA AAAKHgoKDAQAAAAKHgoKDgAAAAAKGMCoyQAACh4KCgwAAAAAChjAqMkAAAAKHgoKDAQAAAAK HgoKDgAAAAAKHgoKDAQAAAAKHgoKDgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI/wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI pwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAk27QOi1vAwDYBQAA2AUAABgAAQAAAGdo/wMAI4MUAQARAQAAAwAAAAAAiQAbBdQB 8AEBgQHMhATAqMkBAQQDRQABCP8SE4QE0BESE4kJTTUtRHVibGlugBgAgICA0BESE/////8K gICAwKjJAP///wCHEQAAAAAg0BESEwAAAAoYwKjJA/////8UgICACgoMAP////wUgICACgoM BP////wUgICACgoOAP////yHPwAAAAAg0BESEwAAABQgAQEBAQAAAAogAgICAgAAABQgAwMD AwAAABQeCgoMAAAAABQeCgoMBAAAABQeCgoOAAwAAAAAFB4KCgwEAAAAFB4KCg4AAgwACoCA gAACAAIAAgAWFwACAAIAAgAAAAoMBgTAqMkBCATAqMkUAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAI/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj/AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACP8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAI/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAinAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACUbtA6jYgDACoAAAAqAAAAGAAAAAAAAAD/AwAjgxQBABEBAAADAAIA AgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAGVbtA6G7sDACoAAAAqAAAAGAABAAAAZ2j/AwAj gxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAGYbtA6tokDAGcAAABnAAAA GAAAAAAAAAD/AwAjgyEBABgBAAAAYwACAAIAAgEAAAAAAAAAAP//////////CUADzgAAAAAA iQAAAAAAojrFAl4AAQABAAEAAAAAAO9ykASrAAIAAgACAAAAAAEVKJICYgADAAMAAwAAAAAA 84UcmG7QOtuJAwBHAAAARwAAABgAAAAAAICA/wMAI4MhAQAZAQAAAEMAAgACAAIBAAAAAAAA AAD//////////wkgA9QAAAAAAIkAAAAAAKsgwwStAAIAAgACAAAAAAEOWJ2ZbtA6YG4DACcA AAAnAAAAGAABAAAAZ2j/AwAjgxEBABoBAAAAIwAAAAAAiQAJEAPSAAIAAgACAAAAAAEQHaKZ btA6eW4DACcAAAAnAAAAGAABAAAAboD/AwAjgxEBABsBAAAAIwAAAAAAiQAJEAPSAAIAAgAC AAAAAAEIZpWZbtA6U7wDAGcAAABnAAAAGAABAAAAgID/AwAjgyEBABgBAAAAYwAAAAAAiQAA AAAAAAAAAP//////////CUAEqwAAAAAAiQAAAAAApjLJAlsAAQABAAEAAAAAAO9ykAPSAAIA AgACAAAAAAEQHaICXwADAAMAAwAAAAAA84UcmW7QOmu8AwBHAAAARwAAABgAAQAAAAAC/wMA I4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKsAAAAAAIkAAAAAALAe0wPS AAIAAgACAAAAAAEIZpWabtA6N2MDACcAAAAnAAAAGAAAAAAAAAD/AwAjgxEBABoBAAAAIwAC AAIAAgEJEAPMAAAAAACJAAAAAACiOsWabtA6XmMDACcAAAAnAAAAGAAAAAAAAQD/AwAjgxEB ABsBAAAAIwACAAIAAgEJEAPSAAAAAACJAAAAAACrIMObbtA6Kn4JACoAAAAqAAAAGAAAAAAA Z2j/AwAjgxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAGcbtA6UMYIACoA AAAqAAAAGAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANF AAGdbtA6KIsDAJ8BAACfAQAAGAAAAAAAACP/AwAjgxsBABIBAAABmwSmAAIAAgACAAAAAAEV KJIDAQQDRQABgQHMhgQCAgIChAQCAgICiQhNMTAtT3NsbwItAAqAgIAAAwADAAMACoCAgAAB AAEAAQAKgICAAAEAAQABAAqAgIAAAAAAAIkAFsQAAwADAAMAAAAKDAYECgoOAQgECgoOAgAB AAEAAQAAAApABgQKCgwCCAQKCgwBCyBLk9HMS5PRzEuT0cxLk9HMS5PRzEuT0cxLk9HMS5PR zAoES5PRzAkES5PRzAMEAAAEAAABAAEAAQAAAApABgQKCgwGCAQKCgwFCyBLk9HMS5PRzEuT 0cxLk9HMS5PRzEuT0cxLk9HMS5PRzAoES5PRzAkES5PRzAMEAAAEAAAAAAAAiQAAAAoMBgTA qMkUCATAqMkBgDwAgICAAgICAv////8KgICACgoMAP////wKgICACgoMBP////wKgICACgoO AP////wKgICAwKjJAP///wCHLAAAAAAgAgICAgAAAAoeCgoMAAAAAAoeCgoMBAAAAAoeCgoO AAAAAAoYwKjJnW7QOu0RBQAQAQAAEAEAABgAAAAAAAAA/wMAI4MbAQAUAQAAAQwEqAACAAIA AgAAAAABDlidAwEEA0UAAYEBzIYEAgICAoQEAgICAokITTEwLU9zbG+AYACAgIACAgIC//// /wqAgIAKCgwA/////AqAgIAKCgwE/////AqAgIAKCg4A/////AqAgIABAQEB/////wqAgIAD AwMD/////wqAgIDAqMkA////AAqAgIDQERIT/////4dHAAAAACACAgICAAAACh4KCgwAAAAA Ch4KCgwEAAAACh4KCg4AAAAACiABAQEBAAAACiADAwMDAAAAChjAqMkAAAAKINAREhMCDAAK gICAAAAAAACJABYXAAAAAACJAAAACgwGBMCoyRQIBMCoyQGebtA6wUgDACcAAAAnAAAAGAAB AAAAZ2j/AwAjgxEBABoBAAAAIwAAAAAAiQAJEASkAAIAAgACAAAAAAEVKJKebtA620gDACcA AAAnAAAAGAABAAAAboD/AwAjgxEBABsBAAAAIwAAAAAAiQAJEASmAAIAAgACAAAAAAEOWJ2e btA6n5YDAJMAAACTAAAAGAABAAAAgID/AwAjgxsBABIBAAAAjwSmAAAAAACJAAAAAACmMskD AQQDRQABgQHMhgTQERIThATQERITiQlNNS1EdWJsaW6AGACAgIDQERIT/////wqAgIDAqMkA ////AIcRAAAAACDQERITAAAAChjAqMkCDAAKgICAAAIAAgACABYXAAIAAgACAAAACgwGBMCo yQEIBMCoyRSebtA6pNkDAGcAAABnAAAAGAAAAAAAAAD/AwAjgyEBABgBAAAAYwACAAIAAgEA AAAAAAAAAP//////////CUAEpAAAAAAAiQAAAAAApjLJAlgAAQABAAEAAAAAAO9ykASlAAIA AgACAAAAAAEVKJICXAADAAMAAwAAAAAA84Ucnm7QOs/ZAwBHAAAARwAAABgAAAAAAAAA/wMA I4MhAQAZAQAAAEMAAgACAAIBAAAAAAAAAAD//////////wkgA84AAAAAAIkAAAAAAKsgwwSn AAIAAgACAAAAAAEOWJ2ebtA6qR0FABEBAAARAQAAGAABAAAAAAD/AwAjgxsBABQBAAABDQSs AAAAAACJAAAAAACxFMkDAQQDRQABgQHMhgTQERIThATQERITiQlNNS1EdWJsaW6AYACAgIDQ ERIT/////wqAgIDAqMkA////ABSAgIABAQEB/////wqAgIACAgIC/////xSAgIADAwMD//// /xSAgIAKCgwA/////BSAgIAKCgwE/////BSAgIAKCg4A/////IdHAAAAACDQERITAAAAChjA qMkAAAAUIAEBAQEAAAAKIAICAgIAAAAUIAMDAwMAAAAUHgoKDAAAAAAUHgoKDAQAAAAUHgoK DgACDAAKgICAAAIAAgACABYXAAIAAgACAAAACgwGBMCoyQEIBMCoyRSfbtA66N0BACcAAAAn AAAAGAAAAAAAAAD/AwAjgxEBABoBAAAAIwACAAIAAgEJEASkAAAAAACJAAAAAACmMsmfbtA6 Ct4BACcAAAAnAAAAGAAAAAAAAAD/AwAjgxEBABsBAAAAIwACAAIAAgEJEASqAAAAAACJAAAA AACxFMmfbtA6fb4DAGcAAABnAAAAGAABAAAAT3P/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAA AAAAAP//////////CUAEpQAAAAAAiQAAAAAApjLJAlUAAQABAAEAAAAAAO9ykASiAAIAAgAC AAAAAAEVKJICWQADAAMAAwAAAAAA84Ucn27QOpW+AwBHAAAARwAAABgAAQAAAMxL/wMAI4Mh AQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKsAAAAAAIkAAAAAALEUyQSlAAIA AgACAAAAAAEOWJ2kbtA6aAYCACoAAAAqAAAAGAAAAAAAZ2j/AwAjgxQBABEBAAADAAIAAgAC ABsAJgHwAQCBAcyEBMCoyRQBBANFAAGkbtA6L8ADAGcAAABnAAAAGAABAAAAACP/AwAjgyEB ABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEoAAAAAAAiQAAAAAApjLJAlAAAQAB AAEAAAAAAO9ykASdAAIAAgACAAAAAAEVKJICVAADAAMAAwAAAAAA84UcpG7QOkjAAwBHAAAA RwAAABgAAQAAAICA/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKYA AAAAAIkAAAAAALEUyQSgAAIAAgACAAAAAAEOWJ2kbtA6MNYLACoAAAAqAAAAGAABAAAAAAD/ AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAGpbtA6zcEDAGcAAABn AAAAGAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEmwAA AAAAiQAAAAAApjLJAksAAQABAAEAAAAAAO9ykASYAAIAAgACAAAAAAEVKJICTwADAAMAAwAA AAAA84UcqW7QOubBAwBHAAAARwAAABgAAQAAAAEA/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAA AAAAAAD//////////wkgBKEAAAAAAIkAAAAAALEUyQSbAAIAAgACAAAAAAEOWJ2sbtA6kfwH ABwAAAAcAAAAGAAAAAAAAAD/AwAjghgBAAQAePeUCkUAAQACAAIAAgDGAgA8rG7QOtDmCAAq AAAAKgAAABgAAAAAAGdo/wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATAqMkUAQQD RQABrW7QOhGKAgAqAAAAKgAAABgAAQAAAAAA/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEA gQHMhATAqMkBAQQDRQABrm7QOm/DAwBnAAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMA AAAAAIkAAAAAAAAAAAD//////////wlABJYAAAAAAIkAAAAAAKYyyQJGAAEAAQABAAAAAADv cpAEkwACAAIAAgAAAAABFSiSAkoAAwADAAMAAAAAAPOFHK5u0DqHwwMARwAAAEcAAAAYAAEA AABPc/8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIAScAAAAAACJAAAA AACxFMkElgACAAIAAgAAAAABDlidsm7QOli4AwBnAAAAZwAAABgAAAAAAGdo/wMAI4MhAQAY AQAAAGMAAgACAAIBAAAAAAAAAAD//////////wlABJAAAAAAAIkAAAAAAKYyyQJEAAEAAQAB AAAAAADvcpAEkQACAAIAAgAAAAABFSiSAkgAAwADAAMAAAAAAPOFHLJu0DqBuAMARwAAAEcA AAAYAAAAAAABAP8DACODIQEAGQEAAABDAAIAAgACAQAAAAAAAAAA//////////8JIASXAAAA AACJAAAAAACxFMkEkwACAAIAAgAAAAABDlids27QOhDFAwBnAAAAZwAAABgAAQAAAAAA/wMA I4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABJEAAAAAAIkAAAAAAKYyyQJB AAEAAQABAAAAAADvcpAEjgACAAIAAgAAAAABFSiSAkUAAwADAAMAAAAAAPOFHLNu0DooxQMA RwAAAEcAAAAYAAEAAABPc/8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8J IASXAAAAAACJAAAAAACxFMkEkQACAAIAAgAAAAABDlidtW7QOh3fAAAqAAAAKgAAABgAAQAA AGdo/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABtW7QOvNuBwAc AAAAHAAAABgAAQAAAAAA/wMAI4IYAQAEAHgn4QpFAAEAAAAAAIkAxgIAPLVu0DpbwggAKgAA ACoAAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UA Abhu0DqbxgMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA //////////8JQASMAAAAAACJAAAAAACmMskCPAABAAEAAQAAAAAA73KQBIkAAgACAAIAAAAA ARUokgJAAAMAAwADAAAAAADzhRy4btA6tMYDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkB AAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEkgAAAAAAiQAAAAAAsRTJBIwAAgACAAIA AAAAAQ5Ynbxu0Dr4Jw4AKgAAACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAm AfABAIEBzIQEwKjJAQEEA0UAAb1u0DpJyAMAZwAAAGcAAAAYAAEAAAAAAP8DACODIQEAGAEA AABjAAAAAACJAAAAAAAAAAAA//////////8JQASHAAAAAACJAAAAAACmMskCNwABAAEAAQAA AAAA73KQBIQAAgACAAIAAAAAARUokgI7AAMAAwADAAAAAADzhRy9btA6T8gDAEcAAABHAAAA GAABAAAAAAH/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEjQAAAAAA iQAAAAAAsRTJBIcAAgACAAIAAAAAAQ5Ynb1u0Dqopg0AKgAAACoAAAAYAAAAAABnaP8DACOD FAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAcJu0DrhyQMAZwAAAGcAAAAY AAEAAAAAAP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQASCAAAAAACJ AAAAAACmMskCMgABAAEAAQAAAAAA73KQBH8AAgACAAIAAAAAARUokgI2AAMAAwADAAAAAADz hRzCbtA6+skDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAA AP//////////CSAEiAAAAAAAiQAAAAAAsRTJBIIAAgACAAIAAAAAAQ5YncRu0DrrWAEAKgAA ACoAAAAYAAEAAABnaP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UA AcVu0Dp12AkAKgAAACoAAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEB zIQEwKjJFAEEA0UAAcZu0DoUvgMAZwAAAGcAAAAYAAAAAAAAAP8DACODIQEAGAEAAABjAAIA AgACAQAAAAAAAAAA//////////8JQAR8AAAAAACJAAAAAACmMskCMAABAAEAAQAAAAAA73KQ BH0AAgACAAIAAAAAARUokgI0AAMAAwADAAAAAADzhRzGbtA6O74DAEcAAABHAAAAGAAAAAAA AAH/AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAAAP//////////CSAEgwAAAAAAiQAAAAAA sRTJBH8AAgACAAIAAAAAAQ5Yncdu0DqCywMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEA AABjAAAAAACJAAAAAAAAAAAA//////////8JQAR9AAAAAACJAAAAAACmMskCLQABAAEAAQAA AAAA73KQBHoAAgACAAIAAAAAARUokgIxAAMAAwADAAAAAADzhRzHbtA6mssDAEcAAABHAAAA GAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEgwAAAAAA iQAAAAAAsRTJBH0AAgACAAIAAAAAAQ5Ynctu0DrojwQAKgAAACoAAAAYAAEAAAAAAP8DACOD FAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UAAcxu0Do1zQMAZwAAAGcAAAAY AAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQAR4AAAAAACJ AAAAAACmMskCKAABAAEAAQAAAAAA73KQBHUAAgACAAIAAAAAARUokgIsAAMAAwADAAAAAADz hRzMbtA6TM0DAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAA AP//////////CSAEfgAAAAAAiQAAAAAAsRTJBHgAAgACAAIAAAAAAQ5Ync1u0Dq1sgAAKgAA ACoAAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UA AdFu0DrJzgMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA //////////8JQARzAAAAAACJAAAAAACmMskCIwABAAEAAQAAAAAA73KQBHAAAgACAAIAAAAA ARUokgInAAMAAwADAAAAAADzhRzRbtA64c4DAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkB AAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEeQAAAAAAiQAAAAAAsRTJBHMAAgACAAIA AAAAAQ5YndJu0Do7Vg4AKgAAACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAm AfABAIEBzIQEwKjJAQEEA0UAAdVu0DrOsAIAKgAAACoAAAAYAAAAAABnaP8DACODFAEAEQEA AAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAdZu0Dp59wMAZwAAAGcAAAAYAAEAAAAA AP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQARuAAAAAACJAAAAAACm MskCHgABAAEAAQAAAAAA73KQBGsAAgACAAIAAAAAARUokgIiAAMAAwADAAAAAADzhRzWbtA6 kfcDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP////// ////CSAEdAAAAAAAiQAAAAAAsRTJBG4AAgACAAIAAAAAAQ5Yndpu0DriwwMAZwAAAGcAAAAY AAAAAABnaP8DACODIQEAGAEAAABjAAIAAgACAQAAAAAAAAAA//////////8JQARoAAAAAACJ AAAAAACmMskCHAABAAEAAQAAAAAA73KQBGkAAgACAAIAAAAAARUokgIgAAMAAwADAAAAAADz hRzabtA6CsQDAEcAAABHAAAAGAAAAAAAAQD/AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAA AP//////////CSAEbwAAAAAAiQAAAAAAsRTJBGsAAgACAAIAAAAAAQ5Yndpu0DpYGwYAKgAA ACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UA Adtu0DoD0gMAZwAAAGcAAAAYAAEAAAAAAP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA //////////8JQARpAAAAAACJAAAAAACmMskCGQABAAEAAQAAAAAA73KQBGYAAgACAAIAAAAA ARUokgIdAAMAAwADAAAAAADzhRzbbtA6G9IDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkB AAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEbwAAAAAAiQAAAAAAsRTJBGkAAgACAAIA AAAAAQ5Yndxu0DpFUwEAKgAAACoAAAAYAAAAAABnaP8DACODFAEAEQEAAAMAAgACAAIAGwAm AfABAIEBzIQEwKjJFAEEA0UAAeBu0DrJ0wMAZwAAAGcAAAAYAAEAAAAAAP8DACODIQEAGAEA AABjAAAAAACJAAAAAAAAAAAA//////////8JQARkAAAAAACJAAAAAACmMskCFAABAAEAAQAA AAAA73KQBGEAAgACAAIAAAAAARUokgIYAAMAAwADAAAAAADzhRzgbtA61dMDAEcAAABHAAAA GAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEagAAAAAA iQAAAAAAsRTJBGQAAgACAAIAAAAAAQ5YneFu0DrhKgkAKgAAACoAAAAYAAEAAABnaP8DACOD FAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UAAeNu0DqhGAIAKgAAACoAAAAY AAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAeVu0Dqv 1QMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////// //8JQARfAAAAAACJAAAAAACmMskCDwABAAEAAQAAAAAA73KQBFwAAgACAAIAAAAAARUokgIT AAMAAwADAAAAAADzhRzlbtA6yNUDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAA AAAAiQAAAAAAAAAAAP//////////CSAEZQAAAAAAiQAAAAAAsRTJBF8AAgACAAIAAAAAAQ5Y nehu0DrzDQgAHAAAABwAAAAYAAAAAAAAAP8DACOCGAEABAB495QKRQABAAIAAgACAMYCADzq btA6PHsAACoAAAAqAAAAGAABAAAAZ2j/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyE BMCoyQEBBANFAAHqbtA659YDAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAA iQAAAAAAAAAAAP//////////CUAEWgAAAAAAiQAAAAAApjLJAgoAAQABAAEAAAAAAO9ykARX AAIAAgACAAAAAAEVKJICDgADAAMAAwAAAAAA84Uc6m7QOv/WAwBHAAAARwAAABgAAQAAAAAB /wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBGAAAAAAAIkAAAAAALEU yQRaAAIAAgACAAAAAAEOWJ3rbtA6VEgGAJMAAACTAAAAGAABAAAAAAD/AwAjgxsBABIBAAAA jwSuAAAAAACJAAAAAACnMMoDAQQDRQABgQHMhgTQERIThATQERITiQlNNS1EdWJsaW6AGACA gIDQERIT/////wqAgIDAqMkA////AIcRAAAAACDQERITAAAAChjAqMkCDAAKgICAAAIAAgAC ABYXAAIAAgACAAAACgwGBMCoyQEIBMCoyRTsbtA6rLsAACoAAAAqAAAAGAAAAAAAZ2j/AwAj gxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAHsbtA6rywDACcAAAAnAAAA GAAAAAAAAAD/AwAjgxEBABoBAAAAIwACAAIAAgEJEASsAAAAAACJAAAAAACnMMrubtA6pckD AGcAAABnAAAAGAAAAAAAAAD/AwAjgyEBABgBAAAAYwACAAIAAgEAAAAAAAAAAP////////// CUAEqgAAAAAAiQAAAAAApzDKAggAAQABAAEAAAAAAO9ykARVAAIAAgACAAAAAAEVKJICDAAD AAMAAwAAAAAA84Uc7m7QOsvJAwBHAAAARwAAABgAAAAAAAAC/wMAI4MhAQAZAQAAAEMAAgAC AAIBAAAAAAAAAAD//////////wkgBFsAAAAAAIkAAAAAALEUyQRXAAIAAgACAAAAAAEOWJ3v btA6k9gDAGcAAABnAAAAGAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP// ////////CUAEqwAAAAAAiQAAAAAApzDKAgUAAQABAAEAAAAAAO9ykARSAAIAAgACAAAAAAEV KJICCQADAAMAAwAAAAAA84Uc727QOqrYAwBHAAAARwAAABgAAQAAAAEA/wMAI4MhAQAZAQAA AEMAAAAAAIkAAAAAAAAAAAD//////////wkgBFsAAAAAAIkAAAAAALEUyQRVAAIAAgACAAAA AAEOWJ3xbtA6Yu4CACoAAAAqAAAAGAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHw AQCBAcyEBMCoyQEBBANFAAHxbtA6hoIHABwAAAAcAAAAGAABAAAAAAD/AwAjghgBAAQAeCfh CkUAAQAAAAAAiQDGAgA89G7QOjDaAwBnAAAAZwAAABgAAQAAAGdo/wMAI4MhAQAYAQAAAGMA AAAAAIkAAAAAAAAAAAD//////////wlABKYAAAAAAIkAAAAAAKcwygIAAAEAAQABAAAAAADv cpAETQACAAIAAgAAAAABFSiSAgQAAwADAAMAAAAAAPOFHPRu0DpH2gMARwAAAEcAAAAYAAEA AAABAP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIARWAAAAAACJAAAA AACxFMkEUAACAAIAAgAAAAABDlid9G7QOgANCgAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQAR AQAAAwACAAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQAB+W7QOtTbAwBnAAAAZwAAABgAAQAA AGdo/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABKEAAAAAAIkAAAAA AKcwygH7AAEAAQABAAAAAADvcpAESAACAAIAAgAAAAABFSiSAf8AAwADAAMAAAAAAPOFHPlu 0Dru2wMARwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//// //////8JIARRAAAAAACJAAAAAACxFMkESwACAAIAAgAAAAABDlid+W7QOtrsBAAqAAAAKgAA ABgAAQAAAAAA/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQAB+27Q OpduCwAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATA qMkUAQQDRQAB/m7QOmndAwBnAAAAZwAAABgAAQAAAGdo/wMAI4MhAQAYAQAAAGMAAAAAAIkA AAAAAAAAAAD//////////wlABJwAAAAAAIkAAAAAAKcwygH2AAEAAQABAAAAAADvcpAEQwAC AAIAAgAAAAABFSiSAfoAAwADAAMAAAAAAPOFHP5u0DqB3QMARwAAAEcAAAAYAAEAAAABAP8D ACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIARMAAAAAACJAAAAAACxFMkE RgACAAIAAgAAAAABDlidAW/QOrGqCQAqAAAAKgAAABgAAQAAAAAA/wMAI4MUAQARAQAAAwAA AAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABAm/QOmPPAwBnAAAAZwAAABgAAAAAAAAA/wMA I4MhAQAYAQAAAGMAAgACAAIBAAAAAAAAAAD//////////wlABJYAAAAAAIkAAAAAAKcwygH0 AAEAAQABAAAAAADvcpAEQQACAAIAAgAAAAABFSiSAfgAAwADAAMAAAAAAPOFHAJv0DqJzwMA RwAAAEcAAAAYAAAAAAAAAf8DACODIQEAGQEAAABDAAIAAgACAQAAAAAAAAAA//////////8J IARHAAAAAACJAAAAAACxFMkEQwACAAIAAgAAAAABDlidAm/QOjv3DAAqAAAAKgAAABgAAAAA AGdo/wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQABA2/QOiDfAwBn AAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlA BJcAAAAAAIkAAAAAAKcwygHxAAEAAQABAAAAAADvcpAEPgACAAIAAgAAAAABFSiSAfUAAwAD AAMAAAAAAPOFHANv0Do43wMARwAAAEcAAAAYAAEAAAAAAf8DACODIQEAGQEAAABDAAAAAACJ AAAAAAAAAAAA//////////8JIARHAAAAAACJAAAAAACxFMkEQQACAAIAAgAAAAABDlidCG/Q OszgAwBnAAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD///// /////wlABJIAAAAAAIkAAAAAAKcwygHsAAEAAQABAAAAAADvcpAEOQACAAIAAgAAAAABFSiS AfAAAwADAAMAAAAAAPOFHAhv0Drn4AMARwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABD AAAAAACJAAAAAAAAAAAA//////////8JIARCAAAAAACJAAAAAACxFMkEPAACAAIAAgAAAAAB DlidCG/QOh0EDwAqAAAAKgAAABgAAQAAAGdo/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEA gQHMhATAqMkBAQQDRQABCW/QOsQKDgAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQARAQAAAwAC AAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQABDW/QOm8JBABnAAAAZwAAABgAAQAAAGdo/wMA I4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABI0AAAAAAIkAAAAAAKcwygHn AAEAAQABAAAAAADvcpAENAACAAIAAgAAAAABFSiSAesAAwADAAMAAAAAAPOFHA1v0DqJCQQA RwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8J IAQ9AAAAAACJAAAAAACxFMkENwACAAIAAgAAAAABDlidEW/QOs5DDgAqAAAAKgAAABgAAQAA AAAA/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABEm/QOgQLBABn AAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlA BIgAAAAAAIkAAAAAAKcwygHiAAEAAQABAAAAAADvcpAELwACAAIAAgAAAAABFSiSAeYAAwAD AAMAAAAAAPOFHBJv0DodCwQARwAAAEcAAAAYAAEAAAAAAf8DACODIQEAGQEAAABDAAAAAACJ AAAAAAAAAAAA//////////8JIAQ4AAAAAACJAAAAAACxFMkEMgACAAIAAgAAAAABDlidEm/Q OiNsBgAqAAAAKgAAABgAAAAAAP///wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATA qMkUAQQDRQABFm/QOjLVAwBnAAAAZwAAABgAAAAAAGdo/wMAI4MhAQAYAQAAAGMAAgACAAIB AAAAAAAAAAD//////////wlABIIAAAAAAIkAAAAAAKcwygHgAAEAAQABAAAAAADvcpAELQAC AAIAAgAAAAABFSiSAeQAAwADAAMAAAAAAPOFHBZv0Dpa1QMARwAAAEcAAAAYAAAAAAABAP8D ACODIQEAGQEAAABDAAIAAgACAQAAAAAAAAAA//////////8JIAQzAAAAAACJAAAAAACxFMkE LwACAAIAAgAAAAABDlidF2/QOrzlAwBnAAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMA AAAAAIkAAAAAAAAAAAD//////////wlABIMAAAAAAIkAAAAAAKcwygHdAAEAAQABAAAAAADv cpAEKgACAAIAAgAAAAABFSiSAeEAAwADAAMAAAAAAPOFHBdv0DrV5QMARwAAAEcAAAAYAAEA AAABAP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIAQzAAAAAACJAAAA AACxFMkELQACAAIAAgAAAAABDlidGW/QOlrFDgAqAAAAKgAAABgAAQAAAGdo/wMAI4MUAQAR AQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABG2/QOsNLBAAqAAAAKgAAABgAAAAA AAAA/wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQABHG/QOjnnAwBn AAAAZwAAABgAAQAAAGdo/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlA BH4AAAAAAIkAAAAAAKcwygHYAAEAAQABAAAAAADvcpAEJQACAAIAAgAAAAABFSiSAdwAAwAD AAMAAAAAAPOFHBxv0DpX5wMARwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABDAAAAAACJ AAAAAAAAAAAA//////////8JIAQuAAAAAACJAAAAAACxFMkEKAACAAIAAgAAAAABDlidIW/Q OuzoAwBnAAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD///// /////wlABHkAAAAAAIkAAAAAAKcwygHTAAEAAQABAAAAAADvcpAEIAACAAIAAgAAAAABFSiS AdcAAwADAAMAAAAAAPOFHCFv0DoE6QMARwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABD AAAAAACJAAAAAAAAAAAA//////////8JIAQpAAAAAACJAAAAAACxFMkEIwACAAIAAgAAAAAB DlidIm/QOqrgBwAqAAAAKgAAABgAAQAAAGdo/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEA gQHMhATAqMkBAQQDRQABI2/QOoOLDAAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQARAQAAAwAC AAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQABJG/QOjYfCAAcAAAAHAAAABgAAAAAAAAA/wMA I4IYAQAEAHj3lApFAAEAAgACAAIAxgIAPCZv0Dqe6gMAZwAAAGcAAAAYAAEAAABnaP8DACOD IQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQAR0AAAAAACJAAAAAACnMMoBzgAB AAEAAQAAAAAA73KQBBsAAgACAAIAAAAAARUokgHSAAMAAwADAAAAAADzhRwmb9A6tuoDAEcA AABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAE JAAAAAAAiQAAAAAAsRTJBB4AAgACAAIAAAAAAQ5YnSpv0DrSswMAZwAAAGcAAAAYAAAAAAAA AP8DACODIQEAGAEAAABjAAIAAgACAQAAAAAAAAAA//////////8JQARuAAAAAACJAAAAAACn MMoBzAABAAEAAQAAAAAA73KQBBkAAgACAAIAAAAAARUokgHQAAMAAwADAAAAAADzhRwqb9A6 97MDAEcAAABHAAAAGAAAAAAAAQD/AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAAAP////// ////CSAEHwAAAAAAiQAAAAAAsRTJBBsAAgACAAIAAAAAAQ5YnStv0Do97AMAZwAAAGcAAAAY AAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQARvAAAAAACJ AAAAAACnMMoByQABAAEAAQAAAAAA73KQBBYAAgACAAIAAAAAARUokgHNAAMAAwADAAAAAADz hRwrb9A6V+wDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAA AP//////////CSAEHwAAAAAAiQAAAAAAsRTJBBkAAgACAAIAAAAAAQ5YnStv0DqAlQcAKgAA ACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UA ASxv0DoZrAcAKgAAACoAAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEB zIQEwKjJFAEEA0UAAS1v0DpLlgcAHAAAABwAAAAYAAEAAABnaP8DACOCGAEABAB4J+EKRQAB AAAAAACJAMYCADwwb9A60u0DAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAA iQAAAAAAAAAAAP//////////CUAEagAAAAAAiQAAAAAApzDKAcQAAQABAAEAAAAAAO9ykAQR AAIAAgACAAAAAAEVKJIByAADAAMAAwAAAAAA84UcMG/QOurtAwBHAAAARwAAABgAAQAAAAEA /wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBBoAAAAAAIkAAAAAALEU yQQUAAIAAgACAAAAAAEOWJ0zb9A6SHkDACoAAAAqAAAAGAABAAAAZ2j/AwAjgxQBABEBAAAD AAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAEzb9A6yGMEABEBAAARAQAAGAABAAAAAAD/ AwAjgxsBABQBAAABDQSuAAAAAACJAAAAAACyEsoDAQQDRQABgQHMhgTQERIThATQERITiQlN NS1EdWJsaW6AYACAgIDQERIT/////wqAgIDAqMkA////ABSAgIABAQEB/////wqAgIACAgIC /////xSAgIADAwMD/////xSAgIAKCgwA/////BSAgIAKCgwE/////BSAgIAKCg4A/////IdH AAAAACDQERITAAAAChjAqMkAAAAUIAEBAQEAAAAKIAICAgIAAAAUIAMDAwMAAAAUHgoKDAAA AAAUHgoKDAQAAAAUHgoKDgACDAAKgICAAAIAAgACABYXAAIAAgACAAAACgwGBMCoyQEIBMCo yRQzb9A6ALMOACoAAAAqAAAAGAAAAAAAAAD/AwAjgxQBABEBAAADAAIAAgACABsAJgHwAQCB AcyEBMCoyRQBBANFAAE0b9A6GXoEACcAAAAnAAAAGAAAAAAAAAD/AwAjgxEBABsBAAAAIwAC AAIAAgEJEASrAAAAAACJAAAAAACyEso1b9A6Re8DAGcAAABnAAAAGAABAAAAZ2j/AwAjgyEB ABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEZQAAAAAAiQAAAAAApzDKAb8AAQAB AAEAAAAAAO9ykAQMAAIAAgACAAAAAAEVKJIBwwADAAMAAwAAAAAA84UcNW/QOnUWBABHAAAA RwAAABgAAQAAAHVi/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKwA AAAAAIkAAAAAALISygQPAAIAAgACAAAAAAEOWJ06b9A6FvEDAGcAAABnAAAAGAABAAAAAAD/ AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEYAAAAAAAiQAAAAAApzDK AboAAQABAAEAAAAAAO9ykAQHAAIAAgACAAAAAAEVKJIBvgADAAMAAwAAAAAA84UcOm/QOi7x AwBHAAAARwAAABgAAQAAAAEA/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD///////// /wkgBKcAAAAAAIkAAAAAALISygQKAAIAAgACAAAAAAEOWJ07b9A64jECACoAAAAqAAAAGAAA AAAAZ2j/AwAjgxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAE8b9A62eMA ACoAAAAqAAAAGAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEB BANFAAE+b9A6seADAGcAAABnAAAAGAAAAAAAZ2j/AwAjgyEBABgBAAAAYwACAAIAAgEAAAAA AAAAAP//////////CUAEWgAAAAAAiQAAAAAApzDKAbgAAQABAAEAAAAAAO9ykAQFAAIAAgAC AAAAAAEVKJIBvAADAAMAAwAAAAAA84UcPm/QOtngAwBHAAAARwAAABgAAAAAAHVi/wMAI4Mh AQAZAQAAAEMAAgACAAIBAAAAAAAAAAD//////////wkgBKIAAAAAAIkAAAAAALISygQHAAIA AgACAAAAAAEOWJ0/b9A6r/IDAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAA iQAAAAAAAAAAAP//////////CUAEWwAAAAAAiQAAAAAApzDKAbUAAQABAAEAAAAAAO9ykAQC AAIAAgACAAAAAAEVKJIBuQADAAMAAwAAAAAA84UcP2/QOsfyAwBHAAAARwAAABgAAQAAAAEA /wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKIAAAAAAIkAAAAAALIS ygQFAAIAAgACAAAAAAEOWJ1Cb9A6M6kCACoAAAAqAAAAGAAAAAAAZ2j/AwAjgxQBABEBAAAD AAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAFEb9A6S7sCACoAAAAqAAAAGAABAAAAAAD/ AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAFEb9A6TfQDAGcAAABn AAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEVgAA AAAAiQAAAAAApzDKAbAAAQABAAEAAAAAAO9ykAP9AAIAAgACAAAAAAEVKJIBtAADAAMAAwAA AAAA84UcRG/QOmT0AwBHAAAARwAAABgAAQAAAAAB/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAA AAAAAAD//////////wkgBJ0AAAAAAIkAAAAAALISygQAAAIAAgACAAAAAAEOWJ1Jb9A6+PUD AGcAAABnAAAAGAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP////////// CUAEUQAAAAAAiQAAAAAApzDKAasAAQABAAEAAAAAAO9ykAP4AAIAAgACAAAAAAEVKJIBrwAD AAMAAwAAAAAA84UcSW/QOhH2AwBHAAAARwAAABgAAQAAAHVi/wMAI4MhAQAZAQAAAEMAAAAA AIkAAAAAAAAAAAD//////////wkgBJgAAAAAAIkAAAAAALISygP7AAIAAgACAAAAAAEOWJ1J b9A6ugsNABABAAAQAQAAGAAAAAAAAAD/AwAjgxsBABQBAAABDASuAAIAAgACAAAAAAEPVp4D AQQDRQABgQHMhgQCAgIChAQCAgICiQhNMTAtT3Nsb4BgAICAgAICAgL/////CoCAgAoKDAD/ ///8CoCAgAoKDAT////8CoCAgAoKDgD////8CoCAgAEBAQH/////CoCAgAMDAwP/////CoCA gMCoyQD///8ACoCAgNAREhP/////h0cAAAAAIAICAgIAAAAKHgoKDAAAAAAKHgoKDAQAAAAK HgoKDgAAAAAKIAEBAQEAAAAKIAMDAwMAAAAKGMCoyQAAAAog0BESEwIMAAqAgIAAAAAAAIkA FhcAAAAAAIkAAAAKDAYEwKjJFAgEwKjJAUpv0DqdIQwAKgAAACoAAAAYAAAAAABnaP8DACOD FAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAUpv0DqggQwAJwAAACcAAAAY AAEAAAAAAP8DACODEQEAGwEAAAAjAAAAAACJAAkQBKwAAgACAAIAAAAAAQ9Wnktv0DoF8w4A KgAAACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEE A0UAAU5v0Drq9wMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAA AAAA//////////8JQARMAAAAAACJAAAAAACnMMoBpgABAAEAAQAAAAAA73KQA/MAAgACAAIA AAAAARUokgGqAAMAAwADAAAAAADzhRxOb9A6AvgDAEcAAABHAAAAGAABAAAAdWL/AwAjgyEB ABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEkwAAAAAAiQAAAAAAshLKBKgAAgAC AAIAAAAAAQ9WnlJv0DpZvwMAZwAAAGcAAAAYAAAAAAAAAP8DACODIQEAGAEAAABjAAIAAgAC AQAAAAAAAAAA//////////8JQARGAAAAAACJAAAAAACnMMoBpAABAAEAAQAAAAAA73KQA/EA AgACAAIAAAAAARUokgGoAAMAAwADAAAAAADzhRxSb9A6fr8DAEcAAABHAAAAGAAAAAAAgID/ AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAAAP//////////CSAEjgAAAAAAiQAAAAAAshLK BKYAAgACAAIAAAAAAQ9WnlJv0DquPQkAKgAAACoAAAAYAAAAAABnaP8DACODFAEAEQEAAAMA AgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAVJv0DrODg0AMQEAADEBAAAYAAAAAAAAAP8D ACODGwEAEgEAAAEtBKwAAQABAAEAAAAAAPBwkQEBBANFAAGBAcyGBAEBAQGEBAEBAQGJB001 LU5pY2WAJACAgIABAQEB/////wqAgIAKCgwA/////AqAgIAKCgwE/////IcbAAAAACABAQEB AAAACh4KCgwAAAAACh4KCgwEAhcACoCAgAACAAIAAgAKgICAAAIAAgACABaWAAIAAgACAAAA CkAGBAoKDAEIBAoKDAILIEuT0cxLk9HMS5PRzEuT0cxLk9HMS5PRzEuT0cxLk9HMCgRLk9HM CQRLk9HMAwQAAAQAAAIAAgACAAAACkAGBAoKDAUIBAoKDAYLIEuT0cxLk9HMS5PRzEuT0cxL k9HMS5PRzEuT0cxLk9HMCgRLk9HMCQRLk9HMAwQAAAQAU2/QOjv5AwBnAAAAZwAAABgAAQAA AAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABEcAAAAAAIkAAAAA AKcwygSqAAEAAQABAAAAAADwcJED7gACAAIAAgAAAAABFSiSAaUAAwADAAMAAAAAAPOFHFNv 0DpT+QMARwAAAEcAAAAYAAEAAAAAI/8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//// //////8JIASOAAAAAACJAAAAAACyEsoEowACAAIAAgAAAAABD1aeU2/QOi7BCwAnAAAAJwAA ABgAAQAAAAAA/wMAI4MRAQAaAQAAACMAAAAAAIkACRAEqgABAAEAAQAAAAAA8HCRU2/QOjo2 DAAqAAAAKgAAABgAAQAAAAEA/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkB AQQDRQABWG/QOvP6AwBnAAAAZwAAABgAAQAAAGdo/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAA AAAAAAD//////////wlABEIAAAAAAIkAAAAAAKcwygSlAAEAAQABAAAAAADwcJED6QACAAIA AgAAAAABFSiSAaAAAwADAAMAAAAAAPOFHFhv0DoO+wMARwAAAEcAAAAYAAEAAABpY/8DACOD IQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIASJAAAAAACJAAAAAACyEsoEngAC AAIAAgAAAAABD1aeW2/QOic3BAAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQARAQAAAwACAAIA AgAbACYB8AEAgQHMhATAqMkUAQQDRQABW2/QOrs0DgAqAAAAKgAAABgAAQAAAGdo/wMAI4MU AQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABXW/QOoD8AwBnAAAAZwAAABgA AQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABD0AAAAAAIkA AAAAAKcwygSgAAEAAQABAAAAAADwcJED5AACAAIAAgAAAAABFSiSAZsAAwADAAMAAAAAAPOF HF1v0DqZ/AMARwAAAEcAAAAYAAEAAACAgP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA //////////8JIASEAAAAAACJAAAAAACyEsoEmQACAAIAAgAAAAABD1aeYG/QOo0wCAAcAAAA HAAAABgAAAAAAGdo/wMAI4IYAQAEAHj3lApFAAEAAgACAAIAxgIAPGJv0Do4/gMAZwAAAGcA AAAYAAEAAAAAAP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQAQ4AAAA AACJAAAAAACnMMoEmwABAAEAAQAAAAAA8HCRA98AAgACAAIAAAAAARUokgGWAAMAAwADAAAA AADzhRxib9A6Uf4DAEcAAABHAAAAGAABAAAAgID/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAA AAAAAP//////////CSAEfwAAAAAAiQAAAAAAshLKBJQAAgACAAIAAAAAAQ9WnmJv0DoB6A4A KgAAACoAAAAYAAAAAABnaP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEE A0UAAWNv0DpTLQAAKgAAACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfAB AIEBzIQEwKjJAQEEA0UAAWZv0DohxQMAZwAAAGcAAAAYAAAAAAAAAP8DACODIQEAGAEAAABj AAIAAgACAQAAAAAAAAAA//////////8JQAQyAAAAAACJAAAAAACnMMoEmQABAAEAAQAAAAAA 8HCRA90AAgACAAIAAAAAARUokgGUAAMAAwADAAAAAADzhRxmb9A6R8UDAEcAAABHAAAAGAAA AAAAgID/AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAAAP//////////CSAEegAAAAAAiQAA AAAAshLKBJIAAgACAAIAAAAAAQ9Wnmdv0DrR/wMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEA GAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQAQzAAAAAACJAAAAAACnMMoElgABAAEA AQAAAAAA8HCRA9oAAgACAAIAAAAAARUokgGRAAMAAwADAAAAAADzhRxnb9A66f8DAEcAAABH AAAAGAABAAAAaWP/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEegAA AAAAiQAAAAAAshLKBI8AAgACAAIAAAAAAQ9Wnmlv0Dq4qQcAHAAAABwAAAAYAAEAAAAAAP8D ACOCGAEABAB4J+EKRQABAAAAAACJAMYCADxqb9A6F+4MACoAAAAqAAAAGAAAAAAAZ2j/AwAj gxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAFrb9A6I8gCACoAAAAqAAAA GAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAFsb9A6 VgEEAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP////// ////CUAELgAAAAAAiQAAAAAApzDKBJEAAQABAAEAAAAAAPBwkQPVAAIAAgACAAAAAAEVKJIB jAADAAMAAwAAAAAA84UcbG/QOm4BBABHAAAARwAAABgAAQAAAICA/wMAI4MhAQAZAQAAAEMA AAAAAIkAAAAAAAAAAAD//////////wkgBHUAAAAAAIkAAAAAALISygSKAAIAAgACAAAAAAEP Vp5tb9A6fPMKAMkAAADJAAAAGAAAAAAAZ2j/AwAjgxsBABIBAAAAxQSsAAMAAwADAAAAAAD0 gx0BAQQDRQABgQHMhgQDAwMDhAQDAwMDiQpNMjAtVmllbm5hgBgAgICAAwMDA/////8KgICA CgoOAP////yHEgAAAAAgAwMDAwAAAAoeCgoOAAIMAAqAgIAAAgACAAIAFksAAgACAAIAAAAK QAYECgoOAggECgoOAQsgS5PRzEuT0cxLk9HMS5PRzEuT0cxLk9HMS5PRzEuT0cwKBEuT0cwJ BEuT0cwDBAAAAABub9A6hKsHACcAAAAnAAAAGAABAAAAAgD/AwAjgxEBABoBAAAAIwAAAAAA iQAJEASqAAMAAwADAAAAAAD0gx1xb9A6BQMEAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgB AAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEKQAAAAAAiQAAAAAApzDKBIwAAQABAAEA AAAAAPBwkQPQAAIAAgACAAAAAAEVKJIEpwADAAMAAwAAAAAA9IMdcW/QOh4DBABHAAAARwAA ABgAAQAAAICA/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBHAAAAAA AIkAAAAAALISygSFAAIAAgACAAAAAAEPVp5xb9A6cIwNACoAAAAqAAAAGAAAAAAAZ2j/AwAj gxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAFzb9A6jxUOACoAAAAqAAAA GAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAF2b9A6 nAQEAGcAAABnAAAAGAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP////// ////CUAEJAAAAAAAiQAAAAAApzDKBIcAAQABAAEAAAAAAPBwkQPLAAIAAgACAAAAAAEVKJIE ogADAAMAAwAAAAAA9IMddm/QOrQEBABHAAAARwAAABgAAQAAAAAC/wMAI4MhAQAZAQAAAEMA AAAAAIkAAAAAAAAAAAD//////////wkgBGsAAAAAAIkAAAAAALISygSAAAIAAgACAAAAAAEP Vp56b9A658oDAGcAAABnAAAAGAAAAAAAAAD/AwAjgyEBABgBAAAAYwACAAIAAgEAAAAAAAAA AP//////////CUAEHgAAAAAAiQAAAAAApzDKBIUAAQABAAEAAAAAAPBwkQPJAAIAAgACAAAA AAEVKJIEoAADAAMAAwAAAAAA9IMdem/QOg3LAwBHAAAARwAAABgAAAAAAICA/wMAI4MhAQAZ AQAAAEMAAgACAAIBAAAAAAAAAAD//////////wkgBGYAAAAAAIkAAAAAALISygR+AAIAAgAC AAAAAAEPVp56b9A69xgEACoAAAAqAAAAGAAAAAAAqMn/AwAjgxQBABEBAAADAAIAAgACABsA JgHwAQCBAcyEBMCoyRQBBANFAAF7b9A6XAYEAGcAAABnAAAAGAABAAAAZ2j/AwAjgyEBABgB AAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEHwAAAAAAiQAAAAAApzDKBIIAAQABAAEA AAAAAPBwkQPGAAIAAgACAAAAAAEVKJIEnQADAAMAAwAAAAAA9IMde2/QOnUGBABHAAAARwAA ABgAAQAAAAAC/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBGYAAAAA AIkAAAAAALISygR7AAIAAgACAAAAAAEPVp58b9A6eM0CACoAAAAqAAAAGAABAAAAAAD/AwAj gxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAGAb9A6/QcEAGcAAABnAAAA GAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEGgAAAAAA iQAAAAAApzDKBH0AAQABAAEAAAAAAPBwkQPBAAIAAgACAAAAAAEVKJIEmAADAAMAAwAAAAAA 9IMdgG/QOhUIBABHAAAARwAAABgAAQAAAAAC/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAA AAD//////////wkgBGEAAAAAAIkAAAAAALISygR2AAIAAgACAAAAAAEPVp6Bb9A6IEYCACoA AAAqAAAAGAAAAAAAAAD/AwAjgxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANF AAGDb9A6nr8KACoAAAAqAAAAGAABAAAAZ2j/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCB AcyEBMCoyQEBBANFAAE= --PNTmBPCT7hxwcZjr-- From Manav Bhatia" Hi Dave OR if anybody else can clear this point .. I was going through your presentation archived at nanog where you have compared the two link state protocols viz IS-IS and OSPF .. I am working on IS-IS and am not much aware of OSPF and i was looking at the scalabilities issues related to both of the protocols. There you have said that the problem with OSPF is that in theory OSPF topology is limited to how much we can stuff in the router LSA as each router gets one router LSA and it cant be bigger than the biggest of the IP datagram (64K) and so can contain some O(5000) links. And the problem you said with IS-IS is the number of LSPs a single router can issue which is 256. My question is that how can we say that in OSPF a router has to stuff all its link database in ** one ** LSA. We have the mechanism of I-bit and the M-bit wherein we control the division of a large topological database description into multiple messages. Can you please throw some light on this. Thanks and Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Manav Bhatia" Message-ID: <002701c12980$72129e20$da046c6b@Manav> Hi Manral, I was able to do this calculation but what i wanted to ask was .. Where is it mentioned that a router can originate only one-router LSA for each area it is connected to .. as i understand during the database exchange process the routers form a master/slave relationship, the master being first to transmit. The master sends database description packets to the slave to describe its database of link state information. Flags in database description packets indicate whether they are form the master or slave (the M/S bit), the first such packet (the I bit) and if there are more packets to come (the M bit). Database exchange is complete when a router recieves a database description packet from its neighbor with the M bit off. If this is so then there is no limit on the size of the LSAs an OSPF router can advertise. I am copying it on to the list so that others can chime in and help us out .. Regards, Manav ----- Original Message ----- From: "Manral, Vishwas" To: "'Manav Bhatia'" Cc: Sent: Monday, August 20, 2001 5:02 PM Subject: RE: [Isis-wg] OSPF and IS-IS Scalability > Hi Manav/Dave, > > Well each router can originate only one router LSA for each area it is > connected to. > > Each link in the router can take up at most 24 bytes. The maximum size of a > ospf LS-Update packet is 2^16, as the packet length of the ospf header is 24 > bytes. So the total number of links maximum is about 2^16/ 24 is > approximately equal to 2730. > > However if we take the minimum link size per link in the router lsa, then > the max is about 2730 * 2, or O(5000). > > Tell me Dave where i m wrong, or is it the IP packet we are talking about? > > Thanks, > Vishwas > > > > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Monday, August 20, 2001 3:42 PM > To: isis-wg@spider.juniper.net > Cc: dkatz@juniper.com > Subject: [Isis-wg] OSPF and IS-IS Scalability > > > Hi Dave OR if anybody else can clear this point .. > > I was going through your presentation archived at nanog where you have > compared the two link state protocols viz IS-IS and OSPF .. I am working on > IS-IS and am not much aware of OSPF and i was looking at the scalabilities > issues related to both of the protocols. There you have said that the > problem with OSPF is that in theory OSPF topology is limited to how much we > can stuff in the router LSA as each router gets one router LSA and it cant > be bigger than the biggest of the IP datagram (64K) and so can contain some > O(5000) links. > And the problem you said with IS-IS is the number of LSPs a single router > can issue which is 256. My question is that how can we say that in OSPF a > router has to stuff all its link database in ** one ** LSA. We have the > mechanism of I-bit and the M-bit wherein we control the division of a large > topological database description into multiple messages. > > Can you please throw some light on this. > > Thanks and Regards, > Manav Bhatia > "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From henk@Procket.com Mon Aug 20 23:08:35 2001 From: henk@Procket.com (Henk Smit) Date: Mon, 20 Aug 2001 15:08:35 -0700 (PDT) Subject: [Isis-wg] Initialisation question In-Reply-To: <20010819161418.A12747@juniper.net> from "Hannes Gredler" at Aug 19, 2001 04:14:18 PM Message-ID: <200108202208.f7KM8Zj14870@redd3174.procket.com> > | Sorry I should have said that I'd read that bit, but I'm still not > | clear exactly what happens. I guess that once two routers are adjacent > | they exchange CSNPs and then send PSNPs for > | any LSPs they are short of or are old? Correct? You have been reading rfc2328, haven't you. :-) > correct - for your convenience i have attached a tcpdump > to see what happens; Sorry, this is not correct. When a p2p adjacency comes up, both routers: 1) for each LSP in the LSPDB, set the SRM bit for this interface 2) send a CSNP (note, can consist of multiple packets) 3) wait for a while to give the other router some time to send a CSNP 4) hopefully receive a CNSP 5) when they receive the CSNP from the other side, clear the SRM bit for all LSPs that the other router already seems to have 6) send all LSPs that still have the SRM bit set If the CSNP from the other router gets lost somewhere, you will end up sending all LSPs. This might be some unnecessary work, but it will guarantee that the LSPDBs will be in sync. henk. > > | > | > | On Sun, 19 Aug 2001, Hannes Gredler wrote: > | > | > On Sun, Aug 19, 2001 at 09:44:34AM +0000, John Greenhalgh wrote: > | > | Hi, > | > | > | > | I'm looking through ISO 10589 and trying to understand how routers learn > | > | the link state database once adjacencies have been formed. For broadcast I > | > | gather that the CSNP from the DIS will initiate an update, but what about > | > | on point-to-point? Any pointers gladly received! > | > > | > john, > | > > | > take a look at paragraph 7.3.20.2.e where it says: > | > > | > [ ... ] CSNPs are transmited on > | > point-to-point circuits at initialisation. > | > > | > HTH, > | > > | > /hannes From henk@Procket.com Mon Aug 20 23:16:44 2001 From: henk@Procket.com (Henk Smit) Date: Mon, 20 Aug 2001 15:16:44 -0700 (PDT) Subject: [Isis-wg] OSPF and IS-IS Scalability In-Reply-To: <002701c12980$72129e20$da046c6b@Manav> from "Manav Bhatia" at Aug 20, 2001 07:30:05 PM Message-ID: <200108202216.f7KMGiL14888@redd3174.procket.com> This seems a question for the ospf mailinglist ..... In OSPF there is no limit to the number of LSAs in the LSDB. The I/M bit mechanism you describe helps in that respect. But the problem is that even though the LSDB can contain as many packets as you want, each packet is limited in size to 64K. The description of a single router *has* to be done in one single router LSA. That means the router LSA can not be bigger than 64KB, or you will not be able to send it to your neighbors. The only way an OSPF router can advertise which routers it is directly adjacent to, is by including those inside its router LSA. So if the router LSA can only be 64KB, the number of neighbors that can be advertised is limited. Henk. > Hi Manral, > I was able to do this calculation but what i wanted to ask was .. > Where is it mentioned that a router can originate only one-router LSA for > each area it is connected to .. as i understand during the database exchange > process the routers form a master/slave relationship, the master being first > to transmit. The master sends database description packets to the slave to > describe its database of link state information. Flags in database > description packets indicate whether they are form the master or slave (the > M/S bit), the first such packet (the I bit) and if there are more packets to > come (the M bit). Database exchange is complete when a router recieves a > database description packet from its neighbor with the M bit off. > > If this is so then there is no limit on the size of the LSAs an OSPF router > can advertise. > > I am copying it on to the list so that others can chime in and help us out > .. > > Regards, > Manav > > ----- Original Message ----- > From: "Manral, Vishwas" > To: "'Manav Bhatia'" > Cc: > Sent: Monday, August 20, 2001 5:02 PM > Subject: RE: [Isis-wg] OSPF and IS-IS Scalability > > > > Hi Manav/Dave, > > > > Well each router can originate only one router LSA for each area it is > > connected to. > > > > Each link in the router can take up at most 24 bytes. The maximum size of > a > > ospf LS-Update packet is 2^16, as the packet length of the ospf header is > 24 > > bytes. So the total number of links maximum is about 2^16/ 24 is > > approximately equal to 2730. > > > > However if we take the minimum link size per link in the router lsa, then > > the max is about 2730 * 2, or O(5000). > > > > Tell me Dave where i m wrong, or is it the IP packet we are talking about? > > > > Thanks, > > Vishwas > > > > > > > > -----Original Message----- > > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > > Sent: Monday, August 20, 2001 3:42 PM > > To: isis-wg@spider.juniper.net > > Cc: dkatz@juniper.com > > Subject: [Isis-wg] OSPF and IS-IS Scalability > > > > > > Hi Dave OR if anybody else can clear this point .. > > > > I was going through your presentation archived at nanog where you have > > compared the two link state protocols viz IS-IS and OSPF .. I am working > on > > IS-IS and am not much aware of OSPF and i was looking at the scalabilities > > issues related to both of the protocols. There you have said that the > > problem with OSPF is that in theory OSPF topology is limited to how much > we > > can stuff in the router LSA as each router gets one router LSA and it cant > > be bigger than the biggest of the IP datagram (64K) and so can contain > some > > O(5000) links. > > And the problem you said with IS-IS is the number of LSPs a single router > > can issue which is 256. My question is that how can we say that in OSPF a > > router has to stuff all its link database in ** one ** LSA. We have the > > mechanism of I-bit and the M-bit wherein we control the division of a > large > > topological database description into multiple messages. > > > > Can you please throw some light on this. > > > > Thanks and Regards, > > Manav Bhatia > > "C is not a big language, and is not well served by a big book." -- K&R2 > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From henk@Procket.com Mon Aug 20 23:37:58 2001 From: henk@Procket.com (Henk Smit) Date: Mon, 20 Aug 2001 15:37:58 -0700 (PDT) Subject: [Isis-wg] Doubts on Traffic Engineering In-Reply-To: from "Sachidananda K" at Aug 08, 2001 02:23:14 PM Message-ID: <200108202237.f7KMbwe14947@redd3174.procket.com> > Hello, > I have some doubts related to the traffic engineering related draft > associated with IS - IS. According to the Draft > draft-ietf-isis-traffic-03.txt, certain TLVs are modified to add Information > on traffic Engineering. > These are: > 1. IS Reachability TLV > 2. IP Reachability TLV > > My questions: > Queries Regarding the Extended IS Reachability TLV > ------------------------------------------------------------- > 1. Sub TLV: 3 Description: Administrative Group > Query: > a. Who assigns the Adminstrative Group for the Router. Is it a configurable > parameter ? Quote: 4.1 Sub-TLV 3: Administrative group (color, resource class) The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Answer: the network administrator. Note, "Adminstrative Group" is not something assigned to a router. It is assigned to a link. > b. Is this sub-TLV a must or optional ? All sub-TLVs of TLV22 are optional. > ------------------------------------------------------------- > 2. Sub TLV: 9, 10 & 11 > Query: > a. How do we come to know about the Maximum Link bandwidth of the Link ? It is defined by the layer2 properties of the link (example: ethernet is 10 Mbps), or configured by the network administator. > b. Are there any Functional Computation for this purpose ? No idea. Don't think so. > c. Or can this be included as a configurable Parameter? Yes. > d. Is this sub-TLV a must or optional ? All sub-TLVs of TLV22 are optional. > -------------------------------------------------------------- > 3. Sub TLV: 18 Description: Traffic Engineering Default metric > Query: > a. Is this a configurable Parameter ? Yes. > b. Is this sub-TLV optional or must ? All sub-TLVs of TLV22 are optional. > ------------------------------------------------------------ > Queries Regarding Extended IP Reachability TLV > Are there any sub-TLVs defined for this TLV after the publishing of the > draft ? Not that I know of. You can check the drafts yourself at: http://www.ietf.org/html.charters/isis-charter.html > ------------------------------------------------------------ > I was also wondering if the implementation compliant with this draft is to > transmit all the TLVs (IP internal reachibility, IP external reachibility > and IP extended reachibility) or should it transmit either 2 or 1 of these > depending on circumstances. Depends on circumstances. To make use of the wider metrics of the newer TLVs, all routers inside an area (or participating in the L2 backbone) must understand the new TLVs. Once all routers are upgraded and configured to understand the new TLVs, then there is no benefit anymore in advertising the older type TLVs. So typically you will see routers only advertise both old and new TLVs during a (short) transition period. > Can you please suggest any standard/draft that answers all my questions if > at all there is any. > > I shall be obliged to receive early response. > Thanking you in advance for all the responses. > Sachi It would be nice if you would ask these questions from an email account that shows us who you are. Hotmail addresses are a bit impersonal. Henk. From henk@Procket.com Mon Aug 20 23:46:57 2001 From: henk@Procket.com (Henk Smit) Date: Mon, 20 Aug 2001 15:46:57 -0700 (PDT) Subject: [Isis-wg] Routing or forwarding In-Reply-To: from "Jeff Parker" at Aug 10, 2001 10:07:37 AM Message-ID: <200108202246.f7KMkvg14996@redd3174.procket.com> > An alternative proposal to deal with the cell tax was > proposed which encodes both IP and ISIS traffic "raw", > and demultiplexes based on the difference between > the first nibble of the NLPID for ISIS (0x8) and > the version number for IP (0x4 or 0x6). This proposal > seems to have aged off the list, but gathered support > from several vendors. I wrote the draft for that proposal when I was at a previous job. At the time I contacted a few large ISPs that had ATM backbones. Nobody seemed to be really interested to save some bandwidth. Some because they had enough bandwidth, some because they were planning to move to PacketOverSonet (and MPLS). So I never commited the changes to my former employer's software. And because my idea had no been deployed, I let the draft die. Are there really people using this hack to run ISIS and IP over one aal5mux VC ? I'd be very interested to hear from them. Thanks, Henk. > > ps: Though I don't think the spec has anything against ISIS > > running over IP, but I doubt if there are any such > > implementations on the field. > > A bit of history on this... > > There -was- a draft proposal to run ISIS over IP. A number > of reasons were put forward for this, including allowing > larger LSPs (let IP handle fragmentation) and avoiding > something refered to as the "ATM cell tax" that came about > if you needed to multiplex two protocols over ATM, and the > resulting effect of requiring two ATM cells to hols a TCP > Ack. There were folks who implemented this encapsulation. > > The chief driving force for seemed to be avoiding > the cell tax: there were doubts that adding a second > layer of fragmentation was a good thing. > > An alternative proposal to deal with the cell tax was > proposed which encodes both IP and ISIS traffic "raw", > and demultiplexes based on the difference between > the first nibble of the NLPID for ISIS (0x8) and > the version number for IP (0x4 or 0x6). This proposal > seems to have aged off the list, but gathered support > from several vendors. > > - jeff parker > - axiowave networks From jparker@axiowave.com Mon Aug 20 23:57:40 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 20 Aug 2001 18:57:40 -0400 Subject: [Isis-wg] Routing or forwarding Message-ID: > > An alternative proposal to deal with the cell tax was > > proposed which ... demultiplexes based on the ... > > the first nibble > > I wrote the draft for that proposal when I was at a previous job. > At the time I contacted a few large ISPs that had ATM backbones. > Nobody seemed to be really interested to save some bandwidth. > Some because they had enough bandwidth, some because they were > planning to move to PacketOverSonet (and MPLS). > So I never commited the changes to my former employer's software. > And because my idea had no been deployed, I let the draft die. > > Are there really people using this hack to run ISIS and IP over > one aal5mux VC ? I'd be very interested to hear from them. > Thanks, > > Henk. Henk - And I was counting your former employer as one vendor! In a previous life, I heard from ISPs that were interested in removing the ATM cell tax, and suspect that concern remains. We all know that not everything that is requested and delivered is deployed. I have heard more than one vendor discuss your proposal with interest. I don't know of any deployments. - jeff parker - axiowave networks From Lakshminarayanan Rajamanickam" This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C12A4D.2C9CB380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, I have some doubts related to ISIS over NBMA networks: why doesn't ISIS support the *real* NBMA directly (not supporting p2mp! = but treating it as a collection of p2p circuits) are there any major(!) protocol changes need to be done to ISIS for = supporting NBMA p2mp? also i would like to know if there is any vendor supporting this = feature(p2mp support)? any response in this regard would be of great helpful thanks in advance, lakshminarayan r ------=_NextPart_000_0017_01C12A4D.2C9CB380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
I have some doubts related to ISIS = over NBMA=20 networks:
why doesn't ISIS support the *real* = NBMA directly=20 (not supporting p2mp! 
but treating it as a collection of p2p=20 circuits)
are there any major(!) = protocol changes=20 need to be done to ISIS for supporting NBMA p2mp?
also i would like to know=20 if there is any vendor supporting this feature(p2mp=20 support)?
any response in this regard would be of = great=20 helpful
 
thanks in advance,
lakshminarayan r
 
------=_NextPart_000_0017_01C12A4D.2C9CB380-- From dkatz@juniper.net Tue Aug 21 07:48:24 2001 From: dkatz@juniper.net (Dave Katz) Date: Mon, 20 Aug 2001 23:48:24 -0700 (PDT) Subject: [Isis-wg] P2MP In-Reply-To: <001a01c12a0a$1f4a7f20$bf086e0a@huawei.com> (eta_narayananl@partner.huawei.com) Message-ID: <200108210648.XAA19125@cirrus.juniper.net> ISIS predated much of the growth of NBMA networks. Having said that, I've always maintained that OSPF's P2MP mode is essentially a hack for vendors that did not allow the creation of virtual point-to-point interfaces over NBMA at the system level, since this is effectively what P2MP mode emulates. It would probably be a smaller hack to ISIS to support this than it was to OSPF (since ISIS couldn't care less about IP subnets, as far as its own operation is concerned) but there doesn't seem to be any real call for it. why doesn't ISIS support the *real* NBMA directly (not supporting p2mp! = but treating it as a collection of p2p circuits) are there any major(!) protocol changes need to be done to ISIS for = supporting NBMA p2mp? also i would like to know if there is any vendor supporting this = feature(p2mp support)? any response in this regard would be of great helpful From sachidananda_k@hotmail.com Tue Aug 21 12:03:39 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Tue, 21 Aug 2001 11:03:39 +0000 Subject: [Isis-wg] Protocol parameter. Message-ID: Hello, I have some questions related to the parameter minimumBroadcastLSPTransmissionInterval as described in section 7.3.15.6 of ISO 10589. Does this parameter corresponds to the frequency at which Link State Database is scanned for transmitting the LSP? That is every minimumBroadcastLSPTransmissionInterval duration the Link state database MUST be scanned for searching the LSP to be sent. Or it corresponds to the minimum time interval that needs to be allowed between consecutive packets (be it of any type) on a LAN interface? that is suppose on a particular interface (say A) if a LSP is sent, then for the next minimumBroadcastLSPTransmissionInterval duration no other packets of any type is to be sent on this interface. Apart from this, if the point 1 is not true, then is there any parameter that dictates the frequency at which the link state database is to be scanned for searching the LSP to be sent? Thanking in advance for all early responses that I receive. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From Internet-Drafts@ietf.org Tue Aug 21 12:27:11 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 21 Aug 2001 07:27:11 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-04.txt Message-ID: <200108211127.HAA05191@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 for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-traffic-04.txt Pages : 11 Date : 20-Aug-01 This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-04.txt 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-traffic-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-traffic-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: <20010820142205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-traffic-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-traffic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010820142205.I-D@ietf.org> --OtherAccess-- --NextPart-- From Manav Bhatia" Message-ID: <00a301c12a3f$6d2c98b0$da046c6b@Manav> Please find my comments inline .. > Does this parameter corresponds to the frequency at which Link State > Database is scanned for transmitting the LSP? That is every > minimumBroadcastLSPTransmissionInterval duration the Link state database > MUST be scanned for searching the LSP to be sent. Yes. Setting the SRMflag does not cause the LSP to be transmitted immediately. Instead the IS scans the database after every minimumBroadcastLSPTransmissionInterval and choses the LSP to be multicasted randomly. Once this is done the SRMflag for the corresponding LSP is cleared. Hope this helps, Manav Bhatia > > Or it corresponds to the minimum time interval that needs to be allowed > between consecutive packets (be it of any type) on a LAN interface? that is > suppose on a particular interface (say A) if a LSP is sent, then for the > next minimumBroadcastLSPTransmissionInterval duration no other packets of > any type is to be sent on this interface. > > Apart from this, if the point 1 is not true, then is there any parameter > that dictates the frequency at which the link state database is to be > scanned for searching the LSP to be sent? > > Thanking in advance for all early responses that I receive. > Sachi > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Internet-Drafts@ietf.org Tue Aug 21 14:45:58 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 21 Aug 2001 09:45:58 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-04.txt Message-ID: <200108211345.JAA12794@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 for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-traffic-04.txt Pages : 11 Date : 20-Aug-01 This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-04.txt 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-traffic-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-traffic-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: <20010820142205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-traffic-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-traffic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010820142205.I-D@ietf.org> --OtherAccess-- --NextPart-- From dkatz@juniper.net Tue Aug 21 16:04:28 2001 From: dkatz@juniper.net (Dave Katz) Date: Tue, 21 Aug 2001 08:04:28 -0700 (PDT) Subject: [Isis-wg] Protocol parameter. In-Reply-To: <00a301c12a3f$6d2c98b0$da046c6b@Manav> (mnvbhatia@yahoo.com) Message-ID: <200108211504.IAA19768@cirrus.juniper.net> Of course, any implementation that actually scans the database looking for things to send will probably have other intractable scaling problems as well. Unlike the OSPF spec, the ISIS spec provides very little implementation guidance (a feature, I believe, as it promotes actual thinking.) All that minimumBroadcastLSPTransmissionInterval does is ensure that the transmission rate is controlled so you don't swamp your receivers (as there is no flow control in the protocol.) X-Apparently-From: Reply-To: "Manav Bhatia" From: "Manav Bhatia" Cc: References: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 18:16:16 +0530 Please find my comments inline .. > Does this parameter corresponds to the frequency at which Link State > Database is scanned for transmitting the LSP? That is every > minimumBroadcastLSPTransmissionInterval duration the Link state database > MUST be scanned for searching the LSP to be sent. Yes. Setting the SRMflag does not cause the LSP to be transmitted immediately. Instead the IS scans the database after every minimumBroadcastLSPTransmissionInterval and choses the LSP to be multicasted randomly. Once this is done the SRMflag for the corresponding LSP is cleared. Hope this helps, Manav Bhatia > > Or it corresponds to the minimum time interval that needs to be allowed > between consecutive packets (be it of any type) on a LAN interface? that is > suppose on a particular interface (say A) if a LSP is sent, then for the > next minimumBroadcastLSPTransmissionInterval duration no other packets of > any type is to be sent on this interface. > > Apart from this, if the point 1 is not true, then is there any parameter > that dictates the frequency at which the link state database is to be > scanned for searching the LSP to be sent? > > Thanking in advance for all early responses that I receive. > Sachi > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From Manav Bhatia" Message-ID: <010201c12a54$3097d1c0$da046c6b@Manav> > Of course, any implementation that actually scans the database looking > for things to send will probably have other intractable scaling problems > as well. Why so ?? Is it because .. if there is a large toplogy then scanning the entire database will take up a lot of time .. which is not required out of a routing protocol because of the convergence issues .. Regards, Manav > > Unlike the OSPF spec, the ISIS spec provides very little implementation > guidance (a feature, I believe, as it promotes actual thinking.) > > All that minimumBroadcastLSPTransmissionInterval does is ensure that > the transmission rate is controlled so you don't swamp your receivers > (as there is no flow control in the protocol.) > > X-Apparently-From: > Reply-To: "Manav Bhatia" > From: "Manav Bhatia" > Cc: > References: > Organization: Samsung India Operations > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 5.50.4133.2400 > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Tue, 21 Aug 2001 18:16:16 +0530 > > Please find my comments inline .. > > > Does this parameter corresponds to the frequency at which Link State > > Database is scanned for transmitting the LSP? That is every > > minimumBroadcastLSPTransmissionInterval duration the Link state database > > MUST be scanned for searching the LSP to be sent. > > Yes. Setting the SRMflag does not cause the LSP to be transmitted > immediately. Instead the IS scans the database after every > minimumBroadcastLSPTransmissionInterval and choses the LSP to be multicasted > randomly. Once this is done the SRMflag for the corresponding LSP is > cleared. > > Hope this helps, > Manav Bhatia > > > > > Or it corresponds to the minimum time interval that needs to be allowed > > between consecutive packets (be it of any type) on a LAN interface? that > is > > suppose on a particular interface (say A) if a LSP is sent, then for the > > next minimumBroadcastLSPTransmissionInterval duration no other packets of > > any type is to be sent on this interface. > > > > Apart from this, if the point 1 is not true, then is there any parameter > > that dictates the frequency at which the link state database is to be > > scanned for searching the LSP to be sent? > > > > Thanking in advance for all early responses that I receive. > > Sachi > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From dkatz@juniper.net Tue Aug 21 16:16:24 2001 From: dkatz@juniper.net (Dave Katz) Date: Tue, 21 Aug 2001 08:16:24 -0700 (PDT) Subject: [Isis-wg] Protocol parameter. In-Reply-To: <010201c12a54$3097d1c0$da046c6b@Manav> (mnvbhatia@yahoo.com) Message-ID: <200108211516.IAA19811@cirrus.juniper.net> Why so ?? Is it because .. if there is a large toplogy then scanning the entire database will take up a lot of time .. which is not required out of a routing protocol because of the convergence issues .. Basically. From marelines@yahoo.com Tue Aug 21 17:21:16 2001 From: marelines@yahoo.com (Mareline Sheldon) Date: Tue, 21 Aug 2001 21:51:16 +0530 Subject: [Isis-wg] ISH PDUs ? Message-ID: <003301c12a5d$502658a0$da046c6b@Manav> Hi, I am supposed to write an implementation of integrated IS-IS which i know i will be running over tcp/ip networks only. Knowing this, do i need to issue ISHs .. for i know all my end systems (if any) have to be manually configured ? Regards, Mary _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From chris_isis@hotmail.com Tue Aug 21 19:09:21 2001 From: chris_isis@hotmail.com (Chris isis) Date: Tue, 21 Aug 2001 19:09:21 +0100 Subject: [Isis-wg] Redistribution of routes from ISIS to OSPF Message-ID: I have not been able to identify a vendor that offers redistribution of IP routes between Integrated IS-IS and OSPF. Have I not looked hard enough? or is it particularly difficult, or even impossible to redistribute routes from OSPF into Integrated IS-IS and the other way around. Thanks, Chris. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From sprevidi@cisco.com Tue Aug 21 19:38:07 2001 From: sprevidi@cisco.com (stefano previdi) Date: Tue, 21 Aug 2001 20:38:07 +0200 Subject: [Isis-wg] Redistribution of routes from ISIS to OSPF In-Reply-To: Message-ID: <4.3.2.7.2.20010821203310.033cdf60@brussels.cisco.com> At 20:09 21/08/2001, Chris isis wrote: >I have not been able to identify a vendor that offers redistribution of IP >routes between Integrated IS-IS and OSPF. > >Have I not looked hard enough? I believe so....I know at least one vendor doing it and doubt it's the only one... >or is it particularly difficult, or even impossible to redistribute routes >from OSPF into Integrated IS-IS and the other way around. whoever implements routing protocols should be able to allow redistribution between them. s. >Thanks, Chris. > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From tgol@laurelnetworks.com Tue Aug 21 20:10:57 2001 From: tgol@laurelnetworks.com (Tayfun Gol) Date: Tue, 21 Aug 2001 15:10:57 -0400 Subject: [Isis-wg] Redistribution of routes from ISIS to OSPF References: <4.3.2.7.2.20010821203310.033cdf60@brussels.cisco.com> Message-ID: <3B82B241.409F1B25@laurelnetworks.com> stefano previdi wrote: > At 20:09 21/08/2001, Chris isis wrote: > >I have not been able to identify a vendor that offers redistribution of IP > >routes between Integrated IS-IS and OSPF. > > > >Have I not looked hard enough? > > I believe so....I know at least one vendor doing it > and doubt it's the only one... > Well, I know at least one more.. ;-) In general, redistribution of routes should be a simple matter of inter-protocol policy configuration. Tayfun Gol > > >or is it particularly difficult, or even impossible to redistribute routes > >from OSPF into Integrated IS-IS and the other way around. > > whoever implements routing protocols should be able to > allow redistribution between them. > > s. > > >Thanks, Chris. > > > >_________________________________________________________________ > >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > >_______________________________________________ > >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 cast@allegronetworks.com Tue Aug 21 21:13:55 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Tue, 21 Aug 2001 13:13:55 -0700 Subject: [Isis-wg] New 10589 spec, PtoP and ISHs Message-ID: >From the original 10589, routers might be able to get around sending ISHs on ptop circuits. The original states routers should transmit an IIH immediately upon circuit startup, and so an implementation need not send an ISH to get the peer IS to start IIH transmission. New 10589, however, removes this wording, and now it appears routers require receipt of an ISH prior to sending the first IIH. Yet if there are old implementations that don't send ISHs, ptop adjacencies won't come up with strict new implementations. Does anyone know whether there are deployed ISIS implementations that don't send ISHs on ptop circuits? Thanks, --Neal From ginsberg@pluris.com Tue Aug 21 21:39:46 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Tue, 21 Aug 2001 13:39:46 -0700 Subject: [Isis-wg] New 10589 spec, PtoP and ISHs Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A63C@avalon.pluris.com> This issue is a confusing one, some of which is due to the fact that the original wording in ISO 10589:1992 was revised by Technical Corrigendum I (published in 1993), but because many people do not have ready access to the TCs, they rely on the uncorrected original text. In fact, the original intent was made clear in TC1 by adding: "An IS shall cause ISO 9542 to send an ISH PDU whenever a point-to-point circuit is first enabled." and then changing the original text in 8.2.3a (which Neal refers to in stating that an IIH was supposed to be sent when the circuit was first enabled) to read: "a)the IS receives an ISH PDU" So the original intent was to wait for receipt of an ISH before beginning to send IIHs. The latest ISO 10589 draft further clarifies this by specifying that ISH's should continue to be sent periodically until the adjacency reaches the UP state. This is a logical requirement discovered when implementing that was not clearly stated even in the TC1 changes. In an IP only IS-IS implementation, the use of ISH's is an anachronism. Many implementations relax the requirements, at least on reception, so that receiving an ISH is not required. In following the old axiom of being "strict in what you send and generous in what you receive", a robust implementation should send ISHs until the adjacency is up, but allow (at least for IP operation) the adjacency to come up without ever seeing an ISH. This is easily achieved by starting to send IIHs when you first receive an IIH. I can tell you from first hand experience that there are indeed implementations out there which do not send ISHs. Les > -----Original Message----- > From: Neal Castagnoli [mailto:cast@allegronetworks.com] > Sent: Tuesday, August 21, 2001 1:14 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] New 10589 spec, PtoP and ISHs > > > > From the original 10589, routers might be able to get around > sending ISHs on > ptop circuits. The original states routers should transmit an IIH > immediately upon circuit startup, and so an implementation > need not send an > ISH to get the peer IS to start IIH transmission. New 10589, however, > removes this wording, and now it appears routers require > receipt of an ISH > prior to sending the first IIH. > > Yet if there are old implementations that don't send ISHs, > ptop adjacencies > won't come up with strict new implementations. Does anyone > know whether > there are deployed ISIS implementations that don't send ISHs on ptop > circuits? > > Thanks, > > --Neal > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From dkatz@juniper.net Tue Aug 21 21:49:11 2001 From: dkatz@juniper.net (Dave Katz) Date: Tue, 21 Aug 2001 13:49:11 -0700 (PDT) Subject: [Isis-wg] Redistribution of routes from ISIS to OSPF In-Reply-To: (chris_isis@hotmail.com) Message-ID: <200108212049.NAA20537@cirrus.juniper.net> Certainly cisco and Juniper both do it; presumably anybody that does route redistribution ought to be able to (nothing special here.) X-Originating-IP: [47.211.0.13] From: "Chris isis" Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Aug 2001 18:09:21.0957 (UTC) FILETIME=[6736E550:01C12A6C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 19:09:21 +0100 I have not been able to identify a vendor that offers redistribution of IP routes between Integrated IS-IS and OSPF. Have I not looked hard enough? or is it particularly difficult, or even impossible to redistribute routes from OSPF into Integrated IS-IS and the other way around. Thanks, Chris. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From Lakshminarayanan Rajamanickam" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C12B18.293F2C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Is Mesh Groups concept (Rfc-2973) applied only to NBMA circuits or=20 It can be applied for normal serial P2P links also ? (a large set of p2p = links that results in a full-mesh!) thanks in advance, lakshminarayan r ------=_NextPart_000_000F_01C12B18.293F2C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
Is Mesh Groups concept (Rfc-2973) = applied only=20 to NBMA circuits or
It can be applied for normal = serial P2P links=20 also ? (a large set of p2p links that results in a = full-mesh!)
 
thanks in advance,
lakshminarayan = r
------=_NextPart_000_000F_01C12B18.293F2C60-- From jparker@axiowave.com Wed Aug 22 15:02:26 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 22 Aug 2001 10:02:26 -0400 Subject: [Isis-wg] RE: Mesh Groups Message-ID: > Is Mesh Groups concept (Rfc-2973) applied only to > NBMA circuits or It can be applied for normal > serial P2P links also ? (a large set of p2p > links that results in a full-mesh!) If you just subscribed to this list, then you missed a discussion of the history behind why IS-IS does not support NBMA. The normal application of mesh groups is a series of circuits that approximates a full mesh. That is, where you are liable to hear about the same LSP from multiple sources. - jeff parker - axiowave networks - I can't remember if I'm the good twin or the evil one. From cast@allegronetworks.com Wed Aug 22 21:18:10 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Wed, 22 Aug 2001 13:18:10 -0700 Subject: [Isis-wg] Route selection Message-ID: We ran a battery of route selection tests against a couple of common implementations. One of the implementations in recent versions follows the RFC 2966 route selection precedence, but in older (deployed) versions treats the metrics as 8 bits wide. The other treats external metric, level 2, and external route (TLV 130) at an absolute lower precedence than L1 internal routes, regardless of the disposition of the up/down bit. Given the inconsistent way these common implementations perform route selection and the attendent routing loops that can form, does it make sense to avoid use of external routes (TLV 130) altogether? Does anyone know of deployed instances in which the use of external routes is required? ----------------- Example: Routing loop caused by inconsistent route selection. C1 is an implementation that absolutely prefers L1 internal routes, C2 chooses based on least cost. 10 10 10 A ---- C1 --- C2 --- B If A advertises a.b.c.d as an external route of cost 10, but B advertises the same route as internal at cost 30, then C2 will use the cheaper route to a.b.c.d through C1 to A at a total cost of 30, but C1 will prefer the more costly route through C2 to B at 50 since it prefers internal routes to external routes regardless of their cost. From Manav Bhatia" A single IS can at most issue 256 LSPs and it has to pack everything it wants to advertise into this much. Are there any hacks wherein i may be able to send more information than i what i am capable of using my 256 LSPs. I believe one such mechanism is by faking a LAN .. but i am not sure as to how it may work. Can anybody please explain ? Thanks and Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From aravindravikumar@yahoo.com Thu Aug 23 11:32:55 2001 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Thu, 23 Aug 2001 03:32:55 -0700 (PDT) Subject: [Isis-wg] Protocol parameter. In-Reply-To: Message-ID: <20010823103255.8412.qmail@web11205.mail.yahoo.com> --0-1920019959-998562775=:8404 Content-Type: text/plain; charset=us-ascii Hi Sachidananda, It definitely corresponds to the minimum time interval that needs to be allowed between consecutive LSPs on a LAN interface. But what other significance this 32 millisecond interval has got depends on which of of the following two views hold good. I am not sure about which one is correct and Iam also eager to know Approach A There are certain conditions that make an LSP qualified to be sent. This applies to individual LSPs on per circuit basis and is mainly related to the timing constraint minimumLSPTransmissionInterval. For a large database it is highly probable that at any given time there are LSPs in the database qualified to be send. In ideal case we would never want to hold back an LSP which is qualified to be sent any further. The speed with which we discover a ready LSP is limited by the speed with which we scan the database. Ideally we would like to continuously scan the database and discover ready LSPs as soon as possible. There is a constraint that limits the speed with which you can send the LSPs in the same LAN, even if you have found that it is ready to be transmitted. The minimumLSPbroadcast interval is the minimum interval that you should have between two LSPs sent on a particular LAN. This means that there is no use in finding out ready LSPs more frequent than this, since you cannot send it more frequently. So an efficient implementation should scan the LSDB once in 32 milliseconds, even if its highly demanding Approach B As said in section 7.3.15.5 of ISO 10589, If we consider an individual LSP it should be kept with in the router's memory without propagating for atleast minimumLSPTransmissionInterval and no more than twice this value (between 5and 10 seconds). This can be achieved if we scan the database once in each 5 seconds. For a point to point link transmit all the selected LSPs. But in case of broadcast network, take into consideration the 32 millisecond interval between LSP transmission. Even if the router finds out that there are a number of LSPs, keep them in queue and send them separated by 32 milliseconds. The main question here is whether the interpretation that a router can keep an individual LSP between 5 and 10 second is correct or not .If we take an average of 7.5 seconds, a topology change will take more than 75 seconds to travel 10 links. This also puts restriction on scalability.But the advantage is that you need need to scan the whole database once in 5 seconds only, rather than 32ms Aravind Sachidananda K wrote: Hello, I have some questions related to the parameter minimumBroadcastLSPTransmissionInterval as described in section 7.3.15.6 of ISO 10589. Does this parameter corresponds to the frequency at which Link State Database is scanned for transmitting the LSP? That is every minimumBroadcastLSPTransmissionInterval duration the Link state database MUST be scanned for searching the LSP to be sent. Or it corresponds to the minimum time interval that needs to be allowed between consecutive packets (be it of any type) on a LAN interface? that is suppose on a particular interface (say A) if a LSP is sent, then for the next minimumBroadcastLSPTransmissionInterval duration no other packets of any type is to be sent on this interface. Apart from this, if the point 1 is not true, then is there any parameter that dictates the frequency at which the link state database is to be scanned for searching the LSP to be sent? Thanking in advance for all early responses that I receive. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg --------------------------------- Do You Yahoo!? Make international calls for as low as $0.04/minute with Yahoo! Messenger. --0-1920019959-998562775=:8404 Content-Type: text/html; charset=us-ascii

 

Hi Sachidananda,

It definitely corresponds to the minimum time interval that needs to be allowed between consecutive LSPs on a LAN interface. But what other significance this 32 millisecond interval has got depends on which of of the following two views hold good. I am not sure about which one is correct and Iam also eager to know

Approach A

          There are certain conditions that make an LSP qualified to be sent. This applies to individual LSPs on per circuit basis and is mainly related to the timing constraint minimumLSPTransmissionInterval. For a large database it is highly probable that at any given time there are LSPs in the database qualified to be send. In ideal case we would never want to hold back an LSP which is qualified to be sent any further. The speed with which we discover a ready LSP is limited by the speed with which we scan the database. Ideally we would like to continuously scan the database and discover ready LSPs as soon as possible. There is a constraint that limits the speed with which you can send the LSPs in the same LAN, even if you have found that it is ready to be transmitted. The minimumLSPbroadcast interval is the minimum interval that you should have between two LSPs sent on a particular LAN. This means that there is no use in finding out ready LSPs more frequent than this, since you cannot send it more frequently. So an efficient implementation should scan the LSDB once in 32 milliseconds, even if its highly demanding

Approach B

As said in section 7.3.15.5 of ISO 10589, If we consider an individual LSP it should be kept with in the router's memory without propagating for atleast minimumLSPTransmissionInterval and no more than twice this value (between 5and 10 seconds). This can be achieved if we scan the database once in each 5 seconds. For a point to point link transmit all the selected LSPs. But in case of broadcast network, take into consideration the 32 millisecond interval between LSP transmission. Even if the router finds out that there are a number of LSPs, keep them in queue and send them separated by 32 milliseconds. The main question here is whether the interpretation that a router can keep an individual LSP between 5 and 10 second is correct or not .If we take an average of 7.5 seconds, a topology change will take more than 75 seconds to travel 10 links. This also puts restriction on scalability.But the advantage is that you need need to scan the whole database once in 5 seconds only, rather than 32ms

Aravind

 

  Sachidananda K <sachidananda_k@hotmail.com> wrote:

Hello,

I have some questions related to the parameter
minimumBroadcastLSPTransmissionInterval as described in section 7.3.15.6 of
ISO 10589.

Does this parameter corresponds to the frequency at which Link State
Database is scanned for transmitting the LSP? That is every
minimumBroadcastLSPTransmissionInterval duration the Link state database
MUST be scanned for searching the LSP to be sent.

Or it corresponds to the minimum time interval that needs to be allowed
between consecutive packets (be it of any type) on a LAN interface? that is
suppose on a particular interface (say A) if a LSP is sent, then for the
next minimumBroadcastLSPTransmissionInterval duration no other packets of
any type is to be sent on this interface.

Apart from this, if the point 1 is not true, then is there any parameter
that dictates the frequency at which the link state database is to be
scanned for searching the LSP to be sent?

Thanking in advance for all early responses that I receive.
Sachi

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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


Do You Yahoo!?
Make international calls for as low as $0.04/minute with Yahoo! Messenger. --0-1920019959-998562775=:8404-- From amir@cwnt.com Thu Aug 23 12:38:25 2001 From: amir@cwnt.com (Amir Hermelin) Date: Thu, 23 Aug 2001 14:38:25 +0300 Subject: [Isis-wg] More than 256 LSPs Message-ID: Manav, check out this draft http://www.ietf.org/internet-drafts/draft-hermelin-ext-lsp-frags-02.txt It attempts to solve the problem and remove the 256 limit. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Thursday, August 23, 2001 5:54 AM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] More than 256 LSPs > > > A single IS can at most issue 256 LSPs and it has to pack > everything it > wants to advertise into this much. Are there any hacks > wherein i may be able > to send more information than i what i am capable of using my > 256 LSPs. I > believe one such mechanism is by faking a LAN .. but i am not > sure as to how > it may work. > Can anybody please explain ? > > Thanks and Regards, > Manav Bhatia > > "C is not a big language, and is not well served by a big > book." -- K&R2 > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From prz@redback.com Thu Aug 23 20:16:45 2001 From: prz@redback.com (Tony Przygienda) Date: Thu, 23 Aug 2001 12:16:45 -0700 Subject: [Isis-wg] Meeting minutes ... Message-ID: <3B85569D.40E1F15D@redback.com> For London from my sketchy notes since I didn't get the notes that Alex was taking yet . Administrativa . isis-transient has been updated and called again, should go to RFC now . isis-3way passed last call, will need addition of TLV codepoint consideration for RFC . isis-snp-checksum same, TLV assignment conflict has been resolved . isis-ipv6 same . large ether frames in editing, under discussion . Presentations . m-isis: Mike had some questions on flooding optimizations mentioned, the discussion that came out of it basically lead to agreement that it's mostly a dangerous idea not worth pursuiting and due to the lack of specifics in the draft lacked in quality. IPv6 has been mentioned and authors answered that the problem is being ignored at the moment due to the lack of requirements from the ISP side. . hermelin-ext-lsp-frags: Mike & Stefano thought that it would make more sense to have a method to issue LSPs > 255 under different system ID and tie those together using some proxy TLV with the original node, concern with presented proposal was that without SPF changes it only presents a restricted functionality (leaf-node). Motion to make it workgroup document. Agreement was that within 8 weeks Stefano & Mike submit an alternative draft and things will be discussed further or merged or otherwise hermelin draft becomes a WG item. . ietf-isis-transient: Danny did not show up to present . shand-isis-restart: After presentation a discussion started WHY it should be done at all and enough reasons have been found to make it a wg item (backups, software upgrades) . ietf-ospf-p2p: Dino brought up some simplifying ideas on the ISIS side that have been considered but would make layer violations worse (taking MAC directly from hellos). Request to make it working group document has been delayed and should be posted by the authors to the mailing list for a wider discussion. . auth-anti-replay: Request has been made to make it a workgroup document. No comment from the room due to the early morning hour and jetlag probably. Tony came up to the mike and brought up several reasons why it does not make sense to accept the draft as it is. Either ISPs with burning desire for that partial solutions should be vocal or we should spend serious time on a clean security solution for ISIS that would encompass proper nonce negotiation for replay protection, source authentication and other best-known-practices. Up to Alex to see whether he wants to pursuit either path. . tlv-codepoints: All drafts taking new TLV values should please refer to that draft -- tony From dino@procket.com Thu Aug 23 21:05:46 2001 From: dino@procket.com (Dino Farinacci) Date: Thu, 23 Aug 2001 13:05:46 -0700 Subject: [Isis-wg] Meeting minutes ... In-Reply-To: <3B85569D.40E1F15D@redback.com> (message from Tony Przygienda on Thu, 23 Aug 2001 12:16:45 -0700) References: <3B85569D.40E1F15D@redback.com> Message-ID: <200108232005.NAA06495@dino-pc.procket.com> >> . ietf-ospf-p2p: Dino brought up some simplifying ideas on the >> ISIS side that have >> been considered but would make layer violations worse (taking >> MAC directly from This layer violation is already in IS-IS when processing LAN IIH's. Dino From prz@redback.com Thu Aug 23 21:52:46 2001 From: prz@redback.com (Tony Przygienda) Date: Thu, 23 Aug 2001 13:52:46 -0700 Subject: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <200108232005.NAA06495@dino-pc.procket.com> Message-ID: <3B856D1D.B159A2E3@redback.com> Dino Farinacci wrote: > >> . ietf-ospf-p2p: Dino brought up some simplifying ideas on the > >> ISIS side that have > >> been considered but would make layer violations worse (taking > >> MAC directly from > > This layer violation is already in IS-IS when processing LAN IIH's. > layer violation meaning that ISIS would probably take to ARP tables to teach them the MAC address of the neighbor if such a scheme is employed (and proxy ARP's not being run) ... That is more than the usual MAC-on-hellos layer violation ;-) -- tony From vgill@vijaygill.com Thu Aug 23 22:14:13 2001 From: vgill@vijaygill.com (Vijay Gill) Date: 23 Aug 2001 21:14:13 +0000 Subject: [Isis-wg] Meeting minutes ... In-Reply-To: Tony Przygienda's message of "Thu, 23 Aug 2001 12:16:45 -0700" References: <3B85569D.40E1F15D@redback.com> Message-ID: <7msneieaxm.fsf@challah.msrl.com> Tony Przygienda writes: > For London from my sketchy notes since I didn't get the notes that Alex > was taking yet > . shand-isis-restart: After presentation a discussion started WHY > > it should be done at> all and enough reasons have been found to > make it a wg item (backups, software upgrades) I would strongly suggest checking the archives of the OSPF wg mailing list (http://discuss.microsoft.com/archives/ospf.html) as there has been significant discussion on a somewhat similar topic. > . auth-anti-replay: Request has been made to make it a workgroup > document. No comment from the room due to the early morning hour > and jetlag probably. Tony came up to the mike and brought up > several reasons why it does not make sense to accept the draft > as it is. Either ISPs with burning desire for that partial > solutions should be vocal or we should spend serious time on a > clean security solution for ISIS that would encompass proper > nonce negotiation for replay protection, source authentication > and other best-known-practices. Up to Alex to see whether he > wants to pursuit either path. In general, the entire aspect of control plane security in IP networks has been of secondary importance (maybe because it is hard to get the control plane working to our satisfaction. The codebase probably comprises as good an attack on our infrastructure as anything the black hats could come up with). That being said, it is probably of use to pursue _a_ solution, and a solution that gets us most of the way there and is codeable and deployable is of more use than the all singing, all dancing undeployable solution which introduces significant amounts of codebase upheaval. /vijay From dino@procket.com Thu Aug 23 22:16:45 2001 From: dino@procket.com (Dino Farinacci) Date: Thu, 23 Aug 2001 14:16:45 -0700 Subject: [Isis-wg] Meeting minutes ... In-Reply-To: <3B856D1D.B159A2E3@redback.com> (message from Tony Przygienda on Thu, 23 Aug 2001 13:52:46 -0700) References: <3B85569D.40E1F15D@redback.com> <200108232005.NAA06495@dino-pc.procket.com> <3B856D1D.B159A2E3@redback.com> Message-ID: <200108232116.OAA07106@dino-pc.procket.com> >> layer violation meaning that ISIS would probably take to ARP tables to >> teach them >> the MAC address of the neighbor if such a scheme is employed (and proxy >> ARP's not being >> run) ... That is more than the usual MAC-on-hellos layer violation ;-) IS-IS deals with layer-2 addresses. If the implementation chooses to add ARP entries, it is a local matter. Just like Russ said. A traditional "layer violation" means a layer-n protocol looks at a layer-(n-1) protocol's header. Dino From prz@redback.com Thu Aug 23 22:01:15 2001 From: prz@redback.com (Tony Przygienda) Date: Thu, 23 Aug 2001 14:01:15 -0700 Subject: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <200108232005.NAA06495@dino-pc.procket.com> <3B856D1D.B159A2E3@redback.com> <200108232116.OAA07106@dino-pc.procket.com> Message-ID: <3B856F1A.87B58E10@redback.com> Dino Farinacci wrote: > >> layer violation meaning that ISIS would probably take to ARP tables to > >> teach them > >> the MAC address of the neighbor if such a scheme is employed (and proxy > >> ARP's not being > >> run) ... That is more than the usual MAC-on-hellos layer violation ;-) > > IS-IS deals with layer-2 addresses. If the implementation chooses to add > ARP entries, it is a local matter. Just like Russ said. > > A traditional "layer violation" means a layer-n protocol looks at a > layer-(n-1) protocol's header. ok, let's call it 'protocol-crosstalk' ;-) then ... -- tony From rja@inet.org Thu Aug 23 23:59:58 2001 From: rja@inet.org (RJ Atkinson) Date: Thu, 23 Aug 2001 18:59:58 -0400 Subject: [Isis-wg] Meeting minutes ... In-Reply-To: <7msneieaxm.fsf@challah.msrl.com> References: <3B85569D.40E1F15D@redback.com> Message-ID: <5.1.0.14.2.20010823185647.009f96b0@10.30.15.2> At 17:14 23/08/01, Vijay Gill wrote: >> . auth-anti-replay: Request has been made to make it a workgroup >> document. No comment from the room due to the early morning hour >> and jetlag probably. Tony came up to the mike and brought up >> several reasons why it does not make sense to accept the draft >> as it is. Either ISPs with burning desire for that partial >> solutions should be vocal or we should spend serious time on a >> clean security solution for ISIS that would encompass proper >> nonce negotiation for replay protection, source authentication >> and other best-known-practices. Up to Alex to see whether he >> wants to pursuit either path. > >In general, the entire aspect of control plane security in IP networks >has been of secondary importance (maybe because it is hard to get the >control plane working to our satisfaction. The codebase probably >comprises as good an attack on our infrastructure as anything the >black hats could come up with). That being said, it is probably of >use to pursue _a_ solution, and a solution that gets us most of the >way there and is codeable and deployable is of more use than the all >singing, all dancing undeployable solution which introduces >significant amounts of codebase upheaval. Vijay, My apologies for my being dim-witted. I'm having trouble interpreting your remarks above: Are you saying you'd be happy with just documenting the already widely deployed (but not yet RFC) IS-IS HMAC-MD5 approach in the current tli draft as an RFC ? XOR Are you saying that you want to forget the installed base, open the hood, tinker, and do something else ? Thanks, Ran rja@inet.org From prz@redback.com Fri Aug 24 00:25:26 2001 From: prz@redback.com (Tony Przygienda) Date: Thu, 23 Aug 2001 16:25:26 -0700 Subject: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> Message-ID: <3B8590E6.17BE6D3A@redback.com> Vijay Gill wrote: > Tony Przygienda writes: > > > For London from my sketchy notes since I didn't get the notes that Alex > > was taking yet > > > . shand-isis-restart: After presentation a discussion started WHY > > > it should be done at> all and enough reasons have been found to > > make it a wg item (backups, software upgrades) > > I would strongly suggest checking the archives of the OSPF wg mailing > list (http://discuss.microsoft.com/archives/ospf.html) as there has > been significant discussion on a somewhat similar topic. aware of that, was not hurting repeating the arguments since some of the crowd does not overlap between ISIS and OSPF ;-) > > . auth-anti-replay: Request has been made to make it a workgroup > > document. No comment from the room due to the early morning hour > > and jetlag probably. Tony came up to the mike and brought up > > several reasons why it does not make sense to accept the draft > > as it is. Either ISPs with burning desire for that partial > > solutions should be vocal or we should spend serious time on a > > clean security solution for ISIS that would encompass proper > > nonce negotiation for replay protection, source authentication > > and other best-known-practices. Up to Alex to see whether he > > wants to pursuit either path. > > In general, the entire aspect of control plane security in IP networks > has been of secondary importance (maybe because it is hard to get the > control plane working to our satisfaction. The codebase probably > comprises as good an attack on our infrastructure as anything the > black hats could come up with). That being said, it is probably of > use to pursue _a_ solution, and a solution that gets us most of the > way there and is codeable and deployable is of more use than the all > singing, all dancing undeployable solution which introduces > significant amounts of codebase upheaval. Vijay, nice tirade but pls read Alex's draft and tell me whehter you desperately need his-flavor-of-partial-replay-protection today. If you do, we make the draft working group item and we'll make sure that you deployed it after the vendors rolled it. If you (as placeholder for any major ISP) don't need it desperately today, it is not worth doing and we should concentrate on a proper framework (if we want to do it at all) that won't be openly picked apart at the mike by some security wizard 6 months from now. I saw couple of chairs standing with their pants down in such a situation and it is mucho embarassing. The only excuses are 'it was desperately needed to be deployed then so little hacky was fine' (case HMAC today) or 'we did thorough work and took into account all the then-known security paranoia'. Anything else does not stand the test of time and based on that observations I was trying to steer the work ... -- tony From vgill@vijaygill.com Fri Aug 24 02:58:38 2001 From: vgill@vijaygill.com (Vijay Gill) Date: 24 Aug 2001 01:58:38 +0000 Subject: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> Message-ID: <7md75mxlpt.fsf@challah.msrl.com> Tony Przygienda writes: > Vijay Gill wrote: > aware of that, was not hurting repeating the arguments since some of > the crowd does not overlap between ISIS and OSPF ;-) Just thought I'd err on the side of caution. The OSPF discussions were not pretty at all. > > black hats could come up with). That being said, it is probably of > > use to pursue _a_ solution, and a solution that gets us most of the > > way there and is codeable and deployable is of more use than the all > > singing, all dancing undeployable solution which introduces > > significant amounts of codebase upheaval. > Vijay, nice tirade but pls read Alex's draft and tell me whehter you > desperately need his-flavor-of-partial-replay-protection today. Thanks to Ran (rja@inet.org) for clearing up some errors. The HMAC solution as proposed by tli appears to be sufficient for now. > vendors rolled it. If you (as placeholder for any major ISP) don't > need it desperately today, it is not worth doing and we should > concentrate on a proper framework (if we want to do it at all) that > won't be openly picked apart at the mike by some security wizard 6 > months from now. I saw couple of chairs standing with their pants A secure solution is needed, I am not sure if the costs of imposing a very complete, unbreakable solution are worth the return given _current_ and past performance [ insert past performance is not a guarantee of future result boilerplate here ] > excuses are 'it was desperately needed to be deployed then so little > hacky was fine' (case HMAC today) or 'we did thorough work and took > into account all the then-known security paranoia'. Anything else > does not stand the test of time and based on that observations I was > trying to steer the work ... I'm basing this on a mandate after an incident some time ago. Senior mangement said 'you will run authentication on all routing protocols or you will find another job' Others mileage may and probably should, vary. /vijay From prz@redback.com Fri Aug 24 07:35:37 2001 From: prz@redback.com (Tony Przygienda) Date: Thu, 23 Aug 2001 23:35:37 -0700 Subject: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> <7md75mxlpt.fsf@challah.msrl.com> Message-ID: <3B85F5B8.C4BBFE02@redback.com> Vijay Gill wrote: > Tony Przygienda writes: > > > Vijay Gill wrote: > > > aware of that, was not hurting repeating the arguments since some of > > the crowd does not overlap between ISIS and OSPF ;-) > > Just thought I'd err on the side of caution. The OSPF discussions > were not pretty at all. ok ... > > > black hats could come up with). That being said, it is probably of > > > use to pursue _a_ solution, and a solution that gets us most of the > > > way there and is codeable and deployable is of more use than the all > > > singing, all dancing undeployable solution which introduces > > > significant amounts of codebase upheaval. > > > Vijay, nice tirade but pls read Alex's draft and tell me whehter you > > desperately need his-flavor-of-partial-replay-protection today. > > Thanks to Ran (rja@inet.org) for clearing up some errors. The HMAC > solution as proposed by tli appears to be sufficient for now. we're in sync then ... > > vendors rolled it. If you (as placeholder for any major ISP) don't > > need it desperately today, it is not worth doing and we should > > concentrate on a proper framework (if we want to do it at all) that > > won't be openly picked apart at the mike by some security wizard 6 > > months from now. I saw couple of chairs standing with their pants > > A secure solution is needed, I am not sure if the costs of imposing > a very complete, unbreakable solution are worth the return given > _current_ and past performance [ insert past performance > is not a guarantee of future result boilerplate here ] neither am I, I was only saying if somebody has cycles to put into that, he rather do a good job rather than come up with a hacky solution for a problem that the ISPs don't have and not solving a problem they may or will have properly either ... > > excuses are 'it was desperately needed to be deployed then so little > > hacky was fine' (case HMAC today) or 'we did thorough work and took > > into account all the then-known security paranoia'. Anything else > > does not stand the test of time and based on that observations I was > > trying to steer the work ... > > I'm basing this on a mandate after an incident some time ago. Senior > mangement said 'you will run authentication on all routing protocols > or you will find another job' of course we know that most of senior managers that cluefull and determined tend to find or being found new jobs way before us techies do ;-) Points taken -- tony From Manav Bhatia" Message-ID: <00e601c12c7f$d93432b0$b4036c6b@Manav> Hi Amir, I went through this draft and is quite interesting but there is another approach which you can take to increase the number of LSPs beyond 256. I dont remember the details but it goes something like this .. We act as two routers that are adjacent to one another and as long as we act like what we are advertising then no one can tell. This way we can thus issue 512 LSPs . Has anybody ever heard of such a concept ?? Thanks and Regards, Manav Bhatia ----- Original Message ----- From: "Amir Hermelin" To: "Manav Bhatia" ; Sent: Thursday, August 23, 2001 5:08 PM Subject: RE: [Isis-wg] More than 256 LSPs Manav, check out this draft http://www.ietf.org/internet-drafts/draft-hermelin-ext-lsp-frags-02.txt It attempts to solve the problem and remove the 256 limit. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Thursday, August 23, 2001 5:54 AM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] More than 256 LSPs > > > A single IS can at most issue 256 LSPs and it has to pack > everything it > wants to advertise into this much. Are there any hacks > wherein i may be able > to send more information than i what i am capable of using my > 256 LSPs. I > believe one such mechanism is by faking a LAN .. but i am not > sure as to how > it may work. > Can anybody please explain ? > > Thanks and Regards, > Manav Bhatia > > "C is not a big language, and is not well served by a big > book." -- K&R2 > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jparker@axiowave.com Fri Aug 24 14:41:49 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 24 Aug 2001 09:41:49 -0400 Subject: [Isis-wg] More than 256 LSPs Message-ID: > there is another approach which you can take ... > We act as two routers that are adjacent > > Manav Bhatia Manav - This was discussed at the last meeting, as captured in TonyP's meeting notes. I can send you a copy of the notes off-line if you missed them. - jeff parker - axiowave networks From rja@inet.org Fri Aug 24 14:36:14 2001 From: rja@inet.org (RJ Atkinson) Date: Fri, 24 Aug 2001 09:36:14 -0400 Subject: [Isis-wg] On authenticating IS-IS In-Reply-To: <3B85F5B8.C4BBFE02@redback.com> References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> <7md75mxlpt.fsf@challah.msrl.com> Message-ID: <5.1.0.14.2.20010824093213.00a1ed30@10.30.15.2> At 02:35 24/08/01, Tony Przygienda wrote: >neither am I, I was only saying if somebody has cycles to put into that, >he rather do a good job rather than come up with a hacky solution for >a problem that the ISPs don't have and not solving a problem they may >or will have properly either ... Tony, My own sense is that the next useful increase in attacker work function (beyond the tli HMAC draft) is probably to go to full Digital Signatures (along the lines of RFC-2154). I am only aware of one implementation of RFC-2154 (done by its authors) and zero deployments of RFC-2154. I interpret that state of implementation and deployment as indicating that: "most of the community doesn't think the current threats justify that level of security complexity and adverse performance impact today" Regards, Ran rja@inet.org From naiming@redback.com Fri Aug 24 20:08:26 2001 From: naiming@redback.com (Naiming Shen) Date: Fri, 24 Aug 2001 12:08:26 -0700 Subject: [Isis-wg] More than 256 LSPs In-Reply-To: Mail from "Manav Bhatia" dated Fri, 24 Aug 2001 15:03:32 +0530 <00e601c12c7f$d93432b0$b4036c6b@Manav> Message-ID: <20010824190826.96A2D1DCC78@prattle.redback.com> ]Hi Amir, ]I went through this draft and is quite interesting but there is another ]approach which you can take to increase the number of LSPs beyond 256. I ]dont remember the details but it goes something like this .. We act as two ]routers that are adjacent to one another and as long as we act like what we ]are advertising then no one can tell. This way we can thus issue 512 LSPs . ]Has anybody ever heard of such a concept ?? how is such a concept different from the draft you just went through? ] ]Thanks and Regards, ]Manav Bhatia ] ]----- Original Message ----- ]From: "Amir Hermelin" ]To: "Manav Bhatia" ; ]Sent: Thursday, August 23, 2001 5:08 PM ]Subject: RE: [Isis-wg] More than 256 LSPs ] ] ]Manav, ] ]check out this draft ]http://www.ietf.org/internet-drafts/draft-hermelin-ext-lsp-frags-02.txt ] ]It attempts to solve the problem and remove the 256 limit. ] ]-- ]Amir Hermelin ]Charlotte's Web Networks Inc. ] ] ]> -----Original Message----- ]> From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] ]> Sent: Thursday, August 23, 2001 5:54 AM ]> To: isis-wg@spider.juniper.net ]> Subject: [Isis-wg] More than 256 LSPs ]> ]> ]> A single IS can at most issue 256 LSPs and it has to pack ]> everything it ]> wants to advertise into this much. Are there any hacks ]> wherein i may be able ]> to send more information than i what i am capable of using my ]> 256 LSPs. I ]> believe one such mechanism is by faking a LAN .. but i am not ]> sure as to how ]> it may work. ]> Can anybody please explain ? ]> ]> Thanks and Regards, ]> Manav Bhatia ]> ]> "C is not a big language, and is not well served by a big ]> book." -- K&R2 ]> ]> ]> ]> _________________________________________________________ ]> Do You Yahoo!? ]> Get your free @yahoo.com address at http://mail.yahoo.com ]> ]> _______________________________________________ ]> Isis-wg mailing list - Isis-wg@external.juniper.net ]> http://external.juniper.net/mailman/listinfo/isis-wg ]> ] ] ]_________________________________________________________ ]Do You Yahoo!? ]Get your free @yahoo.com address at http://mail.yahoo.com ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From naamato@nexthop.com Fri Aug 24 20:12:15 2001 From: naamato@nexthop.com (Nick Amato) Date: Fri, 24 Aug 2001 15:12:15 -0400 Subject: [Isis-wg] unauthenticated LSP purges Message-ID: <20010824151215.C323@wooj.nexthop.com> I have searched the archive and found nothing that relates to this, in any case, sorry if this is an old topic. It seems that ISO 10589 contradicts itself in the area of LSP purges. 7.3.16.4 indicates that when the Remaining Lifetime of an LSP in memory becomes zero: a) set all SRMflags for that LSP, and b) retain only the LSP header Yet in 7.3.15.1, 'Action on receipt of an LSP', the authentication checks in (5) and (6) are performed _before_ the zero lifetime check in (b). A popular vendor seems to check and originate simple authentication on zero lifetime LSPs. draft-ietf-isis-hmac-03.txt indicates that an IS implementing MD5 should never accept unauthenticated purges. This seems like the correct thing to do if either simple or MD5 is in use. Nick Amato naamato@nexthop.com From prz@redback.com Fri Aug 24 21:01:02 2001 From: prz@redback.com (Tony Przygienda) Date: Fri, 24 Aug 2001 13:01:02 -0700 Subject: [Isis-wg] Re: On authenticating IS-IS References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> <7md75mxlpt.fsf@challah.msrl.com> <5.1.0.14.2.20010824093213.00a1ed30@10.30.15.2> Message-ID: <3B86B27E.9E1A5672@redback.com> RJ Atkinson wrote: > At 02:35 24/08/01, Tony Przygienda wrote: > >neither am I, I was only saying if somebody has cycles to put into that, > >he rather do a good job rather than come up with a hacky solution for > >a problem that the ISPs don't have and not solving a problem they may > >or will have properly either ... > > Tony, > > My own sense is that the next useful increase in attacker work > function (beyond the tli HMAC draft) is probably to go to full Digital > Signatures (along the lines of RFC-2154). > > I am only aware of one implementation of RFC-2154 (done by > its authors) and zero deployments of RFC-2154. I interpret that > state of implementation and deployment as indicating that: > > "most of the community doesn't think the current threats > justify that level of security complexity and adverse > performance impact today" agreed, once at it and since as you say things would not be pressing timewise, time could be spend on nonce-negotiation on hellos and possibly key, encryption negotiation so all exchanges between 2 peers could not only be secure but also private. Combined with a method to propagate with an LSP the information whether it was only flooded across encrypted and negotiated links, we could claim all best practical security known to at least me incl. privacy. I have nothing against such far forward-looking work, especially if each of those pieces is standardized as optional. Time may come when we need it. Again, I completely agree that practical deployment of security has far lagged the lip-service being paid to it and therefore the work only makes sense if someone really wants to spend cycles to do it right and is willing to wait long-time for deployment. That is to be attributed probably to the cynical truth that security is not an inherent need mostly, it's rather an acquired taste like horror movies ;-) thanks -- tony From rja@inet.org Fri Aug 24 21:56:53 2001 From: rja@inet.org (RJ Atkinson) Date: Fri, 24 Aug 2001 16:56:53 -0400 Subject: [Isis-wg] Re: On authenticating IS-IS In-Reply-To: <3B86B27E.9E1A5672@redback.com> References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> <7md75mxlpt.fsf@challah.msrl.com> <5.1.0.14.2.20010824093213.00a1ed30@10.30.15.2> Message-ID: <5.1.0.14.2.20010824165424.00a184a0@10.30.15.2> At 16:01 24/08/01, Tony Przygienda wrote: >...since as you say things would not be pressing timewise, >time could be spend on nonce-negotiation on hellos and possibly >key, encryption negotiation so all exchanges between 2 peers could not >only be secure but also private. Combined with a method to propagate >with an LSP the information whether it was only flooded across >encrypted and negotiated links, we could claim all best practical >security known to at least me incl. privacy. I have nothing against >such far forward-looking work, especially if each of those pieces >is standardized as optional. Time may come when we need it. One approach worth examining if confidentiality were an objective would be implementation/deployment of the IEEE 802.10 security specification. It has not been widely implemented or deployed, as far as I know, but some good folks did work on that spec. I do not have a copy, so don't know precisely what is in the 802.10 specification. Ran From jlearman@cisco.com Mon Aug 27 05:41:14 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 27 Aug 2001 00:41:14 -0400 Subject: [Isis-wg] New 10589 spec, PtoP and ISHs In-Reply-To: <17C81AD1F1FED411991E006008F6D1CAA5A63C@avalon.pluris.com> Message-ID: <4.3.2.7.2.20010827003934.02043020@dingdong.cisco.com> If my memory serves me, on a PTP circuit, an implementation is required to handle receipt of an IIH without having received an ISH, so Les's wise general rule doesn't need to be invoked. At 04:39 PM 8/21/2001, Les Ginsberg wrote: >This issue is a confusing one, some of which is due to the fact that the >original wording in ISO 10589:1992 was revised by Technical Corrigendum I >(published in 1993), but because many people do not have ready access to the >TCs, they rely on the uncorrected original text. In fact, the original >intent was made clear in TC1 by adding: > >"An IS shall cause ISO 9542 to send an ISH PDU whenever a point-to-point >circuit is first enabled." > >and then changing the original text in 8.2.3a (which Neal refers to in >stating that an IIH was supposed to be sent when the circuit was first >enabled) to read: > >"a)the IS receives an ISH PDU" > >So the original intent was to wait for receipt of an ISH before beginning to >send IIHs. The latest ISO 10589 draft further clarifies this by specifying >that ISH's should continue to be sent periodically until the adjacency >reaches the UP state. This is a logical requirement discovered when >implementing that was not clearly stated even in the TC1 changes. > >In an IP only IS-IS implementation, the use of ISH's is an anachronism. Many >implementations relax the requirements, at least on reception, so that >receiving an ISH is not required. In following the old axiom of being >"strict in what you send and generous in what you receive", a robust >implementation should send ISHs until the adjacency is up, but allow (at >least for IP operation) the adjacency to come up without ever seeing an ISH. >This is easily achieved by starting to send IIHs when you first receive an >IIH. > >I can tell you from first hand experience that there are indeed >implementations out there which do not send ISHs. > > Les > > > > >> -----Original Message----- >> From: Neal Castagnoli [mailto:cast@allegronetworks.com] >> Sent: Tuesday, August 21, 2001 1:14 PM >> To: isis-wg@spider.juniper.net >> Subject: [Isis-wg] New 10589 spec, PtoP and ISHs >> >> >> >> From the original 10589, routers might be able to get around >> sending ISHs on >> ptop circuits. The original states routers should transmit an IIH >> immediately upon circuit startup, and so an implementation >> need not send an >> ISH to get the peer IS to start IIH transmission. New 10589, however, >> removes this wording, and now it appears routers require >> receipt of an ISH >> prior to sending the first IIH. >> >> Yet if there are old implementations that don't send ISHs, >> ptop adjacencies >> won't come up with strict new implementations. Does anyone >> know whether >> there are deployed ISIS implementations that don't send ISHs on ptop >> circuits? >> >> Thanks, >> >> --Neal >> _______________________________________________ >> 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 amir@cwnt.com Mon Aug 27 08:07:07 2001 From: amir@cwnt.com (Amir Hermelin) Date: Mon, 27 Aug 2001 10:07:07 +0300 Subject: [Isis-wg] More than 256 LSPs Message-ID: Manav, as Naiming expressed, that is the exact concept discussed in the draft. As was detailed in an earlier version of the draft, this does have its limitations (this was discussed at the wg meeting - see notes). In the current (02) version of the draft, these limitations are removed by a new "operational mode" (the term used in the draft): telling other routers that the two (in your example) are really one. The older mode, where we "fool" older implementations into processing the LSPs correctly, still exists. -- Amir Hermelin Charlotte's Web Networks Inc. -----Original Message----- From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] Sent: Friday, August 24, 2001 12:34 PM To: Amir Hermelin; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] More than 256 LSPs Hi Amir, I went through this draft and is quite interesting but there is another approach which you can take to increase the number of LSPs beyond 256. I dont remember the details but it goes something like this .. We act as two routers that are adjacent to one another and as long as we act like what we are advertising then no one can tell. This way we can thus issue 512 LSPs . Has anybody ever heard of such a concept ?? Thanks and Regards, Manav Bhatia ----- Original Message ----- From: "Amir Hermelin" To: "Manav Bhatia" ; Sent: Thursday, August 23, 2001 5:08 PM Subject: RE: [Isis-wg] More than 256 LSPs Manav, check out this draft http://www.ietf.org/internet-drafts/draft-hermelin-ext-lsp-frags-02.txt It attempts to solve the problem and remove the 256 limit. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Thursday, August 23, 2001 5:54 AM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] More than 256 LSPs > > > A single IS can at most issue 256 LSPs and it has to pack > everything it > wants to advertise into this much. Are there any hacks > wherein i may be able > to send more information than i what i am capable of using my > 256 LSPs. I > believe one such mechanism is by faking a LAN .. but i am not > sure as to how > it may work. > Can anybody please explain ? > > Thanks and Regards, > Manav Bhatia > > "C is not a big language, and is not well served by a big > book." -- K&R2 > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From cast@allegronetworks.com Mon Aug 27 18:48:53 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Mon, 27 Aug 2001 10:48:53 -0700 Subject: [Isis-wg] New 10589 spec, PtoP and ISHs Message-ID: I think Les has it right. New strict implementations shouldn't begin sending IIHs until they receive an ISH. Perhaps they will accept the IIH, but they won't begin sending the IIH. --Neal > > > If my memory serves me, on a PTP circuit, an implementation > is required > to handle receipt of an IIH without having received an ISH, so Les's > wise general rule doesn't need to be invoked. > > At 04:39 PM 8/21/2001, Les Ginsberg wrote: > >This issue is a confusing one, some of which is due to the > fact that the > >original wording in ISO 10589:1992 was revised by Technical > Corrigendum I > >(published in 1993), but because many people do not have > ready access to the > >TCs, they rely on the uncorrected original text. In fact, > the original > >intent was made clear in TC1 by adding: > > > >"An IS shall cause ISO 9542 to send an ISH PDU whenever a > point-to-point > >circuit is first enabled." > > > >and then changing the original text in 8.2.3a (which Neal > refers to in > >stating that an IIH was supposed to be sent when the circuit > was first > >enabled) to read: > > > >"a)the IS receives an ISH PDU" > > > >So the original intent was to wait for receipt of an ISH > before beginning to > >send IIHs. The latest ISO 10589 draft further clarifies this > by specifying > >that ISH's should continue to be sent periodically until the > adjacency > >reaches the UP state. This is a logical requirement discovered when > >implementing that was not clearly stated even in the TC1 changes. > > > >In an IP only IS-IS implementation, the use of ISH's is an > anachronism. Many > >implementations relax the requirements, at least on > reception, so that > >receiving an ISH is not required. In following the old axiom of being > >"strict in what you send and generous in what you receive", a robust > >implementation should send ISHs until the adjacency is up, > but allow (at > >least for IP operation) the adjacency to come up without > ever seeing an ISH. > >This is easily achieved by starting to send IIHs when you > first receive an > >IIH. > > > >I can tell you from first hand experience that there are indeed > >implementations out there which do not send ISHs. > > > > Les > > > > > > > > > >> -----Original Message----- > >> From: Neal Castagnoli [mailto:cast@allegronetworks.com] > >> Sent: Tuesday, August 21, 2001 1:14 PM > >> To: isis-wg@spider.juniper.net > >> Subject: [Isis-wg] New 10589 spec, PtoP and ISHs > >> > >> > >> > >> From the original 10589, routers might be able to get around > >> sending ISHs on > >> ptop circuits. The original states routers should transmit an IIH > >> immediately upon circuit startup, and so an implementation > >> need not send an > >> ISH to get the peer IS to start IIH transmission. New > 10589, however, > >> removes this wording, and now it appears routers require > >> receipt of an ISH > >> prior to sending the first IIH. > >> > >> Yet if there are old implementations that don't send ISHs, > >> ptop adjacencies > >> won't come up with strict new implementations. Does anyone > >> know whether > >> there are deployed ISIS implementations that don't send > ISHs on ptop > >> circuits? > >> > >> Thanks, > >> > >> --Neal > >> _______________________________________________ > >> 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 abirjand@UU.NET Mon Aug 27 22:12:48 2001 From: abirjand@UU.NET (Amir Birjandi) Date: Mon, 27 Aug 2001 17:12:48 -0400 Subject: [Isis-wg] Setting the over load bit in an MPLS network Message-ID: <3.0.32.20010827171247.00df2d88@neserve0.corp.us.uu.net> Hi, After reading IS-IS Transient Black hole Avoidance draft i have this basic question. Imagine, we have a multihop Label switch path, which is carrying the traffic. routerA---routerB----routerC----routerD the label switch path---> from A to D. IGP== ISIS there are also a number of disjoint paths between A and D. If we set the overload bit on C or B, how would router A know it should stop sending traffic over that Label switch path. Any comments is highly appreciated Amir From swatirstogi@yahoo.com Tue Aug 28 05:26:26 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Tue, 28 Aug 2001 09:56:26 +0530 Subject: [Isis-wg] Default Routes in ISIS Message-ID: <00cf01c12f79$9d0b5b40$b4036c6b@Manav> Hi, Section 1.3 "Overview of the Integrated IS-IS" in RFC 1195 states that "Default routes are permitted only at level 2 as external routes. Default routes are not permitted at level 1" This would imply that all the L1 routers must be connected to either a L2 only or L1/L2 router. Is it so ?? I thought that a L1 router can be so set up which is only connected to another L1 router which will act as a gateway to the last resort. The other L1 router may in turn be connected to another L1/L2 router to ship packets outside the area. Can anybody please explain. Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From swatirstogi@yahoo.com Tue Aug 28 05:44:39 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Tue, 28 Aug 2001 10:14:39 +0530 Subject: [Isis-wg] rfc 1195 (another one!) Message-ID: <013501c12f7c$272cc460$b4036c6b@Manav> Hi, The way as i understood IS-IS routing goes something like this .. i am a L1 router and i recieve a packet destined to some other area so i forward that packet to my nearest L2 router. How i know that this packet does not belong to my area is by looking at its address. Then once it reaches the L2 router since it is aware of all the areas which it can reach it will forward the packet in question to the appropriate router. It will extract the area address also once again from the destination address in the packet. I hope i am okay till now .. Since everything is mentioned in the address itself and we can do all our routing just by looking at the address then we is it said that "L2 routers should include in their L2 LSPs a complete list of [IP address, subnet mask, metric] specifying all IP addresses reachable in their area" [RFC 1195.. Section 1.3]. Even in dual IS-IS we specify the area so why isn't the entire routing done just by looking at area prefixes. Please comment. Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From sprevidi@cisco.com Tue Aug 28 08:39:32 2001 From: sprevidi@cisco.com (stefano previdi) Date: Tue, 28 Aug 2001 09:39:32 +0200 Subject: [Isis-wg] Setting the over load bit in an MPLS network In-Reply-To: <3.0.32.20010827171247.00df2d88@neserve0.corp.us.uu.net> Message-ID: <4.3.2.7.2.20010828093113.03354bc8@brussels.cisco.com> At 23:12 27/08/2001, Amir Birjandi wrote: >Hi, > >After reading IS-IS Transient Black hole Avoidance > draft i have this basic question. > >Imagine, > >we have a multihop Label switch path, which is carrying the traffic. > >routerA---routerB----routerC----routerD > >the label switch path---> from A to D. > >IGP== ISIS > >there are also a number of disjoint paths between A and D. > >If we set the overload bit on C or B, how would router A know it should >stop sending traffic over that Label switch path. it will know it through spf. labels are bound to routes. When your neighbors advertise you label bindings, you select the label for a given route if such label has been bound by the neighbor who is also your next-hop for that given route. Setting the ovl bit will change the topology, therefore the routing table, and therefore your next-hops. So, you will use other labels from other neighbors (the new next-hops). s. >Any comments is highly appreciated > >Amir >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From sprevidi@cisco.com Tue Aug 28 08:52:22 2001 From: sprevidi@cisco.com (stefano previdi) Date: Tue, 28 Aug 2001 09:52:22 +0200 Subject: [Isis-wg] Default Routes in ISIS In-Reply-To: <00cf01c12f79$9d0b5b40$b4036c6b@Manav> Message-ID: <4.3.2.7.2.20010828094014.03526320@brussels.cisco.com> At 06:26 28/08/2001, Swati Rastogi wrote: >Hi, >Section 1.3 "Overview of the Integrated IS-IS" in RFC 1195 states that >"Default routes are permitted only at level 2 as external routes. Default >routes are not permitted at level 1" >This would imply that all the L1 routers must be connected to either a L2 >only or L1/L2 router. Is it so ?? I thought that a L1 router can be so set >up which is only connected to another L1 router which will act as a gateway >to the last resort. The other L1 router may in turn be connected to another >L1/L2 router to ship packets outside the area. this is not exactly what happens in most implementations. Default route can be orignated in level-1 areas or can be leaked (using rfc2966) into a level-1 area. s. >Can anybody please explain. > >Regards, >Swati > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Eduard.Metz@kpnqwest.com Tue Aug 28 09:29:13 2001 From: Eduard.Metz@kpnqwest.com (Metz, Eduard) Date: Tue, 28 Aug 2001 10:29:13 +0200 Subject: [Isis-wg] Default Routes in ISIS Message-ID: <1E810ACBCC29D51185DF00508B66CCEE04B774@ntexghfd02> L1 routers can use the "attached bit" set by the L1/L2 routers to determine the nearest exit out of the L1 area. This does not require all L1 routers to be connected to an L2 or L1/L2 router, all routers do need to interpret the attached bit (and the L1/L2 need to set it). Most current implementation can/do this ... cheers, Eduard > -----Original Message----- > From: Swati Rastogi [mailto:swatirstogi@yahoo.com] > Sent: 28 August 2001 06:26 > To: isis-wg > Subject: [Isis-wg] Default Routes in ISIS > > > Hi, > Section 1.3 "Overview of the Integrated IS-IS" in RFC 1195 states that > "Default routes are permitted only at level 2 as external > routes. Default > routes are not permitted at level 1" > This would imply that all the L1 routers must be connected to > either a L2 > only or L1/L2 router. Is it so ?? I thought that a L1 router > can be so set > up which is only connected to another L1 router which will > act as a gateway > to the last resort. The other L1 router may in turn be > connected to another > L1/L2 router to ship packets outside the area. > > Can anybody please explain. > > Regards, > Swati > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mshand@cisco.com Tue Aug 28 10:34:10 2001 From: mshand@cisco.com (mike shand) Date: Tue, 28 Aug 2001 10:34:10 +0100 Subject: [Isis-wg] SNAP & NSAP In-Reply-To: <01fa01c1208c$c5d0a4a0$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010828102001.00b7bf08@jaws.cisco.com> At 10:05 09/08/2001 +0530, Manav Bhatia wrote: >I have a small doubt . . > >(i) NSAP is an OSI equivalent of an IP address in a TCP/IP network. Almost. An NSAP is a Network Service Access Point, which has an address, the NSAP address, which is broadly equivalent to an IP address. But note that an NSAP address is NOT tied to an interface in the same way that an IP address is. >Is SNAP address equivalent of the ethernet address in the data link layer if >its a 802.2 ntwrk ? No. SNAP, stands for Sub-network Access Protocol. 8802-2 (LLC) defines various LLC classes. Class 1, which provides a datagram service, has one byte DSAP and SSAP fields, which identify the higher layer (3) protocol. For example FE identifies ISO connectionless network layer protocols. But SAP addresses are only assigned to standardized protocols, so there is another frame format which is used for non-standardized protocols. This is SNAP. It is assigned its own SAP of AA, but then the frame format diverges from LLC1, since it has a 5 byte Protocol ID field, which is used to identifier the higher layer protocol. The first 3 bytes are taken from a 24 bit IEEE block identifier, and the remaining 2 bytes are assigned by the owner of that block. This allows proprietary protocols to be distinguished by a vendor. So although the prot ID field of SNAP LOOKS a bit like an ethernet address, it is in fact a protocol identifier (in the same sense that the SAP addresses are). But aren't we getting somewhat off topic with this spate of OSI tutorials? Mike >Rgds, >Manav > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mshand@cisco.com Tue Aug 28 10:54:19 2001 From: mshand@cisco.com (mike shand) Date: Tue, 28 Aug 2001 10:54:19 +0100 Subject: [Isis-wg] Manual Adjacencies In-Reply-To: <004101c12167$af70fc10$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010828105323.0361a008@jaws.cisco.com> At 12:12 10/08/2001 +0530, Mareline Sheldon wrote: >The RFC 1142 (7.3.3.1) says "NOTE - Manual End system Adjacencies shall not >be included in a level 1 LSPs issued on behalf of a pseudonode, since that >would presuppose that all Intermediate systems on a broadcast subnetwork had >the same set of manual adjacencies as defined in the ciruit" > >This is not very clear .. if it is not done so then how do manual >adjacencies get advertised on a psedonode ? They don't! They only get advertised in the LSPs of the system with the manual adjacency. Mike >Please help! > >/Mary > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mshand@cisco.com Tue Aug 28 11:19:42 2001 From: mshand@cisco.com (mike shand) Date: Tue, 28 Aug 2001 11:19:42 +0100 Subject: [Isis-wg] IIH PDU exchange In-Reply-To: Message-ID: <4.3.2.7.2.20010828111623.035b2258@jaws.cisco.com> At 11:46 14/08/2001 -0400, Jeff Parker wrote: > > "LAN IIH PDUs shall be padded... > > > > Consider the following scenario: The network is in a > > congested state and we are bringing up [all] the IS-IS > > system[s]. > > > > Manav Bhatia > >Manav - > There are periodic dicussions on the list about >the utility of the padding, and I won't rehash those >here. Yes, the original idea was to also detect cases where both ends of the communication thought it was a large MTU, but in fact only small packets could be sent. There are various failure/misconfiguration condidtions which can lead to this, the classic one we had in mind being FDDI's connected through a (non-fragmenting) ethernet bridge, but can also postulate pt-pt links which are data length sensitive. In practice, most implementation permit the padding to be switched off. > If you have so many IS-IS routers that periodic >hello packets are a big problem, then I suspect the >LSP exchange that will start once the adjacencies come >up will have a greater effect. > >- jeff parker >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mshand@cisco.com Tue Aug 28 11:27:29 2001 From: mshand@cisco.com (mike shand) Date: Tue, 28 Aug 2001 11:27:29 +0100 Subject: [Isis-wg] tlv codepoints ... In-Reply-To: <3B79992B.9E287E89@redback.com> Message-ID: <4.3.2.7.2.20010828112434.038e2948@jaws.cisco.com> At 14:33 14/08/2001 -0700, Tony Przygienda wrote: > DECnet Phase IV 42 ? ? ? DEC (ancient) Tony, It should only appear in the IIHs, so.... DECnet PhaseIV 42 y n n From aravindravikumar@yahoo.com Tue Aug 28 11:41:52 2001 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Tue, 28 Aug 2001 03:41:52 -0700 (PDT) Subject: [Isis-wg] Protocol parameter. In-Reply-To: <20010823103255.8412.qmail@web11205.mail.yahoo.com> Message-ID: <20010828104152.63263.qmail@web11208.mail.yahoo.com> --0-355408955-998995312=:63144 Content-Type: text/plain; charset=us-ascii Hi Sachidananda, I feel that I was wrong when I said that individual LSPs will remain in the memory for atleast minimumLSP TransmissionInterval and no more than twice that interval LSP from a particular source shouldn't be transmitted within minimumLSP transmission interval.This means that if we take an individual LSP it will remain in memory before transmission for 0 to 5 seconds according to when the last LSP from same source was transmitted We can achive this requirement precisely by keeping timers for individual LSPs.So as soon as this timer expires we could transmit the LSP on the appropriate circuits.For all point to point circuit with SRM flags set it can be send imediately.For broadcast network ensure an interval of 32 milliseconds between successive transmissions on the same LAN. Since it will be difficult to implement per LSP timer, ISO 10589(7.3.15.5) gives a relaxation to this requirement in section and says that any implementation that ensures an interval between minimumLSP TransmissionInterval and twice that interval is OK . We can avoid the need for individual timers and even then meet the requirement fo broadcast circuit precisely and for point to point circuit almost precisely(maximum delay of 32 millisecondsafter the LSP gets ready),if we scan the database each 32 milliseconds along with last sent timestamp.But as 10589 itself says it will be very inefficient to scan at the whole database at this rate.We are free to use any techinique which is reasonably precise and utilizes the relaxation to the exact timer requirement mentioned above Aravind --------------------------------- Do You Yahoo!? Make international calls for as low as $0.04/minute with Yahoo! Messenger. --------------------------------- Do You Yahoo!? Make international calls for as low as $0.04/minute with Yahoo! Messenger. --0-355408955-998995312=:63144 Content-Type: text/html; charset=us-ascii

Hi Sachidananda, 

         I feel that I was wrong when I said that individual LSPs will remain in the memory for atleast minimumLSP TransmissionInterval and no more than twice that interval

LSP from a particular source shouldn't be transmitted within minimumLSP transmission interval.This means that if we take an individual LSP it will remain in memory before transmission for 0 to 5 seconds according to when the last LSP from same source was transmitted

We can achive this requirement precisely by keeping timers for individual LSPs.So as soon as  this timer expires we could transmit the LSP on the appropriate circuits.For all point to point circuit with SRM flags set it can be send imediately.For broadcast network ensure an interval of 32 milliseconds between successive transmissions on the same LAN.


Since it will be difficult to implement per LSP timer, ISO 10589(7.3.15.5) gives a relaxation to this requirement in section and says that any implementation that ensures an interval between minimumLSP TransmissionInterval and  twice that interval is OK .

We can avoid the need for individual timers and even then meet the requirement fo broadcast circuit precisely and for point to point circuit almost precisely(maximum delay of 32 millisecondsafter the LSP gets ready),if we scan the database each 32 milliseconds along with last sent timestamp.But as 10589 itself says it will be very inefficient to scan at the whole database at this rate.We are free to use any techinique which is reasonably precise and utilizes the relaxation to the exact timer requirement mentioned above

 

Aravind 

Do You Yahoo!?
Make international calls for as low as $0.04/minute with Yahoo! Messenger.


Do You Yahoo!?
Make international calls for as low as $0.04/minute with Yahoo! Messenger. --0-355408955-998995312=:63144-- From mshand@cisco.com Tue Aug 28 11:41:41 2001 From: mshand@cisco.com (mike shand) Date: Tue, 28 Aug 2001 11:41:41 +0100 Subject: [Isis-wg] Protocol parameter. In-Reply-To: <200108211504.IAA19768@cirrus.juniper.net> References: <00a301c12a3f$6d2c98b0$da046c6b@Manav> Message-ID: <4.3.2.7.2.20010828113829.038f8c20@jaws.cisco.com> At 08:04 21/08/2001 -0700, Dave Katz wrote: >Of course, any implementation that actually scans the database looking >for things to send will probably have other intractable scaling problems >as well. > >Unlike the OSPF spec, the ISIS spec provides very little implementation >guidance (a feature, I believe, as it promotes actual thinking.) > >All that minimumBroadcastLSPTransmissionInterval does is ensure that >the transmission rate is controlled so you don't swamp your receivers >(as there is no flow control in the protocol.) and randomizes the transmission order so that multiple routers on the LAN don't all try to send the same LSP at the same time. Note that seeing someone else transmit an LSP clears your SRMflag for it, so you don't need to bother transmitting it. This probably doesn't matter in the normal case of only a few routers on the LAN, but we were trying to make it scale to > 32 routers (I can't remember why :-) Mike > X-Apparently-From: > Reply-To: "Manav Bhatia" > From: "Manav Bhatia" > Cc: > References: > Organization: Samsung India Operations > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 5.50.4133.2400 > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Tue, 21 Aug 2001 18:16:16 +0530 > > Please find my comments inline .. > > > Does this parameter corresponds to the frequency at which Link State > > Database is scanned for transmitting the LSP? That is every > > minimumBroadcastLSPTransmissionInterval duration the Link state database > > MUST be scanned for searching the LSP to be sent. > > Yes. Setting the SRMflag does not cause the LSP to be transmitted > immediately. Instead the IS scans the database after every > minimumBroadcastLSPTransmissionInterval and choses the LSP to be > multicasted > randomly. Once this is done the SRMflag for the corresponding LSP is > cleared. > > Hope this helps, > Manav Bhatia > > > > > Or it corresponds to the minimum time interval that needs to be allowed > > between consecutive packets (be it of any type) on a LAN interface? that > is > > suppose on a particular interface (say A) if a LSP is sent, then for the > > next minimumBroadcastLSPTransmissionInterval duration no other > packets of > > any type is to be sent on this interface. > > > > Apart from this, if the point 1 is not true, then is there any parameter > > that dictates the frequency at which the link state database is to be > > scanned for searching the LSP to be sent? > > > > Thanking in advance for all early responses that I receive. > > Sachi > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From tgol@laurelnetworks.com Tue Aug 28 16:05:35 2001 From: tgol@laurelnetworks.com (Tayfun Gol) Date: Tue, 28 Aug 2001 11:05:35 -0400 Subject: [Isis-wg] rfc 1195 (another one!) References: <013501c12f7c$272cc460$b4036c6b@Manav> Message-ID: <3B8BB33F.E58E1A31@laurelnetworks.com> Swati Rastogi wrote: > Hi, > The way as i understood IS-IS routing goes something like this .. i am a L1 > router and i recieve a packet destined to some other area so i forward that > packet to my nearest L2 router. How i know that this packet does not belong > to my area is by looking at its address. Then once it reaches the L2 router > since it is aware of all the areas which it can reach it will forward the > packet in question to the appropriate router. It will extract the area > address also once again from the destination address in the packet. > I hope i am okay till now .. As far as OSI forwarding goes, you are. > > Since everything is mentioned in the address itself and we can do all our > routing just by looking at the address then we is it said that "L2 routers This again is valid for OSI forwarding only, you can not associate an IP destination address to an area address prefix ( which is derived from NSAP address, you would have an NSAP destination address for forwarding OSI traffic, not IP ) Tayfun Gol > > should include in their L2 LSPs a complete list of [IP address, subnet mask, > metric] specifying all IP addresses reachable in their area" [RFC 1195.. > Section 1.3]. Even in dual IS-IS we specify the area so why isn't the entire > routing done just by looking at area prefixes. > > > Please comment. > > Regards, > Swati > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Larmer@CommSense.Net Tue Aug 28 19:24:29 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Tue, 28 Aug 2001 14:24:29 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents Message-ID: Hi, I am a bit confused as to what exactly should be present in the L2 LSP "IP Internal Reachability Information" TLV? RFC-1195 states the following: 5.2 Overview of IP-Specific Information for IS-IS If included in level 2 LSPs, this field includes only entries reachable by the router, which originates the LSP, either via one of its interfaces, or indirectly via level 1 routing. We are conducting Interoperability tests on various Integrated IS-IS implementations. I am seeing conflicting "IP Internal Reachability Information" in the L2 LSPs being generated throughout the common L1/L2 Domain. To make matters worse, I am seeing conflicting contents when I do a reboot versus a "clear isis" with the same exact configuration? Sometimes the L2 LSP contains ONLY directly attached subnets and other times it contains the union of L1 areas? The reason I raise these issues is because there MAY be a conflict in the protocol specifications, which affects calculation of routes through an IS with an LSPDB overload condition? Let me explain using the following configuration: IP Subnet (10.10.10.0) [A][B][C][D] IP subnet (11.11.11.0) ^ LSPDB Overload condition All 4 IS routers (A,B,C,D) share a common area address (same L1 Sub-Domain) and are also part of the same L2 Domain. IS-B has a LSPDB overload condition and advertises this in it's L1/L2 LSP by setting the LSPDB overload bit. The other routers receive these LSPs and process them properly; they calculate routes to directly attached destinations but do not use IS-B as a transient IS. The problem is that an IP host connected to subnet 11.11.11.0 can still reach subnet 10.10.10.0. This is made possible because IS-B is advertising, in it's L2 LSP, the contents specified above in RFC-1195 Section 5.2. As a consequence, IS-C and IS-D calculate IP subnet 10.10.10.0 to be reachable via L2 routing, because they think IS-B has a direct connection to this subnet. Am I missing something fundamental here? Of course, if the above is the case then it will cause LSPDB overload conditions to be ineffective, given a similar configuration. This means the draft-ietf-isis-transient could also be made ineffective? Is this an implementation problem, protocol specific problem or just me being out to lunch? Any assistance would be greatly appreciated! Cheers, Ken Larmer From naiming@redback.com Tue Aug 28 20:10:21 2001 From: naiming@redback.com (Naiming Shen) Date: Tue, 28 Aug 2001 12:10:21 -0700 Subject: [Isis-wg] Setting the over load bit in an MPLS network In-Reply-To: Mail from Amir Birjandi dated Mon, 27 Aug 2001 17:12:48 EDT <3.0.32.20010827171247.00df2d88@neserve0.corp.us.uu.net> Message-ID: <20010828191021.87D05F2C4F@prattle.redback.com> ]we have a multihop Label switch path, which is carrying the traffic. ] ]routerA---routerB----routerC----routerD ] ]the label switch path---> from A to D. ] ]IGP== ISIS ] ]there are also a number of disjoint paths between A and D. ] ]If we set the overload bit on C or B, how would router A know it should ]stop sending traffic over that Label switch path. ] I would think you may not want to stop sending traffic down this Label switched path. The overload bit here is used as a hint to say C or B's bgp has not yet converged, it is possible that the label switched path calculation does not pay attention to ISIS overload bit and still sets up the label switched path through B and C to D before BGP on B or C can converge. In this case, routers B and C knows how to switch the mpls packets regardless of BGP convergence.(in some cases, the forwarding and rsvp module are always up, so the label switched path is never down) But whether routerA can send traffic down this A->B->C->D lsp depends on implementation, configuration and topology of the network. In some implementation and configuration, as long as the tunnel destination is the bgp nexthop, it can always switch; Even if the IGP routes are tightly coupled with the label switched paths, as long as the IGP has some alternative paths for routerA to reach routerD, it may still forward packets into this label switched path. If the IGP was ospf, then the "overload bit" equivalent should not prevent routerA sending traffic down this label switched path regardless of the topology of network. - Naiming From mshand@cisco.com Wed Aug 29 10:10:18 2001 From: mshand@cisco.com (mike shand) Date: Wed, 29 Aug 2001 10:10:18 +0100 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents In-Reply-To: Message-ID: <4.3.2.7.2.20010829100705.019b4b48@jaws.cisco.com> Ken, I'm confused. What do you mean by L1/L2 LSP? Do you mean the overload bit is set in BOTH L1 and L2? In which case other routers should NOT be seeing these reachable at L1 OR L2. Or do you mean that it is set in L1 only, and because the information is present in L2 LSPs from B (which do not have ovl set), the subnets appear reachable (correctly) at L2, but not at L1? Or do you mean something else entirely? Mike At 14:24 28/08/2001 -0400, Ken Larmer wrote: > All 4 IS routers (A,B,C,D) share a common area address (same L1 > Sub-Domain) >and are also part of the same L2 Domain. IS-B has a LSPDB overload condition >and advertises this in it's L1/L2 LSP by setting the LSPDB overload bit. The >other routers receive these LSPs and process them properly; they calculate >routes to directly attached destinations but do not use IS-B as a transient >IS. The problem is that an IP host connected to subnet 11.11.11.0 can still >reach subnet 10.10.10.0. This is made possible because IS-B is advertising, >in it's L2 LSP, the contents specified above in RFC-1195 Section 5.2. As a >consequence, IS-C and IS-D calculate IP subnet 10.10.10.0 to be reachable >via L2 routing, because they think IS-B has a direct connection to this >subnet. From Larmer@CommSense.Net Wed Aug 29 14:23:43 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Wed, 29 Aug 2001 09:23:43 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents In-Reply-To: <4.3.2.7.2.20010829100705.019b4b48@jaws.cisco.com> Message-ID: Hi Mike, Sorry, I should have made this a bit clearer. The OVL bit is being set in both the L1 and L2 LSPs originated by IS-B. But because the IS-B's L2 LSP contains all of the IP subnets within the L1 area (all IS routers are in the same area), there exists a route to subnet 10.10.10.0 via L2 from IS-C and IS-D. Say each link has a metric = 10. IS-B is advertising L2 reachability to IP subnet 10.10.10.0 with a metric = 20. IS-C and IS-D install an L2 IP route in their routing table to IP subnet 10.10.10.0 via IS-B. IS-B possesses an L1 IP route to IP subnet 10.10.10.0 via IS-A. So IS-B installs a L1 IP route to 10.10.10.0 in its IP routing table. Conversely, IS-A possesses a L2 IP route to IP subnet 11.11.11.0 via IS-B. IS-B possesses an L1 IP route to IP subnet 11.11.11.0 via IS-C... Consequently, we possess an IP route from IS-D (subnet 11.11.11.0) to IS-A (subnet 10.10.10.0), which uses the following path. Source = IS-D and Destination = IS-A. IS-D forwards the IP packet to IS-C via L1, IS-C forwards the IP packet to IS-B via L1 and then IS-B forwards the IP packet to IS-A via L1. IP Subnet (10.10.10.0) [A][B][C][D] IP subnet (11.11.11.0) ^ LSPDB Overload condition Mike, does the above scenario defeat the purpose of setting the LSPDB OVL bit? Cheers, Ken Larmer > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of mike shand > Sent: Wednesday, August 29, 2001 5:10 AM > To: Ken Larmer > Cc: Isis-Wg@Spider. Juniper. Net; Ken Larmer > Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV > contents > > > Ken, > I'm confused. What do you mean by L1/L2 LSP? Do you mean the > overload bit is set in BOTH L1 and L2? In which case other routers should > NOT be seeing these reachable at L1 OR L2. > > Or do you mean that it is set in L1 only, and because the information is > present in L2 LSPs from B (which do not have ovl set), the subnets appear > reachable (correctly) at L2, but not at L1? > > Or do you mean something else entirely? > > Mike > > At 14:24 28/08/2001 -0400, Ken Larmer wrote: > > All 4 IS routers (A,B,C,D) share a common area address (same L1 > > Sub-Domain) > >and are also part of the same L2 Domain. IS-B has a LSPDB > overload condition > >and advertises this in it's L1/L2 LSP by setting the LSPDB > overload bit. The > >other routers receive these LSPs and process them properly; they > calculate > >routes to directly attached destinations but do not use IS-B as > a transient > >IS. The problem is that an IP host connected to subnet > 11.11.11.0 can still > >reach subnet 10.10.10.0. This is made possible because IS-B is > advertising, > >in it's L2 LSP, the contents specified above in RFC-1195 Section > 5.2. As a > >consequence, IS-C and IS-D calculate IP subnet 10.10.10.0 to be reachable > >via L2 routing, because they think IS-B has a direct connection to this > >subnet. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From John.Odak@Marconi.com Thu Aug 30 14:40:57 2001 From: John.Odak@Marconi.com (Odak, John) Date: Thu, 30 Aug 2001 09:40:57 -0400 Subject: [Isis-wg] draft-ietf-isis-diff-te-00.txt Message-ID: <39469E08BD83D411A3D900204840EC5519EBA1@VIE-MSGUSR-01> All, In the subject draft, several items were left as TBD (sub-TLV codes), and one was left as an editor's note (repitition octet at start). Have these been resolved? Are there candidate resolutions? Thank you for any information. -- John Odak From hannes@juniper.net Mon Aug 20 17:05:08 2001 From: hannes@juniper.net (Hannes Gredler) Date: Mon, 20 Aug 2001 18:05:08 +0200 Subject: [Isis-wg] OSPF and IS-IS Scalability In-Reply-To: <005d01c12963$0f49a3f0$da046c6b@Manav>; from mnvbhatia@yahoo.com on Mon, Aug 20, 2001 at 03:41:47PM +0530 References: <005d01c12963$0f49a3f0$da046c6b@Manav> Message-ID: <20010820180508.E32207@juniper.net> manav, i do assume dave was talking about the _router_ LSA itself. which has about 65K "storage space", where IS-IS has 1492*256=381K storage space [altough in practise never reached] --- sure OSPF can originate more information in different LSA types, however experience has shown that exactly this "capability" is the scaling harm of OSPF ... -> if you have to distribute information by _flooding_, better dense pack your information elements; /hannes On Mon, Aug 20, 2001 at 03:41:47PM +0530, Manav Bhatia wrote: | Hi Dave OR if anybody else can clear this point .. | | I was going through your presentation archived at nanog where you have | compared the two link state protocols viz IS-IS and OSPF .. I am working on | IS-IS and am not much aware of OSPF and i was looking at the scalabilities | issues related to both of the protocols. There you have said that the | problem with OSPF is that in theory OSPF topology is limited to how much we | can stuff in the router LSA as each router gets one router LSA and it cant | be bigger than the biggest of the IP datagram (64K) and so can contain some | O(5000) links. | And the problem you said with IS-IS is the number of LSPs a single router | can issue which is 256. My question is that how can we say that in OSPF a | router has to stuff all its link database in ** one ** LSA. We have the | mechanism of I-bit and the M-bit wherein we control the division of a large | topological database description into multiple messages. | | Can you please throw some light on this. | | Thanks and Regards, | Manav Bhatia | "C is not a big language, and is not well served by a big book." -- K&R2 | | | | _________________________________________________________ | Do You Yahoo!? | Get your free @yahoo.com address at http://mail.yahoo.com | | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg From hannes@juniper.net Tue Aug 21 08:29:41 2001 From: hannes@juniper.net (Hannes Gredler) Date: Tue, 21 Aug 2001 09:29:41 +0200 Subject: [Isis-wg] Initialisation question In-Reply-To: <200108202208.f7KM8Zj14870@redd3174.procket.com>; from henk@Procket.com on Mon, Aug 20, 2001 at 03:08:35PM -0700 References: <200108202208.f7KM8Zj14870@redd3174.procket.com> Message-ID: <20010821092941.C3633@juniper.net> On Mon, Aug 20, 2001 at 03:08:35PM -0700, Henk Smit wrote: | | > | Sorry I should have said that I'd read that bit, but I'm still not | > | clear exactly what happens. I guess that once two routers are | adjacent | > | they exchange CSNPs and then send PSNPs for | > | any LSPs they are short of or are old? Correct? | | You have been reading rfc2328, haven't you. :-) | | > correct - for your convenience i have attached a tcpdump | > to see what happens; sorry if being unclear - what the tcpdump shows is initial exchange of CSNPs & LSPs and a PSNP as _acknowldegement_ for the LSPs they are short of; /hannes | Sorry, this is not correct. | | When a p2p adjacency comes up, both routers: | 1) for each LSP in the LSPDB, set the SRM bit for this interface | 2) send a CSNP (note, can consist of multiple packets) | 3) wait for a while to give the other router some time to send a CSNP | 4) hopefully receive a CNSP | 5) when they receive the CSNP from the other side, clear the SRM bit | for all LSPs that the other router already seems to have | 6) send all LSPs that still have the SRM bit set | | If the CSNP from the other router gets lost somewhere, you will end | up sending all LSPs. This might be some unnecessary work, but it will | guarantee that the LSPDBs will be in sync. | | henk. | | | > | > | | > | | > | On Sun, 19 Aug 2001, Hannes Gredler wrote: | > | | > | > On Sun, Aug 19, 2001 at 09:44:34AM +0000, John Greenhalgh wrote: | > | > | Hi, | > | > | | > | > | I'm looking through ISO 10589 and trying to understand how | routers learn | > | > | the link state database once adjacencies have been formed. For | broadcast I | > | > | gather that the CSNP from the DIS will initiate an update, but | what about | > | > | on point-to-point? Any pointers gladly received! | > | > | > | > john, | > | > | > | > take a look at paragraph 7.3.20.2.e where it says: | > | > | > | > [ ... ] CSNPs are transmited on | > | > point-to-point circuits at initialisation. | > | > | > | > HTH, | > | > | > | > /hannes From Russ White Thu Aug 23 21:47:23 2001 From: Russ White (Russ White) Date: Thu, 23 Aug 2001 16:47:23 -0400 (EDT) Subject: [Isis-wg] Meeting minutes ... In-Reply-To: <200108232005.NAA06495@dino-pc.procket.com> Message-ID: Yes--but I think we had settled on covering several methods, and letting people choose based on their implementation, since it really doesn't matter how the other IS does it, just how you do it locally (in other words, this is very close to an implementation detail).... I don't see why pulling it from the iih shouldn't/couldn't be included as well as what's there. Does anyone object? Russ On Thu, 23 Aug 2001, Dino Farinacci wrote: > >> . ietf-ospf-p2p: Dino brought up some simplifying ideas on the > >> ISIS side that have > >> been considered but would make layer violations worse (taking > >> MAC directly from > > This layer violation is already in IS-IS when processing LAN IIH's. > > Dino > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _____________________________ riw@cisco.com <>< Grace Alone From amir.birjandi@wcom.com Mon Aug 27 22:04:05 2001 From: amir.birjandi@wcom.com (Amir Birjandi) Date: Mon, 27 Aug 2001 17:04:05 -0400 Subject: [Isis-wg] Setting the over load bit in an MPLS network Message-ID: <3.0.32.20010827170404.00df2d88@neserve0.corp.us.uu.net> Hi, After reading IS-IS Transient Black hole Avoidance draft i have this basic question. Imagine, we have a multihop Label switch path, which is carrying the traffic. routerA---routerB----routerC----routerD the label switch path---> from A to D. IGP== ISIS there are also a number of disjoint paths between A and D. If we set the overload bit on C or B, how would router A know it should stop sending traffic over that Label switch path. Any comments is highly appreciated Amir From danny@tcb.net Mon Aug 27 23:29:10 2001 From: danny@tcb.net (Danny McPherson) Date: Mon, 27 Aug 2001 16:29:10 -0600 Subject: [Isis-wg] Re: Setting the over load bit in an MPLS network Message-ID: <200108272229.f7RMTA720189@tcb.net> > we have a multihop Label switch path, which is carrying the traffic. > > routerA---routerB----routerC----routerD > > the label switch path---> from A to D. > > IGP== ISIS > > there are also a number of disjoint paths between A and D. > > If we set the overload bit on C or B, how would router A know it should > stop sending traffic over that Label switch path. By A receiving B or C's LSP? Of course, if the LSPs are configured and B & C forward based on a label, not an IP DA, then it really doesn't matter, I suppose .. unless some fancy LSP establishment mechanism is broken as a result of the anomaly. -danny From Larmer@CommSense.Net Tue Sep 4 20:50:20 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Tue, 4 Sep 2001 15:50:20 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents In-Reply-To: Message-ID: Hi, I apologize upfront for the length of this memo. Though, I am still trying to understand if we have a potential RFC-1195 protocol deficiency? I discussed this issue with Mike offline and now we would like to get everyone’s opinion on this “potential” deficiency. In summary, RFC-1195 Annex C Dijkstra Calculation treats IP Reachable addresses as OSI End Systems. L2 LSPs do not contain OSI End System advertisements, however, L2 LSPs do contain IP Reachable addresses. This section applies the same Dijkstra calculations to OSI End Systems advertised in L1 LSPs as is applied to IP Reachable addresses contained within L2 LSPs. This yields a “potentially” undesirable result with reference to calculations through an L1/L2 IS with a LSPDB overload condition. This is because OSI End System Entries are always considered to be directly adjacent. Whereas L2 LSP IP Reachable address Entries are those, which are adjacent and those, which may be determined from the level 1 LSPs from all routers in the area. Of course, the IP Reachable addresses derived from the L1 LSPs in the same area “MAY” not be directly adjacent to the L1/L2 IS advertising these IP Reachable addresses in its L2 LSP. As a consequence, when we use the Dijkstra calculations outlined in RFC-1195, Annex C, we calculate all L2 LSP IP Reachable address Entries as being directly adjacent to an IS with a LSPDB overload condition. This “MAY” result, given the correct configuration, in remote IS routers using an overloaded L1/L2 IS, as a “transient” IS. I have verified this behavior with the following configuration: (10.10.10.0) [A][B][C][D] (11.11.11.0) ^ LSPDB Overload condition All 4 IS routers (A,B,C,D) share a common area address (same L1 Sub-Domain) and are also part of the same L2 Domain. IS-B has a LSPDB overload condition and advertises this in its L1 and L2 LSPs by setting the LSPDB overload bit. The other routers receive these LSPs and process them properly; they calculate routes to directly attached destinations but do not use IS-B as a transient IS. The problem is that an IP host connected to subnet 11.11.11.0 can still reach subnet 10.10.10.0. This is made possible because IS-B is advertising, in it's L2 LSP, the contents specified in RFC-1195 Section 5.2. As a consequence, IS-C and IS-D calculate IP subnet 10.10.10.0 to be reachable via L2 routing, because they think IS-B has a direct connection to this subnet. Conversely, IS-A calculates IP subnet 11.11.11.0 to be reachable via L2 routing, because they think IS-B has a direct connection to this subnet. Now let’s say each link has a metric = 10. IS-B is advertising L2 reachability to IP subnet 10.10.10.0 with a metric = 20. IS-C and IS-D install an L2 IP route in their routing table to IP subnet 10.10.10.0 via their next hop to IS-B. IS-B possesses an L1 IP route to IP subnet 10.10.10.0 via IS-A. So IS-B installs a L1 IP route to 10.10.10.0 in its IP routing table. Conversely, IS-A possesses a L2 IP route to IP subnet 11.11.11.0 via IS-B. IS-B possesses an L1 IP route to IP subnet 11.11.11.0 via IS-C... Consequently, we possess an IP route from IS-D (subnet 11.11.11.0) to IS-A (subnet 10.10.10.0), which uses the following path. Source = IS-D and Destination = IS-A. IS-D forwards the IP packet to IS-C via L1, IS-C forwards the IP packet to IS-B via L1 and then IS-B forwards the IP packet to IS-A via L1. I believe that the above translates into a possible back-door path through a L1/L2 IS, which is in the overload condition. I can think of the following conditions for which this behavior “MAY” have a negative impact, these configurations have “NOT” all been verified. 1. The LSPDB OLV bit may be set manually in most IS-IS implementations and can be used by ISPs as a mechanism for testing new or updated implementations of IS-IS in their backbones. I suspect, this is most often accomplished by either placing an IS DUT in a STUB area or in parallel with an active IS. The stub scenario will still work fine, however, the parallel configuration “MAY” mean that the IS DUT will be used as a transient IS? 2. The LSPDB OLV bit may be set on restart and then cleared on some condition (timer or synchronization with another IGP or EGP). If the IS in question were to generate new LSPs prior to receiving all of its routes, this “MAY” cause this IS to be used as a transient IS, even though it may not possess all of the routing information it needs to make the correct forwarding decisions? 3. When the LSPDB OLV bit is set as a result of an actual LSPDB overload condition, with a similar configuration as I originally outlined, this will cause the IS to be used as a transient IS. Depending on the exact cause of the LSPDB overload condition, this may cause IP packets to be forwarded to incorrect destinations. Consequently, a black hole “MAY” appear in the network? 4. When a router configured as an LSP flooding server, e.g. on an NBMA network, in combination with the mesh-group feature. This “MAY” allow access to the NBMA network prior to complete synchronization? 5. When a router that is aggregating VCs used only for network management. In this case, the network management stations must be on a network directly connected to the router with the set-overload-bit command configured. This allows all of the local network management stations to have complete access to the entire network through the IS with the OVL bit set. This is because they are not going through another IS first to get through this IS with the OVL bit set. The IS routers connected to the remote side of the VCs, more than likely, possess network management IP addresses, which are associated with a particular loopback interface on that IS. ACLs may be configured to only allow SNMP or CLI access to users who connect to this loopback interface IP address. Because these loopback interfaces are 1 hop away (non-adjacent IP subnets), other IS routers in the domain will have connectivity to these IS management capabilities. This “MAY” break an ISPs network security scheme for router management? Proposed resolution: RFC-1195 currently states: L2 LSP IP Internal Reachability Information -- IP addresses within the routing domain reachable directly via one or more interfaces on this Intermediate system. Proposed Change to RFC-1195 Begin: L2 LSP If source systemID, LSP number = 0, LSPDB OVL = 0; IP Internal Reachability Information -- IP addresses within the routing domain reachable directly via one or more interfaces on this Intermediate system. Otherwise; IP Internal Reachability Information -- IP addresses directly attached to one or more interfaces on this Intermediate system. End: The above suggestion should fix these “potential” problems because only directly attached IP subnets will be advertised in L2 LSPs when an LSPDB overload condition is detected. Besides, under actual LSPDB overload conditions, do we really want to advertise information, which “MAY” be based on incomplete LSPDBs? Cheers, Ken Larmer From jparker@axiowave.com Wed Sep 5 17:30:59 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 5 Sep 2001 12:30:59 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV con tents Message-ID: Ken - Interesting point. I've trimmed your note to oblivion. A few questions: > (10.10.10.0) [A][B][C][D] (11.11.11.0) As I read your description of the problem, you have a string of routers, and only one possible path from A to D. You are re-interpreting for IP the rule in 7.2.8.1 (Computing routes through overloaded Intermediate systems) The concern is that in B's overloaded state, it may think that the 11 network is reachable via A, so B should never be used as a transit router. I am trying to understand the proposed solution. Are you suggesting that an overloaded router include directly attached networks in LSP 0, and indirectly l earned networks in later LSPs? Or that overloaded routers should not advertise such routes, as no-one should trust them? I assume that this change requires a "flag day" when all routers upgrade, as a difference of opinion about the validity of these routes can cause black holes (Example above: D is old school, C is new) I have missed the meaning of the phrase "source systemID" on your proposed change, line 2 (text below). Does it belong there? What do we do if we cannot fit all relevant networks in LSP 0? What is the interaction between this commandment and section 7.3.4.4, the admonition to try to keep adjacency information in the same segment? - jeff parker - axiowave networks - If triangles had a God, he would have 3 sides. > -----Original Message----- > From: Ken Larmer [mailto:Larmer@CommSense.Net] > Sent: Tuesday, September 04, 2001 3:50 PM > To: Isis-Wg@Spider. Juniper. Net > Cc: Ken Larmer; Chuck Ouimette; Mike Shand > Subject: RE: [Isis-wg] L2 LSP IP Internal Reachability Information TLV > contents > > > > I am ... trying > to understand if we have a potential RFC-1195 protocol deficiency > [about how] RFC-1195 Annex C Dijkstra Calculation > treats IP Reachable addresses. ... > Proposed resolution: > > RFC-1195 currently states: > > L2 LSP > > IP Internal Reachability Information -- IP addresses > within the routing > domain reachable directly via one or more interfaces > on this Intermediate system. > > Proposed Change to RFC-1195 > > Begin: > > L2 LSP > **> If source systemID, LSP number = 0, LSPDB OVL = 0; > > IP Internal Reachability Information -- IP addresses > within the routing domain reachable directly via one or > more interfaces on this Intermediate system. > > Otherwise; > > IP Internal Reachability Information -- IP addresses > directly attached to one or more interfaces on this > Intermediate system. From Larmer@CommSense.Net Wed Sep 5 19:40:14 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Wed, 5 Sep 2001 14:40:14 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents In-Reply-To: Message-ID: Hi Jeff, I re-read what I sent to the list as a fix and it makes no sense to me either! Sorry, I transposed some stuff from another email message. Let me try to explain the proposed fix with different, more comprehensible, text :^) Replace the text in RFC-1195, section 5.3.5 Level 2 Link State PDU, Internal Reachability Information with the following text: Current text from this section: IP Internal Reachability Information -- IP addresses within the routing domain reachable directly via one or more interfaces on this Intermeditate system. Proposed replacement text: If local L1 LSP number = 0, ovl bit = 1 or local L2 LSP number = 0, ovl bit = 1 then IP Internal Reachability Information = IP addresses directly attached to one or more interfaces on this Intermediate system else IP Internal Reachability Information = IP addresses within the routing domain reachable directly via one or more interfaces on this Intermeditate system end Jeff, I believe that this would fix this problem and it would also have the benefit of reducing the amount of traffic being originated by a "supposedly" unreliable IS. So, when a local IS detects that it no longer has enough space to store L1 LSPs, it should not bother advertising partial information derived from an incomplete L1 LSPDB in its L2 LSPs. This situation is addressed by the If statement "local L1 LSP number = 0, ovl bit = 1". I am not sure how we would address the situation when a L1 LSPDB ovl bit is being set manually? In this case, we would not want to prevent L2 LSPs from advertising IP Reachable addresses derived from L1 LSPs in the same area. Perhaps we could incorporate a check to see if the ovl bit is being set manually, though I am not sure how we would accomplish that??? Of course, if the L2 LSPDB is encountering an overload condition, as long as the L1 LSPDB is fine, the IP Reachable address information we place in the L2 LSP should still be accurate. Though this would still mean that this IS could be used as a transient IS because of this bug. In addition, with the concept of being able to manually set the OVL bit, operators are expecting that this IS would NOT be used as a transient IS. Consequently, the second part of the If statement "local L2 LSP number = 0, ovl bit = 1" is required to prevent this IS from being used as a transient IS when the L2 LSPDB is actually encountering an overload condition or when the L2 LSPDB ovl bit has been set manually. I hope this makes sense? Cheers, Ken Larmer From jparker@axiowave.com Wed Sep 5 21:52:55 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 5 Sep 2001 16:52:55 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV con tents Message-ID: > Proposed replacement text: > > If > local L1 LSP number = 0, ovl bit = 1 > or > local L2 LSP number = 0, ovl bit = 1 > then > IP Internal Reachability Information = IP addresses > directly attached to one or more interfaces on this > Intermediate system > else > IP Internal Reachability Information = IP addresses > within the routing domain reachable directly via one > or more interfaces on this Intermeditate system > end As an editorial comment, this might be clearer if you drop the last "directly". What you are saying is that you can reach this somehow, i.e. perhaps indirectly. > So, when a local IS detects that it no longer > has enough space to store L1 LSPs, it should > not bother advertising partial information > derived from an incomplete L1 LSPDB in its L2 LSPs. I've always figured that overloaded at level X meant overloaded everywhere. I can imagine implementations that are smart enough to segregate memory, but if you have an L1/L2 router that is in trouble at Level n, it is probably in trouble at Level 3-n. > Perhaps we could incorporate a check to see if the ovl bit is > being set manually...??? I'm not sure who 'we' are in the sentence above, but there is only one bit currently, and there is no way for a remote router to tell why the overload bit is set. Of course you may have meant the local IGP... At issue here is how much you can trust a router who knows enough to know that it can't be trusted fully. What you are saying is These are addresses that I know I can reach without full information - a generalization of host addresses. Your scheme puts these addresses in segment 0. I am still unclear about the other addresses. I can imagine two behaviors o Don't send remote networks until you get out of overload. This has the advantage that we don't need to modify old routers: this info isn't there, so there is no temptation to use it o Send information about remote networks in later LSP segments, so that the information has time to flood through the network, and then send out LSP segment 0 with the overload bit clear. The first seems much safer, if a bit slower to converge. It also requires no change in the protocol, and only requires that routers be careful in what they originate. Would that solve your problem? - jeff parker - axiowave networks From Internet-Drafts@ietf.org Thu Sep 6 11:44:57 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Thu, 06 Sep 2001 06:44:57 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-04.txt Message-ID: <200109061044.GAA19381@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-04.txt Pages : 9 Date : 05-Sep-01 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-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-gmpls-extensions-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-gmpls-extensions-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: <20010905125331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010905125331.I-D@ietf.org> --OtherAccess-- --NextPart-- From Larmer@CommSense.Net Thu Sep 6 15:42:56 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 6 Sep 2001 10:42:56 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents In-Reply-To: Message-ID: Hi Jeff, Thanks for the comments, my responses are in-line. > > Proposed replacement text: > > > > If > > local L1 LSP number = 0, ovl bit = 1 > > or > > local L2 LSP number = 0, ovl bit = 1 > > then > > IP Internal Reachability Information = IP addresses > > directly attached to one or more interfaces on this > > Intermediate system > > else > > IP Internal Reachability Information = IP addresses > > within the routing domain reachable directly via one > > or more interfaces on this Intermeditate system > > end > > As an editorial comment, this might be clearer if you > drop the last "directly". What you are saying is > that you can reach this somehow, i.e. perhaps > indirectly. Not really, what I am saying is "only advertise those IP subnets which are directly attached to the router which is advertising them". Indirectly would imply, to me at least, IP subnets which are also reachable via L1 and since L1 information is taken from the L1 LSPs, which make up that area, this would result in the same behavior. Does this make sense? > > So, when a local IS detects that it no longer > > has enough space to store L1 LSPs, it should > > not bother advertising partial information > > derived from an incomplete L1 LSPDB in its L2 LSPs. > > I've always figured that overloaded at level X meant > overloaded everywhere. I can imagine implementations > that are smart enough to segregate memory, but if you > have an L1/L2 router that is in trouble at Level n, > it is probably in trouble at Level 3-n. I agree with this statement given the current implementations. However, wouldn't we be limiting new implementations if we did not treat L1 and L2 LSPDBs as being separate with the potential for allocating different resources for each? > > Perhaps we could incorporate a check to see if the ovl bit is > > being set manually...??? > > I'm not sure who 'we' are in the sentence above, but there > is only one bit currently, and there is no way for > a remote router to tell why the overload bit is set. > Of course you may have meant the local IGP... I'm sorry, by "we", I meant IETF IS-WG. Yes, I did mean the local IS and not remote ISs. Jeff, the problem as I see is not that the remote ISs calculate their routes through this IS incorrectly (though an argument could me made for that, though that would me changing RFC-1195s interpretation of Dijkstra). It is the local IS with the overload condition which is advertising L1 IP reachable addresses within L2 LSPs which is the issue! If the local IS did not advertise these routes, I believe there wouldn't be a possible backdoor through an overload L1/L2 IS. Jeff, I believe the above is a result of the way RFC-1195, annex C processes local IP Reachable addresses (local to the IS running the calculation). RFC-1195, Annex C states the following: C.1.4 The Algorithm 1) Add to PATHS, where W is a special value indicating traffic to SELF is passed up to internal processes (rather than forwarded). 2) Now pre-load TENT with the local adjacency database (Each entry made to TENT must be marked as being either an End System or a router to enable the check at the end of Step 2 to be made correctly - Note that each local IP reachability entry is included as an adjacency, and is marked as being an End System). ... ... Step 1: Examine the zeroeth link state PDU of P, the system just placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID as P, and LSP number zero). 1) If this LSP is present, and the "Infinite Hippity Cost" bit is clear, then for each LSP of P (i.e., all LSPs with the same first 7 octets of LSPID and P, irrespective of the value of LSP number) compute: dist(P,N) = d(P) + metric.k(P,N) for each neighbor N (both End System and router) of the system P. If the "Infinite Hippity Cost" bit is set, only consider the End System neighbors of the system P. Note that the End Systems neighbors of the system P includes IP reachable address entries included in the LSPs from system P. ... ... >From what I can determine, because the local IS is added to PATHS first, the check to see if the "Infinite Hippity Cost" bit is set, does not take place. It only takes place for subsequent ISs which are added to PATHS. Let me know if I am misinterpreting this section of Annex C? > At issue here is how much you can trust a router who > knows enough to know that it can't be trusted fully. > What you are saying is > > These are addresses that I know I can reach without > full information - a generalization of host addresses. Yes, this is correct! > Your scheme puts these addresses in segment 0. > I am still unclear about the other addresses. > I can imagine two behaviors Jeff, the reason I am suggesting we check local LSPs, LSP number = 0, ovl =1, is because, in accordance with ISO-10589, this is the only LSP number for which we should set this bit. Regardless of how many L2 LSPs an overload IS generates, it will check to see if its LSP number = 0, ovl = 1. If it is, that IS will only generate as many L2 LSPs as required to advertise the directly attached IP subnets. Conversely, if the local LSP number = 0, ovl = 0, that same IS will generate as many L2 LSPs as is required to fit all of the reachable IP subnets within the local area. Does that make sense? > o Don't send remote networks until you get out of > overload. This has the advantage that we > don't need to modify old routers: this > info isn't there, so there is no temptation > to use it > > o Send information about remote networks > in later LSP segments, so that the information > has time to flood through the network, and then > send out LSP segment 0 with the overload bit > clear. > > The first seems much safer, if a bit slower to converge. > It also requires no change in the protocol, and only > requires that routers be careful in what they originate. > Would that solve your problem? Yes, I agree! One other point though. If we do not originate this information from an overloaded IS, remote ISs will not have to calculate these routes. This is goodness in my opinion because if we actually have an IS, which is overloaded, we don't really want to trust its advertised information. Of course, except for the attached IP subnets. Though, given the right circumstances, even that information may be questionable? In addition, if we manually set the ovl bit, we are more than likely doing this because we are either testing this IS or we want to wait until we have more routes before we allow remote ISs to use this IS as a transient IS. The problem is that we still advertise the information we already possess and remote ISs unnecessarily process this information. If we were to remove this questionable information from the L2 LSPs and only add it when the ovl bit is cleared, we would lesson the amount of processing remote ISs would have to process until the remote IS in question was no longer advertising a LSPDB overload condition. Actually Jeff, I can think of several different ways we can lesson the impact of an overloaded IS on the rest of the network if we don't consider locally attached IP subnet information to be reliable. We could eliminate advertisement of any IP Reachable subnets until that IS is no longer in the LSPDB overload condition. Wouldn't advertisement of the IP Interface information be sufficient for remote management capabilities? One final point. I found this "potential" bug while conducting interoperability tests in our lab. I would feel much more comfortable proceeding ahead if someone else were to verify this problem in their lab. Conceptually it all makes sense, but I strongly suggest we have some additional verification for this "potential" bug prior to looking for a fix! Cheers, Ken Larmer From jparker@axiowave.com Thu Sep 6 17:06:39 2001 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 6 Sep 2001 12:06:39 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV con tents Message-ID: > > As an editorial comment, this might be clearer if you > > drop the last "directly". What you are saying is > > that you can reach this somehow, i.e. perhaps > > indirectly. > > Not really, what I am saying is "only advertise those IP > subnets which are directly attached to the router which > is advertising them". Indirectly would imply... > IP subnets which are also reachable via L1 I was refering to the section where you describe default behavior. I think you want to drop "directly" there. > If the local IS did not advertise these routes, > [when in the overload state] I > believe there wouldn't be a possible backdoor through > an overload L1/L2 IS. I think this is your proposal in a nutshell. I would guess the next step is to draw this up as a formal proposal. Since this is a modification to an IETF document, I suppose a draft to this group is the next step. - jeff parker From naiming@redback.com Thu Sep 6 17:43:13 2001 From: naiming@redback.com (Naiming Shen) Date: Thu, 06 Sep 2001 09:43:13 -0700 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents In-Reply-To: Mail from "Ken Larmer" dated Thu, 06 Sep 2001 10:42:56 EDT Message-ID: <20010906164313.2CB361DCC73@prattle.redback.com> Ken, It seems to me more like an implementation issue, I at least know more than one venders do this correctly. This problem does not need to be only happening on L2 LSPs of a L1/L2 border router(to borrow an ospf term), when a router originating it's own LSPs, it has three sources for it's IP tlv: (1) it's own IP subnets on interfaces (2) route leaking between levels, either L2 routes leaks down into L1 or L1 routes leaks up into L2 domain, this only happens on L1/L2 border routers. (3) external IP routes redistributed into ISIS on either levels. When an ISIS router is in "normal" condition, it can possibly do any or all the the three above while building it's own LSPs, but when a router is or claims in an "overload" condition, and if it is able to update and send out newer version of it's LSPs, it should only do the first one, and skip the next two if is configured to do so. But it's a good idea to document this somewhere. Thanks. ]Hi Jeff, ] ] Thanks for the comments, my responses are in-line. ] ]> > Proposed replacement text: ]> > ]> > If ]> > local L1 LSP number = 0, ovl bit = 1 ]> > or ]> > local L2 LSP number = 0, ovl bit = 1 ]> > then ]> > IP Internal Reachability Information = IP addresses ]> > directly attached to one or more interfaces on this ]> > Intermediate system ]> > else ]> > IP Internal Reachability Information = IP addresses ]> > within the routing domain reachable directly via one ]> > or more interfaces on this Intermeditate system ]> > end ]> ]> As an editorial comment, this might be clearer if you ]> drop the last "directly". What you are saying is ]> that you can reach this somehow, i.e. perhaps ]> indirectly. ] ]Not really, what I am saying is "only advertise those IP subnets which are ]directly attached to the router which is advertising them". Indirectly would ]imply, to me at least, IP subnets which are also reachable via L1 and since ]L1 information is taken from the L1 LSPs, which make up that area, this ]would result in the same behavior. Does this make sense? ] ]> > So, when a local IS detects that it no longer ]> > has enough space to store L1 LSPs, it should ]> > not bother advertising partial information ]> > derived from an incomplete L1 LSPDB in its L2 LSPs. ]> ]> I've always figured that overloaded at level X meant ]> overloaded everywhere. I can imagine implementations ]> that are smart enough to segregate memory, but if you ]> have an L1/L2 router that is in trouble at Level n, ]> it is probably in trouble at Level 3-n. ] ]I agree with this statement given the current implementations. However, ]wouldn't we be limiting new implementations if we did not treat L1 and L2 ]LSPDBs as being separate with the potential for allocating different ]resources for each? ] ]> > Perhaps we could incorporate a check to see if the ovl bit is ]> > being set manually...??? ]> ]> I'm not sure who 'we' are in the sentence above, but there ]> is only one bit currently, and there is no way for ]> a remote router to tell why the overload bit is set. ]> Of course you may have meant the local IGP... ] ]I'm sorry, by "we", I meant IETF IS-WG. Yes, I did mean the local IS and not ]remote ISs. Jeff, the problem as I see is not that the remote ISs calculate ]their routes through this IS incorrectly (though an argument could me made ]for that, though that would me changing RFC-1195s interpretation of ]Dijkstra). It is the local IS with the overload condition which is ]advertising L1 IP reachable addresses within L2 LSPs which is the issue! If ]the local IS did not advertise these routes, I believe there wouldn't be a ]possible backdoor through an overload L1/L2 IS. ] ]Jeff, I believe the above is a result of the way RFC-1195, annex C processes ]local IP Reachable addresses (local to the IS running the calculation). ]RFC-1195, Annex C states the following: ] ]C.1.4 The Algorithm ] ] 1) Add to PATHS, where W is a special value indicating ] traffic to SELF is passed up to internal processes (rather than ] forwarded). ] ] 2) Now pre-load TENT with the local adjacency database (Each ] entry made to TENT must be marked as being either an End System ] or a router to enable the check at the end of Step 2 to be made ] correctly - Note that each local IP reachability entry is ] included as an adjacency, and is marked as being an End System). ]... ]... ] ] Step 1: Examine the zeroeth link state PDU of P, the system just ] placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID ] as P, and LSP number zero). ] ] 1) If this LSP is present, and the "Infinite Hippity Cost" bit is ] clear, then for each LSP of P (i.e., all LSPs with the same ] first 7 octets of LSPID and P, irrespective of the value of ] LSP number) compute: ] ] dist(P,N) = d(P) + metric.k(P,N) ] ] for each neighbor N (both End System and router) of the system P. If ] the "Infinite Hippity Cost" bit is set, only consider the End System ] neighbors of the system P. Note that the End Systems neighbors of the ] system P includes IP reachable address entries included in the LSPs ] from system P. ]... ]... ] ]>From what I can determine, because the local IS is added to PATHS first, the ]check to see if the "Infinite Hippity Cost" bit is set, does not take place. ]It only takes place for subsequent ISs which are added to PATHS. Let me know ]if I am misinterpreting this section of Annex C? ] ]> At issue here is how much you can trust a router who ]> knows enough to know that it can't be trusted fully. ]> What you are saying is ]> ]> These are addresses that I know I can reach without ]> full information - a generalization of host addresses. ] ]Yes, this is correct! ] ]> Your scheme puts these addresses in segment 0. ]> I am still unclear about the other addresses. ]> I can imagine two behaviors ] ]Jeff, the reason I am suggesting we check local LSPs, LSP number = 0, ovl ]=1, is because, in accordance with ISO-10589, this is the only LSP number ]for which we should set this bit. Regardless of how many L2 LSPs an overload ]IS generates, it will check to see if its LSP number = 0, ovl = 1. If it is, ]that IS will only generate as many L2 LSPs as required to advertise the ]directly attached IP subnets. Conversely, if the local LSP number = 0, ovl = ]0, that same IS will generate as many L2 LSPs as is required to fit all of ]the reachable IP subnets within the local area. ] ]Does that make sense? ] ]> o Don't send remote networks until you get out of ]> overload. This has the advantage that we ]> don't need to modify old routers: this ]> info isn't there, so there is no temptation ]> to use it ]> ]> o Send information about remote networks ]> in later LSP segments, so that the information ]> has time to flood through the network, and then ]> send out LSP segment 0 with the overload bit ]> clear. ]> ]> The first seems much safer, if a bit slower to converge. ]> It also requires no change in the protocol, and only ]> requires that routers be careful in what they originate. ]> Would that solve your problem? ] ]Yes, I agree! One other point though. If we do not originate this ]information from an overloaded IS, remote ISs will not have to calculate ]these routes. This is goodness in my opinion because if we actually have an ]IS, which is overloaded, we don't really want to trust its advertised ]information. Of course, except for the attached IP subnets. Though, given ]the right circumstances, even that information may be questionable? ] ]In addition, if we manually set the ovl bit, we are more than likely doing ]this because we are either testing this IS or we want to wait until we have ]more routes before we allow remote ISs to use this IS as a transient IS. The ]problem is that we still advertise the information we already possess and ]remote ISs unnecessarily process this information. If we were to remove this ]questionable information from the L2 LSPs and only add it when the ovl bit ]is cleared, we would lesson the amount of processing remote ISs would have ]to process until the remote IS in question was no longer advertising a LSPDB ]overload condition. ] ]Actually Jeff, I can think of several different ways we can lesson the ]impact of an overloaded IS on the rest of the network if we don't consider ]locally attached IP subnet information to be reliable. We could eliminate ]advertisement of any IP Reachable subnets until that IS is no longer in the ]LSPDB overload condition. Wouldn't advertisement of the IP Interface ]information be sufficient for remote management capabilities? ] ]One final point. I found this "potential" bug while conducting ]interoperability tests in our lab. I would feel much more comfortable ]proceeding ahead if someone else were to verify this problem in their lab. ]Conceptually it all makes sense, but I strongly suggest we have some ]additional verification for this "potential" bug prior to looking for a fix! ] ]Cheers, ]Ken Larmer ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From Internet-Drafts@ietf.org Fri Sep 7 11:49:10 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 07 Sep 2001 06:49:10 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-05.txt Message-ID: <200109071049.GAA05637@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-05.txt Pages : 59 Date : 06-Sep-01 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 [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-05.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-05.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-05.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: <20010906141621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010906141621.I-D@ietf.org> --OtherAccess-- --NextPart-- From Larmer@CommSense.Net Fri Sep 7 14:30:57 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Fri, 7 Sep 2001 09:30:57 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents In-Reply-To: <20010906164313.2CB361DCC73@prattle.redback.com> Message-ID: > It seems to me more like an implementation issue, I at least > know more than one venders do this correctly. Thanks Naiming, I noticed that same behavior also! Cheers, Ken Larmer From jparker@axiowave.com Mon Sep 10 14:29:00 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 10 Sep 2001 09:29:00 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-05.txt 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_000_01C139FC.8CEA1F20 Content-Type: text/plain; charset="iso-8859-1" This rev of the mib was cleanup, rather than introducing new functionality. The newest version of the InetAddress "macros" simplify the encoding of IP addrs, and I think the external addresses, such as SysInstance and CircIndex are now handled correctly. l1 was changed to L1 to aid the eye. >From the doc: -- Changes in version 05. -- Used InetAddressPrefixLength to specify Mask Length. -- Where it made sense, used L1 (L2) rather than l1 (l2). -- Added text on use of Summary Address. -- Added ranges to INTEGER. -- Fixed use of external index such as isisSysInstance. -- Cleaned up errors: -- Defintion of isisCircLevelDefaultMetric. -- Defintion of isisCircLevelPartSNPInterval. -- Case in name IsisPacketCountEntry. -- Access for indicies. Not yet done: Conformance section Boilerplate for SNMP Docs ("SNMP is devided into three parts...") Traps Control for any of the recent drafts, such as hitless restart Authors could assist by forwarding suggestions on what needs managing Add counting for MTU mismatches - jeff parker - axiowave networks - If triangles had a God, he would have 3 sides. > 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-05.txt > Pages : 59 > Date : 06-Sep-01 > > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-05.txt ------_=_NextPart_000_01C139FC.8CEA1F20 Content-Type: message/rfc822 To: Subject: Date: Mon, 10 Sep 2001 09:29:00 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C139FC.8CEA1F20" ------_=_NextPart_002_01C139FC.8CEA1F20 Content-Type: text/plain ------_=_NextPart_002_01C139FC.8CEA1F20 Content-Type: application/octet-stream; name="ATT06765.txt" Content-Disposition: attachment; filename="ATT06765.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010906141621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-05.txt ------_=_NextPart_002_01C139FC.8CEA1F20 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-isis-wg-mib-05.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C139FC.8CEA1F20-- ------_=_NextPart_000_01C139FC.8CEA1F20-- From swatirstogi@yahoo.com Mon Sep 10 15:25:08 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Mon, 10 Sep 2001 19:55:08 +0530 Subject: [Isis-wg] draft-ietf-isis-traffic-04.txt Message-ID: <00be01c13a04$66da0950$b4036c6b@Manav> Hi, I was just going through the above stated draft. I have a very elementary doubt. Why aren't the sub TLVs numbered as 1,2,3,4,5 etc. Why are they numbered as 3,6,8,9,etc. This is the draft that i presume introduced these additional subTLVs, so why aren't the numbers really ordered ? This is indeed a very foolish doubt .. but am just curious. Thanks, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From Manav Bhatia" When going through the IS-IS extensions for Traffic engineering i noticed that its said that implementations must not inject a /32 prefix for the interface address as this can lead to forwarding loops when interacting with systems that do not support this sub-tlv. The same is mentioned for the sub-tlv for ipv4 neighbor address. as i understand, if a router is not able to understand any (sub)tlv it can ignore it and can be skipped on receipt, but will forward the same. Also why are the interface/neighbor address not considered for IPv6 Thanks, Manav "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From oran@cisco.com Tue Sep 11 14:52:45 2001 From: oran@cisco.com (David R. Oran) Date: Tue, 11 Sep 2001 09:52:45 -0400 Subject: [Isis-wg] FW: (jtc1sc06.184) Announcement of Document Availability Message-ID: <02b001c13ac9$099cc0f0$24ee2ca1@cisco.com> This is a multi-part message in MIME format. ------=_NextPart_000_02B1_01C13AA7.828B20F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ANNOUNCEMENT OF DOCUMENT AVAILABILITY ========================================= Document Posted : SC6 N12029- N12030 ========================================= The following documents are now available from the JTC1/SC6 web site : http://www.jtc1sc06.org ------------------------------------------ ------------------------------------------ Document Number : 12029 Replaces : Document Type : Disposition of Comments Date Assigned : 2001-09-11 Document Title : Disposition of comments on FCD 10589 2nd Edition (2001) Due Date : Pages : 5 Source : Project Editor (Micah Bartell) Project Number : Status : As per the Nara resolution 6.7.3, the text and the Explanatory Report of ISO/IEC 10889 with this document are submitted to ITTF for FDIS ballot. Action ID : ITTF ------------------------------------------- ------------------------------------------- Document Number : 12030 Replaces : Document Type : Information from JTC1 Secretariat Date Assigned : 2001-09-11 Document Title : IETF WG Review: IP Flow Information Export (ipfix) Due Date : Pages : 2 Source : JTC1 Secretariat Project Number : Status : For your information. Action ID : FYI --------------------------------------------- --------------------------------------------- =============================== Ms. Jooran Lee JTC1/SC6 Secretariat Korean Standards Association Phone: +82 2 369 8308 Fax: +82 2 369 8349 Email: secretariat@jtc1sc06.org http://www.jtc1sc06.org =============================== ------=_NextPart_000_02B1_01C13AA7.828B20F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
ANNOUNCEMENT OF DOCUMENT = AVAILABILITY

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= Document Posted=20 : SC6 N12029-=20 N12030
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
The following documents are = now available from the=20 JTC1/SC6 web site :
http://www.jtc1sc06.org
------------------------------------------
 
------------------------------------------

Document = Number :=20 12029
Replaces :
Document Type : Disposition of = Comments
Date Assigned : = 2001-09-11
Document Title = : Disposition of comments on FCD=20 10589 2nd Edition (2001)
Due Date :
Pages :=20 5
Source : Project Editor = (Micah Bartell)
Project Number :
Status : = As per the Nara=20 resolution 6.7.3, the text and the Explanatory Report of ISO/IEC 10889=20
with this document are = submitted to ITTF for FDIS=20 ballot.
Action ID : = ITTF
 
-------------------------------------------

-------------= ------------------------------

Document=20 Number : 12030
Replaces :
Document Type = : Information from JTC1=20 Secretariat
Date Assigned : = 2001-09-11
Document Title : IETF WG = Review: IP Flow Information=20 Export (ipfix)
Due Date :
Pages : = 2
Source : JTC1=20 Secretariat
Project Number :
Status : = For your=20 information.
Action ID : FYI
 
---------------------------------------------

-----------= ----------------------------------
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ms.=20 Jooran Lee
JTC1/SC6 Secretariat
Korean Standards = Association
Phone: +82=20 2 369 8308
Fax: +82 2 369 8349
Email: secretariat@jtc1sc06.org
= http://www.jtc1sc06.org
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
------=_NextPart_000_02B1_01C13AA7.828B20F0-- From swatirstogi@yahoo.com Thu Sep 13 06:28:48 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Thu, 13 Sep 2001 10:58:48 +0530 Subject: [Isis-wg] Mesh Groups Doubt Message-ID: <009d01c13c14$f91b4150$b4036c6b@Manav> Hi, Is the concept of mesh groups something is similiar to that of the route reflectors in BGP. It would have been a lot clearer in the rfc if an example using the mesh groups would have also been provided. Can anybody please help me in understanding the concept of mesh groups. ? Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From dkatz@juniper.net Thu Sep 13 06:31:54 2001 From: dkatz@juniper.net (Dave Katz) Date: Wed, 12 Sep 2001 22:31:54 -0700 (PDT) Subject: [Isis-wg] Mesh Groups Doubt In-Reply-To: <009d01c13c14$f91b4150$b4036c6b@Manav> (swatirstogi@yahoo.com) Message-ID: <200109130531.WAA12576@cirrus.juniper.net> It's a cheap hack to reduce the flooding load in highly meshed networks by not flooding LSPs across all links. --Dave Hi, Is the concept of mesh groups something is similiar to that of the route reflectors in BGP. It would have been a lot clearer in the rfc if an example using the mesh groups would have also been provided. Can anybody please help me in understanding the concept of mesh groups. ? Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From netprotoengr@yahoo.com Fri Sep 14 17:32:52 2001 From: netprotoengr@yahoo.com (NetProtocols Engineer) Date: Fri, 14 Sep 2001 09:32:52 -0700 (PDT) Subject: [Isis-wg] ISIS: what ISO protocols do we need? ... Message-ID: <20010914163252.24988.qmail@web13504.mail.yahoo.com> Hi! I was wondering what all ISO protocols (CLNP, ESIS, etc) do we need to get ISIS running? Also, is my understanding correct: ISIS goes directly on top of the link layer (Eth/PPP)? So, what, if any, roles do CLNP and ESIS, etc play in ISIS' functionality? Thanks in advance for your responses! __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From cast@allegronetworks.com Fri Sep 14 18:54:00 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Fri, 14 Sep 2001 10:54:00 -0700 Subject: [Isis-wg] draft-ietf-isis-traffic-04.txt, MAX_PATH_METRIC Message-ID: I was checking the archives to find an answer to the question "why is MAX_PATH_METRIC 2^32-2^25?", instead of what would appear to be more reflective of the offered reasons behind the constant's choice, which would be 2^32 - 2^24, or even 2^32-(2^24-1). All I found was the same question, copied below, apparantly unanswered. Does anyone know the reasoning? Care to share it? Thanks, --Neal --------------------------------------------------------------- Hi: In draft "IS-IS extensions for traffic engineeing": "It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25)." What does it mean "a single link metric does not overflow the number of bits for internal metric calculation."? Also where does it come from "2^25" in the following statement? Thanks. _ming From netprotoengr@yahoo.com Fri Sep 14 19:54:40 2001 From: netprotoengr@yahoo.com (NetProtocols Engineer) Date: Fri, 14 Sep 2001 11:54:40 -0700 (PDT) Subject: [Isis-wg] ISIS: what ISO protocols do we need? ... In-Reply-To: <5A063B55DDB6D411937100D0B7C84E38017A6BEF@tonga.force10networks.com> Message-ID: <20010914185440.86452.qmail@web13505.mail.yahoo.com> Great! Thanks for helping out on that. But per 1195 section 4.4: --------------------------------------------------------------------- For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links. --------------------------------------------------------------------- These ISH packets are different from ISIS Hellos, right? And since our primary interest is p2p links (duh! like everyone else!! ;-), I am wondering if we would need to bring in some ISH related code? Again, thanks in advance for all help. --- Nageswara Soma wrote: > You don't need CLNP or ESIS to run ISIS. > ESIS is only used to exchange some information > between ES and IS. In reality we don't see any ES. > So just ISIS should work fine. As you pointed out > ISIS PDUs are encapsulated in Ethernet frames. > +-----------------------------------------+ > | DA(6) | SA(6) | Len(2) |LLC(3) | PDU | > +-----------------------------------------+ > > DA - destination multicast MAC address (refer to ISO10589) > SA - Source MAC address > Len - length of payload (LLC header + ISIS PDU) > LLC - LLC header > PDU - LSP, IIH, CSNP, PSNP etc > > LLC header: > DSAP - destination SAP (0xFE for ISO) > SSAP - source SAP (0xFE for ISO) > CTRL - control field (0x3 for ISO) > > Hope it helps > Soma > > > -----Original Message----- > > From: NetProtocols Engineer [mailto:netprotoengr@yahoo.com] > > Sent: Friday, September 14, 2001 9:33 AM > > To: isis-wg@spider.juniper.net > > Subject: [Isis-wg] ISIS: what ISO protocols do we need? ... > > > > > > Hi! I was wondering what all ISO protocols (CLNP, ESIS, etc) > > do we need to get > > ISIS running? Also, is my understanding correct: ISIS goes > > directly on top of > > the link layer (Eth/PPP)? So, what, if any, roles do CLNP and > > ESIS, etc play in > > ISIS' functionality? > > > > Thanks in advance for your responses! > > > > > > __________________________________________________ > > Terrorist Attacks on U.S. - How can you help? > > Donate cash, emergency relief information > > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From jlearman@cisco.com Fri Sep 14 20:48:14 2001 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 14 Sep 2001 15:48:14 -0400 Subject: [Isis-wg] ISIS: what ISO protocols do we need? ... In-Reply-To: <20010914185440.86452.qmail@web13505.mail.yahoo.com> References: <5A063B55DDB6D411937100D0B7C84E38017A6BEF@tonga.force10networks.com> Message-ID: <4.3.2.7.2.20010914154145.019842f0@dingdong.cisco.com> ISO 10589 requires you to send an ESIS ISH PDU when starting a point-to-point circuit. (This is in technical corrigendum 1, and will be in the new version of the spec.) Also, you are supposed to wait until you receive an IIH or an ESIS ISH before sending an IIH. It may no longer be a practical necessity, but it's required by the spec. In any case, you will definitely need to be able to receive them without causing problems. Jeff At 02:54 PM 9/14/2001, NetProtocols Engineer wrote: >Great! Thanks for helping out on that. But per 1195 section 4.4: >--------------------------------------------------------------------- >For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, >as the first step in establishing the link between routers. All IS-IS >routers are therefore required to transmit and receive ISO 9542 ISH >packets on point-to-point links. >--------------------------------------------------------------------- >These ISH packets are different from ISIS Hellos, right? And since >our primary interest is p2p links (duh! like everyone else!! ;-), >I am wondering if we would need to bring in some ISH related code? > >Again, thanks in advance for all help. > > >--- Nageswara Soma wrote: >> You don't need CLNP or ESIS to run ISIS. >> ESIS is only used to exchange some information >> between ES and IS. In reality we don't see any ES. >> So just ISIS should work fine. As you pointed out >> ISIS PDUs are encapsulated in Ethernet frames. >> +-----------------------------------------+ >> | DA(6) | SA(6) | Len(2) |LLC(3) | PDU | >> +-----------------------------------------+ >> >> DA - destination multicast MAC address (refer to ISO10589) >> SA - Source MAC address >> Len - length of payload (LLC header + ISIS PDU) >> LLC - LLC header >> PDU - LSP, IIH, CSNP, PSNP etc >> >> LLC header: >> DSAP - destination SAP (0xFE for ISO) >> SSAP - source SAP (0xFE for ISO) >> CTRL - control field (0x3 for ISO) >> >> Hope it helps >> Soma >> >> > -----Original Message----- >> > From: NetProtocols Engineer [mailto:netprotoengr@yahoo.com] >> > Sent: Friday, September 14, 2001 9:33 AM >> > To: isis-wg@spider.juniper.net >> > Subject: [Isis-wg] ISIS: what ISO protocols do we need? ... >> > >> > >> > Hi! I was wondering what all ISO protocols (CLNP, ESIS, etc) >> > do we need to get >> > ISIS running? Also, is my understanding correct: ISIS goes >> > directly on top of >> > the link layer (Eth/PPP)? So, what, if any, roles do CLNP and >> > ESIS, etc play in >> > ISIS' functionality? >> > >> > Thanks in advance for your responses! >> > >> > >> > __________________________________________________ >> > Terrorist Attacks on U.S. - How can you help? >> > Donate cash, emergency relief information >> > http://dailynews.yahoo.com/fc/US/Emergency_Information/ >> > _______________________________________________ >> > Isis-wg mailing list - Isis-wg@external.juniper.net >> > http://external.juniper.net/mailman/listinfo/isis-wg >> > > > >__________________________________________________ >Terrorist Attacks on U.S. - How can you help? >Donate cash, emergency relief information >http://dailynews.yahoo.com/fc/US/Emergency_Information/ >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Internet-Drafts@ietf.org Fri Jul 6 11:50:23 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 06 Jul 2001 06:50:23 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-03.txt Message-ID: <200107061050.GAA25859@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 Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-03.txt Pages : 6 Date : 05-Jul-01 This document describes the authentication of IS-IS PDUs using the HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions to support IPv4 described in [3]. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-hmac-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-hmac-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010705113838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- From netprotoengr@yahoo.com Tue Sep 18 19:56:38 2001 From: netprotoengr@yahoo.com (NetProtocols Engineer) Date: Tue, 18 Sep 2001 11:56:38 -0700 (PDT) Subject: [Isis-wg] circuit type in isis ... Message-ID: <20010918185638.28262.qmail@web13504.mail.yahoo.com> Hi! Out of curiousity (i.e. I have no real need to do this right now, but, ...): How do I determine the circuit type (p2p, broadcast, etc) for an ISIS interface if I am not directly connected to a router? So, e.g.: R1 ------- { Network } ------- RD | | R2 How can RD determine if R1-R2 link is p2p, nbma, bcast, etc? Thanks for your responses. __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From tgol@laurelnetworks.com Tue Sep 18 20:46:28 2001 From: tgol@laurelnetworks.com (Tayfun Gol) Date: Tue, 18 Sep 2001 15:46:28 -0400 Subject: [Isis-wg] circuit type in isis ... References: <20010918185638.28262.qmail@web13504.mail.yahoo.com> Message-ID: <3BA7A494.F533683E@laurelnetworks.com> NetProtocols Engineer wrote: > Hi! Out of curiousity (i.e. I have no real need to do this > right now, but, ...): How do I determine the circuit type > (p2p, broadcast, etc) for an ISIS interface if I am not > directly connected to a router? > > So, e.g.: > > R1 ------- { Network } ------- RD > | > | > R2 > > How can RD determine if R1-R2 link is p2p, nbma, bcast, etc? > > Thanks for your responses. > First of all, there is no notion of nbma networks in IS-IS ( at least not in the current standards ), you either have PTP or broadcast links in the topology as far as IS-IS is concerned. For the topology above, the type of the link between R1 and R2 can be determined from IS reachability TLV's advertised by R1 or R2. If the link between R1 and R2 were a multiaccess link, R1 and R2 would be advertising reachability to the elected DIS on that network and whoever became DIS would generate a pseudonode LSP advertising reachability to R1 and R2 back. If the link type were PTP, R1 and R2 would be advertising reachability to each other directly. Hope this helps.. Thanks, Tayfun Gol Laurel Networks > > __________________________________________________ > Terrorist Attacks on U.S. - How can you help? > Donate cash, emergency relief information > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From jparker@axiowave.com Thu Sep 20 19:19:36 2001 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 20 Sep 2001 14:19:36 -0400 Subject: [Isis-wg] RE: draft-ietf-isis-wg-mib-05.txt Message-ID: > Hi, > Could someone please explain to me the third sentance of the following > object definition? > > isisManAreaAddrExistState OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The state of the isisManAreaAddrEntry. This object > follows the Row Status behaviour. If an attempt is > made to set this object to the value off when the > corresponding isisManAreaAddrEntry is the only valid > entry for this instance and when the corresponding ISIS > instance has isisSysAdminState set to On then the attempt > is rejected." > DEFVAL { active } > ::= { isisManAreaAddrEntry 2 } Ken - Each IS-IS Router (IS for short) must have at least one area configured. The verbage above tries to say: "You cannot delete the -last- area" To change areas, you add, then delete, rather than deleting and then adding. - jeff parker - axiowave networks - All those who believe in psychokinesis, raise my hand. From sachidananda_k@hotmail.com Fri Sep 21 16:11:22 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Fri, 21 Sep 2001 15:11:22 +0000 Subject: [Isis-wg] pseudonode LSP Message-ID: Hi All, I have a question regarding the pseudonode LSPs transmission. Should the designated IS send the pseudonode LSPs only on the LAN interface on which it is a DIS or should it send them on all the interfaces. Let me take an example: SYS1 is a L1 intermediate system with 3 broadcast interfaces (ifA, ifB and ifC) and 2 point to point interfaces (say ppp0, ppp1). SYS1 is a DIS on the LAN to which it is connected through ifB. Then does the SYS1 has to send the pseudonode LSPs and CSNPs on only ifB or should these packets be sent on all the interfaces ifA, ifB, ifC, ppp0 and ppp1. Thanking in advance for all the early reaponses. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From sachidananda_k@hotmail.com Sat Sep 22 12:53:24 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Sat, 22 Sep 2001 11:53:24 +0000 Subject: [Isis-wg] Decision process and LSP arrival Message-ID: Hi All, While executing the deicsion process, if any LSP is received, how can I add it to the Link State Database without disturbing the decision process. Actually a note in the section 7.3.20.1 from ISO 10589, describes an optimization. However, I am not very clear with it. Can anybody please explain it to me. Thanking in advance for all early responses Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From mlu@chiaro.com Sat Sep 22 21:38:49 2001 From: mlu@chiaro.com (May Lu) Date: Sat, 22 Sep 2001 15:38:49 -0500 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV con tents Message-ID: <2383E22BDFF6D311BB8400B0D021A507CDD1BA@MAIL> --=_IS_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Naiming, In you previous e-mail, the 3rd type of sources may comes from different protocols that are redistributed into ISIS. It may contains directly connected routes, statically configured routes and routes redistributed from other protocols. If the router is or claims in an "overload" condition, should it still include the redistributed directly connected routes and statically routes? Xiaomei Lu -----Original Message----- From: Naiming Shen [mailto:naiming@redback.com] Sent: Thursday, September 06, 2001 11:43 AM To: Ken Larmer Cc: Isis-Wg@Spider. Juniper. Net; Jeff Parker; Chuck Ouimette Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents Ken, It seems to me more like an implementation issue, I at least know more than one venders do this correctly. This problem does not need to be only happening on L2 LSPs of a L1/L2 border router(to borrow an ospf term), when a router originating it's own LSPs, it has three sources for it's IP tlv: (1) it's own IP subnets on interfaces (2) route leaking between levels, either L2 routes leaks down into L1 or L1 routes leaks up into L2 domain, this only happens on L1/L2 border routers. (3) external IP routes redistributed into ISIS on either levels. When an ISIS router is in "normal" condition, it can possibly do any or all the the three above while building it's own LSPs, but when a router is or claims in an "overload" condition, and if it is able to update and send out newer version of it's LSPs, it should only do the first one, and skip the next two if is configured to do so. But it's a good idea to document this somewhere. Thanks. ]Hi Jeff, ] ] Thanks for the comments, my responses are in-line. ] ]> > Proposed replacement text: ]> > ]> > If ]> > local L1 LSP number = 0, ovl bit = 1 ]> > or ]> > local L2 LSP number = 0, ovl bit = 1 ]> > then ]> > IP Internal Reachability Information = IP addresses ]> > directly attached to one or more interfaces on this ]> > Intermediate system ]> > else ]> > IP Internal Reachability Information = IP addresses ]> > within the routing domain reachable directly via one ]> > or more interfaces on this Intermeditate system ]> > end ]> ]> As an editorial comment, this might be clearer if you ]> drop the last "directly". What you are saying is ]> that you can reach this somehow, i.e. perhaps ]> indirectly. ] ]Not really, what I am saying is "only advertise those IP subnets which are ]directly attached to the router which is advertising them". Indirectly would ]imply, to me at least, IP subnets which are also reachable via L1 and since ]L1 information is taken from the L1 LSPs, which make up that area, this ]would result in the same behavior. Does this make sense? ] ]> > So, when a local IS detects that it no longer ]> > has enough space to store L1 LSPs, it should ]> > not bother advertising partial information ]> > derived from an incomplete L1 LSPDB in its L2 LSPs. ]> ]> I've always figured that overloaded at level X meant ]> overloaded everywhere. I can imagine implementations ]> that are smart enough to segregate memory, but if you ]> have an L1/L2 router that is in trouble at Level n, ]> it is probably in trouble at Level 3-n. ] ]I agree with this statement given the current implementations. However, ]wouldn't we be limiting new implementations if we did not treat L1 and L2 ]LSPDBs as being separate with the potential for allocating different ]resources for each? ] ]> > Perhaps we could incorporate a check to see if the ovl bit is ]> > being set manually...??? ]> ]> I'm not sure who 'we' are in the sentence above, but there ]> is only one bit currently, and there is no way for ]> a remote router to tell why the overload bit is set. ]> Of course you may have meant the local IGP... ] ]I'm sorry, by "we", I meant IETF IS-WG. Yes, I did mean the local IS and not ]remote ISs. Jeff, the problem as I see is not that the remote ISs calculate ]their routes through this IS incorrectly (though an argument could me made ]for that, though that would me changing RFC-1195s interpretation of ]Dijkstra). It is the local IS with the overload condition which is ]advertising L1 IP reachable addresses within L2 LSPs which is the issue! If ]the local IS did not advertise these routes, I believe there wouldn't be a ]possible backdoor through an overload L1/L2 IS. ] ]Jeff, I believe the above is a result of the way RFC-1195, annex C processes ]local IP Reachable addresses (local to the IS running the calculation). ]RFC-1195, Annex C states the following: ] ]C.1.4 The Algorithm ] ] 1) Add to PATHS, where W is a special value indicating ] traffic to SELF is passed up to internal processes (rather than ] forwarded). ] ] 2) Now pre-load TENT with the local adjacency database (Each ] entry made to TENT must be marked as being either an End System ] or a router to enable the check at the end of Step 2 to be made ] correctly - Note that each local IP reachability entry is ] included as an adjacency, and is marked as being an End System). ]... ]... ] ] Step 1: Examine the zeroeth link state PDU of P, the system just ] placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID ] as P, and LSP number zero). ] ] 1) If this LSP is present, and the "Infinite Hippity Cost" bit is ] clear, then for each LSP of P (i.e., all LSPs with the same ] first 7 octets of LSPID and P, irrespective of the value of ] LSP number) compute: ] ] dist(P,N) = d(P) + metric.k(P,N) ] ] for each neighbor N (both End System and router) of the system P. If ] the "Infinite Hippity Cost" bit is set, only consider the End System ] neighbors of the system P. Note that the End Systems neighbors of the ] system P includes IP reachable address entries included in the LSPs ] from system P. ]... ]... ] ]>From what I can determine, because the local IS is added to PATHS first, the ]check to see if the "Infinite Hippity Cost" bit is set, does not take place. ]It only takes place for subsequent ISs which are added to PATHS. Let me know ]if I am misinterpreting this section of Annex C? ] ]> At issue here is how much you can trust a router who ]> knows enough to know that it can't be trusted fully. ]> What you are saying is ]> ]> These are addresses that I know I can reach without ]> full information - a generalization of host addresses. ] ]Yes, this is correct! ] ]> Your scheme puts these addresses in segment 0. ]> I am still unclear about the other addresses. ]> I can imagine two behaviors ] ]Jeff, the reason I am suggesting we check local LSPs, LSP number = 0, ovl ]=1, is because, in accordance with ISO-10589, this is the only LSP number ]for which we should set this bit. Regardless of how many L2 LSPs an overload ]IS generates, it will check to see if its LSP number = 0, ovl = 1. If it is, ]that IS will only generate as many L2 LSPs as required to advertise the ]directly attached IP subnets. Conversely, if the local LSP number = 0, ovl = ]0, that same IS will generate as many L2 LSPs as is required to fit all of ]the reachable IP subnets within the local area. ] ]Does that make sense? ] ]> o Don't send remote networks until you get out of ]> overload. This has the advantage that we ]> don't need to modify old routers: this ]> info isn't there, so there is no temptation ]> to use it ]> ]> o Send information about remote networks ]> in later LSP segments, so that the information ]> has time to flood through the network, and then ]> send out LSP segment 0 with the overload bit ]> clear. ]> ]> The first seems much safer, if a bit slower to converge. ]> It also requires no change in the protocol, and only ]> requires that routers be careful in what they originate. ]> Would that solve your problem? ] ]Yes, I agree! One other point though. If we do not originate this ]information from an overloaded IS, remote ISs will not have to calculate ]these routes. This is goodness in my opinion because if we actually have an ]IS, which is overloaded, we don't really want to trust its advertised ]information. Of course, except for the attached IP subnets. Though, given ]the right circumstances, even that information may be questionable? ] ]In addition, if we manually set the ovl bit, we are more than likely doing ]this because we are either testing this IS or we want to wait until we have ]more routes before we allow remote ISs to use this IS as a transient IS. The ]problem is that we still advertise the information we already possess and ]remote ISs unnecessarily process this information. If we were to remove this ]questionable information from the L2 LSPs and only add it when the ovl bit ]is cleared, we would lesson the amount of processing remote ISs would have ]to process until the remote IS in question was no longer advertising a LSPDB ]overload condition. ] ]Actually Jeff, I can think of several different ways we can lesson the ]impact of an overloaded IS on the rest of the network if we don't consider ]locally attached IP subnet information to be reliable. We could eliminate ]advertisement of any IP Reachable subnets until that IS is no longer in the ]LSPDB overload condition. Wouldn't advertisement of the IP Interface ]information be sufficient for remote management capabilities? ] ]One final point. I found this "potential" bug while conducting ]interoperability tests in our lab. I would feel much more comfortable ]proceeding ahead if someone else were to verify this problem in their lab. ]Conceptually it all makes sense, but I strongly suggest we have some ]additional verification for this "potential" bug prior to looking for a fix! ] ]Cheers, ]Ken Larmer ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg --=_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 Sanjay.Harwani@marconi.com Sat Sep 22 22:05:38 2001 From: Sanjay.Harwani@marconi.com (Harwani, Sanjay) Date: Sat, 22 Sep 2001 17:05:38 -0400 Subject: [Isis-wg] test - please ignore Message-ID: <313680C9A886D511A06000204840E1CF529936@whq-msgusr-02.pit.comms.marconi.com> From swatirstogi@yahoo.com Mon Sep 24 07:47:04 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Mon, 24 Sep 2001 12:17:04 +0530 Subject: [Isis-wg] pseudonode LSP Message-ID: <075001c144c4$c0a71a20$b4036c6b@Manav> > I have a question regarding the pseudonode LSPs transmission. > Should the designated IS send the pseudonode LSPs only on the LAN > interface >on which it is a DIS or should it send them on all the interfaces. only on the LAN on which it is the DIS. ~Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jlearman@cisco.com Mon Sep 24 15:11:05 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 24 Sep 2001 10:11:05 -0400 Subject: [Isis-wg] pseudonode LSP In-Reply-To: <075001c144c4$c0a71a20$b4036c6b@Manav> Message-ID: <4.3.2.7.2.20010924100911.01f941c8@dingdong.cisco.com> At 02:47 AM 9/24/2001, Swati Rastogi wrote: >> I have a question regarding the pseudonode LSPs transmission. >> Should the designated IS send the pseudonode LSPs only on the LAN >> interface >>on which it is a DIS or should it send them on all the interfaces. > >only on the LAN on which it is the DIS. I think you must have misunderstood the question. LSPs are propagated throughout the subdomain, regardless of the point of origination (self, others, real, pseudo). The same mechanism is used for propagating pseudonode LSPs as other LSPs, therefore they will be transmitted out ALL links, broadcast and point-to-point, that are in the same subdomain (L1 area or L2 backbone). Jeff >~Swati > > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Internet-Drafts@ietf.org Mon Sep 24 15:59:41 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 24 Sep 2001 10:59:41 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-igp-p2p-over-lan-00.txt Message-ID: <200109241459.KAA16290@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 : Point-to-point operation over LAN in link-state routing protocols Author(s) : N. Shen et al. Filename : draft-ietf-isis-igp-p2p-over-lan-00.txt Pages : 8 Date : 21-Sep-01 The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.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-igp-p2p-over-lan-00.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-igp-p2p-over-lan-00.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: <20010924105709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-igp-p2p-over-lan-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010924105709.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Mon Sep 24 15:59:48 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 24 Sep 2001 10:59:48 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-restart-00.txt Message-ID: <200109241459.KAA16315@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 : Restart signaling for ISIS Author(s) : M. Shand Filename : draft-ietf-isis-restart-00.txt Pages : 9 Date : 21-Sep-01 The IS-IS routing protocol (RFC 1142 [2], ISO/IEC 10589 [3]) is a link state intra-domain routing protocol. Normally, when an IS-IS router is re-started, the neighboring routers detect the restart event and cycle their adjacencies with the restarting router through the down state. This is necessary in order to invoke the protocol mechanisms to ensure correct re-synchronization of the LSP database. However, the cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes temporary disruption of routes passing through the restarting router. In certain scenarios such temporary disruption of the routes is highly undesirable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-restart-00.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-restart-00.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-restart-00.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: <20010924105727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-restart-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-restart-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010924105727.I-D@ietf.org> --OtherAccess-- --NextPart-- From Ravindra.Sunkad@vivacenetworks.com Mon Sep 24 17:26:09 2001 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Mon, 24 Sep 2001 09:26:09 -0700 Subject: [Isis-wg] Decision process and LSP arrival Message-ID: The note basically says that an LSP for a system can be received during the Dijkstra computation in the following two cases: 1. If the system has not yet been visited in Dijkstra. i.e. when it does get visited later the updated LSP information will be used. 2. If the system has already been determined to be on the shortest PATH tree. In that case instead of abandoning the current run of Dijkstra use the updated LSP information in the next run of Dijkstra. Ravi -----Original Message----- From: Sachidananda K [mailto:sachidananda_k@hotmail.com] Sent: Saturday, September 22, 2001 4:53 AM To: isis-wg@spider.juniper.net Subject: [Isis-wg] Decision process and LSP arrival Hi All, While executing the deicsion process, if any LSP is received, how can I add it to the Link State Database without disturbing the decision process. Actually a note in the section 7.3.20.1 from ISO 10589, describes an optimization. However, I am not very clear with it. Can anybody please explain it to me. Thanking in advance for all early responses Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From naiming@redback.com Mon Sep 24 18:57:20 2001 From: naiming@redback.com (Naiming Shen) Date: Mon, 24 Sep 2001 10:57:20 -0700 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV con tents In-Reply-To: Mail from May Lu dated Sat, 22 Sep 2001 15:38:49 CDT <2383E22BDFF6D311BB8400B0D021A507CDD1BA@MAIL> Message-ID: <20010924175720.9A9961DCC78@prattle.redback.com> Yes, it makes sense to allow redistributed source from connected or static through. So this is very implementation related, and one can have knobs to do so. But a good practice is to aggragate connected and static routes on the router then import them into ibgp instead of into igp. ]--=_IS_MIME_Boundary ]Content-Type: text/plain; ] charset="iso-8859-1" ] ]Naiming, ] ]In you previous e-mail, the 3rd type of sources may comes from different ]protocols that are redistributed into ISIS. It may contains directly ]connected routes, statically configured routes and routes redistributed from ]other protocols. If the router is or claims in an "overload" condition, ]should it still include the redistributed directly connected routes and ]statically routes? ] ]Xiaomei Lu ] ] ]-----Original Message----- ]From: Naiming Shen [mailto:naiming@redback.com] ]Sent: Thursday, September 06, 2001 11:43 AM ]To: Ken Larmer ]Cc: Isis-Wg@Spider. Juniper. Net; Jeff Parker; Chuck Ouimette ]Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV ]contents ] ] ] ]Ken, ] ] It seems to me more like an implementation issue, I at least ]know more than one venders do this correctly. ] ] This problem does not need to be only happening on L2 LSPs of ]a L1/L2 border router(to borrow an ospf term), when a router originating ]it's own LSPs, it has three sources for it's IP tlv: ] ] (1) it's own IP subnets on interfaces ] (2) route leaking between levels, either L2 routes leaks down into L1 ] or L1 routes leaks up into L2 domain, this only happens on L1/L2 ] border routers. ] (3) external IP routes redistributed into ISIS on either levels. ] ] When an ISIS router is in "normal" condition, it can possibly ]do any or all the the three above while building it's own LSPs, but when ]a router is or claims in an "overload" condition, and if it is able to ]update and send out newer version of it's LSPs, it should only do the ]first one, and skip the next two if is configured to do so. ] ] But it's a good idea to document this somewhere. Thanks. ] ] - Naiming From tli@Procket.com Tue Sep 25 10:24:04 2001 From: tli@Procket.com (Tony Li) Date: Tue, 25 Sep 2001 02:24:04 -0700 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV con tents In-Reply-To: <20010924175720.9A9961DCC78@prattle.redback.com> References: <2383E22BDFF6D311BB8400B0D021A507CDD1BA@MAIL> <20010924175720.9A9961DCC78@prattle.redback.com> Message-ID: <15280.19764.178150.885970@alpha-tli.procket.com> Interesting... If the router is truly in an overload state, I would tend to want as much traffic to shy away from it as possible. This is just because overloaded routers tend to behave Very Predictably. Also Very Badly. ;-) If the router is instead in overload to avoid carrying transit traffic, then I would also want to not advertise routes that would tend to ADD transit traffic. In my grokking of 10589, the only reason to advertise anything is to allow reachability to ESes behind a single overloaded router. The direct analog in IP would only to allow interface prefixes (or redistribute connected). I'd argue that even redistrubted static routes are more likely to be in the transit class. Tony Naiming Shen writes: | | Yes, it makes sense to allow redistributed source from connected or | static through. So this is very implementation related, and one can | have knobs to do so. But a good practice is to aggragate connected | and static routes on the router then import them into ibgp instead | of into igp. | | ]--=_IS_MIME_Boundary | ]Content-Type: text/plain; | ] charset="iso-8859-1" | ] | ]Naiming, | ] | ]In you previous e-mail, the 3rd type of sources may comes from different | ]protocols that are redistributed into ISIS. It may contains directly | ]connected routes, statically configured routes and routes redistributed from | ]other protocols. If the router is or claims in an "overload" condition, | ]should it still include the redistributed directly connected routes and | ]statically routes? | ] | ]Xiaomei Lu | ] | ] | ]-----Original Message----- | ]From: Naiming Shen [mailto:naiming@redback.com] | ]Sent: Thursday, September 06, 2001 11:43 AM | ]To: Ken Larmer | ]Cc: Isis-Wg@Spider. Juniper. Net; Jeff Parker; Chuck Ouimette | ]Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV | ]contents | ] | ] | ] | ]Ken, | ] | ] It seems to me more like an implementation issue, I at least | ]know more than one venders do this correctly. | ] | ] This problem does not need to be only happening on L2 LSPs of | ]a L1/L2 border router(to borrow an ospf term), when a router originating | ]it's own LSPs, it has three sources for it's IP tlv: | ] | ] (1) it's own IP subnets on interfaces | ] (2) route leaking between levels, either L2 routes leaks down into L1 | ] or L1 routes leaks up into L2 domain, this only happens on L1/L2 | ] border routers. | ] (3) external IP routes redistributed into ISIS on either levels. | ] | ] When an ISIS router is in "normal" condition, it can possibly | ]do any or all the the three above while building it's own LSPs, but when | ]a router is or claims in an "overload" condition, and if it is able to | ]update and send out newer version of it's LSPs, it should only do the | ]first one, and skip the next two if is configured to do so. | ] | ] But it's a good idea to document this somewhere. Thanks. | ] | ] | | - Naiming | _______________________________________________ | 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 naiming@redback.com Tue Sep 25 19:28:17 2001 From: naiming@redback.com (Naiming Shen) Date: Tue, 25 Sep 2001 11:28:17 -0700 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV con tents In-Reply-To: Mail from Tony Li dated Tue, 25 Sep 2001 02:24:04 PDT <15280.19764.178150.885970@alpha-tli.procket.com> Message-ID: <20010925182817.9E3B0F2C45@prattle.redback.com> Agreed the static redistribution is not as clear as the connected, that's why I suggested zillions of knobs to control this "overload bit" feature;-) If a non-bgp customer of an ISP has it's own address space, then usually static route is used in this case, even though the preferable way is to inject this static into ibgp, but if the ISP likes to inject this into IGP, then it would be good to redistribute them even in "oeveload" state since this may be the only way to reach this customer. Yes, only the users can really decide how the static route is being used in their network. Another way of looking at this; since the router needs to redistribute connect and static into igp, then it's an edge router. so this bgp related "overload" feature should be disabled on this router, since it usually does not handle transit traffic. last one is of course we never have to consider bgp related "overload", since everything at least in "millisecond or nanosecond convergence", before we have time to build LSP, the routing is already converged... ] ] ]Interesting... ] ]If the router is truly in an overload state, I would tend to want as much ]traffic to shy away from it as possible. This is just because overloaded ]routers tend to behave Very Predictably. Also Very Badly. ;-) ] ]If the router is instead in overload to avoid carrying transit traffic, ]then I would also want to not advertise routes that would tend to ADD ]transit traffic. ] ]In my grokking of 10589, the only reason to advertise anything is to allow ]reachability to ESes behind a single overloaded router. The direct analog ]in IP would only to allow interface prefixes (or redistribute connected). ]I'd argue that even redistrubted static routes are more likely to be in the ]transit class. ] ]Tony ] ]Naiming Shen writes: ] | ] | Yes, it makes sense to allow redistributed source from connected or ] | static through. So this is very implementation related, and one can ] | have knobs to do so. But a good practice is to aggragate connected ] | and static routes on the router then import them into ibgp instead ] | of into igp. ] | ] | ]--=_IS_MIME_Boundary ] | ]Content-Type: text/plain; ] | ] charset="iso-8859-1" ] | ] ] | ]Naiming, ] | ] ] | ]In you previous e-mail, the 3rd type of sources may comes from different ] | ]protocols that are redistributed into ISIS. It may contains directly ] | ]connected routes, statically configured routes and routes redistributed from ] | ]other protocols. If the router is or claims in an "overload" condition, ] | ]should it still include the redistributed directly connected routes and ] | ]statically routes? ] | ] ] | ]Xiaomei Lu ] | ] ] | ] ] | ]-----Original Message----- ] | ]From: Naiming Shen [mailto:naiming@redback.com] ] | ]Sent: Thursday, September 06, 2001 11:43 AM ] | ]To: Ken Larmer ] | ]Cc: Isis-Wg@Spider. Juniper. Net; Jeff Parker; Chuck Ouimette ] | ]Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV ] | ]contents ] | ] ] | ] ] | ] ] | ]Ken, ] | ] ] | ] It seems to me more like an implementation issue, I at least ] | ]know more than one venders do this correctly. ] | ] ] | ] This problem does not need to be only happening on L2 LSPs of ] | ]a L1/L2 border router(to borrow an ospf term), when a router originating ] | ]it's own LSPs, it has three sources for it's IP tlv: ] | ] ] | ] (1) it's own IP subnets on interfaces ] | ] (2) route leaking between levels, either L2 routes leaks down into L1 ] | ] or L1 routes leaks up into L2 domain, this only happens on L1/L2 ] | ] border routers. ] | ] (3) external IP routes redistributed into ISIS on either levels. ] | ] ] | ] When an ISIS router is in "normal" condition, it can possibly ] | ]do any or all the the three above while building it's own LSPs, but when ] | ]a router is or claims in an "overload" condition, and if it is able to ] | ]update and send out newer version of it's LSPs, it should only do the ] | ]first one, and skip the next two if is configured to do so. ] | ] ] | ] But it's a good idea to document this somewhere. Thanks. ] | ] ] | ] ] | ] | - Naiming ] | _______________________________________________ ] | Isis-wg mailing list - Isis-wg@external.juniper.net ] | http://external.juniper.net/mailman/listinfo/isis-wg ] | _______________________________________________ ] | Isis-wg-external mailing list ] | Isis-wg-external@mailist.procket.com ] | http://mailist.procket.com/mailman/listinfo/isis-wg-external ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From oran@cisco.com Wed Sep 26 20:06:00 2001 From: oran@cisco.com (David R. Oran) Date: Wed, 26 Sep 2001 15:06:00 -0400 Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV con tents In-Reply-To: <15280.19764.178150.885970@alpha-tli.procket.com> Message-ID: <027101c146be$486195d0$724e44ab@cisco.com> > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net] On Behalf Of Tony Li > Sent: Tuesday, September 25, 2001 5:24 AM > To: Naiming Shen > Cc: May Lu; Isis-Wg@Spider. Juniper. Net > Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability > Information TLV con tents > > > > > Interesting... > > If the router is truly in an overload state, I would tend to > want as much traffic to shy away from it as possible. This > is just because overloaded routers tend to behave Very > Predictably. Also Very Badly. ;-) > > If the router is instead in overload to avoid carrying > transit traffic, then I would also want to not advertise > routes that would tend to ADD transit traffic. > > In my grokking of 10589, the only reason to advertise > anything is to allow reachability to ESes behind a single > overloaded router. The direct analog in IP would only to > allow interface prefixes (or redistribute connected). I'd > argue that even redistrubted static routes are more likely to > be in the transit class. > Just to give the historical motivation, the idea was to maximize the probability network management would work to reach through a busted router by chaining Telnets or SNMP through the reachable ESs. The "cause" of the problem might be some other router than the one in overload state. Dave. From dasnabendu@yahoo.com Fri Oct 5 12:28:31 2001 From: dasnabendu@yahoo.com (nabendu das) Date: Fri, 5 Oct 2001 04:28:31 -0700 (PDT) Subject: [Isis-wg] spf implementation for level2 Message-ID: <20011005112831.78187.qmail@web13201.mail.yahoo.com> --0-774477117-1002281311=:75661 Content-Type: text/plain; charset=us-ascii hi list, about SPF implementation as per ISO -10589, TENT and PATH are of the form where N is a system identifier of 8 octet. But level2 SPF database & level2 forwarding database stores the address prefixs of the destination area. now my question is how to get area or area prefix after the SPF because we are operating the SPF only on system IDs. one thing can be done to get the area addresses from the LSP of the IS . but then how to arrange the SPF & forwarding database for level 2. for level1, we can hash on system ID & can store all the info of SPF & forwarding database in a single linked list for all the systems whose ID hashes to a particular hash value. u plz guide me for level 2 data structures for SPF & forwarding & also how to arrange those data structures. can we use hashing, & if so how is it done on the area addresses/ area prefixes. thanking in advance --------------------------------- Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. Yahoo! by Phone. --0-774477117-1002281311=:75661 Content-Type: text/html; charset=us-ascii

hi list,

about SPF implementation as per  ISO -10589, TENT and PATH are of the form <N, d(N), adj(N)> where N is a system identifier of 8 octet. But level2 SPF database & level2 forwarding database stores the address prefixs of the destination area. now my question is how to get area or area prefix after the SPF because we are operating the SPF only on system IDs. one thing can be done to get the area addresses from the LSP of the IS .  but then how to arrange the SPF & forwarding database for level 2. for level1, we can hash on system ID & can store all the info of SPF &  forwarding database in a single linked list for all the systems whose ID hashes to a particular hash value.

u plz guide me for level 2 data structures for SPF & forwarding & also how to arrange those data structures. can we use hashing, & if so how is it done on the area addresses/ area prefixes.

thanking in advance

 


Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. Yahoo! by Phone. --0-774477117-1002281311=:75661-- From sherwin@torrentnet.com Mon Oct 8 21:28:16 2001 From: sherwin@torrentnet.com (Chris Sherwin) Date: Mon, 08 Oct 2001 16:28:16 -0400 Subject: [Isis-wg] Status of some drafts Message-ID: <200110082028.f98KSGJ04443@malibu.torrentnet.com> Hi, I am interested in knowing what the status of some work in this group is. In particular, I have been browsing the workgroup's mail archive and various proceedings trying to figure out what happened to the IS-IS over IPv4 and 3-way handshake efforts. It seems they have expired? They are listed as submitted for RFC status, but I cannot find any RFCs, although I can pick up old copies of the drafts. Even if expired, are these drafts supported widely in industry? Thanks, Chris. From tli@Procket.com Wed Oct 10 10:05:36 2001 From: tli@Procket.com (Tony Li) Date: Wed, 10 Oct 2001 02:05:36 -0700 Subject: [Isis-wg] Status of some drafts In-Reply-To: <200110082028.f98KSGJ04443@malibu.torrentnet.com> References: <200110082028.f98KSGJ04443@malibu.torrentnet.com> Message-ID: <15300.3936.346196.194436@alpha-tli.procket.com> | I am interested in knowing what the status of some work in this group | is. In particular, I have been browsing the workgroup's mail archive | and various proceedings trying to figure out what happened to | the IS-IS over IPv4 and 3-way handshake efforts. | | It seems they have expired? They are listed as submitted for RFC status, | but I cannot find any RFCs, although I can pick up old copies of the | drafts. | | Even if expired, are these drafts supported widely in industry? Chris, I believe that we, as a group, came to the consensus that the IS-IS over IPv4 draft was not necessary. There were better ways of solving that particular problem. The 3-way handshake was being driven by Tony P. He's offline at the moment and I think we'll have to wait for his input. I'm hoping that it moves forward and I know that it's been implemented multiple times. Tony From prz@net4u.ch Wed Oct 10 12:49:37 2001 From: prz@net4u.ch (Tony Przygienda) Date: Wed, 10 Oct 2001 13:49:37 +0200 (MEST) Subject: [Isis-wg] Status of some drafts In-Reply-To: <15300.3936.346196.194436@alpha-tli.procket.com> from Tony Li at "Oct 10, 2001 2: 5:36 am" Message-ID: <200110101149.NAA22067@net4u.net4u.ch> > > > | I am interested in knowing what the status of some work in this group > | is. In particular, I have been browsing the workgroup's mail archive > | and various proceedings trying to figure out what happened to > | the IS-IS over IPv4 and 3-way handshake efforts. > | > | It seems they have expired? They are listed as submitted for RFC status, > | but I cannot find any RFCs, although I can pick up old copies of the > | drafts. > | > | Even if expired, are these drafts supported widely in industry? > > > Chris, > > I believe that we, as a group, came to the consensus that the IS-IS over > IPv4 draft was not necessary. There were better ways of solving that > particular problem. yes, on ice now, if major reasons come up, will revive it. > The 3-way handshake was being driven by Tony P. He's offline at the moment > and I think we'll have to wait for his input. I'm hoping that it moves > forward and I know that it's been implemented multiple times. yes, multiple drafts are after last call stuck in 'will be RFC any minute now' status. Will check with AD later -- tony From jparker@axiowave.com Wed Oct 10 14:33:08 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 10 Oct 2001 09:33:08 -0400 Subject: [Isis-wg] Status of some drafts Message-ID: > > The 3-way handshake ... [is] > > stuck in 'will be RFC any minute now' status. Pity there is no way to have a semi-official link to docs that are between stools. I have a bootleg copy of draft-ietf-isis-3way-03.txt that I'd be happy to forward to those who need to implement but don't have any text. - jeff parker From zengjing_sec@yahoo.com Wed Oct 10 19:30:21 2001 From: zengjing_sec@yahoo.com (Jing Zeng) Date: Wed, 10 Oct 2001 11:30:21 -0700 Subject: [Isis-wg] Status of some drafts In-Reply-To: <200110101149.NAA22067@net4u.net4u.ch> Message-ID: Can any body explain the idea of three way handshake for ISIS or give some draft about this topic? (Sorry, I am new to this mailing-list) Jing -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Tony Przygienda Sent: Wednesday, October 10, 2001 4:50 AM To: Tony Li Cc: sherwin@torrentnet.com; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Status of some drafts > > > | I am interested in knowing what the status of some work in this group > | is. In particular, I have been browsing the workgroup's mail archive > | and various proceedings trying to figure out what happened to > | the IS-IS over IPv4 and 3-way handshake efforts. > | > | It seems they have expired? They are listed as submitted for RFC status, > | but I cannot find any RFCs, although I can pick up old copies of the > | drafts. > | > | Even if expired, are these drafts supported widely in industry? > > > Chris, > > I believe that we, as a group, came to the consensus that the IS-IS over > IPv4 draft was not necessary. There were better ways of solving that > particular problem. yes, on ice now, if major reasons come up, will revive it. > The 3-way handshake was being driven by Tony P. He's offline at the moment > and I think we'll have to wait for his input. I'm hoping that it moves > forward and I know that it's been implemented multiple times. yes, multiple drafts are after last call stuck in 'will be RFC any minute now' status. Will check with AD later -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From jparker@axiowave.com Wed Oct 10 20:21:49 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 10 Oct 2001 15:21:49 -0400 Subject: [Isis-wg] Status of some drafts Message-ID: > Can any body explain the idea of three way handshake for ISIS or give > some draft about this topic? (Sorry, I am new to this mailing-list) > > Jing Jing - >From the draft. The IS-IS protocol [1] assumes certain requirements stated in ISO 10589 (section 6.7.2) for the operation of IS-IS over point-to-point links and hence provides only a two-way handshake when establishing adjacencies on point-to-point links. The protocol does not operate correctly if these subnetwork requirements for point-to-point links are not met. The basic mechanism defined in the standard is that each side declares the other side to be reachable if a Hello packet is heard from it. Once this occurs, each side then sends a Complete Sequence Number PDU (CSNP) to trigger database synchronization. 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). In addition, SONET links bring a third issue, which is that when SONET protection is used, 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. The solution proposed here ensures correct operation of the protocol over unreliable point-to-point links. As part of the solution to the three-way handshaking issue, a method is defined for supporting more than 256 point-to-point interfaces which is more robust than the ad hoc methods currently in use. I will send you a copy of the draft off-line. - jeff parker - axiowave networks From bmammen@celoxnetworks.com Thu Oct 11 00:24:21 2001 From: bmammen@celoxnetworks.com (Mammen, Biju) Date: Wed, 10 Oct 2001 19:24:21 -0400 Subject: [Isis-wg] isisSysInstance Message-ID: <1117F7D44159934FB116E36F4ABF221B5A3CBD@celox-ma1-ems1.celoxnetworks.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_000_01C151E2.B0F80EB0 Content-Type: text/plain; charset="iso-8859-1" Hello all, This question seems to have popped up time and again but have gone unanswered on all occasions. Some guidance is really appreciated: a) What would be the implication of defining multiple instances of ISIS (as per draft-ietf-isis-wg-mib-05.txt)? b) Would all these instances work on the same Unified routing table or different ones? c) Would each of this instance have its own LSDatabases? d) Is this the same as CISCO's view of multi area support in a single router? ( A single Level 2 and 28 Level 1s) Thanks and regards Biju ------_=_NextPart_000_01C151E2.B0F80EB0 Content-Type: application/octet-stream; name="Mammen, Biju.vcf" Content-Disposition: attachment; filename="Mammen, Biju.vcf" BEGIN:VCARD VERSION:2.1 N:Mammen;Biju FN:Mammen, Biju ORG:;Development Engineering TITLE:MTS TEL;WORK;VOICE:508-305-7258 ADR;WORK:;2083;;Southborough;MA;;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2083=0D=0ASouthborough, MA=0D=0AUSA EMAIL;PREF;INTERNET:bmammen@celoxnetworks.com REV:20010625T155925Z END:VCARD ------_=_NextPart_000_01C151E2.B0F80EB0-- From Anand@ambernetworks.com Thu Oct 11 01:15:11 2001 From: Anand@ambernetworks.com (Anand Ammundi) Date: Wed, 10 Oct 2001 17:15:11 -0700 Subject: [Isis-wg] isisSysInstance Message-ID: <9F4704BE89F7D4118A0F0002B328C36CA0F789@usa04.ambernetworks.com> Biju, my 2C on this... firstly most of the multi-instance routing protocol is fairly vendor specific. One of driving forces behind multi-instancing is from the VPN angle. So for example, BGP with 2547 would route between PE's, preserving the respective VPN route identities, while the local CE - PE IGP (typically RIP or OSPF) would multi-instance themselves, typically per VPN routing space and run independently. (and then there is that virtual router !!) IP for it's part would have to maintain it's routes seperately per VPN, but here is where things are different from vendor to vendor. One could have a many-to-many relationship between IGP and IP. so you could have multi-instance IS-IS over 1 IP as also an instance over an instance of IP. (do note when I say ISIS o IP, I mean the routing table part) However, whatever be the implementation, the LSP database would logically be separate for each instance and each instance runs on its own steam. I don't know much about Cisco multi-area support though. hope this helps. regards anand -----Original Message----- From: Mammen, Biju [mailto:bmammen@celoxnetworks.com] Sent: Wednesday, October 10, 2001 4:24 PM To: 'isis-wg@external.juniper.net' Subject: [Isis-wg] isisSysInstance Hello all, This question seems to have popped up time and again but have gone unanswered on all occasions. Some guidance is really appreciated: a) What would be the implication of defining multiple instances of ISIS (as per draft-ietf-isis-wg-mib-05.txt)? b) Would all these instances work on the same Unified routing table or different ones? c) Would each of this instance have its own LSDatabases? d) Is this the same as CISCO's view of multi area support in a single router? ( A single Level 2 and 28 Level 1s) Thanks and regards Biju From naiming@redback.com Thu Oct 11 10:03:17 2001 From: naiming@redback.com (Naiming Shen) Date: Thu, 11 Oct 2001 02:03:17 -0700 Subject: [Isis-wg] isisSysInstance In-Reply-To: Mail from "Mammen, Biju" dated Wed, 10 Oct 2001 19:24:21 EDT <1117F7D44159934FB116E36F4ABF221B5A3CBD@celox-ma1-ems1.celoxnetworks.com> Message-ID: <20011011090317.AC7DD1DCC65@prattle.redback.com> ] ]Hello all, ]This question seems to have popped up time and again but have gone ]unanswered on all occasions. Some guidance is really appreciated: Never seen those questions before. ] ]a) What would be the implication of defining multiple instances of ]ISIS (as per draft-ietf-isis-wg-mib-05.txt)? More work. ] ]b) Would all these instances work on the same Unified routing table or ]different ones? It depends. One can have a single instance using multiple routing/forwarding tables, such as in the case of M-ISIS(multi-topology isis). One can also have multiple instances using a single routing/forwarding table. A good example will be this: an ISP has an old backbone, and is building a new/next-generation backbone. Those two backbones use two seperate IGPs(ISIS in this case) at least before the complete migration. If some of the routers are shared among those two backbones, they may want to put two ISIS instances on those routers and they can share(or not to share) the same routing table, even though two ISISes don't talk to each other. Since the backbone ISIS usually handles router's loopback addresses and internal networks, they may not have overlapping address space, so there is no reason not to share the same routing table. Even in the case they have overlapping addresses, they can always set one instance to be prefered in distance and hopefully they go to the same destinations. They can even redistribute routes between the two instances, so they can run two seperate IGPs but only one instance of BGP. Just to make sure the redistributed routes are tagged properly or using some address mask scheme so that the routes will not be redistributed back to it's originating instance. In the case of VPN application, they have overlapping address space and also destinating to different places, then multiple instnaces need to have multiple routing tables. So in general, we can say N instances will result in M routing tables, where M and N > 0, depends on the network requirement and implementations. ] ]c) Would each of this instance have its own LSDatabases? this is always true. ] ]d) Is this the same as CISCO's view of multi area support in a single ]router? ]( A single Level 2 and 28 Level 1s) no comment on specific implementation. thanks. ] ]Thanks and regards ]Biju ] - Naiming From sherwin@torrentnet.com Thu Oct 11 15:01:51 2001 From: sherwin@torrentnet.com (Chris Sherwin) Date: Thu, 11 Oct 2001 10:01:51 -0400 Subject: [Isis-wg] Status of some drafts In-Reply-To: Your message of "Wed, 10 Oct 2001 13:49:37 +0200." <200110101149.NAA22067@net4u.net4u.ch> Message-ID: <200110111401.f9BE1pv28204@malibu.torrentnet.com> Thanks to everyone for their quick responses to my question. So, I am wondering which other drafts are in this limbo state of being widely used/"will be RFC any minute now" like 3-way handshake, and which ones have been dropped as uninteresting, like IS-IS over IP? Chris. >> I believe that we, as a group, came to the consensus that the IS-IS over >> IPv4 draft was not necessary. There were better ways of solving that >> particular problem. > >yes, on ice now, if major reasons come up, will revive it. > >> The 3-way handshake was being driven by Tony P. He's offline at the moment >> and I think we'll have to wait for his input. I'm hoping that it moves >> forward and I know that it's been implemented multiple times. > >yes, multiple drafts are after last call stuck in 'will be RFC any minute >now' status. Will check with AD later > > -- tony > > From koen.vermeulen@alcatel.be Tue Oct 16 07:33:16 2001 From: koen.vermeulen@alcatel.be (Koen Vermeulen) Date: Tue, 16 Oct 2001 08:33:16 +0200 Subject: [Isis-wg] ManualL2Only Message-ID: <3BCBD4AC.7E461711@alcatel.be> Hello, Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an explicit rule whether or not to include the network address of a manualL2only-enabled interface in the L1 LSP generated by a L1/L2 IS. Somebody has some ideas/good reasons for not including the address of that manualL2only interface in L1? Thanks, Koen From jlearman@cisco.com Wed Oct 17 15:19:39 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 17 Oct 2001 10:19:39 -0400 Subject: [Isis-wg] ManualL2Only In-Reply-To: <3BCBD4AC.7E461711@alcatel.be> Message-ID: <4.3.2.7.2.20011017100605.0195ae70@dingdong.cisco.com> At 02:33 AM 10/16/2001, Koen Vermeulen wrote: >Hello, > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an >explicit rule whether or not to include the network address >of a manualL2only-enabled interface in the L1 LSP generated >by a L1/L2 IS. >Somebody has some ideas/good reasons for not including >the address of that manualL2only interface in L1? Without consulting the specs, I can say that it doesn't make sense to include such an adjacency in the L1 LSP. If you do, then when you run SPF, you will either use "inadmissible" local knowledge when running SPF (thereby creating a different topology than other ISs) or else you won't heed the L2-only nature of the link and will forward L1 traffic on it. For example: A --- B ==== C ---- D | | E -- F -- G -- H -- I where all are in the same area, but the link between B and C is L2-only. If A wants to send data to D, it will send it to B. If B heeds the l2-only property, it would send it back to A. Note that B runs the SPF using the same data as everyone else: the LSDB. It uses its adjacency database also, true, but only to preload "tent" (or is it "paths", it's been a while). B needs to advertise links consistently with how it would use them itself, so that the area topology is identical for all ISs in the area. Regards, Jeff >Thanks, >Koen > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From koen.vermeulen@alcatel.be Wed Oct 17 16:13:30 2001 From: koen.vermeulen@alcatel.be (Koen Vermeulen) Date: Wed, 17 Oct 2001 17:13:30 +0200 Subject: [Isis-wg] ManualL2Only References: Message-ID: <3BCDA01A.C97B057@alcatel.be> Hello Jeff, I think I have to be more specific, because it seems that my question was not understood completely. I will try to explain what I meant with an example. Suppose you have following 3 IS's: 1 2 A ----- B ----- C L1 L1/L2 L2 where link 2 has network address x and is configured as manualL2only. This means that B will only try to form a L2 adjacency with C. My question is now: is it allowed to add address x in an ip reachability TLV to the L1 LSP of B or will this lead to some problems? Right now, I can't think of any problems adding the network address of a manualL2only to L1. I would even expect that this way of working is the correct one because of the fact that IS-IS areas cut through interfaces and not through routers as is done in OSPF. I hope this makes my question more clear? Thanks, Koen Jeff Learman wrote: > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > >Hello, > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > >explicit rule whether or not to include the network address > >of a manualL2only-enabled interface in the L1 LSP generated > >by a L1/L2 IS. > >Somebody has some ideas/good reasons for not including > >the address of that manualL2only interface in L1? > > Without consulting the specs, I can say that it doesn't make > sense to include such an adjacency in the L1 LSP. If you do, > then when you run SPF, you will either use "inadmissible" > local knowledge when running SPF (thereby creating a different > topology than other ISs) or else you won't heed the L2-only > nature of the link and will forward L1 traffic on it. > > For example: > > A --- B ==== C ---- D > | | > E -- F -- G -- H -- I > > where all are in the same area, but the link between B and C > is L2-only. If A wants to send data to D, it will send it to > B. If B heeds the l2-only property, it would send it back to A. > > Note that B runs the SPF using the same data as everyone else: > the LSDB. It uses its adjacency database also, true, but only > to preload "tent" (or is it "paths", it's been a while). > > B needs to advertise links consistently with how it would use > them itself, so that the area topology is identical for all ISs > in the area. > > Regards, > Jeff > > >Thanks, > >Koen > > > >_______________________________________________ > >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 Larmer@CommSense.Net Wed Oct 17 16:33:31 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Wed, 17 Oct 2001 11:33:31 -0400 Subject: [Isis-wg] ManualL2Only In-Reply-To: <4.3.2.7.2.20011017100605.0195ae70@dingdong.cisco.com> Message-ID: Hi Koen, I found the following conflicting references. ISO-10589 V1 states the following: -In the Intermediate System Neighbours option the set of Intermediate system IDs of neighbouring In termediate systems formed from: The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode) from adjacencies in the state Up, on circuits of type Point-Point, In or Out, with xneighbourSystemType L1 Intermediate System xneighbourSystemType L2 Intermediate System and adjacencyUsage Level 2 or Level1 and 2. ISO-10589 V2 states the following: 7.3.7 Generation of level 1 LSPs (non-pseudonode) - In the Intermediate System Neighbours option - the set of Intermediate system IDs of neighbouring Intermediate systems formed from . The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode) from adjacencies in the state "Up", on circuits of type "ptToPt", "staticIn", or "staticOut", with x neighbourSystemType "L1 Intermediate System" x neighbourSystemType "L2 Intermediate System" and adjacencyUsage "Level 1" or "Level 1 and 2". I believe that this section should read as follows: 7.3.7 Generation of level 1 LSPs (non-pseudonode) - In the Intermediate System Neighbours option - the set of Intermediate system IDs of neighbouring Intermediate systems formed from . The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode) from adjacencies in the state "Up", on circuits of type "ptToPt", "staticIn", or "staticOut", with x neighbourSystemType "L1 Intermediate System" RFC-1195 states the following for the IP Internal Reachability Information TLV for both L1 and L2 LSPs. IP Internal Reachability Information -- IP addresses within the routing domain reachable directly via one or more interfaces on this Intermediate system. I believe this should read as follows for L1 LSPs IP Internal Reachability Information -- IP addresses within the L1 routing subdomain reachable directly via one or more interfaces on this Intermediate system. Cheers, Ken Larmer CommSense Networks www.commsense.net > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman > Sent: Wednesday, October 17, 2001 10:20 AM > To: Koen Vermeulen > Cc: Isis-wg > Subject: Re: [Isis-wg] ManualL2Only > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > >Hello, > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > >explicit rule whether or not to include the network address > >of a manualL2only-enabled interface in the L1 LSP generated > >by a L1/L2 IS. > >Somebody has some ideas/good reasons for not including > >the address of that manualL2only interface in L1? > > Without consulting the specs, I can say that it doesn't make > sense to include such an adjacency in the L1 LSP. If you do, > then when you run SPF, you will either use "inadmissible" > local knowledge when running SPF (thereby creating a different > topology than other ISs) or else you won't heed the L2-only > nature of the link and will forward L1 traffic on it. > > For example: > > A --- B ==== C ---- D > | | > E -- F -- G -- H -- I > > where all are in the same area, but the link between B and C > is L2-only. If A wants to send data to D, it will send it to > B. If B heeds the l2-only property, it would send it back to A. > > Note that B runs the SPF using the same data as everyone else: > the LSDB. It uses its adjacency database also, true, but only > to preload "tent" (or is it "paths", it's been a while). > > B needs to advertise links consistently with how it would use > them itself, so that the area topology is identical for all ISs > in the area. > > Regards, > Jeff > > > >Thanks, > >Koen > > > >_______________________________________________ > >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 Wed Oct 17 16:44:32 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 17 Oct 2001 11:44:32 -0400 Subject: [Isis-wg] ManualL2Only In-Reply-To: <3BCDA01A.C97B057@alcatel.be> References: Message-ID: <4.3.2.7.2.20011017112619.0193ea88@dingdong.cisco.com> Reading your original email more carefully, I see I made a mistake. You were talking about the interface address, not the adjacency. This case would not be covered in ISO 10589, because in OSI, interfaces do not have network layer addresses. It's only an issue for IP addresses. In general, I would prefer using an unnumbered interface between areas, if possible, to avoid wasting a subnet address that can't be wholly within a single area, and therefore able to be summarized. This is a minor point, and it's often not possible to use an unnumbered interface, so the question remains. I don't see any harm in including the address, and I don't see any benefit to omitting it. I don't have a lot of experience in integrated IS-IS, though, so you may want to wait for other opinions. Regards, Jeff Disclaimer: I am not working on IS-IS at Cisco nor am I familiar with Cisco's IS-IS implementation. Just trying to keep brain cells from a previous job alive. At 11:13 AM 10/17/2001, Koen Vermeulen wrote: >Hello Jeff, > >I think I have to be more specific, because it seems that >my question was not understood completely. I will try to >explain what I meant with an example. > >Suppose you have following 3 IS's: > > 1 2 >A ----- B ----- C >L1 L1/L2 L2 > >where link 2 has network address x and is configured as >manualL2only. This means that B will only try to form >a L2 adjacency with C. >My question is now: is it allowed to add address x in an ip >reachability TLV to the L1 LSP of B or will this lead to >some problems? >Right now, I can't think of any problems adding the >network address of a manualL2only to L1. I would >even expect that this way of working is the correct >one because of the fact that IS-IS areas cut through >interfaces and not through routers as is done in OSPF. > >I hope this makes my question more clear? > >Thanks, >Koen > >Jeff Learman wrote: > >> At 02:33 AM 10/16/2001, Koen Vermeulen wrote: >> >Hello, >> > >> >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an >> >explicit rule whether or not to include the network address >> >of a manualL2only-enabled interface in the L1 LSP generated >> >by a L1/L2 IS. >> >Somebody has some ideas/good reasons for not including >> >the address of that manualL2only interface in L1? >> >> Without consulting the specs, I can say that it doesn't make >> sense to include such an adjacency in the L1 LSP. If you do, >> then when you run SPF, you will either use "inadmissible" >> local knowledge when running SPF (thereby creating a different >> topology than other ISs) or else you won't heed the L2-only >> nature of the link and will forward L1 traffic on it. >> >> For example: >> >> A --- B ==== C ---- D >> | | >> E -- F -- G -- H -- I >> >> where all are in the same area, but the link between B and C >> is L2-only. If A wants to send data to D, it will send it to >> B. If B heeds the l2-only property, it would send it back to A. >> >> Note that B runs the SPF using the same data as everyone else: >> the LSDB. It uses its adjacency database also, true, but only >> to preload "tent" (or is it "paths", it's been a while). >> >> B needs to advertise links consistently with how it would use >> them itself, so that the area topology is identical for all ISs >> in the area. >> >> Regards, >> Jeff >> >> >Thanks, >> >Koen >> > >> >_______________________________________________ >> >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 ginsberg@pluris.com Thu Oct 18 03:17:49 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 17 Oct 2001 19:17:49 -0700 Subject: [Isis-wg] ManualL2Only Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A748@avalon.pluris.com> The text in both ISO 10589 V1 and V2 is correct. Please see my comments in line. Les > -----Original Message----- > From: Ken Larmer [mailto:Larmer@CommSense.Net] > Sent: Wednesday, October 17, 2001 8:34 AM > To: Jeff Learman; Koen Vermeulen > Cc: Isis-wg > Subject: RE: [Isis-wg] ManualL2Only > > > Hi Koen, > > I found the following conflicting references. > > ISO-10589 V1 states the following: > > -In the Intermediate System Neighbours option the set of > Intermediate system > IDs of neighbouring In > termediate systems formed from: > > The set of neighbourSystemIDs with an appended zero octet (indicating > non-pseudonode) > from adjacencies in the state Up, on circuits of type > Point-Point, In or > Out, with > > xneighbourSystemType L1 Intermediate System > > xneighbourSystemType L2 Intermediate System and > adjacencyUsage Level 2 or > Level1 and 2. > You have misquoted the text from 7.3.7. It actually states: x neighbourSystemType L2 Intermediate System and adjacencyUsage Level 1 or Level1 and 2. This text is identical to the text found in V2 which you correctly quote below. > > ISO-10589 V2 states the following: > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > - In the Intermediate System Neighbours option - the set > of Intermediate > system IDs of neighbouring Intermediate systems formed from > > . The set of neighbourSystemIDs with an appended zero > octet (indicating > non-pseudonode) from adjacencies in the state "Up", on > circuits of type > "ptToPt", "staticIn", or "staticOut", with > > x neighbourSystemType "L1 Intermediate System" > > x neighbourSystemType "L2 Intermediate System" and > adjacencyUsage "Level 1" > or "Level 1 and 2". > > I believe that this section should read as follows: > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > - In the Intermediate System Neighbours option - the set > of Intermediate > system IDs of neighbouring Intermediate systems formed from > > . The set of neighbourSystemIDs with an appended zero > octet (indicating > non-pseudonode) from adjacencies in the state "Up", on > circuits of type > "ptToPt", "staticIn", or "staticOut", with > > x neighbourSystemType "L1 Intermediate System" > This is not correct. On a point-point circuit, a single adjacency is formed and the adjacency usage is set based upon the advertised circuit types (L1, L2-only, L1 and L2) and whether the neighbors share an area address. If one system is an L1 IS or an L2 IS with circuit type L1-only, then it would set circuit type to L1 and adjacency usage could only be L1. If both neighbors are L2 ISs and do not have the circuit set to L2-only, then adjacency usage will be Level 1 and 2. In both cases you would want to advertise this neighbor in your L1 LSP since it is reachable at this level. It is probably somewhat confusing to talk about "neighborSystemType" since what is actually advertised in IIH PDUs is "circuit type". While the IS type bounds the possible values for circuit type, it is not equivalent. A Level 2 IS is assumed to operate as an L1 IS in its area and can therefore use the circuit for both L1 and L2 traffic (default behavior) or designate the circuit as L1 only or L2 only. An L1 IS of course, can only use the circuit for L1 traffic. On LANs, separate adjacencies are formed for Level 1 and Level 2 and the adjacency usage can be implicitly set to L1 and L2 respectively. (This is not explicitly stated in the spec.) > > RFC-1195 states the following for the IP Internal > Reachability Information > TLV for both L1 and L2 LSPs. > > IP Internal Reachability Information -- IP addresses within > the routing > domain reachable directly via one or more interfaces on this > Intermediate > system. > > I believe this should read as follows for L1 LSPs > > IP Internal Reachability Information -- IP addresses within > the L1 routing > subdomain reachable directly via one or more interfaces on > this Intermediate > system. > > > > Cheers, > Ken Larmer > CommSense Networks > www.commsense.net > > > > -----Original Message----- > > From: isis-wg-admin@external.juniper.net > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman > > Sent: Wednesday, October 17, 2001 10:20 AM > > To: Koen Vermeulen > > Cc: Isis-wg > > Subject: Re: [Isis-wg] ManualL2Only > > > > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > > >Hello, > > > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > > >explicit rule whether or not to include the network address > > >of a manualL2only-enabled interface in the L1 LSP generated > > >by a L1/L2 IS. > > >Somebody has some ideas/good reasons for not including > > >the address of that manualL2only interface in L1? > > > > Without consulting the specs, I can say that it doesn't make > > sense to include such an adjacency in the L1 LSP. If you do, > > then when you run SPF, you will either use "inadmissible" > > local knowledge when running SPF (thereby creating a different > > topology than other ISs) or else you won't heed the L2-only > > nature of the link and will forward L1 traffic on it. > > > > For example: > > > > A --- B ==== C ---- D > > | | > > E -- F -- G -- H -- I > > > > where all are in the same area, but the link between B and C > > is L2-only. If A wants to send data to D, it will send it to > > B. If B heeds the l2-only property, it would send it back to A. > > > > Note that B runs the SPF using the same data as everyone else: > > the LSDB. It uses its adjacency database also, true, but only > > to preload "tent" (or is it "paths", it's been a while). > > > > B needs to advertise links consistently with how it would use > > them itself, so that the area topology is identical for all ISs > > in the area. > > > > Regards, > > Jeff > > > > > > >Thanks, > > >Koen > > > > > >_______________________________________________ > > >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 Larmer@CommSense.Net Fri Oct 19 14:05:24 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Fri, 19 Oct 2001 09:05:24 -0400 Subject: [Isis-wg] ManualL2Only In-Reply-To: <17C81AD1F1FED411991E006008F6D1CAA5A748@avalon.pluris.com> Message-ID: Hi Les, Please see my comments inline. Cheers, Ken Larmer > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: Wednesday, October 17, 2001 10:18 PM > To: 'Ken Larmer'; Jeff Learman; Koen Vermeulen > Cc: Isis-wg > Subject: RE: [Isis-wg] ManualL2Only > > > The text in both ISO 10589 V1 and V2 is correct. Please see my comments in > line. > > Les > > > > -----Original Message----- > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > Sent: Wednesday, October 17, 2001 8:34 AM > > To: Jeff Learman; Koen Vermeulen > > Cc: Isis-wg > > Subject: RE: [Isis-wg] ManualL2Only > > > > > > Hi Koen, > > > > I found the following conflicting references. > > > > ISO-10589 V1 states the following: > > > > -In the Intermediate System Neighbours option the set of > > Intermediate system > > IDs of neighbouring In > > termediate systems formed from: > > > > The set of neighbourSystemIDs with an appended zero octet (indicating > > non-pseudonode) > > from adjacencies in the state Up, on circuits of type > > Point-Point, In or > > Out, with > > > > xneighbourSystemType L1 Intermediate System > > > > xneighbourSystemType L2 Intermediate System and > > adjacencyUsage Level 2 or > > Level1 and 2. > > > > You have misquoted the text from 7.3.7. It actually states: > > x neighbourSystemType L2 Intermediate System and > adjacencyUsage Level 1 or > Level1 and 2. > Les, here is a cut and paste from RFC-1142 (Integrated IS-IS) 7.3.7 Generation of Level 1 LSPs (non-pseudonode) The Level 1 Link State PDU not generated on behalf of a pseudonode contains the following information in its variable length fields. ... -In the Intermediate System Neighbours option the set of Intermediate system IDs of neighbouring In termediate systems formed from: xThe set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode) from adjacencies in the state Up, on circuits of type Point-Point, In or Out, with xneighbourSystemType L1 Intermediate System xneighbourSystemType L2 Intermediate System and adjacencyUsage Level 2 or Level1 and 2. I believe this is different from the V2 spec? > This text is identical to the text found in V2 which you correctly quote > below. > > > > > ISO-10589 V2 states the following: > > > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > > > - In the Intermediate System Neighbours option - the set > > of Intermediate > > system IDs of neighbouring Intermediate systems formed from > > > > . The set of neighbourSystemIDs with an appended zero > > octet (indicating > > non-pseudonode) from adjacencies in the state "Up", on > > circuits of type > > "ptToPt", "staticIn", or "staticOut", with > > > > x neighbourSystemType "L1 Intermediate System" > > > > x neighbourSystemType "L2 Intermediate System" and > > adjacencyUsage "Level 1" > > or "Level 1 and 2". > > > > I believe that this section should read as follows: > > > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > > > - In the Intermediate System Neighbours option - the set > > of Intermediate > > system IDs of neighbouring Intermediate systems formed from > > > > . The set of neighbourSystemIDs with an appended zero > > octet (indicating > > non-pseudonode) from adjacencies in the state "Up", on > > circuits of type > > "ptToPt", "staticIn", or "staticOut", with > > > > x neighbourSystemType "L1 Intermediate System" > > > > This is not correct. > > On a point-point circuit, a single adjacency is formed and the adjacency > usage is set based upon the advertised circuit types (L1, L2-only, L1 and > L2) and whether the neighbors share an area address. If one > system is an L1 > IS or an L2 IS with circuit type L1-only, then it would set > circuit type to > L1 and adjacency usage could only be L1. If both neighbors are L2 > ISs and do > not have the circuit set to L2-only, then adjacency usage will be Level 1 > and 2. In both cases you would want to advertise this neighbor in your L1 > LSP since it is reachable at this level. Les, yes you are correct! I was looking at the text in the V1 spec when I made the above statement. Of course, my proposed text was still wrong! The V2 spec is correct! > It is probably somewhat confusing to talk about "neighborSystemType" since > what is actually advertised in IIH PDUs is "circuit type". While > the IS type > bounds the possible values for circuit type, it is not > equivalent. A Level 2 > IS is assumed to operate as an L1 IS in its area and can therefore use the > circuit for both L1 and L2 traffic (default behavior) or designate the > circuit as L1 only or L2 only. An L1 IS of course, can only use > the circuit > for L1 traffic. > > On LANs, separate adjacencies are formed for Level 1 and Level 2 and the > adjacency usage can be implicitly set to L1 and L2 respectively. (This is > not explicitly stated in the spec.) > > > > > RFC-1195 states the following for the IP Internal > > Reachability Information > > TLV for both L1 and L2 LSPs. > > > > IP Internal Reachability Information -- IP addresses within > > the routing > > domain reachable directly via one or more interfaces on this > > Intermediate > > system. > > > > I believe this should read as follows for L1 LSPs > > > > IP Internal Reachability Information -- IP addresses within > > the L1 routing > > subdomain reachable directly via one or more interfaces on > > this Intermediate > > system. > > Any comments on the above text??? > > > > Cheers, > > Ken Larmer > > CommSense Networks > > www.commsense.net > > > > > > > -----Original Message----- > > > From: isis-wg-admin@external.juniper.net > > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman > > > Sent: Wednesday, October 17, 2001 10:20 AM > > > To: Koen Vermeulen > > > Cc: Isis-wg > > > Subject: Re: [Isis-wg] ManualL2Only > > > > > > > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > > > >Hello, > > > > > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > > > >explicit rule whether or not to include the network address > > > >of a manualL2only-enabled interface in the L1 LSP generated > > > >by a L1/L2 IS. > > > >Somebody has some ideas/good reasons for not including > > > >the address of that manualL2only interface in L1? > > > > > > Without consulting the specs, I can say that it doesn't make > > > sense to include such an adjacency in the L1 LSP. If you do, > > > then when you run SPF, you will either use "inadmissible" > > > local knowledge when running SPF (thereby creating a different > > > topology than other ISs) or else you won't heed the L2-only > > > nature of the link and will forward L1 traffic on it. > > > > > > For example: > > > > > > A --- B ==== C ---- D > > > | | > > > E -- F -- G -- H -- I > > > > > > where all are in the same area, but the link between B and C > > > is L2-only. If A wants to send data to D, it will send it to > > > B. If B heeds the l2-only property, it would send it back to A. > > > > > > Note that B runs the SPF using the same data as everyone else: > > > the LSDB. It uses its adjacency database also, true, but only > > > to preload "tent" (or is it "paths", it's been a while). > > > > > > B needs to advertise links consistently with how it would use > > > them itself, so that the area topology is identical for all ISs > > > in the area. > > > > > > Regards, > > > Jeff > > > > > > > > > >Thanks, > > > >Koen > > > > > > > >_______________________________________________ > > > >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 ginsberg@pluris.com Fri Oct 19 20:04:22 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Fri, 19 Oct 2001 12:04:22 -0700 Subject: [Isis-wg] ManualL2Only Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A752@avalon.pluris.com> Ken - Using RFC 1142 as a reference is something I would strongly discourage. It was an early draft of ISO 10589 - many corrections were made before the 1992 ISO standard was published. Clearly the section you quoted was one of them. When I accused you of misquoting, I was assuming you were referencing the 1992 spec. Certainly, one should never refer to RFC 1142 as ISO 10589 V1 - that designation rightfully belongs to the 1992 ISO standard. I would also go one step further and encourage folks to use the 2001 V2 draft. This includes corrections to the 1992 spec. ftp.cisco.com/pub/rfc/ISO/ISO10589v2-2001-07-04.pdf As for the issue of advertising directly connected reachability for L2-only circuits in L1 LSPs, I am not in favor of that. L1 routers are supposed to direct packets destined for addresses "out of the area" to the nearest L2 router. Including L2-only reachability deviates from that model - and I see no compelling reason to do so. Les > -----Original Message----- > From: Ken Larmer [mailto:Larmer@CommSense.Net] > Sent: Friday, October 19, 2001 6:05 AM > To: Les Ginsberg; Jeff Learman; Koen Vermeulen > Cc: Isis-wg > Subject: RE: [Isis-wg] ManualL2Only > > > Hi Les, > > Please see my comments inline. > > Cheers, > Ken Larmer > > > -----Original Message----- > > From: Les Ginsberg [mailto:ginsberg@pluris.com] > > Sent: Wednesday, October 17, 2001 10:18 PM > > To: 'Ken Larmer'; Jeff Learman; Koen Vermeulen > > Cc: Isis-wg > > Subject: RE: [Isis-wg] ManualL2Only > > > > > > The text in both ISO 10589 V1 and V2 is correct. Please see > my comments in > > line. > > > > Les > > > > > > > -----Original Message----- > > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > > Sent: Wednesday, October 17, 2001 8:34 AM > > > To: Jeff Learman; Koen Vermeulen > > > Cc: Isis-wg > > > Subject: RE: [Isis-wg] ManualL2Only > > > > > > > > > Hi Koen, > > > > > > I found the following conflicting references. > > > > > > ISO-10589 V1 states the following: > > > > > > -In the Intermediate System Neighbours option the set of > > > Intermediate system > > > IDs of neighbouring In > > > termediate systems formed from: > > > > > > The set of neighbourSystemIDs with an appended zero octet > (indicating > > > non-pseudonode) > > > from adjacencies in the state Up, on circuits of type > > > Point-Point, In or > > > Out, with > > > > > > xneighbourSystemType L1 Intermediate System > > > > > > xneighbourSystemType L2 Intermediate System and > > > adjacencyUsage Level 2 or > > > Level1 and 2. > > > > > > > You have misquoted the text from 7.3.7. It actually states: > > > > x neighbourSystemType L2 Intermediate System and > > adjacencyUsage Level 1 or > > Level1 and 2. > > > > Les, here is a cut and paste from RFC-1142 (Integrated IS-IS) > > 7.3.7 Generation of Level 1 LSPs (non-pseudonode) > The Level 1 Link State PDU not generated on behalf of a > pseudonode contains > the following information in its variable length fields. > ... > -In the Intermediate System Neighbours option the set of > Intermediate system > IDs of neighbouring In > termediate systems formed from: > > xThe set of neighbourSystemIDs with an appended zero octet (indicating > non-pseudonode) > from adjacencies in the state Up, on circuits of type > Point-Point, In or > Out, with > > xneighbourSystemType L1 Intermediate System > > xneighbourSystemType L2 Intermediate System and > adjacencyUsage Level 2 or > Level1 and 2. > > I believe this is different from the V2 spec? > > > This text is identical to the text found in V2 which you > correctly quote > > below. > > > > > > > > ISO-10589 V2 states the following: > > > > > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > > > > > - In the Intermediate System Neighbours option - the set > > > of Intermediate > > > system IDs of neighbouring Intermediate systems formed from > > > > > > . The set of neighbourSystemIDs with an appended zero > > > octet (indicating > > > non-pseudonode) from adjacencies in the state "Up", on > > > circuits of type > > > "ptToPt", "staticIn", or "staticOut", with > > > > > > x neighbourSystemType "L1 Intermediate System" > > > > > > x neighbourSystemType "L2 Intermediate System" and > > > adjacencyUsage "Level 1" > > > or "Level 1 and 2". > > > > > > I believe that this section should read as follows: > > > > > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > > > > > - In the Intermediate System Neighbours option - the set > > > of Intermediate > > > system IDs of neighbouring Intermediate systems formed from > > > > > > . The set of neighbourSystemIDs with an appended zero > > > octet (indicating > > > non-pseudonode) from adjacencies in the state "Up", on > > > circuits of type > > > "ptToPt", "staticIn", or "staticOut", with > > > > > > x neighbourSystemType "L1 Intermediate System" > > > > > > > This is not correct. > > > > On a point-point circuit, a single adjacency is formed and > the adjacency > > usage is set based upon the advertised circuit types (L1, > L2-only, L1 and > > L2) and whether the neighbors share an area address. If one > > system is an L1 > > IS or an L2 IS with circuit type L1-only, then it would set > > circuit type to > > L1 and adjacency usage could only be L1. If both neighbors are L2 > > ISs and do > > not have the circuit set to L2-only, then adjacency usage > will be Level 1 > > and 2. In both cases you would want to advertise this > neighbor in your L1 > > LSP since it is reachable at this level. > > Les, yes you are correct! I was looking at the text in the V1 > spec when I > made the above statement. Of course, my proposed text was > still wrong! The > V2 spec is correct! > > > It is probably somewhat confusing to talk about > "neighborSystemType" since > > what is actually advertised in IIH PDUs is "circuit type". While > > the IS type > > bounds the possible values for circuit type, it is not > > equivalent. A Level 2 > > IS is assumed to operate as an L1 IS in its area and can > therefore use the > > circuit for both L1 and L2 traffic (default behavior) or > designate the > > circuit as L1 only or L2 only. An L1 IS of course, can only use > > the circuit > > for L1 traffic. > > > > On LANs, separate adjacencies are formed for Level 1 and > Level 2 and the > > adjacency usage can be implicitly set to L1 and L2 > respectively. (This is > > not explicitly stated in the spec.) > > > > > > > > RFC-1195 states the following for the IP Internal > > > Reachability Information > > > TLV for both L1 and L2 LSPs. > > > > > > IP Internal Reachability Information -- IP addresses within > > > the routing > > > domain reachable directly via one or more interfaces on this > > > Intermediate > > > system. > > > > > > I believe this should read as follows for L1 LSPs > > > > > > IP Internal Reachability Information -- IP addresses within > > > the L1 routing > > > subdomain reachable directly via one or more interfaces on > > > this Intermediate > > > system. > > > > > Any comments on the above text??? > > > > > > > Cheers, > > > Ken Larmer > > > CommSense Networks > > > www.commsense.net > > > > > > > > > > -----Original Message----- > > > > From: isis-wg-admin@external.juniper.net > > > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of > Jeff Learman > > > > Sent: Wednesday, October 17, 2001 10:20 AM > > > > To: Koen Vermeulen > > > > Cc: Isis-wg > > > > Subject: Re: [Isis-wg] ManualL2Only > > > > > > > > > > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > > > > >Hello, > > > > > > > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > > > > >explicit rule whether or not to include the network address > > > > >of a manualL2only-enabled interface in the L1 LSP generated > > > > >by a L1/L2 IS. > > > > >Somebody has some ideas/good reasons for not including > > > > >the address of that manualL2only interface in L1? > > > > > > > > Without consulting the specs, I can say that it doesn't make > > > > sense to include such an adjacency in the L1 LSP. If you do, > > > > then when you run SPF, you will either use "inadmissible" > > > > local knowledge when running SPF (thereby creating a different > > > > topology than other ISs) or else you won't heed the L2-only > > > > nature of the link and will forward L1 traffic on it. > > > > > > > > For example: > > > > > > > > A --- B ==== C ---- D > > > > | | > > > > E -- F -- G -- H -- I > > > > > > > > where all are in the same area, but the link between B and C > > > > is L2-only. If A wants to send data to D, it will send it to > > > > B. If B heeds the l2-only property, it would send it back to A. > > > > > > > > Note that B runs the SPF using the same data as everyone else: > > > > the LSDB. It uses its adjacency database also, true, but only > > > > to preload "tent" (or is it "paths", it's been a while). > > > > > > > > B needs to advertise links consistently with how it would use > > > > them itself, so that the area topology is identical for all ISs > > > > in the area. > > > > > > > > Regards, > > > > Jeff > > > > > > > > > > > > >Thanks, > > > > >Koen > > > > > > > > > >_______________________________________________ > > > > >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 ginsberg@pluris.com Fri Oct 19 21:36:48 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Fri, 19 Oct 2001 13:36:48 -0700 Subject: [Isis-wg] ManualL2Only Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A754@avalon.pluris.com> > > Les, > > >As for the issue of advertising directly connected > reachability for L2-only > >circuits in L1 LSPs, I am not in favor of that. L1 routers > are supposed to > >direct packets destined for addresses "out of the area" to > the nearest L2 > >router. Including L2-only reachability deviates from that > model - and I see > >no compelling reason to do so. > > This is what I thought at first -- but the question was about > the LOCAL > IP address on the circuit, NOT the circuit itself or the remote IP > address. I see no reason not to advertise any of the box's > IP addresses, > do you? > Jeff - The question of advertising a /32 reachability to the interface address - as opposed to advertising reachability to the subnet connected to the L2-only circuit - is less interesting (at least to me). This is simply another advertisement for the router itself and is not likely to improve your chances of finding a shorter path to the router than you would have without this advertisement. This question is not really limited to the case of an L2-only interface and an L1-LSP. In theory, one could advertise /32 reachability to all local interface addresses - but this is not particularly useful, wastes LSP space, and is not typically done. Les > Note: this was sent only to you, but feel free to respond > using the list. > > > > Les > > > >> -----Original Message----- > >> From: Ken Larmer [mailto:Larmer@CommSense.Net] > >> Sent: Friday, October 19, 2001 6:05 AM > >> To: Les Ginsberg; Jeff Learman; Koen Vermeulen > >> Cc: Isis-wg > >> Subject: RE: [Isis-wg] ManualL2Only > >> > >> > >> Hi Les, > >> > >> Please see my comments inline. > >> > >> Cheers, > >> Ken Larmer > >> > >> > -----Original Message----- > >> > From: Les Ginsberg [mailto:ginsberg@pluris.com] > >> > Sent: Wednesday, October 17, 2001 10:18 PM > >> > To: 'Ken Larmer'; Jeff Learman; Koen Vermeulen > >> > Cc: Isis-wg > >> > Subject: RE: [Isis-wg] ManualL2Only > >> > > >> > > >> > The text in both ISO 10589 V1 and V2 is correct. Please see > >> my comments in > >> > line. > >> > > >> > Les > >> > > >> > > >> > > -----Original Message----- > >> > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > >> > > Sent: Wednesday, October 17, 2001 8:34 AM > >> > > To: Jeff Learman; Koen Vermeulen > >> > > Cc: Isis-wg > >> > > Subject: RE: [Isis-wg] ManualL2Only > >> > > > >> > > > >> > > Hi Koen, > >> > > > >> > > I found the following conflicting references. > >> > > > >> > > ISO-10589 V1 states the following: > >> > > > >> > > -In the Intermediate System Neighbours option the set of > >> > > Intermediate system > >> > > IDs of neighbouring In > >> > > termediate systems formed from: > >> > > > >> > > The set of neighbourSystemIDs with an appended zero octet > >> (indicating > >> > > non-pseudonode) > >> > > from adjacencies in the state Up, on circuits of type > >> > > Point-Point, In or > >> > > Out, with > >> > > > >> > > xneighbourSystemType L1 Intermediate System > >> > > > >> > > xneighbourSystemType L2 Intermediate System and > >> > > adjacencyUsage Level 2 or > >> > > Level1 and 2. > >> > > > >> > > >> > You have misquoted the text from 7.3.7. It actually states: > >> > > >> > x neighbourSystemType L2 Intermediate System and > >> > adjacencyUsage Level 1 or > >> > Level1 and 2. > >> > > >> > >> Les, here is a cut and paste from RFC-1142 (Integrated IS-IS) > >> > >> 7.3.7 Generation of Level 1 LSPs (non-pseudonode) > >> The Level 1 Link State PDU not generated on behalf of a > >> pseudonode contains > >> the following information in its variable length fields. > >> ... > >> -In the Intermediate System Neighbours option the set of > >> Intermediate system > >> IDs of neighbouring In > >> termediate systems formed from: > >> > >> xThe set of neighbourSystemIDs with an appended zero octet > (indicating > >> non-pseudonode) > >> from adjacencies in the state Up, on circuits of type > >> Point-Point, In or > >> Out, with > >> > >> xneighbourSystemType L1 Intermediate System > >> > >> xneighbourSystemType L2 Intermediate System and > >> adjacencyUsage Level 2 or > >> Level1 and 2. > >> > >> I believe this is different from the V2 spec? > >> > >> > This text is identical to the text found in V2 which you > >> correctly quote > >> > below. > >> > > >> > > > >> > > ISO-10589 V2 states the following: > >> > > > >> > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > >> > > > >> > > - In the Intermediate System Neighbours option - the set > >> > > of Intermediate > >> > > system IDs of neighbouring Intermediate systems formed from > >> > > > >> > > . The set of neighbourSystemIDs with an appended zero > >> > > octet (indicating > >> > > non-pseudonode) from adjacencies in the state "Up", on > >> > > circuits of type > >> > > "ptToPt", "staticIn", or "staticOut", with > >> > > > >> > > x neighbourSystemType "L1 Intermediate System" > >> > > > >> > > x neighbourSystemType "L2 Intermediate System" and > >> > > adjacencyUsage "Level 1" > >> > > or "Level 1 and 2". > >> > > > >> > > I believe that this section should read as follows: > >> > > > >> > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > >> > > > >> > > - In the Intermediate System Neighbours option - the set > >> > > of Intermediate > >> > > system IDs of neighbouring Intermediate systems formed from > >> > > > >> > > . The set of neighbourSystemIDs with an appended zero > >> > > octet (indicating > >> > > non-pseudonode) from adjacencies in the state "Up", on > >> > > circuits of type > >> > > "ptToPt", "staticIn", or "staticOut", with > >> > > > >> > > x neighbourSystemType "L1 Intermediate System" > >> > > > >> > > >> > This is not correct. > >> > > >> > On a point-point circuit, a single adjacency is formed and > >> the adjacency > >> > usage is set based upon the advertised circuit types (L1, > >> L2-only, L1 and > >> > L2) and whether the neighbors share an area address. If one > >> > system is an L1 > >> > IS or an L2 IS with circuit type L1-only, then it would set > >> > circuit type to > >> > L1 and adjacency usage could only be L1. If both neighbors are L2 > >> > ISs and do > >> > not have the circuit set to L2-only, then adjacency usage > >> will be Level 1 > >> > and 2. In both cases you would want to advertise this > >> neighbor in your L1 > >> > LSP since it is reachable at this level. > >> > >> Les, yes you are correct! I was looking at the text in the V1 > >> spec when I > >> made the above statement. Of course, my proposed text was > >> still wrong! The > >> V2 spec is correct! > >> > >> > It is probably somewhat confusing to talk about > >> "neighborSystemType" since > >> > what is actually advertised in IIH PDUs is "circuit type". While > >> > the IS type > >> > bounds the possible values for circuit type, it is not > >> > equivalent. A Level 2 > >> > IS is assumed to operate as an L1 IS in its area and can > >> therefore use the > >> > circuit for both L1 and L2 traffic (default behavior) or > >> designate the > >> > circuit as L1 only or L2 only. An L1 IS of course, can only use > >> > the circuit > >> > for L1 traffic. > >> > > >> > On LANs, separate adjacencies are formed for Level 1 and > >> Level 2 and the > >> > adjacency usage can be implicitly set to L1 and L2 > >> respectively. (This is > >> > not explicitly stated in the spec.) > >> > > >> > > > >> > > RFC-1195 states the following for the IP Internal > >> > > Reachability Information > >> > > TLV for both L1 and L2 LSPs. > >> > > > >> > > IP Internal Reachability Information -- IP addresses within > >> > > the routing > >> > > domain reachable directly via one or more interfaces on this > >> > > Intermediate > >> > > system. > >> > > > >> > > I believe this should read as follows for L1 LSPs > >> > > > >> > > IP Internal Reachability Information -- IP addresses within > >> > > the L1 routing > >> > > subdomain reachable directly via one or more interfaces on > >> > > this Intermediate > >> > > system. > >> > > > >> > >> Any comments on the above text??? > >> > >> > > > >> > > Cheers, > >> > > Ken Larmer > >> > > CommSense Networks > >> > > www.commsense.net > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: isis-wg-admin@external.juniper.net > >> > > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of > >> Jeff Learman > >> > > > Sent: Wednesday, October 17, 2001 10:20 AM > >> > > > To: Koen Vermeulen > >> > > > Cc: Isis-wg > >> > > > Subject: Re: [Isis-wg] ManualL2Only > >> > > > > >> > > > > >> > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > >> > > > >Hello, > >> > > > > > >> > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > >> > > > >explicit rule whether or not to include the network address > >> > > > >of a manualL2only-enabled interface in the L1 LSP generated > >> > > > >by a L1/L2 IS. > >> > > > >Somebody has some ideas/good reasons for not including > >> > > > >the address of that manualL2only interface in L1? > >> > > > > >> > > > Without consulting the specs, I can say that it doesn't make > >> > > > sense to include such an adjacency in the L1 LSP. If you do, > >> > > > then when you run SPF, you will either use "inadmissible" > >> > > > local knowledge when running SPF (thereby creating a > different > >> > > > topology than other ISs) or else you won't heed the L2-only > >> > > > nature of the link and will forward L1 traffic on it. > >> > > > > >> > > > For example: > >> > > > > >> > > > A --- B ==== C ---- D > >> > > > | | > >> > > > E -- F -- G -- H -- I > >> > > > > >> > > > where all are in the same area, but the link between B and C > >> > > > is L2-only. If A wants to send data to D, it will send it to > >> > > > B. If B heeds the l2-only property, it would send > it back to A. > >> > > > > >> > > > Note that B runs the SPF using the same data as > everyone else: > >> > > > the LSDB. It uses its adjacency database also, > true, but only > >> > > > to preload "tent" (or is it "paths", it's been a while). > >> > > > > >> > > > B needs to advertise links consistently with how it would use > >> > > > them itself, so that the area topology is identical > for all ISs > >> > > > in the area. > >> > > > > >> > > > Regards, > >> > > > Jeff > >> > > > > >> > > > > >> > > > >Thanks, > >> > > > >Koen > >> > > > > > >> > > > >_______________________________________________ > >> > > > >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 Oct 19 23:25:20 2001 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 19 Oct 2001 18:25:20 -0400 Subject: [Isis-wg] ManualL2Only In-Reply-To: <4.3.2.7.2.20011017112619.0193ea88@dingdong.cisco.com> References: <3BCDA01A.C97B057@alcatel.be> Message-ID: <4.3.2.7.2.20011019174404.019bbe90@dingdong.cisco.com> Koen, Sorry, I have to change my answer again. Les pointed out to me that you said "network address" (meaning with a net mask less than 32 bits), not "host address" (with 32 bits). I agree with Les that only L1 network addresses should be advertised in an L1 LSP. The host address of the router on that network could be advertised. Jeff At 11:44 AM 10/17/2001, Jeff Learman wrote: >Reading your original email more carefully, I see I made a >mistake. You were talking about the interface address, >not the adjacency. This case would not be covered in ISO 10589, >because in OSI, interfaces do not have network layer addresses. >It's only an issue for IP addresses. > >In general, I would prefer using an unnumbered interface between >areas, if possible, to avoid wasting a subnet address that can't >be wholly within a single area, and therefore able to be summarized. >This is a minor point, and it's often not possible to use an >unnumbered interface, so the question remains. > >I don't see any harm in including the address, and I don't >see any benefit to omitting it. I don't have a lot of experience >in integrated IS-IS, though, so you may want to wait for other >opinions. > >Regards, >Jeff > >Disclaimer: I am not working on IS-IS at Cisco nor am I familiar with >Cisco's IS-IS implementation. Just trying to keep brain cells from >a previous job alive. > > >At 11:13 AM 10/17/2001, Koen Vermeulen wrote: >>Hello Jeff, >> >>I think I have to be more specific, because it seems that >>my question was not understood completely. I will try to >>explain what I meant with an example. >> >>Suppose you have following 3 IS's: >> >> 1 2 >>A ----- B ----- C >>L1 L1/L2 L2 >> >>where link 2 has network address x and is configured as >>manualL2only. This means that B will only try to form >>a L2 adjacency with C. >>My question is now: is it allowed to add address x in an ip >>reachability TLV to the L1 LSP of B or will this lead to >>some problems? >>Right now, I can't think of any problems adding the >>network address of a manualL2only to L1. I would >>even expect that this way of working is the correct >>one because of the fact that IS-IS areas cut through >>interfaces and not through routers as is done in OSPF. >> >>I hope this makes my question more clear? >> >>Thanks, >>Koen >> >>Jeff Learman wrote: >> >>> At 02:33 AM 10/16/2001, Koen Vermeulen wrote: >>> >Hello, >>> > >>> >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an >>> >explicit rule whether or not to include the network address >>> >of a manualL2only-enabled interface in the L1 LSP generated >>> >by a L1/L2 IS. >>> >Somebody has some ideas/good reasons for not including >>> >the address of that manualL2only interface in L1? >>> >>> Without consulting the specs, I can say that it doesn't make >>> sense to include such an adjacency in the L1 LSP. If you do, >>> then when you run SPF, you will either use "inadmissible" >>> local knowledge when running SPF (thereby creating a different >>> topology than other ISs) or else you won't heed the L2-only >>> nature of the link and will forward L1 traffic on it. >>> >>> For example: >>> >>> A --- B ==== C ---- D >>> | | >>> E -- F -- G -- H -- I >>> >>> where all are in the same area, but the link between B and C >>> is L2-only. If A wants to send data to D, it will send it to >>> B. If B heeds the l2-only property, it would send it back to A. >>> >>> Note that B runs the SPF using the same data as everyone else: >>> the LSDB. It uses its adjacency database also, true, but only >>> to preload "tent" (or is it "paths", it's been a while). >>> >>> B needs to advertise links consistently with how it would use >>> them itself, so that the area topology is identical for all ISs >>> in the area. >>> >>> Regards, >>> Jeff >>> >>> >Thanks, >>> >Koen >>> > >>> >_______________________________________________ >>> >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 Internet-Drafts@ietf.org Mon Oct 22 12:02:50 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 22 Oct 2001 07:02:50 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-01.txt Message-ID: <200110221102.HAA10342@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-01.txt Pages : 7 Date : 19-Oct-01 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-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-multi-topology-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-multi-topology-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: <20011019141226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011019141226.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Tue Oct 23 12:02:37 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 23 Oct 2001 07:02:37 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-transient-02.txt Message-ID: <200110231102.HAA25477@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 Transient Blackhole Avoidance Author(s) : D. McPherson Filename : draft-ietf-isis-transient-02.txt Pages : 6 Date : 22-Oct-01 This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-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-transient-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-transient-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: <20011022135523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-transient-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-transient-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011022135523.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Fri Oct 26 12:06:09 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 26 Oct 2001 07:06:09 -0400 Subject: [Isis-wg] I-D ACTION:draft-ash-ospf-isis-congestion-control-01.txt Message-ID: <200110261106.HAA27096@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Mechanisms for Congestion Control/Failure Recovery in OSPF & ISIS Networks Author(s) : J. Ash et al. Filename : draft-ash-ospf-isis-congestion-control-01.txt Pages : Date : 25-Oct-01 Earlier papers and contributions identified issues of congestion control and failure recovery for link-state protocol networks, such as OSPF, ISIS, and PNNI networks [maunder, choudhury, pappalardo1, pappalardo2, atm01-0101].The problem addressed is to enable link-state protocols to a) gracefully recover from massive loss of topology database information, and b) respond gracefully to network overloads and failures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-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-ash-ospf-isis-congestion-control-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-ash-ospf-isis-congestion-control-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: <20011025145328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-ospf-isis-congestion-control-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ash-ospf-isis-congestion-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011025145328.I-D@ietf.org> --OtherAccess-- --NextPart-- From sherwin@torrentnet.com Fri Oct 26 18:45:03 2001 From: sherwin@torrentnet.com (Chris Sherwin) Date: Fri, 26 Oct 2001 13:45:03 -0400 Subject: [Isis-wg] M-ISIS Message-ID: <200110261745.f9QHj3A23704@malibu.torrentnet.com> Hi all, Is this M-ISIS draft similar to/the same as the multi-instance IS-IS Juniper has? Does CISCO support something like this? Chris. From naiming@redback.com Mon Oct 29 06:10:20 2001 From: naiming@redback.com (Naiming Shen) Date: Sun, 28 Oct 2001 22:10:20 -0800 Subject: [Isis-wg] M-ISIS In-Reply-To: Mail from Chris Sherwin dated Fri, 26 Oct 2001 13:45:03 EDT <200110261745.f9QHj3A23704@malibu.torrentnet.com> Message-ID: <20011029061020.5A3CE1DCC79@prattle.redback.com> To the wg list, the new version M-ISIS 01.txt has been posted on ietf websiet. The main change is to add an IPv6 reachable prefix TLV for multi-topology(section 8.4). Please send comments. ]Hi all, ] ]Is this M-ISIS draft similar to/the same as the multi-instance IS-IS ]Juniper has? No. The main point of M-ISIS is "SINGLE instance". Even though its possible to use multi-instance to form multi-topology of ISIS, the tricky thing is if more than one instance need to share the same interface on a router, a mechanism is needed to multiplex inbound isis packets to the right instance. Although one can freely add new TLVs inside ISIS packets, the issue is backwards compatibility, especially when the DIS on a LAN runs old code. But M-ISIS does not exclude multi-instance application of ISIS. It will be perfectly reasonable to run multiple instances of M-ISIS on a router. If two networks both run M-ISIS as IGPs resides on the router, multi-instance of M-ISIS will be useful there. ]Does CISCO support something like this? ] ]Chris. - Naiming From mshand@cisco.com Wed Oct 31 08:19:29 2001 From: mshand@cisco.com (mike shand) Date: Wed, 31 Oct 2001 08:19:29 +0000 Subject: [Isis-wg] tlv codepoint for ISIS-restart draft In-Reply-To: <3B79992B.9E287E89@redback.com> Message-ID: <4.3.2.7.2.20011031081332.00b4c868@jaws.cisco.com> Tony, I need to assign a real codepoint for the "restart" TLV in draft-ietf-isis-restart. I don't think we have any procedure to do this. Looking at your draft, I see that 11 is currently free. So may I propose that I use that? Mike From prz@net4u.ch Wed Oct 31 12:34:23 2001 From: prz@net4u.ch (Tony Przygienda) Date: Wed, 31 Oct 2001 13:34:23 +0100 (MET) Subject: [Isis-wg] tlv codepoint for ISIS-restart draft In-Reply-To: <4.3.2.7.2.20011031081332.00b4c868@jaws.cisco.com> from mike shand at "Oct 31, 2001 8:19:29 am" Message-ID: <200110311234.NAA18079@net4u.net4u.ch> > Tony, > I need to assign a real codepoint for the "restart" TLV in > draft-ietf-isis-restart. I don't think we have any procedure to do this. > Looking at your draft, I see that 11 is currently free. So may I propose > that I use that? > > Mike we tend to crash in low numbers more likely, could you live something >128, let's say 211? -- tony From mshand@cisco.com Wed Oct 31 13:17:14 2001 From: mshand@cisco.com (mike shand) Date: Wed, 31 Oct 2001 13:17:14 +0000 Subject: [Isis-wg] tlv codepoint for ISIS-restart draft In-Reply-To: <200110311234.NAA18079@net4u.net4u.ch> References: <4.3.2.7.2.20011031081332.00b4c868@jaws.cisco.com> Message-ID: <4.3.2.7.2.20011031131604.00b7b398@jaws.cisco.com> At 13:34 31/10/2001 +0100, Tony Przygienda wrote: > > Tony, > > I need to assign a real codepoint for the "restart" TLV in > > draft-ietf-isis-restart. I don't think we have any procedure to do this. > > Looking at your draft, I see that 11 is currently free. So may I propose > > that I use that? > > > > Mike > >we tend to crash in low numbers more likely, could you live something >128, >let's say 211? I have no vested interest in any number (apart from 42 of course :-) 211 is as good as any other. Mike > -- tony > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From naiming@redback.com Wed Oct 31 20:11:20 2001 From: naiming@redback.com (Naiming Shen) Date: Wed, 31 Oct 2001 12:11:20 -0800 Subject: [Isis-wg] tlv codepoint for ISIS-restart draft In-Reply-To: Mail from mike shand dated Wed, 31 Oct 2001 13:17:14 GMT <4.3.2.7.2.20011031131604.00b7b398@jaws.cisco.com> Message-ID: <20011031201120.9B72FF2C40@prattle.redback.com> tony, please update it also with tlv 237: Multi-Topology Reachable IPv6 Prefixes TLV cheers. ]At 13:34 31/10/2001 +0100, Tony Przygienda wrote: ]> > Tony, ]> > I need to assign a real codepoint for the "restart" TLV in ]> > draft-ietf-isis-restart. I don't think we have any procedure to do this. ]> > Looking at your draft, I see that 11 is currently free. So may I propose ]> > that I use that? ]> > ]> > Mike ]> ]>we tend to crash in low numbers more likely, could you live something >128, ]>let's say 211? ] ]I have no vested interest in any number (apart from 42 of course :-) ] ]211 is as good as any other. ] ] Mike ] ] ] ]> -- 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 - Naiming From Ming.Chan@spirentcom.com Thu Nov 1 17:59:07 2001 From: Ming.Chan@spirentcom.com (Chan, Chung Ming) Date: Thu, 1 Nov 2001 07:59:07 -1000 Subject: [Isis-wg] Simple questions on the use of Authentication TLVs Message-ID: <8AC36D3167EED41184C800508BD9540501EE3B69@apollo.adtech-inc.com> All, I'm new to ISIS and hope some one can answer me the following questions regarding to the use of Authentication TLV. Thank you in advance! I'm working with ISO/IEC 10589:1992 and RFC 1195. In both spec there is Authentication VLF defined with different Code points, 10 for ISO10589 and 133 for RFC1195. The questions that I've: 1) If the router is supporting RFC 1195, SHALL it use 133 or 10? What is the guideline for using it? 2) Or should the router accept code point 10, if it supports RFC1195? Thanks, Ming Chan From Ming.Chan@SpirentCom.COM Thu Nov 1 18:01:13 2001 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming) Date: Thu, 1 Nov 2001 08:01:13 -1000 Subject: [Isis-wg] Simple questions on the use of Authentication TLVs Message-ID: <8AC36D3167EED41184C800508BD9540501EE3B6A@apollo.adtech-inc.com> All, I'm new to ISIS and hope some one can answer me the following questions regarding to the use of Authentication TLV. Thank you in advance! I'm working with ISO/IEC 10589:1992 and RFC 1195. In both spec there is Authentication VLF defined with different Code points, 10 for ISO10589 and 133 for RFC1195. The questions that I've: 1) If the router is supporting RFC 1195, SHALL it use 133 or 10? What is the guideline for using it? 2) Or should the router accept code point 10, if it supports RFC1195? Thanks, Ming Chan From azalani@opnet.com Fri Nov 2 17:54:55 2001 From: azalani@opnet.com (Ashish Zalani) Date: Fri, 02 Nov 2001 12:54:55 -0500 Subject: [Isis-wg] Circuit ID field in IS-IS Hello PDUs Message-ID: <4.2.1.20011102124812.00b0ec80@mail.opnet.com> Hi, I am relatively new to IS-IS and am trying to understand how IS-IS PDUs are handled. Specifically, I am curious to know how the Circuit ID field in a Point-to-Point IIH (or the LAN ID field in a L1/L2 LAN IIH) is assigned. From what I understand, the circuit ID is a 1-byte field that uniquely identifies the interface on the system. That would allow for a maximum of 255 interfaces. What happens if the number of (connected) interfaces on a router is more than 255? How is the circuit ID ensured to be unique among all interfaces? Thanks, -Ashish. Ashish Zalani Modeling Engineer OPNET Technologies, Inc. From naiming@redback.com Sun Nov 4 10:00:19 2001 From: naiming@redback.com (Naiming Shen) Date: Sun, 04 Nov 2001 02:00:19 -0800 Subject: [Isis-wg] Circuit ID field in IS-IS Hello PDUs In-Reply-To: Mail from Ashish Zalani dated Fri, 02 Nov 2001 12:54:55 EST <4.2.1.20011102124812.00b0ec80@mail.opnet.com> Message-ID: <20011104100019.1BAB34BA21E@prattle.redback.com> For p2p isis interface, the best algorithm: circuit_id = ( slot_id * 1 + port_id * 2 + channel_id * 3 + dlci_num + vci * vpi + vlan_cid * 4 + interface_dwdm_wave_length_in_nm * 5 + uniform_distributed_ramdom_number(0, 2**24 - 1) + max(1200, seconds_laps_since_January_3_1997) + cost_of_router_in_euros ) % 255; For LAN isis interface, just make sure it's unique and not exceeding 255. if more than 255 LAN intf on a router is needed, tricky mechanism is required. thanks. ]Hi, ] ]I am relatively new to IS-IS and am trying to understand how IS-IS PDUs are ]handled. Specifically, I am curious to know how the Circuit ID field in a ]Point-to-Point IIH (or the LAN ID field in a L1/L2 LAN IIH) is assigned. ] ] From what I understand, the circuit ID is a 1-byte field that uniquely ]identifies the interface on the system. That would allow for a maximum of ]255 interfaces. What happens if the number of (connected) interfaces on a ]router is more than 255? How is the circuit ID ensured to be unique among ]all interfaces? ] ]Thanks, ]-Ashish. ]Ashish Zalani ]Modeling Engineer ]OPNET Technologies, Inc. ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From Narendra" This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C16779.3D9408A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Can anyone help me in clearing my doubts in = for extending the number of IS-IS LSP fragments beyond 256 limit. =20 1.While Generating extended LSP, whether to generate extended LSP as = soon as extended System-ID is configured or when the Original LSP = fragments reaches its maximum limit of 256?. 2. Either in operation mode 1 or in operation mode 2, adjacency with = `Virtual System` will be established only by `Originating System`. is = this correct?. if so why it is said in section "forming Adjacencies" that "if a = neighbour is to be included in extended LSP S`, then S`should be used as = the system-id in IS Hellos and IS-IS Hellos when forming an adjacency = with that neighbour". Does this mean that the originating System in Mode 2 will send As many hellos as the number of extended = System Ids it uses ? 3. If there is space in Original LSP due to purging of some original LSP = fragments, then do we need to regenerate both original LSP and extended = LSP with moving some of LSP`s content from extended LSP to Original LSP. 4. Is it correct that there will be no changes to the PsudonodeLSPs of = the originating system as the virtual Systems are assumed to be on P2P = links? 5. Are there any vendors/ ISIS implementions that has implemented this = draft?=20 thanks in advance Narendra G.H. ------=_NextPart_000_0049_01C16779.3D9408A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Can anyone help me = in clearing my=20 doubts in <draft-hermelin-ext-lsp-frags-02.txt>
 = for=20 extending the number of IS-IS LSP fragments beyond 256=20 limit.
 
1.While Generating extended LSP, = whether to=20 generate extended LSP as soon as extended   System-ID is = configured or=20 when the Original LSP fragments reaches its maximum limit of=20 256?.
 
2. Either in operation mode 1 or in = operation mode=20 2, adjacency with `Virtual System` will be established only by = `Originating=20 System`. is this correct?.
if so why it is said in section = "forming=20 Adjacencies"  that "if  a neighbour is to be included in = extended=20 LSP S`, then S`should be used as the system-id in IS Hellos and IS-IS = Hellos=20 when forming an adjacency with that neighbour". Does this mean that the=20 originating
System in Mode 2 will send As many hellos as the number = of=20 extended System Ids it
uses ?

3. If there is space in Original LSP due = to purging=20 of some original LSP fragments, then do we need to regenerate both = original LSP=20 and extended LSP with moving some of LSP`s content from extended LSP to = Original=20 LSP.

4. Is it correct that there will be no changes to the PsudonodeLSPs = of=20 the
originating system as the virtual Systems are assumed to be on = P2P=20 links?

5. Are there any vendors/ ISIS implementions that  has = implemented this=20 draft?


thanks in advance

Narendra=20 G.H.

------=_NextPart_000_0049_01C16779.3D9408A0-- From amir@cwnt.com Thu Nov 8 08:09:45 2001 From: amir@cwnt.com (Amir Hermelin) Date: Thu, 8 Nov 2001 10:09:45 +0200 Subject: [Isis-wg] Doubts regarding extending LSP fragments beyond 256 Message-ID: Narendra, my answers inline. Also, a new version of the draft will be published shortly. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Narendra [mailto:eta_narengh@partner.huawei.com] > Sent: Wednesday, November 07, 2001 4:45 AM > To: isis-wg@juniper.net > Cc: Narendra > Subject: [Isis-wg] Doubts regarding extending LSP fragments beyond 256 > > > Hi All, > > Can anyone help me in clearing my doubts in > > for extending the number of IS-IS LSP fragments beyond 256 limit. > > 1.While Generating extended LSP, whether to generate extended > LSP as soon as extended System-ID is configured or when the > Original LSP fragments reaches its maximum limit of 256?. IMO this is implementation-specific. While using extended LSPs before the original LSP space is depleted, could result in cluttering the network with un-needed 'virtual' systems, a vendor might choose to do so, to reserve extra space in the original LSPs for whatever reason. Furthermore, in Mode 2 this doesn't produce any additional overhead, since the LS information has to be generated anyway. > 2. Either in operation mode 1 or in operation mode 2, > adjacency with `Virtual System` will be established only by > `Originating System`. is this correct?. That is not correct. Here's the text from section 7: " It should be noted, that an IS must use the system-id of the LSP that will include a neighbor, when forming an adjacency with that neighbor. That is, if a neighbor is to be included in extended LSP S', then S' should be used as the system-id in IS Hellos [3] and IS- IS Hellos when forming an adjacency with that neighbor. This is regardless of the Operational Mode. Of course, in Mode 1 this means that only the original system-id will be used when sending hellos. " What you said is correct for mode 1 - since only original LSPs include ISN TLVs, then only original system-ids will be heard on hellos by the other neighbors. However, in mode 2 it is possible to include ISNs in Extended LSPs; say LSPs with Extended system-id S'. Then, this neighbor must hear S' in the hellos, and not the original system-id (so it advertises an adjacency to S', and bi-direct check will pass).> if so why it is said in section "forming Adjacencies" that > "if a neighbour is to be included in extended LSP S`, then > S`should be used as the system-id in IS Hellos and IS-IS > Hellos when forming an adjacency with that neighbour". Does > this mean that the originating > System in Mode 2 will send As many hellos as the number of > extended System Ids it > uses ? This does not affect the number of hellos - only what system-id is advertised in them. > 3. If there is space in Original LSP due to purging of some > original LSP fragments, then do we need to regenerate both > original LSP and extended LSP with moving some of LSP`s > content from extended LSP to Original LSP. If I understand correctly, you're asking about whether to 'compact' the number of LSP sets in use. I think the same answer to 1 applies here. > 4. Is it correct that there will be no changes to the > PsudonodeLSPs of the > originating system as the virtual Systems are assumed to be > on P2P links? That depends. If your'e running mode 2, and advertising an extended system-id on a broadcast network, and you're the DIS on that network, you can advertise the extended system-id in the pseudonode as well - no limitation here. What's assumed to be p2p links are the connections between the original and virtual systems in Mode 1 only - in Mode 2 these connections don't exist (see 4.2 of draft). Besides, there's no real limitation that the pseudonode and DIS share the same system-id - it's just a convenience. > 5. Are there any vendors/ ISIS implementions that has > implemented this draft? I'm aware of only one. > thanks in advance welcome. HTH > Narendra G.H. > From aridamank@future.futsoft.com Thu Nov 8 12:25:20 2001 From: aridamank@future.futsoft.com (Aridaman) Date: Thu, 8 Nov 2001 17:55:20 +0530 Subject: [Isis-wg] (no subject) Message-ID: <000001c16850$6fc776e0$0b03040a@future.futsoft.com> hi all, Can anyone help me in clearing my doubts in isis draft for ipv6. 1. As we are having different types of adddresses(site local, global...... ) in ipv6. Which address will be advertised in which LSP(L1/L2). Also Pls tell about any document that elaborate routing for ipv6. Thanks in advance ari. From Ming.Chan@SpirentCom.COM Fri Nov 9 15:59:22 2001 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming) Date: Fri, 9 Nov 2001 05:59:22 -1000 Subject: [Isis-wg] AreaMisMatch Event Message-ID: <8AC36D3167EED41184C800508BD9540501EE3BA9@apollo.adtech-inc.com> Hi, I've a question regarding to Area Address mismatch. Hope someone can clarify that to me. According to ISO/IEC 10589, section 8.4.2.2, item a) "If a match is not found between any pair (i.e. the local and remote system have no area address in common), the IS shall reject the adjacency" My understanding of the phase "reject the adjacency" means: 1) If the IS is not already have an adjacency with the remote IS, then don't form any adjacency using the received IIH (Essentially drops/discards the IIH) 2) If the IS is already have an adjacency with the remote IS, then the IS shall "reset the adjacency with the remote IS." (i.e. the IS goes back to Enabled state, sending IIH without the MAC address of the remote IS). My reasoning is that if the remote IS's area address is changed and there is not area address in common any more, there is no more reason for keeping the adjacency. I know #1 shall be TRUE; but not sure about #2. Could anyone help to clarify that? Thanks, Ming Chan From jparker@axiowave.com Fri Nov 9 17:33:31 2001 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 9 Nov 2001 12:33:31 -0500 Subject: [Isis-wg] AreaMisMatch Event Message-ID: > According to ISO/IEC 10589, section 8.4.2.2, item a) > > "If a match is not found between any pair (i.e. the local > and remote system have no area address in common), the > IS shall reject the adjacency" > > My understanding of the phase "reject the adjacency" means: > 1) If the IS is not already have an adjacency with the > remote IS, then don't form any adjacency > > 2) If the IS is already have an adjacency with the remote > IS, then the IS shall "reset the adjacency with the remote > IS." Spot on. From Ravindra.Sunkad@vivacenetworks.com Fri Nov 9 17:57:04 2001 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Fri, 9 Nov 2001 09:57:04 -0800 Subject: [Isis-wg] AreaMisMatch Event Message-ID: Yes. You should delete the adjacency in this case. Ravi -----Original Message----- From: Chan, Chung Ming [mailto:Ming.Chan@spirentcom.com] Sent: Friday, November 09, 2001 7:59 AM To: 'isis-wg@external.juniper.net' Cc: Chan, Chung Ming Subject: [Isis-wg] AreaMisMatch Event Hi, I've a question regarding to Area Address mismatch. Hope someone can clarify that to me. According to ISO/IEC 10589, section 8.4.2.2, item a) "If a match is not found between any pair (i.e. the local and remote system have no area address in common), the IS shall reject the adjacency" My understanding of the phase "reject the adjacency" means: 1) If the IS is not already have an adjacency with the remote IS, then don't form any adjacency using the received IIH (Essentially drops/discards the IIH) 2) If the IS is already have an adjacency with the remote IS, then the IS shall "reset the adjacency with the remote IS." (i.e. the IS goes back to Enabled state, sending IIH without the MAC address of the remote IS). My reasoning is that if the remote IS's area address is changed and there is not area address in common any more, there is no more reason for keeping the adjacency. I know #1 shall be TRUE; but not sure about #2. Could anyone help to clarify that? 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 Nov 9 18:00:52 2001 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 09 Nov 2001 13:00:52 -0500 Subject: [Isis-wg] AreaMisMatch Event In-Reply-To: <8AC36D3167EED41184C800508BD9540501EE3BA9@apollo.adtech-inc .com> Message-ID: <4.3.2.7.2.20011109111956.018f3890@dingdong.cisco.com> That would be my interpretation. If you continue sending IIHs with your MAC address in it, that would goof up DR election. The intent is that you would have no L1 adjacency for this system at all. (If you're a L2 router, you'd form or retain a L2 adjacency.) Regards, Jeff Disclaimer - I don't work in IS-IS at Cisco, so what I say has nothing to do with Cisco's implementation. Opinions expressed are my own, and may not be those of my employer. And when I say something really wrong, Les Guinsberg usually disabuses everyone ;-) At 10:59 AM 11/9/2001, Chan, Chung Ming wrote: >Hi, > I've a question regarding to Area Address mismatch. Hope someone can >clarify that to me. > > According to ISO/IEC 10589, section 8.4.2.2, item a) > >"If a match is not found between any pair (i.e. the local >and remote system have no area address in common), the >IS shall reject the adjacency" > > >My understanding of the phase "reject the adjacency" means: >1) If the IS is not already have an adjacency with the remote IS, then >don't form any adjacency using the received IIH (Essentially drops/discards >the IIH) >2) If the IS is already have an adjacency with the remote IS, then the IS >shall "reset the adjacency with the remote IS." (i.e. the IS goes back to >Enabled state, sending IIH without the MAC address of the remote IS). My >reasoning is that if the remote IS's area address is changed and there is >not area address in common any more, there is no more reason for keeping the >adjacency. > >I know #1 shall be TRUE; but not sure about #2. > >Could anyone help to clarify that? > > > >Thanks, > > > >Ming Chan > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From henk@Procket.com Fri Nov 9 23:29:34 2001 From: henk@Procket.com (Henk Smit) Date: Fri, 9 Nov 2001 15:29:34 -0800 (PST) Subject: [Isis-wg] AreaMisMatch Event In-Reply-To: <8AC36D3167EED41184C800508BD9540501EE3BA9@apollo.adtech-inc.com> from "Chan, Chung Ming" at Nov 09, 2001 05:59:22 AM Message-ID: <200111092329.fA9NTYQQ024143@redd3174.procket.com> Seems like I am the only one to disagree with the rest. :-) I would prefer my code to just ignore the incoming IIH and drop it. If the other router was really reconfigured with different area address(es) then the next few IIHs will be dropped too, causing the adjacency to time out eventually. This will take some time. And could be speed up by bringing down the adjacency immediately. What do you gain ? If a network admin really wants the adjacency to be reset quickly, he can clear it manually after the manual area address change. The downside of clearing the adjacency is that you are making your network less robust. Remember that IIHs have no layer3 checksum. So in case you are receiving a (partially) corrupted packet, this one corrupted packet can take down an adjacency immediately. If you just ignore the packet, and it was really an incidental corruption, the adjacency stays up. In a previous life I've seen this happen on ATM networks. Henk. > Hi, > I've a question regarding to Area Address mismatch. Hope someone can > clarify that to me. > > According to ISO/IEC 10589, section 8.4.2.2, item a) > > "If a match is not found between any pair (i.e. the local > and remote system have no area address in common), the > IS shall reject the adjacency" > > > My understanding of the phase "reject the adjacency" means: > 1) If the IS is not already have an adjacency with the remote IS, then > don't form any adjacency using the received IIH (Essentially drops/discards > the IIH) > 2) If the IS is already have an adjacency with the remote IS, then the IS > shall "reset the adjacency with the remote IS." (i.e. the IS goes back to > Enabled state, sending IIH without the MAC address of the remote IS). My > reasoning is that if the remote IS's area address is changed and there is > not area address in common any more, there is no more reason for keeping the > adjacency. > > I know #1 shall be TRUE; but not sure about #2. > > Could anyone help to clarify that? > > > > Thanks, > > > > Ming Chan > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From ginsberg@pluris.com Sat Nov 10 00:10:44 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Fri, 9 Nov 2001 16:10:44 -0800 Subject: [Isis-wg] AreaMisMatch Event Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F591@avalon.pluris.com> It is probably also worth mentioning that deliberately configuring routers on a LAN which operate as L1 routers but are in different areas is a dubious practice at best. This is the reason the spec calls for an AreaMismatch event to be generated when such a condition is detected. Using a LAN as an L2-only backbone - where none of the routers operate as L1 routers on that circuit - makes sense. Having a mixture of routers, all in the same area, some of which are L2 capable, all connected to the same LAN also makes sense. The case which sparked the original question, although certainly not unheard of, should be discouraged. Les -----Original Message----- From: Henk Smit To: Ming.Chan@spirentcom.com Cc: isis-wg@spider.juniper.net Sent: 11/9/01 3:29 PM Subject: Re: [Isis-wg] AreaMisMatch Event Seems like I am the only one to disagree with the rest. :-) I would prefer my code to just ignore the incoming IIH and drop it. If the other router was really reconfigured with different area address(es) then the next few IIHs will be dropped too, causing the adjacency to time out eventually. This will take some time. And could be speed up by bringing down the adjacency immediately. What do you gain ? If a network admin really wants the adjacency to be reset quickly, he can clear it manually after the manual area address change. The downside of clearing the adjacency is that you are making your network less robust. Remember that IIHs have no layer3 checksum. So in case you are receiving a (partially) corrupted packet, this one corrupted packet can take down an adjacency immediately. If you just ignore the packet, and it was really an incidental corruption, the adjacency stays up. In a previous life I've seen this happen on ATM networks. Henk. > Hi, > I've a question regarding to Area Address mismatch. Hope someone can > clarify that to me. > > According to ISO/IEC 10589, section 8.4.2.2, item a) > > "If a match is not found between any pair (i.e. the local > and remote system have no area address in common), the > IS shall reject the adjacency" > > > My understanding of the phase "reject the adjacency" means: > 1) If the IS is not already have an adjacency with the remote IS, then > don't form any adjacency using the received IIH (Essentially drops/discards > the IIH) > 2) If the IS is already have an adjacency with the remote IS, then the IS > shall "reset the adjacency with the remote IS." (i.e. the IS goes back to > Enabled state, sending IIH without the MAC address of the remote IS). My > reasoning is that if the remote IS's area address is changed and there is > not area address in common any more, there is no more reason for keeping the > adjacency. > > I know #1 shall be TRUE; but not sure about #2. > > Could anyone help to clarify that? > > > > 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 Radia Perlman - Boston Center for Networking Sun Nov 11 01:27:59 2001 From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking) Date: Sat, 10 Nov 2001 20:27:59 -0500 (EST) Subject: [Isis-wg] AreaMisMatch Event Message-ID: <200111110127.UAA15877@bcn.East.Sun.COM> I'd agree with Henk. Henks's suggested behavior (throwing away and perhaps logging the IIH) will eventually bring down the adjacency, where "eventually" is no longer than it would take to notice a dead router neighbor. And the other behavior (bringing it down immediately) would make it easier, when no authentication is being used...how often is authentication used these days?...to disrupt a network by sending bogus packets. Though I could imagine the argument that if someone can send bogus IS-IS packets and there's no authentication, you're pretty much gonna lose anyway. Radia From sachidananda_k@hotmail.com Mon Nov 12 06:49:34 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Mon, 12 Nov 2001 06:49:34 +0000 Subject: [Isis-wg] Doubts on SPF execution on DUAL ISIS Message-ID: Hello, In a dual ISIS implementation, is it required to execute the SPF algorithm twice (once for IP network topology and second for OSI network topolgy)? Or should it be executed without taking into consideration the protocol supported? Although, I was told that this is very much specific to implementation, I would like to bring out the example and get myself clarified. This question arised to me basically for the below example. +--+ 2 +--+ 3 +--+ |c |------------| b|-----------| a | +--+ +--+ +-- + \ / \ 8 / 4 \ / +---+ 7 +---+ | d | ---------------| e | +---+ +---+ If IS 'c', 'd', and 'e' are IP enabled and 'b' and 'a' are OSI only. If we donot consider the protocol supported then from 'c' to 'e' we have the route that doesnot suport IP at all. Therefore, with this for 'c', destination 'e' is not reachable in IP topology. Whereas there exists the route via 'd' (though expensive). Please clarify me in this regards. Thanks in advance. Sachi. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From mshand@cisco.com Mon Nov 12 08:48:47 2001 From: mshand@cisco.com (mike shand) Date: Mon, 12 Nov 2001 08:48:47 +0000 Subject: [Isis-wg] AreaMisMatch Event In-Reply-To: <200111092329.fA9NTYQQ024143@redd3174.procket.com> References: <8AC36D3167EED41184C800508BD9540501EE3BA9@apollo.adtech-inc.com> Message-ID: <4.3.2.7.2.20011112084716.034d21f8@jaws.cisco.com> At 15:29 09/11/2001 -0800, Henk Smit wrote: > Seems like I am the only one to disagree with the rest. :-) Good point Henk, I agree (although I suspect this wasn't what we meant when we wrote 10589). Mike > I would prefer my code to just ignore the incoming IIH and drop it. > If the other router was really reconfigured with different area address(es) > then the next few IIHs will be dropped too, causing the adjacency to time > out eventually. > > This will take some time. And could be speed up by bringing down the > adjacency immediately. What do you gain ? If a network admin really > wants the adjacency to be reset quickly, he can clear it manually after > the manual area address change. > > The downside of clearing the adjacency is that you are making your > network less robust. > Remember that IIHs have no layer3 checksum. So in case you are > receiving a (partially) corrupted packet, this one corrupted packet > can take down an adjacency immediately. If you just ignore the packet, > and it was really an incidental corruption, the adjacency stays up. > In a previous life I've seen this happen on ATM networks. > > Henk. > > > > > > Hi, > > I've a question regarding to Area Address mismatch. Hope someone can > > clarify that to me. > > > > According to ISO/IEC 10589, section 8.4.2.2, item a) > > > > "If a match is not found between any pair (i.e. the local > > and remote system have no area address in common), the > > IS shall reject the adjacency" > > > > > > My understanding of the phase "reject the adjacency" means: > > 1) If the IS is not already have an adjacency with the remote IS, then > > don't form any adjacency using the received IIH (Essentially drops/discards > > the IIH) > > 2) If the IS is already have an adjacency with the remote IS, then the IS > > shall "reset the adjacency with the remote IS." (i.e. the IS goes back to > > Enabled state, sending IIH without the MAC address of the remote IS). My > > reasoning is that if the remote IS's area address is changed and there is > > not area address in common any more, there is no more reason for > keeping the > > adjacency. > > > > I know #1 shall be TRUE; but not sure about #2. > > > > Could anyone help to clarify that? > > > > > > > > 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 naiming@redback.com Mon Nov 12 09:07:18 2001 From: naiming@redback.com (Naiming Shen) Date: Mon, 12 Nov 2001 01:07:18 -0800 Subject: [Isis-wg] Doubts on SPF execution on DUAL ISIS In-Reply-To: Mail from "Sachidananda K" dated Mon, 12 Nov 2001 06:49:34 GMT Message-ID: <20011112090718.8866E1DCC64@prattle.redback.com> ]Hello, ] ]In a dual ISIS implementation, is it required to execute the SPF algorithm ]twice (once for IP network topology and second for OSI network topolgy)? Or ]should it be executed without taking into consideration the protocol ]supported? ] ]Although, I was told that this is very much specific to implementation, I ]would like to bring out the example and get myself clarified. yes, it's an implementation issue. but regardless of running spf once or 10 times in this case, the algorithm should not put an IP-only router onto the TENT while using an OSI-only router as its nexthop. also, mix clns and ip like this in the network is asking for trouble. according to rfc1195, all the links of a router should announce the identical set of NLPIDs. if not, routing loop may be formed. a simple example: 2(clns) 1 ------------- A(ip) ----- B(ip,clns) C(ip,clns) | ------------- | | 25(ip) | | | +------------------------------------+ 12(ip) B has two parallel links to C, one has cost of 2 for clns circuit, the other has cost of 25 for ip only circuit. To reach C: A knows the cost is 3 (it does not know that link of 2 is for clns only); B knows its 13. then the routing loop to reach C: A -> B -> C B -> A -> C there must be some reason people want to try M-ISIS :-) - Naiming ] ]This question arised to me basically for the below example. ] ]+--+ 2 +--+ 3 +--+ ]|c |----------| b|-----------|a | ]+--+ +--+ +--+ ] \ / ] \ 8 / 4 ] \ / ] +---+ 7 +---+ ] | d | -------------| e | ] +---+ +---+ ] ] ]If IS 'c', 'd', and 'e' are IP enabled and 'b' and 'a' are OSI only. If we ]donot consider the protocol supported then from 'c' to 'e' we have the route ]that doesnot suport IP at all. Therefore, with this for 'c', destination 'e' ]is not reachable in IP topology. Whereas there exists the route via 'd' ](though expensive). ] ]Please clarify me in this regards. ]Thanks in advance. ] ]Sachi. ] From erez@cwnt.com Mon Nov 12 15:12:36 2001 From: erez@cwnt.com (Erez Morabia) Date: Mon, 12 Nov 2001 17:12:36 +0200 Subject: [Isis-wg] Overload & Attached bits Message-ID: Hi all, I have some questions regarding the 'overload bit' and the 'attached bit' and their possible relations. 1. Can a router have both bits set at the same time? 2. Should we consider overloaded routers in our search for the nearest attached level-2 intermediate system? (if we do, we might insert a default route with a next-hop to the overloaded router to the forwarding database...) 3. When we want to check if we are 'attached', we check if we can reach at least one intermediate system which resides in another area. Should we consider overloaded routers in our search? Thanks, Erez From Ravindra.Sunkad@vivacenetworks.com Mon Nov 12 17:43:59 2001 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Mon, 12 Nov 2001 09:43:59 -0800 Subject: [Isis-wg] Overload & Attached bits Message-ID: -----Original Message----- From: Erez Morabia [mailto:erez@cwnt.com] Sent: Monday, November 12, 2001 7:13 AM To: isis-wg@spider.juniper.net Subject: [Isis-wg] Overload & Attached bits Hi all, I have some questions regarding the 'overload bit' and the 'attached bit' and their possible relations. 1. Can a router have both bits set at the same time? Yes. 2. Should we consider overloaded routers in our search for the nearest attached level-2 intermediate system? (if we do, we might insert a default route with a next-hop to the overloaded router to the forwarding database...) No. You do not want any traffic (except destined for the local subnets of the overloaded IS) to be forwarded to the overloaded IS. 3. When we want to check if we are 'attached', we check if we can reach at least one intermediate system which resides in another area. Should we consider overloaded routers in our search? I think so. If you don't, the local subnets of the overloaded IS will not be reachable by networks in other L1 areas. Thanks, Erez _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From sprevidi@cisco.com Mon Nov 12 22:50:20 2001 From: sprevidi@cisco.com (stefano previdi) Date: Mon, 12 Nov 2001 23:50:20 +0100 Subject: [Isis-wg] Overload & Attached bits In-Reply-To: Message-ID: <4.3.2.7.2.20011112223806.01c36ea8@brussels.cisco.com> At 18:43 12/11/2001, Ravindra Sunkad wrote: >-----Original Message----- >From: Erez Morabia [mailto:erez@cwnt.com] >Sent: Monday, November 12, 2001 7:13 AM >To: isis-wg@spider.juniper.net >Subject: [Isis-wg] Overload & Attached bits > > >Hi all, >I have some questions regarding the 'overload bit' and the 'attached bit' >and their possible relations. > >1. Can a router have both bits set at the same time? > >Yes. > >2. Should we consider overloaded routers in our search > for the nearest attached level-2 intermediate system? > (if we do, we might insert a default route with a next-hop > to the overloaded router to the forwarding database...) > >No. You do not want any traffic (except destined for the local subnets of >the overloaded IS) to be forwarded to the overloaded IS. In some cases you would prefer not to make such "exception". I think it depends on the reason why you did set the overload bit: if the overloaded router is also one of the iBGP next-hops in your network, you may not want to forward traffic to it....unless the router is not "overloaded" enough to re-route internet traffic... Now of course, I'm not sure if a router is ever used as L1L2 _and_ peering point... s. >3. When we want to check if we are 'attached', we check if we can > reach at least one intermediate system which resides in > another area. Should we consider overloaded routers in our > search? > >I think so. If you don't, the local subnets of the overloaded IS will not be >reachable by networks in other L1 areas. > >Thanks, >Erez From sachidananda_k@hotmail.com Tue Nov 13 14:51:38 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Tue, 13 Nov 2001 14:51:38 +0000 Subject: [Isis-wg] Partition repair for IP Only ISIS Message-ID: Hello, I had some doubts regarding the partition repair. In an IP only ISIS type of implementation (according to the RFC 1195) can the partition repair be supported. Please clarify my doubt in this regard. Thanking you in advance for all the responses. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From erez@cwnt.com Tue Nov 13 14:59:02 2001 From: erez@cwnt.com (Erez Morabia) Date: Tue, 13 Nov 2001 16:59:02 +0200 Subject: FW: [Isis-wg] Overload & Attached bits Message-ID: Hi, Thanks for the useful replys. I added some questions/thoughts inline. > -----Original Message----- > From: stefano previdi [mailto:sprevidi@cisco.com] > Sent: Tuesday, November 13, 2001 12:50 AM > To: Ravindra Sunkad > Cc: Erez Morabia; isis-wg@spider.juniper.net > Subject: RE: [Isis-wg] Overload & Attached bits > > > At 18:43 12/11/2001, Ravindra Sunkad wrote: > > > >-----Original Message----- > >From: Erez Morabia [mailto:erez@cwnt.com] > >Sent: Monday, November 12, 2001 7:13 AM > >To: isis-wg@spider.juniper.net > >Subject: [Isis-wg] Overload & Attached bits > > > > > >Hi all, > >I have some questions regarding the 'overload bit' and the > 'attached bit' > >and their possible relations. > > > >1. Can a router have both bits set at the same time? > > > >Yes. > > > >2. Should we consider overloaded routers in our search > > for the nearest attached level-2 intermediate system? > > (if we do, we might insert a default route with a next-hop > > to the overloaded router to the forwarding database...) > > > >No. You do not want any traffic (except destined for the > local subnets of > >the overloaded IS) to be forwarded to the overloaded IS. > > In some cases you would prefer not to make such "exception". I > think it depends on the reason why you did set the overload bit: > if the overloaded router is also one of the iBGP next-hops in your > network, you may not want to forward traffic to it....unless the > router is not "overloaded" enough to re-route internet traffic... > > Now of course, I'm not sure if a router is ever used as L1L2 _and_ > peering point... > > s. > I agree with Ravindra. > >3. When we want to check if we are 'attached', we check if we can > > reach at least one intermediate system which resides in > > another area. Should we consider overloaded routers in our > > search? > > > >I think so. If you don't, the local subnets of the > overloaded IS will not be > >reachable by networks in other L1 areas. That's a good argument, but on the other hand, we might end up with default route towards L1/2 router which can't really reach another area (except for directly connected info on the overloaded router). I hope the following example will clearify this: L1RtrA(AreaX)------L1/2RtrB(AreaX)------L2RtrC(AreaY,Overloded)- - - (AreaY/Backbone) Note: RtrA and RtrB have L1 connection RtrB and RtrC have L2 connection RtrA will insert a default route towards RtrB although RtrB doesn't really know any other area because RtrC is overloaded (and shouldn't be used as a "transient" IS). A more problematic case can be when we have another "real" attached router which we won't choose as our nearest L2 as a result of metric considerations. example: L1/2RtrB(AreaX)--------L2RtrC(AreaY,Overload)--------1/2RtrD(AreaX)- - - (L2 backbone) | | +-----------+----------------------------------------------------------+ | RtrA(AreaX) Note: RtrA and RtrB have L1 connection RtrA and RtrD have L1 connection RtrB, RtrC and RtrD have L2 connection Suppose RtrA-RtrB is a low cost connection and RtrA-RtrD is a high cost connection. If we consider overloaded routers in our attached algorithm, RtrB will be considered as attached. As a result, RtrA will insert a default route towards RtrB and this will cause a loss of data because RtrC separates RtrB from the backbone. If we won't consider overloaded routers in our attached algorithm, a default route will be inserted towards RtrD... It seems to me that avoiding the above presented case may be more important than avoiding a situation where local subnets of overloaded IS will not be reachable by networks in other L1 areas. But I might be wrong... :-) > > > >Thanks, > >Erez > > Thanks again, Erez From Ravindra.Sunkad@vivacenetworks.com Tue Nov 13 22:39:18 2001 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Tue, 13 Nov 2001 14:39:18 -0800 Subject: [Isis-wg] Overload & Attached bits Message-ID: Erez, My comments are inline. Ravi > -----Original Message----- > From: Erez Morabia [mailto:erez@cwnt.com] > Sent: Tuesday, November 13, 2001 6:59 AM > To: Ravindra Sunkad; sprevidi@cisco.com > Cc: isis-wg@spider.juniper.net > Subject: FW: [Isis-wg] Overload & Attached bits > > > Hi, > Thanks for the useful replys. > I added some questions/thoughts inline. > > > -----Original Message----- > > From: stefano previdi [mailto:sprevidi@cisco.com] > > Sent: Tuesday, November 13, 2001 12:50 AM > > To: Ravindra Sunkad > > Cc: Erez Morabia; isis-wg@spider.juniper.net > > Subject: RE: [Isis-wg] Overload & Attached bits > > > > > > At 18:43 12/11/2001, Ravindra Sunkad wrote: > > > > > > >-----Original Message----- > > >From: Erez Morabia [mailto:erez@cwnt.com] > > >Sent: Monday, November 12, 2001 7:13 AM > > >To: isis-wg@spider.juniper.net > > >Subject: [Isis-wg] Overload & Attached bits > > > > > > > > >Hi all, > > >I have some questions regarding the 'overload bit' and the > > 'attached bit' > > >and their possible relations. > > > > > >1. Can a router have both bits set at the same time? > > > > > >Yes. > > > > > >2. Should we consider overloaded routers in our search > > > for the nearest attached level-2 intermediate system? > > > (if we do, we might insert a default route with a next-hop > > > to the overloaded router to the forwarding database...) > > > > > >No. You do not want any traffic (except destined for the > > local subnets of > > >the overloaded IS) to be forwarded to the overloaded IS. > > > > In some cases you would prefer not to make such > "exception". I think > > it depends on the reason why you did set the overload bit: if the > > overloaded router is also one of the iBGP next-hops in your > network, > > you may not want to forward traffic to it....unless the > router is not > > "overloaded" enough to re-route internet traffic... > > > > Now of course, I'm not sure if a router is ever used as L1L2 _and_ > > peering point... > > > > s. > > > > I agree with Ravindra. > > > >3. When we want to check if we are 'attached', we check if we can > > > reach at least one intermediate system which resides in > > > another area. Should we consider overloaded routers in our > > > search? > > > > > >I think so. If you don't, the local subnets of the > > overloaded IS will not be > > >reachable by networks in other L1 areas. > > That's a good argument, but on the other hand, we might > end up with default route towards L1/2 router which can't > really reach another area (except for directly connected info > on the overloaded router). I hope the following example will > clearify this: > > L1RtrA(AreaX)------L1/2RtrB(AreaX)------L2RtrC(AreaY,Overloded)- - - > (AreaY/Backbone) > > Note: > RtrA and RtrB have L1 connection > RtrB and RtrC have L2 connection > > RtrA will insert a default route towards RtrB although RtrB > doesn't really know any other area because RtrC is overloaded > (and shouldn't be used as a "transient" IS). > Since RtrC is overloaded, RtrB will not install routes for networks in L1 areas other than AreaY. So, RtrC will not get transit traffic destined to networks in other L1 areas. > A more problematic case can be when we have another "real" > attached router which we won't choose as our nearest L2 as a > result of metric considerations. > example: > > > L1/2RtrB(AreaX)--------L2RtrC(AreaY,Overload)--------1/2RtrD(A > reaX)- - - (L2 backbone) > | > | > > +-----------+------------------------------------------------- > ---------+ > | > RtrA(AreaX) > > Note: > RtrA and RtrB have L1 connection > RtrA and RtrD have L1 connection > RtrB, RtrC and RtrD have L2 connection > > Suppose RtrA-RtrB is a low cost connection and RtrA-RtrD is a > high cost connection. If we consider overloaded routers in > our attached algorithm, RtrB will be considered as attached. > As a result, RtrA will insert a default route towards RtrB > and this will > cause a loss of data because RtrC separates RtrB from the > backbone. If we won't consider overloaded routers in our > attached algorithm, a default route will be inserted towards RtrD... > > It seems to me that avoiding the above presented case may be > more important than > avoiding a situation where local subnets of overloaded IS > will not be reachable by > networks in other L1 areas. > But I might be wrong... :-) This is a trivial case of the overloaded IS creating a disconnected backbone. If RtrB was also connected to say L2RtrE(AreaZ) then RtrB would have been attached but still disconnected from the rest of the backbone. > > > > > >Thanks, > > >Erez > > > > > > Thanks again, > Erez > From nagastabagamba@yahoo.com Wed Nov 14 08:53:17 2001 From: nagastabagamba@yahoo.com (Nagasta Bagamba) Date: Wed, 14 Nov 2001 00:53:17 -0800 (PST) Subject: FW: [Isis-wg] Overload & Attached bits Message-ID: <20011114085317.59801.qmail@web21109.mail.yahoo.com> Hello Erez and WG, I want to make some comments about the 2 first issues you brought up. 1. Can a router have both bits set at the same time? I understand you agree the answer for that is Yes. But, I know of at least one major vendor which doesn't allow to set this 2 bits at the same time. The reason for that is a kind of a mystery to me... Does anyone have an idea what the reason for that may be? 2. Should we consider overloaded routers in our search for the nearest attached level-2 intermediate system? You decided that the answer is No. But, I know of at least 2 major vendors which consider overloaded routers in the search for the nearest attached level-2 IS. If vendors-mixture ISIS topology will be built, routing loops may occure. Does anyone have an idea how to avoid routing loops in such a topology? 10x, Nagasta __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From sachidananda_k@hotmail.com Wed Nov 14 11:40:09 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Wed, 14 Nov 2001 11:40:09 +0000 Subject: [Isis-wg] interaction with other IGP Message-ID: Hello, I'm not very familiar with ISIS. I have some doubts on dual ISIS. If an intermediate system running other IGP (like ISOF, RIP) along with ISIS, receive a new route from the other routing protocols, then how do we advertise this routes to adjacent ISIS system. Do we advertise them at all or not? If we do how frequently and how? Please clarify my doubts. Thanking you in advance for all responses. Sachi. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From jlearman@cisco.com Wed Nov 14 13:31:41 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 14 Nov 2001 08:31:41 -0500 Subject: [Isis-wg] interaction with other IGP In-Reply-To: Message-ID: <4.3.2.7.2.20011114082801.018d5ea8@dingdong.cisco.com> There may be practical answers that contradict this, but the academic answer is that you use only one routing protocol as your IGP in a routing domain. That's part of what makes it a routing domain -- consistent routing policy & protocol. There are likely to be a lot of exceptions that will work, especially stub networks. I would be very hesitant to use any other IGP to represent a transit subnetwork (a path between two parts of the area/domain that use IS-IS). Regards, Jeff At 06:40 AM 11/14/2001, Sachidananda K wrote: >Hello, > >I'm not very familiar with ISIS. I have some doubts on dual ISIS. >If an intermediate system running other IGP (like ISOF, RIP) along with ISIS, receive a new route from the other routing protocols, then how do we advertise this routes to adjacent ISIS system. >Do we advertise them at all or not? >If we do how frequently and how? > >Please clarify my doubts. > >Thanking you in advance for all responses. >Sachi. > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From ehietbrink@lucent.com Wed Nov 14 19:25:53 2001 From: ehietbrink@lucent.com (Erik Hietbrink) Date: Wed, 14 Nov 2001 20:25:53 +0100 Subject: FW: [Isis-wg] Overload & Attached bits References: <20011114085317.59801.qmail@web21109.mail.yahoo.com> Message-ID: <3BF2C541.C5C5C9D4@lucent.com> Nagasta Bagamba wrote: > > 2. Should we consider overloaded routers in our search > for the nearest attached level-2 intermediate system? > > You decided that the answer is No. But, I know of at > least 2 major vendors which consider overloaded > routers in the search for the nearest attached level-2 > IS. > If vendors-mixture ISIS topology will be built, > routing loops may occure. Does anyone have an idea how > to avoid routing loops in such a topology? Hi, ISO10589-2001, section 9.8, says about the Overload bit: "An LSP with this bit set will not be used by any decision process to calculate routes to another IS through the originating system". I would interpret this statement so that no default level 2 IS route may be calculated to an IS with the overload bit set. Regards, Erik From naiming@redback.com Wed Nov 14 20:14:51 2001 From: naiming@redback.com (Naiming Shen) Date: Wed, 14 Nov 2001 12:14:51 -0800 Subject: FW: [Isis-wg] Overload & Attached bits In-Reply-To: Mail from Erik Hietbrink dated Wed, 14 Nov 2001 20:25:53 +0100 <3BF2C541.C5C5C9D4@lucent.com> Message-ID: <20011114201451.E5F5AF2C4C@prattle.redback.com> I would try to avoid picking the router with OL bit set if there are multiple gateways available. But if all the L2/L1 gateways have the OL bit set, then pick them anyway and send default traffic to them. Since if not, those traffic will be dropped on the local L1 routers. Often the OL bit these days indicate the BGP is not converged yet, at least a subset of the traffic can still be delivered through the gateways which is better than drop all of them. In the old days, routing and forwarding compete for the same resource on routers, so doing the above suggestion would not be a good behaviour, its hardly this case now. ]Nagasta Bagamba wrote: ]> ]> 2. Should we consider overloaded routers in our search ]> for the nearest attached level-2 intermediate system? ]> ]> You decided that the answer is No. But, I know of at ]> least 2 major vendors which consider overloaded ]> routers in the search for the nearest attached level-2 ]> IS. ]> If vendors-mixture ISIS topology will be built, ]> routing loops may occure. Does anyone have an idea how ]> to avoid routing loops in such a topology? ] ]Hi, ] ]ISO10589-2001, section 9.8, says about the Overload bit: ]"An LSP with this bit set will not be used by any decision process to ]calculate routes to another IS through the originating system". ] ]I would interpret this statement so that no default level 2 IS ]route may be calculated to an IS with the overload bit set. ] ]Regards, ]Erik ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From alan@routingloop.com Wed Nov 14 21:32:06 2001 From: alan@routingloop.com (Alan Hannan) Date: Wed, 14 Nov 2001 15:32:06 -0600 Subject: FW: [Isis-wg] Overload & Attached bits In-Reply-To: <20011114201451.E5F5AF2C4C@prattle.redback.com> References: <20011114201451.E5F5AF2C4C@prattle.redback.com> Message-ID: <20011114153206.E16841@routingloop.com> FWIW, in ISP routing topology design, often times a box with the IS-IS OL-bit set is used for carrying traffic. There are two situtaions where this occurs, and they are usually both where the router in question is used as part of an auxilliary or out-of-band networks. The first is where the router in question is used only as a gateway of last resort for certain kinds of traffic, with a default route back towards the NMS or NOC area, only for the purpose of carrying a subset of traffic. Note that typically this router is not meant to carry production traffic. The second is where the router in question is using other routing protocols to carry certain types of traffic/destinations. i.e. Ships in the Night kind of stuff. Also, this router is not meant to carry production traffic in this context, rather stats and management traffic (telnet to boxes, SNMP, etc..). I assert that common ISP usage of IS-IS OL-bit does not comply with ISO10589-2001, section 9.8, yet it does comply with the wording if the phrase "any decision process' is changed to 'the IS-IS routing algorithm". -alan Thus spake Naiming Shen (naiming@redback.com) on or about Wed, Nov 14, 2001 at 12:14:51PM -0800: > > I would try to avoid picking the router with OL bit set if there are > multiple gateways available. But if all the L2/L1 gateways have the OL > bit set, then pick them anyway and send default traffic to them. Since > if not, those traffic will be dropped on the local L1 routers. Often > the OL bit these days indicate the BGP is not converged yet, at least > a subset of the traffic can still be delivered through the gateways > which is better than drop all of them. In the old days, routing and > forwarding compete for the same resource on routers, so doing the above > suggestion would not be a good behaviour, its hardly this case now. > > ]Nagasta Bagamba wrote: > ]> > ]> 2. Should we consider overloaded routers in our search > ]> for the nearest attached level-2 intermediate system? > ]> > ]> You decided that the answer is No. But, I know of at > ]> least 2 major vendors which consider overloaded > ]> routers in the search for the nearest attached level-2 > ]> IS. > ]> If vendors-mixture ISIS topology will be built, > ]> routing loops may occure. Does anyone have an idea how > ]> to avoid routing loops in such a topology? > ] > ]Hi, > ] > ]ISO10589-2001, section 9.8, says about the Overload bit: > ]"An LSP with this bit set will not be used by any decision process to > ]calculate routes to another IS through the originating system". > ] > ]I would interpret this statement so that no default level 2 IS > ]route may be calculated to an IS with the overload bit set. > ] > ]Regards, > ]Erik > ]_______________________________________________ > ]Isis-wg mailing list - Isis-wg@external.juniper.net > ]http://external.juniper.net/mailman/listinfo/isis-wg > > - Naiming > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From naiming@redback.com Wed Nov 14 23:18:52 2001 From: naiming@redback.com (Naiming Shen) Date: Wed, 14 Nov 2001 15:18:52 -0800 Subject: FW: [Isis-wg] Overload & Attached bits In-Reply-To: Mail from Alan Hannan dated Wed, 14 Nov 2001 15:32:06 CST <20011114153206.E16841@routingloop.com> Message-ID: <20011114231852.AAA85F2C42@prattle.redback.com> Hi, Alan, Great to hear all the 10589 "vialations":-) I had personal experience of the similar vialation: routerA and routerB were in a webfarm connected by GigEs running IS-IS, and each had a OCx link to the backbone. It was nice to set OL bit on both routerA and routerB so that those two routers didn't carry transit traffic through the webfarm. My previous posting just responded to the case when OL and ATT bits are both set in a L1 area. ] ] FWIW, in ISP routing topology design, often times a box with the ] IS-IS OL-bit set is used for carrying traffic. ] ] There are two situtaions where this occurs, and they are usually ] both where the router in question is used as part of an auxilliary or ] out-of-band networks. ] ] The first is where the router in question is used only as a gateway of last ] resort for certain kinds of traffic, with a default route back towards the ] NMS or NOC area, only for the purpose of carrying a subset of ] traffic. Note that typically this router is not meant to carry ] production traffic. ] ] The second is where the router in question is using other routing ] protocols to carry certain types of traffic/destinations. i.e. ] Ships in the Night kind of stuff. Also, this router is not meant to ] carry production traffic in this context, rather stats and ] management traffic (telnet to boxes, SNMP, etc..). ] ] I assert that common ISP usage of IS-IS OL-bit does not comply with ] ISO10589-2001, section 9.8, yet it does comply with the wording if ] the phrase "any decision process' is changed to 'the IS-IS routing ] algorithm". ] ] -alan ] ]Thus spake Naiming Shen (naiming@redback.com) ] on or about Wed, Nov 14, 2001 at 12:14:51PM -0800: ]> ]> I would try to avoid picking the router with OL bit set if there are ]> multiple gateways available. But if all the L2/L1 gateways have the OL ]> bit set, then pick them anyway and send default traffic to them. Since ]> if not, those traffic will be dropped on the local L1 routers. Often ]> the OL bit these days indicate the BGP is not converged yet, at least ]> a subset of the traffic can still be delivered through the gateways ]> which is better than drop all of them. In the old days, routing and ]> forwarding compete for the same resource on routers, so doing the above ]> suggestion would not be a good behaviour, its hardly this case now. ]> ]> ]Nagasta Bagamba wrote: ]> ]> ]> ]> 2. Should we consider overloaded routers in our search ]> ]> for the nearest attached level-2 intermediate system? > ]> ]> ]> You decided that the answer is No. But, I know of at ]> ]> least 2 major vendors which consider overloaded ]> ]> routers in the search for the nearest attached level-2 ]> ]> IS. ]> ]> If vendors-mixture ISIS topology will be built, ]> ]> routing loops may occure. Does anyone have an idea how ]> ]> to avoid routing loops in such a topology? ]> ] ]> ]Hi, ]> ] ]> ]ISO10589-2001, section 9.8, says about the Overload bit: ]> ]"An LSP with this bit set will not be used by any decision process to ]> ]calculate routes to another IS through the originating system". ]> ] ]> ]I would interpret this statement so that no default level 2 IS ]> ]route may be calculated to an IS with the overload bit set. ]> ] ]> ]Regards, ]> ]Erik ]> ]_______________________________________________ ]> ]Isis-wg mailing list - Isis-wg@external.juniper.net ]> ]http://external.juniper.net/mailman/listinfo/isis-wg ]> ]> - Naiming ]> _______________________________________________ ]> Isis-wg mailing list - Isis-wg@external.juniper.net ]> http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From sachidananda_k@hotmail.com Thu Nov 15 11:14:59 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Thu, 15 Nov 2001 11:14:59 +0000 Subject: [Isis-wg] LAN ID field in LAN IIH Message-ID: Hello, I've a question related to the values to be filled in packet format for the L1 LAN ISH. As soon as the IS comes up, what value do we fill in the LAN ID field. Is it supposed to be left blank ( filled with all 0's). I'm refering to the first Hello packet sent on the broadcast interface. Please help me clarify this doubt. Thanking you in advance for all the response. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From Larmer@CommSense.Net Thu Nov 15 13:57:54 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 15 Nov 2001 08:57:54 -0500 Subject: [Isis-wg] LAN ID field in LAN IIH In-Reply-To: Message-ID: Hi Sachi, > I've a question related to the values to be filled in packet > format for the > L1 LAN ISH. As soon as the IS comes up, what value do we fill in > the LAN ID > field. Is it supposed to be left blank ( filled with all 0's). > I'm refering > to the first Hello packet sent on the broadcast interface. Do you mean L1 LAN IIH PDU? An ISH is sent on a broadcast interface if you are running IS-IS and/or DECnet Phase V. The ISH is meant to inform OSI ES or DECnet Phase V ES of the routers available on a given LAN. However, in Integrated IS-IS (IP-Only) there is no need to send an ISH on a broadcast circuit (Int IS-IS does not care about ESs). With reference to a LAN IIH PDU, when a broadcast circuit is first enabled, the LAN ID portion is set in accordance with the following ISO-10589 reference: 8.4.1 Enabling of broadcast circuits When the broadcast circuit is enabled on an Intermediate system the IS shall perform the following actions. a) Commence sending IIH PDUs with the LAN ID field set to the concatenation of its own systemID and its locally assigned one octet Local Circuit ID. ... d) After waiting iSISHelloTimer × 2 seconds, run the Level 1 and or the level 2 designated intermediate system election process depending on the Intermediate system type. 8.4.5 LAN designated intermediate systems The LAN ID field in the LAN IIH PDUs transmitted by this system shall be set to the value of the LAN ID field reported in the LAN IIH PDU (for the appropriate level) received from the system which this system considers to be the Designated Intermediate System. This value shall also be passed to the Update Process, as the pseudonode ID, to enable Link State PDUs to be issued for this system claiming connectivity to the pseudonode. If this system, as a result of the Designated Intermediate System election process, considers itself to be designated Intermediate System, the LAN ID field shall be set to the concatenation of this system’s own system ID and the locally assigned one octet Local Circuit ID. From jparker@axiowave.com Thu Nov 15 20:21:02 2001 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 15 Nov 2001 15:21:02 -0500 Subject: [Isis-wg] Revised MIB Message-ID: I've just sent in revision .06 of the ISIS MIB to the ietf. Most changes were made to accommodate SMICng. Some edits were made to comments. The list of major changes is below. -- Changes in version 06. -- Updates for clean SMICng compile -- Remove unused IMPORTed types -- Removed restrictions on InetAddressType (pity) -- Conformance section added The next effort will be to add Notifications (aka Traps) to the mix. I have started off with the 10589 list of alarms, but would be happy to add any events that the community would find useful. I will also be looking at traffic engineering knobs that need adding. Comments always welcome. This is a busy week at the IETF, so it may be awhile before the draft appears. If you wish to see an early version, drop me a line: the reflector will not relay a document this big. - jeff parker - axiowave networks - There's many a man hath more hair than wit. From nagastabagamba@yahoo.com Fri Nov 16 12:36:00 2001 From: nagastabagamba@yahoo.com (Nagasta Bagamba) Date: Fri, 16 Nov 2001 04:36:00 -0800 (PST) Subject: [Isis-wg] Overload & Attached bits Message-ID: <20011116123600.46330.qmail@web21102.mail.yahoo.com> Hi, It seems to me that we all want the overload bit to have a different meaning depends on the cause of the overloading situation: Erik, you want to go by the book (in this case the ISO 10589). I don't think anyone can argue with your interpretation. Shen, in your example you prefer to send traffic to any IS than not sending at all. I suppose in most cases the traffic will go through the overloaded IS and reach the destination safely. But as you said, you suppose that in most cases the overload bit indicates the BGP is not converged yet. Erez, you gave an example why not using the the overloaded IS in the nearest attached algo. Alan, you gave an example for why not using the overloaded IS as transient. It looks like there should be a different behavior depends on the cause of the overloading (on-startup, 'real' database overload, new tested router...). As I see it, we have 2 problems: 1. There is only ONE bit, so other routers have no idea what was the reason for setting it. 2. We can't 'violate' the ISO/RFC standards just because we think there are better ways to do things. Standards are what the protocol is all about... In a multi-vendors isis topology, the system administrator will have a really hard job trying to figure out the behavior in an overloaded situation. Regards, Nagi --- Naiming Shen wrote: > To: Alan Hannan > CC: Erik Hietbrink , > Nagasta Bagamba , > isis-wg@spider.juniper.net > Subject: Re: FW: [Isis-wg] Overload & Attached bits > Date: Wed, 14 Nov 2001 15:18:52 -0800 > From: Naiming Shen > > > Hi, Alan, > Great to hear all the 10589 "vialations":-) > I had personal experience of the similar vialation: > routerA > and routerB were in a webfarm connected by GigEs > running IS-IS, and > each had a OCx link to the backbone. It was nice to > set OL bit on > both routerA and routerB so that those two routers > didn't carry > transit traffic through the webfarm. My previous > posting just > responded to the case when OL and ATT bits are both > set in a L1 area. > > ] > ] FWIW, in ISP routing topology design, often > times a box with the > ] IS-IS OL-bit set is used for carrying traffic. > ] > ] There are two situtaions where this occurs, and > they are usually > ] both where the router in question is used as > part of an auxilliary or > ] out-of-band networks. > ] > ] The first is where the router in question is > used only as a gateway of last > ] resort for certain kinds of traffic, with a > default route back towards the > ] NMS or NOC area, only for the purpose of > carrying a subset of > ] traffic. Note that typically this router is not > meant to carry > ] production traffic. > ] > ] The second is where the router in question is > using other routing > ] protocols to carry certain types of > traffic/destinations. i.e. > ] Ships in the Night kind of stuff. Also, this > router is not meant to > ] carry production traffic in this context, rather > stats and > ] management traffic (telnet to boxes, SNMP, > etc..). > ] > ] I assert that common ISP usage of IS-IS OL-bit > does not comply with > ] ISO10589-2001, section 9.8, yet it does comply > with the wording if > ] the phrase "any decision process' is changed to > 'the IS-IS routing > ] algorithm". > ] > ] -alan > ] > ]Thus spake Naiming Shen (naiming@redback.com) > ] on or about Wed, Nov 14, 2001 at 12:14:51PM > -0800: > ]> > ]> I would try to avoid picking the router with OL > bit set if there are > ]> multiple gateways available. But if all the > L2/L1 gateways have the OL > ]> bit set, then pick them anyway and send default > traffic to them. Since > ]> if not, those traffic will be dropped on the > local L1 routers. Often > ]> the OL bit these days indicate the BGP is not > converged yet, at least > ]> a subset of the traffic can still be delivered > through the gateways > ]> which is better than drop all of them. In the > old days, routing and > ]> forwarding compete for the same resource on > routers, so doing the above > ]> suggestion would not be a good behaviour, its > hardly this case now. > ]> > ]> ]Nagasta Bagamba wrote: > ]> ]> > ]> ]> 2. Should we consider overloaded routers in > our search > ]> ]> for the nearest attached level-2 > intermediate system? > > ]> > ]> ]> You decided that the answer is No. But, I > know of at > ]> ]> least 2 major vendors which consider > overloaded > ]> ]> routers in the search for the nearest > attached level-2 > ]> ]> IS. > ]> ]> If vendors-mixture ISIS topology will be > built, > ]> ]> routing loops may occure. Does anyone have > an idea how > ]> ]> to avoid routing loops in such a topology? > ]> ] > ]> ]Hi, > ]> ] > ]> ]ISO10589-2001, section 9.8, says about the > Overload bit: > ]> ]"An LSP with this bit set will not be used by > any decision process to > ]> ]calculate routes to another IS through the > originating system". > ]> ] > ]> ]I would interpret this statement so that no > default level 2 IS > ]> ]route may be calculated to an IS with the > overload bit set. > ]> ] > ]> ]Regards, > ]> ]Erik > ]> > ]_______________________________________________ > ]> ]Isis-wg mailing list - > Isis-wg@external.juniper.net > ]> > ]http://external.juniper.net/mailman/listinfo/isis-wg > ]> > ]> - Naiming > ]> _______________________________________________ > ]> Isis-wg mailing list - > Isis-wg@external.juniper.net > ]> > http://external.juniper.net/mailman/listinfo/isis-wg > > - Naiming __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From ehietbrink@lucent.com Fri Nov 16 14:51:37 2001 From: ehietbrink@lucent.com (Erik Hietbrink) Date: Fri, 16 Nov 2001 15:51:37 +0100 Subject: [Isis-wg] Overload & Attached bits References: <20011116123600.46330.qmail@web21102.mail.yahoo.com> Message-ID: <3BF527F9.F7B64731@lucent.com> Nagasta Bagamba wrote: > > It looks like there should be a different behavior > depends on the cause of the overloading (on-startup, > 'real' database overload, new tested router...). > As I see it, we have 2 problems: > 1. There is only ONE bit, so other routers have no > idea what was the reason for setting it. > 2. We can't 'violate' the ISO/RFC standards just > because we think there are better ways to do things. > Standards are what the protocol is all about... > > In a multi-vendors isis topology, the system > administrator will have a really hard job trying to > figure out the behavior in an overloaded situation. Good summary. My major concern is what to do in a dual-ISIS stack (NE supports ISIS for OSI and I-ISIS for IP), when this overload bit is interpreted differently. My personal choice for conveying information retrieved from other routing processes (like BGP convergence) would be to put it in a TLV. We should avoid having multi-interpretable fields in PDUs. Regards, Erik From henk@Procket.com Fri Nov 16 17:52:54 2001 From: henk@Procket.com (Henk Smit) Date: Fri, 16 Nov 2001 09:52:54 -0800 (PST) Subject: [Isis-wg] Overload & Attached bits In-Reply-To: <20011116123600.46330.qmail@web21102.mail.yahoo.com> from "Nagasta Bagamba" at Nov 16, 2001 04:36:00 AM Message-ID: <200111161752.fAGHqsfM010674@redd3174.procket.com> > In a multi-vendors isis topology, the system > administrator will have a really hard job trying to > figure out the behavior in an overloaded situation. The problem is this: Right now we are discussing how L1-only routers should interpret the overload-bit and the attached-bit. IMHO this is not open for discussion. 10589 clearly says how a router is supposed to compute routes when it sees LSPs with either the attached bit (ATT) set, or the overload bit (OVL) set. As noted, when you change this, you will run into compatability issues. So: don't change the interpretation of the OVL and ATT bits. What is not clearly defined is when a router must, could or should set the ATT bit and/or OVL bit. So implementators are free to play with algorithms when to set or not set those bits. Setting one of these bits means that the router either invites or discourages other routers to send traffic through it. Regardless of what algorithms implementors use for their L1L2 routers to decide to set the ATT bit and OVL bit, if all routers interpret these bits the same way, this should never cause routing loops. Let's look at the problem of a L1L2 router setting the OVL bit. It means it doesn't want to attract intra-area transit traffic. If the implementor also meant that he didn't want to attract L1->L2 inter-area traffic, then the implementor should make sure that his router also does not set the ATT bit. Simple as that. If a router sets both ATT and OVL, that means it does not want to forward intra-area traffic, but it does want to forward L1->L2 inter-area traffic. The same is through for inter-area traffic in the other direction. If a L1L2 router sets the OVL bit in its L2 LSP, but it also advertises all L1 prefixes learned via L1 routing, then it must forward traffic to those L1 destinations. If it doesn't want to forward that L2->L1 traffic, then it must not advertise those L1 prefixes in its L2 LSP. Last remaining problem. Suppose a L1L2 router is the only router that supplies connectivity between two parts of the network. Setting the OVL bit will make those two parts effectively disconnected. This might not always be the behaviour you want. If you want to solve this problem by making routers interpret the OVL in a different way, then you run into compatability problems again. So don't try to solve this problem by chaning the interpretation on the other routers. Solve it by changing the behaviour of the advertising router. A solution would be to not use the OVL bit to discourage other routers to compute a path through this router. In stead, the router could advertise all its links with a very high metric. That would cause paths through this router to be the least preferred, but in case there are no other paths, it would still be used. And thus the network will not become partitioned. (Granted, this will probably work better with the newer TLVs with wider metrics). So it might not be enough to just set or not set the OVL bit. A router should also adjust the ATT bit. And it should consider which L1->L2 and L2->L1 prefixes to advertise. And it should make a decision wether to use the OVL bit trick or the trick where it set its link metrics to a high value. All this can be done in the advertising router. It is easy to solve problems by changing semantics of existing protocols. Unfortunately usually that won't work in the real world. Useful solutions should work in a backward compatible way. Putting all intelligence in the advertising router should ensure backward compatibility. Hope this helps, Henk. From hannes@juniper.net Mon Sep 10 19:55:43 2001 From: hannes@juniper.net (Hannes Gredler) Date: Mon, 10 Sep 2001 20:55:43 +0200 Subject: [Isis-wg] draft-ietf-isis-traffic-04.txt In-Reply-To: <00be01c13a04$66da0950$b4036c6b@Manav>; from swatirstogi@yahoo.com on Mon, Sep 10, 2001 at 07:55:08PM +0530 References: <00be01c13a04$66da0950$b4036c6b@Manav> Message-ID: <20010910205543.B18900@juniper.net> [chaos] theory tells .. the best scheme is to use _no_ scheme as you cannot maintain it anyway ;-) /hannes On Mon, Sep 10, 2001 at 07:55:08PM +0530, Swati Rastogi wrote: | Hi, | I was just going through the above stated draft. I have a very elementary | doubt. Why aren't the sub TLVs numbered as 1,2,3,4,5 etc. Why are they | numbered as 3,6,8,9,etc. This is the draft that i presume introduced these | additional subTLVs, so why aren't the numbers really ordered ? | | This is indeed a very foolish doubt .. but am just curious. | | Thanks, | Swati | | | _________________________________________________________ | Do You Yahoo!? | Get your free @yahoo.com address at http://mail.yahoo.com | | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg From KChapman@unispherenetworks.com Thu Sep 20 18:53:10 2001 From: KChapman@unispherenetworks.com (Chapman, Ken) Date: Thu, 20 Sep 2001 13:53:10 -0400 Subject: [Isis-wg] draft-ietf-isis-wg-mib-05.txt Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C031F4291@mailwest.unispherenetworks.com> Hi, Could someone please explain to me the third sentance of the following object definition? isisManAreaAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the isisManAreaAddrEntry. This object follows the Row Status behaviour. If an attempt is made to set this object to the value off when the corresponding isisManAreaAddrEntry is the only valid entry for this instance and when the corresponding ISIS instance has isisSysAdminState set to On then the attempt is rejected." DEFVAL { active } ::= { isisManAreaAddrEntry 2 } Thanks, Ken ps. Please e-mail me direct; I'm not a member of your list. (I just do a lot of SNMP stuff.) ++++++++++++++++++++++++++++++++++++++++++++++ Ken Chapman Unisphere Networks, Inc. M/S 2056 Tel: +1 978 589 0288 10 Technology Park Drive Fax: +1 978 589 0800 Westford, MA 01886 Email: KChapman@UnisphereNetworks.com ++++++++++++++++++++++++++++++++++++++++++++++ From 0xLJC0EED2EEz/0xLJC4CFBEA9D1D0BEBFCBF9z/0xLJBDBBBBBBB2FAC6B7CAC2D2B5B2BFz/zte_ltd@mail.zte.com.cn Sat Sep 22 09:03:05 2001 From: 0xLJC0EED2EEz/0xLJC4CFBEA9D1D0BEBFCBF9z/0xLJBDBBBBBBB2FAC6B7CAC2D2B5B2BFz/zte_ltd@mail.zte.com.cn (0xLJC0EED2EEz/0xLJC4CFBEA9D1D0BEBFCBF9z/0xLJBDBBBBBBB2FAC6B7CAC2D2B5B2BFz/zte_ltd) Date: Sat, 22 Sep 2001 16:03:05 +0800 Subject: [Isis-wg] how to transfer isis pdu in p2p link? Message-ID: In Lan , isis pdu is transmitted using 802.3. Who knows what link protocol is used when isis pdu transmitted in p2p network? thx advance From mjyang@etri.re.kr Tue Sep 4 03:04:54 2001 From: mjyang@etri.re.kr (Mijung Yang) Date: Tue, 4 Sep 2001 11:04:54 +0900 Subject: [Isis-wg] Question about Internet Draft of IS-IS TE extension Message-ID: <000f01c134e5$fd8cc1e0$37c2fe81@etri.re.kr> This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C13531.6D49B060 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQpEZWFyLi4NCg0KSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IGRyYWZ0LWlldGYtaXNpcy10 cmFmZmljLTA0LnR4dC4NCiANCkZpcnN0LA0KSSBkb24ndCBrbm93IGV4YWN0IG1lYW5pbmcgcHJl Zml4IGxlbmd0aCBmaWVsZCg2Yml0cykgYW5kIElQdjQgcHJlZml4IGZpZWxkKDB+NG9jdGV0cykN CmluIHRoZSBleHRlbmRlZCBJUCByZWFjaGFiaWxpdHkgVExWLg0KSSB0aGluayB0aGF0IHRoZSBt ZWFuaW5nIG9mIHR3byBmaWVsZHMgaXMgc2FtZS4NCkFuZCwgSG93IGNhbiBJIGtub3cgdGhlIHJl YWNoYWJsZSBuZXR3b3JrPw0KUGxlYXNlLCBsZXQgbWUgaW5mb3JtIHRoZSBleGFjdCBtZWFuaW5n IGFuZCB1c2FnZSBvZiB0aGUgdHdvIGZpZWxkcyANCiANClNlY29uZCwNCkkgd2FudCB0byBjb25m aXJtIHRoYXQgc3ViLVRMViA2IGFuZCBzdWItVExWIDggaW4gdGhlIGV4dGVuZGVkIElTIHJlYWNo YWJpbGl0eSBUTFYgDQppbmRpY2F0ZSB0d28gZW5kIGFkZHJlc3Mgb2YgdGhlIGxpbmsgYW5kIHRo aXMgYWRkcmVzcyBpcyByb3V0ZXIgSUQgYWRkcmVzcyBvciBub3QuDQoNCkF3YWl0aW5nIHRoZSBw bGVhc3VyZSBvZiB5b3VyIHJlcGx5LiANClJlZ2FyZHMsDQoNCi0tLS0tLS0tLS0tLS0tLS0tDQpN aWp1bmcgWWFuZyAvIEVUUkkgDQpURUw6ICs4Mi00Mi04NjAtNDkyMiANCkZBWDogKzgyLTQyLTg2 MC01NDQwIA0KRS1tYWlsOiBtanlhbmdAZXRyaS5yZS5rciANCg0K ------=_NextPart_000_000C_01C13531.6D49B060 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj5EZWFyLi48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+SSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IA0KZHJhZnQtaWV0Zi1pc2lz LXRyYWZmaWMtMDQudHh0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkZpcnN0LDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPkkgZG9uJ3Qga25vdyBleGFjdCBtZWFuaW5nIHByZWZpeCBsZW5ndGggZmll bGQoNmJpdHMpIGFuZCBJUHY0IA0KcHJlZml4IGZpZWxkKDB+NG9jdGV0cyk8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5pbiB0aGUgZXh0ZW5kZWQgSVAgcmVhY2hhYmlsaXR5IFRMVi48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHRoaW5rIHRoYXQgdGhlIG1lYW5pbmcg b2YgdHdvIGZpZWxkcyBpcyBzYW1lLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkFu ZCwgSG93IGNhbiZuYnNwO0kga25vdyB0aGUmbmJzcDtyZWFjaGFibGUgDQpuZXR3b3JrPzwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlBsZWFzZSwgbGV0IG1lIGluZm9ybSB0aGUgZXhh Y3QgbWVhbmluZyBhbmQgdXNhZ2Ugb2YgdGhlIHR3byANCmZpZWxkczwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPlNlY29uZCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHdhbnQgdG8gY29u ZmlybSB0aGF0IHN1Yi1UTFYgNiBhbmQgc3ViLVRMViA4IGluIHRoZSBleHRlbmRlZCANCklTIHJl YWNoYWJpbGl0eSBUTFYgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+aW5kaWNhdGUg dHdvIGVuZCBhZGRyZXNzIG9mIHRoZSBsaW5rIGFuZCB0aGlzIGFkZHJlc3MgaXMgDQpyb3V0ZXIg SUQgYWRkcmVzcyBvciBub3QuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9Mj5Bd2FpdGluZyB0aGUgcGxlYXN1cmUgb2YgeW91ciBy ZXBseS48L0ZPTlQ+IA0KPERJVj48Rk9OVCBzaXplPTI+UmVnYXJkcyw8QlI+PC9GT05UPjwvRk9O VD48Rk9OVCBzaXplPTI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+LS0tLS0tLS0t LS0tLS0tLS08QlI+TWlqdW5nIFlhbmcgLyBFVFJJIDxCUj5URUw6IA0KKzgyLTQyLTg2MC00OTIy IDxCUj5GQVg6ICs4Mi00Mi04NjAtNTQ0MCA8QlI+RS1tYWlsOiA8QSANCmhyZWY9Im1haWx0bzpt anlhbmdAZXRyaS5yZS5rciI+bWp5YW5nQGV0cmkucmUua3I8L0E+IA0KPEJSPjwvRElWPjwvRElW PjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000C_01C13531.6D49B060-- From jparker@axiowave.com Mon Nov 19 22:31:36 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 19 Nov 2001 17:31:36 -0500 Subject: [Isis-wg] draft-ietf-isis-wg-mib-05.txt Message-ID: > Hi, > Could someone please explain to me the third sentance of the following > object definition? > > isisManAreaAddrExistState OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The state of the isisManAreaAddrEntry. This object > follows the Row Status behaviour. If an attempt is > made to set this object to the value off when the > corresponding isisManAreaAddrEntry is the only valid > entry for this instance and when the corresponding ISIS > instance has isisSysAdminState set to On then the attempt > is rejected." > DEFVAL { active } > ::= { isisManAreaAddrEntry 2 } Ken - RowStatus is something I didn't create. See Dave Perkins book for a discussion of this. Briefly it is used to disambiguate creation and deletion. "If an attempt is made to set this object to the value off when the corresponding isisManAreaAddrEntry is the only valid entry for this instance and when the corresponding ISIS instance has isisSysAdminState set to On then the attempt is rejected." If someone wants to remove an Area Address, at it is the only configured address left, you should not allow this to happen, as the protocol needs to have at least one defined. You -can- do this if you turn off the protocol, and then remove the Address. Suggestions on how to make this clearer are welcome. - jeff parker - axiowave networks From jparker@axiowave.com Mon Nov 19 23:24:34 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 19 Nov 2001 18:24:34 -0500 Subject: [Isis-wg] draft-ietf-isis-wg-mib-05.txt Message-ID: > RowSatus has no value named "off". > Do you mean "destroy" or do you mean "notInService" or do you > mean both? > I suspect that both should return inconsistentValue. > You really need to make sure you explain the exact expected > behaviour for a varbind as complex as RowStatus. > Ken > > RowStatus is something I didn't create. See Dave Perkins book for > > a discussion of this. Briefly it is used to disambiguate creation > > and deletion. Clearly RowStatus is something I didn't create -or- understand. I think you are right: an attempt to take an active entry to destroy or notInService should generate inconsistentValue. isisManAreaAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the isisManAreaAddrEntry. This object follows the Row Status behavior. If the isisSysAdminState for this instance is 'on', and an attempt is made to set this object to the value 'destroy' or 'notInService' when this is the only isisManAreaAddrEntry for this instance in state 'active', then the set should return inconsistentValue." DEFVAL { active } ::= { isisManAreaAddrEntry 2 } - jeff parker - axiowave networks From henk@Procket.com Tue Nov 20 00:08:06 2001 From: henk@Procket.com (Henk Smit) Date: Mon, 19 Nov 2001 16:08:06 -0800 (PST) Subject: [Isis-wg] draft-ietf-isis-traffic-04.txt In-Reply-To: <20010910205543.B18900@juniper.net> from "Hannes Gredler" at Sep 10, 2001 08:55:43 PM Message-ID: <200111200008.fAK086DD011110@redd3174.procket.com> They started with 1,2,3,4,5 ..... Then people found out that some sub-TLVs were actually not needed, and stopped using them in their implementations. But others kept being used. We kept those in the draft. And why change the numbers later ? This stuff is already deployed, so changing the number is gonna be painful, and serves no real purposes. Henk. > [chaos] theory tells .. the best scheme is to use _no_ scheme as > you cannot maintain it anyway ;-) > > /hannes > > On Mon, Sep 10, 2001 at 07:55:08PM +0530, Swati Rastogi wrote: > | Hi, > | I was just going through the above stated draft. I have a very elementary > | doubt. Why aren't the sub TLVs numbered as 1,2,3,4,5 etc. Why are they > | numbered as 3,6,8,9,etc. This is the draft that i presume introduced these > | additional subTLVs, so why aren't the numbers really ordered ? > | > | This is indeed a very foolish doubt .. but am just curious. > | > | Thanks, > | Swati > | > | > | _________________________________________________________ > | Do You Yahoo!? > | Get your free @yahoo.com address at http://mail.yahoo.com > | > | _______________________________________________ > | Isis-wg mailing list - Isis-wg@external.juniper.net > | http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From henk@procket.com Tue Nov 20 00:05:42 2001 From: henk@procket.com (Henk Smit) Date: Mon, 19 Nov 2001 16:05:42 -0800 (PST) Subject: [Isis-wg] how to transfer isis pdu in p2p link? In-Reply-To: from "0xLJC0EED2EEz/0xLJC4CFBEA9D1D0BEBFCBF9z/0xLJBDBBBBBBB2FAC6B7CAC2D2B5B2BFz/zte_ltd" at Sep 22, 2001 04:03:05 PM Message-ID: <200111200005.fAK05gMr011090@redd3174.procket.com> > In Lan , isis pdu is transmitted using 802.3. Who knows what link protocol > is used when isis pdu transmitted in p2p network? Whatever you want. Whatever you are running on the p2p link. So if you use PPP, ISIS will be inside a PPP frame. If you wanna run cisco's HDLC, the ISIS packet will be inside a HDLC frame. Unlike ethernet, where you can run 4 different encapsulations at the same time, on a p2p link you can run only one encapsulation at the same time Henk. From dhudek@ma.ultranet.com Tue Nov 20 01:50:03 2001 From: dhudek@ma.ultranet.com (David Hudek) Date: Mon, 19 Nov 2001 20:50:03 -0500 Subject: [Isis-wg] Question about subTLVs 6 & 8 of TLV 22 Message-ID: <3BF9B6CB.C8C1439F@ma.ultranet.com> hi all, I was starting to look more closely at the draft ISIS Extensions for Traffic Engineering rfc, and of course, found myself looking at an old out-of-date copy :-) I quickly switched to the latest, but then noticed a change I have a question about. Back in version 02, when discussing subTLVs 6 and 8 of the Extended IS Reachability TLV (22), there was a proposed scheme for encoding IP addresses when the interface in question essentially had none... when it was an unnumbered point-to-point link (although it would only seem to work if the interfaceID of the unnumbered interface would fit into 16 bits?) [basically, put the advertising rtrID in the iface addr subTlv(6), and the low 16 bits of the interface id in the nbr addr subTlv(8)] In the latest version (04, I believe), that text seems to have been removed, which begs the question, why? and how ought one encode address info for unnumbered point-to-points? I skimmed the old mails and didn't notice discussion about it... if I missed it and this is a boring rehash :-), can someone just point me to the subject lines and/or dates? If not, can anyone shed light on the rationale for the change and how unnumbered p2p's should be treated? Thanks in advance, dave h dhudek@ma.ultranet.com From jparker@axiowave.com Tue Nov 20 15:50:05 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 20 Nov 2001 10:50:05 -0500 Subject: [Isis-wg] draft-ietf-isis-wg-mib-05.txt Message-ID: > Jeff, > ... > The term "instance" is overloaded in the SNMP world (e.g. row > instance, object instance), so it might be clearer (to people > like me who understand SNMP much better than IS-IS) if you > qualified it with something like "protocol instance". > > Ken Replaced throughout with the term "instantiation". After sending draft 06 to the IESG, I found I had time to add Notifications (Traps) to the document. I have a version of the draft (07) that I am trying to get reviewed by the SNMP-irati. The IESG would like to find a MIB-expert with IS-IS domain knowledge. If there is a lurker on this list that this description fits, perhaps we can discuss what would be needed to move this closer to something closer to what the IESG is looking for. - jeff parker - axiowave networks From ramanann@future.futsoft.com Thu Nov 22 05:16:40 2001 From: ramanann@future.futsoft.com (Ramanan) Date: Thu, 22 Nov 2001 10:46:40 +0530 Subject: [Isis-wg] Removal of Excess Paths Message-ID: Hi Please clarify me regarding the Removal of excess paths. As per Pg. 15, (Sec. 7.2.7) of ISO 10589 - ver 1992, ~~~~ "When there are more than maximumPathSplits legal paths to a destination, this set shall be pruned until only maximum-Path Splits remain. The Intermediate system shall discriminate based upon: .... circuit ID: where two or more paths are associated with adjacencies of the same type, and same neighbour ID, an adjacency with a lower circuit ID is retained in preference to an adjacency with a higher circuit ID, where cir-cuit ID is the value of · ptPtCircuitID for non-broadcast circuits, · l1CircuitID for broadcast circuits when running the Level 1 Decision Process, and · l2CircuitID for broadcast circuits when running the Level 2 Decision Process." ~~~~ here I believe isisCircPttoPtCircID (isisCircEntry 22) (Circuit Table MIB Object) is to be used as the ptPtCircuitID for non-broadcast circuits to do the removal of excess paths, ..., (Incidentally this isisCircPttoPtCircID is filled after the negotiation of the Hello PDUs, hope I'm right here!!!) BUT, which MIB object is to be used for the l1CircuitID & l2CircuitID for the Broadcast Circuits. correct me if I'm wrong. Thanks Regards' Ramanan From KChapman@unispherenetworks.com Fri Oct 19 17:03:46 2001 From: KChapman@unispherenetworks.com (Chapman, Ken) Date: Fri, 19 Oct 2001 12:03:46 -0400 Subject: [Isis-wg] draft-ietf-isis-wg-mib-05.txt Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C031F4368@mailwest.unispherenetworks.com> I'm looking at the ISIS-MIB and think that it would be nice to include UNITS for many of the time-related objects. Most of them have the information in the descriptions, but rsIsisSysIshHoldTime and rsIsisSysIshConfigTimer do not. Are they in milliseconds? Thanks. Ken ++++++++++++++++++++++++++++++++++++++++++++++ Ken Chapman Unisphere Networks, Inc. M/S 2056 Tel: +1 978 589 0288 10 Technology Park Drive Fax: +1 978 589 0800 Westford, MA 01886 Email: KChapman@UnisphereNetworks.com ++++++++++++++++++++++++++++++++++++++++++++++ From danny@tcb.net Mon Oct 22 17:16:58 2001 From: danny@tcb.net (Danny McPherson) Date: Mon, 22 Oct 2001 10:16:58 -0600 Subject: [Isis-wg] FW: draft-ietf-isis-transient-02.txt Message-ID: <200110221616.f9MGGwV12786@tcb.net> FYI... Only resubmitted to address expiry. No content changes... danny@dog% diff draft-ietf-isis-transient-01.txt draft-ietf-isis-transient-02.txt 7,8c7,8 < INTERNET DRAFT Amber Networks, Inc. < July 2001 --- > INTERNET DRAFT TCB > October 2001 13c13 < --- > 58c58 < INTERNET DRAFT July 2001 --- > INTERNET DRAFT October 2001 114c114 < INTERNET DRAFT July 2001 --- > INTERNET DRAFT October 2001 170c170 < INTERNET DRAFT July 2001 --- > INTERNET DRAFT October 2001 226c226 < INTERNET DRAFT July 2001 --- > INTERNET DRAFT October 2001 282c282 < INTERNET DRAFT July 2001 --- > INTERNET DRAFT October 2001 322,326c322,326 < Amber Networks, Inc. < 48664 Milmont Drive < Fremont, CA 94538 < Phone: 510.687.5226 < Email: danny@ambernetworks.com --- > TCB > Phone: 303.470.9257 > Email: danny@tcb.net ------- Forwarded Message To: internet-drafts@ietf.org From: Danny McPherson Reply-To: danny@tcb.net Subject: draft-ietf-isis-transient-02.txt Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Oct 2001 10:14:32 -0600 Sender: danny@dog.tcb.net Network Working Group Danny McPherson INTERNET DRAFT TCB October 2001 IS-IS Transient Blackhole Avoidance 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. 2. Abstract This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. McPherson, D. [Page 1] =0C INTERNET DRAFT October 2001 3. Introduction When an IS-IS router that was previously a transit router becomes unavailable as a result of some transient condition such as a reboot, other routers within the routing domain must select an alternative path to reach destinations which had previously transited the failed router. Presumably, the newly selected router(s) comprising the path have been available for some time and, as a result, have complete forwarding information bases (FIBs) which contain a full set of reachability information for both internal and external (e.g., BGP) destination networks. When the previously failed router becomes available again, in only a few seconds paths that had previously transited the router are again selected as the optimal path by the IGP. As a result, forwarding tables are updated and packets are once again forwarded along the path. Unfortunately, external destination reachability information (e.g., learned via BGP) is not yet available to the router, and as a result, packets bound for destinations not learned via the IGP are unnecessarily discarded. A simple interoperable mechanism to alleviate the offshoot associated with this deterministic behavior is discussed below. 4. Discussion This document describes a simple, interoperable mechanism that can be employed in IS-IS [1, 2] networks in order to avoid transition to a newly available path until other associated routing protocols such as BGP have had sufficient time to converge. The benefits of such a mechanism can realized when considering the following scenario depicted in Figure 1. McPherson, D. [Page 2] =0C INTERNET DRAFT October 2001 D.1 | +-------+ | RtrD | +-------+ / \ / \ +-------+ +-------+ | RtrB | | RtrC | +-------+ +-------+ \ / \ / +-------+ | RtrA | +-------+ | S.1 Figure 1: Example Network Topology Host S.1 is transmitting data to destination D.1 via a primary path of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to destina=AD= tion D.1 via BGP from RtrD. RtrA's primary path to D.1 is selected because when calculating the path to BGP NEXT_HOP of RtrD the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less than the sum of the metrics of the RtrA-RtrC-RtrD path. Assume RtrB becomes unavailable and as a result the RtrC path to RtrD is used. Once RtrA's FIB is updated and it begins forwarding packets to RtrC everything should behave properly as RtrC has existing forwarding information regarding destination D.1's availability via BGP NEXT_HOP RtrD. Assume now that RtrB comes back online. In only a few seconds IS-IS neighbor state has been established with RtrA and RtrD and database syn=AD= chronization has occurred. RtrA now realizes that the best path to des=AD= tination D.1 is via RtrB, and therefore updates it FIB appropriately. RtrA begins to forward packets destined to D.1 to RtrB. Though, because RtrB has yet to establish and synchronization it's BGP neighbor rela=AD tionship and routing information with RtrD, RtrB has no knowledge regarding reachability of destination D.1, and therefore discards the packets received from RtrA destined to D.1. If RtrB were to temporarily set it's LSP Overload bit while synchroniz=AD= ing BGP tables with it's neighbors, RtrA would continue to use the work=AD= ing RtrA->RtrC->RtrD path, and the LSP should only be used to obtain McPherson, D. [Page 3] =0C INTERNET DRAFT October 2001 reachability to locally connected networks (rather than for calculating transit paths through the router, as defined in [1]). However, it should be noted that when RtrB goes away its LSP is still present in the IS-IS databases of all other routers in the routing domain. When RtrB comes back it establishes adjacencies. As soon as its neighbors have an adjacency with RtrB, they will advertise their new adjacency in their new LSP. The result is that all the other routers will receive new LSPs from RtrA and RtrD containing the RtrB adjacency, even though RtrB is still completing its synchronization and therefore has not yet sent it's new LSP yet. At this time SPF is computed and everyone will include RtrB in their tree since they will use the old version of RtrB LSP (the new one has not yet arrived). Once RtrB has finished establishing all its adjacen=AD cies, it will then regenerate its LSP and flood it. Then all other routers within the domain will finally compute SPF with the correct information. Only at that time will the Overload bit be taken into account. As such, it is recommended that each time a router establishes an adja=AD= cency, it will update its LSP and flood it immediately, even before beginning database synchronization. This will allow for the Overload bit setting to propagate immediately, and remove the potential for an older version of the reloaded routers LSP to be used. After synchronization of BGP tables with neighboring routers (or expiry of some other timer or trigger), RtrB would generate a new LSP, clearing the Overload bit, and RtrA could again begin using the optimal path via RtrB. Typically, in service provider networks IBGP connections are done via peerings with 'loopback' addresses. As such, the newly available router must advertise it's own loopback (or similar) IP address, as well as associated adjacencies, in order to make the loopbacks accessible to other routers within the routing domain. It's because of this that sim=AD= ply flooding an empty LSP is not sufficient. McPherson, D. [Page 4] =0C INTERNET DRAFT October 2001 5. Deployment Considerations Such a mechanism increases overall network availability and allows network operators to alleviate the deterministic blackholing behavior introduced in this scenario. Similar mechanisms [3] have been defined for OSPF, though only after realizing the usefulness obtained from that of the IS-IS Overload bit technique. This mechanism has been deployed in several large IS-IS networks for a number of years. Triggers for setting the Overload bit as described are left to the implementer. Some potential triggers could perhaps include "N sec=AD onds after booting", or "N number of BGP prefixes in the BGP Loc- RIB". Unlike similar mechanisms employed in [3], if the Overload bit is set in a router's LSP, NO transit paths are calculated through the router. As such, if no alternative paths are available to the desti=AD= nation network, employing such a mechanism may actually have a nega=AD= tive impact on convergence (i.e., the router maintains the only available path to reach downstream routers, but the Overload bit dis=AD= allows other nodes in the network from calculating paths via the router, and as such, no feasible path exists to the routers). Finally, if all systems within an IS-IS routing domain haven't imple=AD= mented the Overload bit correctly, forwarding loops may occur. 6. Potential Alternatives Alternatively, it may be considered more appealing to employ some=AD thing more akin to [3] for this purpose. With this model, during transient conditions a node advertises excessively high link metrics to serve as an indication to other nodes in the network that paths transiting the router are "less desirable" than existing paths. The advantage of a metric-based mechanism over the Overload bit mech=AD= anism proposed here model is that transit paths may still be calcu=AD lated through the router. Another advantage is that a metric- based mechanism does not require that all nodes in the IS-IS domain cor=AD rectly implement the Overload bit. However, as currently deployed, IS-IS provides for only 6 bits of space for link metric allocation, and 10 bits aggregate path metric. Though extensions proposed in [4] remove this limitation, they've not yet been widely deployed. As such, there's currently little flexi=AD bility when using link metrics for this purpose. Of course, both McPherson, D. [Page 5] =0C INTERNET DRAFT October 2001 methods proposed in this document are backwards-compatible. 7. Security Considerations The mechanisms specified in this memo introduces no new security issues to IS-IS. 8. Acknowledgements The author of this document makes no claim to the originality of the idea. Thanks to Stefano Previdi for valuable feedback on the mecha=AD= nism discussed in this document. 9. References [1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992. [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. [3] Retana et al., "OSPF Stub Router Advertisement", RFC 3137, June 2001. [4] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", Work in Progress. 10. Author's Address Danny McPherson TCB Phone: 303.470.9257 Email: danny@tcb.net McPherson, D. [Page 6] =0C ------- End of Forwarded Message From Ming.Chan@spirentcom.com Wed Oct 31 01:20:35 2001 From: Ming.Chan@spirentcom.com (Chan, Chung Ming) Date: Tue, 30 Oct 2001 15:20:35 -1000 Subject: [Isis-wg] Simple questions on the use of Authentication TLVs Message-ID: <8AC36D3167EED41184C800508BD9540501EE3B53@apollo.adtech-inc.com> All, I'm new to ISIS and hope some one can answer me the following questions regarding to the use of Authentication TLV. Thank you in advance! I'm working with ISO/IEC 10589:1992 and RFC 1195. In both spec there is Authentication VLF defined with different Code points, 10 for ISO10589 and 133 for RFC1195. The questions that I've: 1) If the router is supporting RFC 1195, SHALL it use 133 or 10? What is the guideline for using it? 2) Or should the router accept code point 10, if it supports RFC1195? Thanks, Ming Chan From hannes@juniper.net Tue Oct 9 10:09:28 2001 From: hannes@juniper.net (Hannes Gredler) Date: Tue, 9 Oct 2001 11:09:28 +0200 Subject: [Isis-wg] Status of some drafts In-Reply-To: <200110082028.f98KSGJ04443@malibu.torrentnet.com>; from sherwin@torrentnet.com on Mon, Oct 08, 2001 at 04:28:16PM -0400 References: <200110082028.f98KSGJ04443@malibu.torrentnet.com> Message-ID: <20011009110928.A19958@juniper.net> On Mon, Oct 08, 2001 at 04:28:16PM -0400, Chris Sherwin wrote: | Hi, | | I am interested in knowing what the status of some work in this group | is. In particular, I have been browsing the workgroup's mail archive | and various proceedings trying to figure out what happened to | the IS-IS over IPv4 and 3-way handshake efforts. | It seems they have expired? They are listed as submitted for RFC status, | but I cannot find any RFCs, although I can pick up old copies of the | drafts. chris, IS-IS over IP was considered to be uninteresting, the 3-way draft (at least v2 of the draft) is widely deployed. /hannes From ramanann" Hi Please clarify me regarding the Removal of excess paths. As per Pg. 15, (Sec. 7.2.7) of ISO 10589 - ver 1992, ~~~~ "When there are more than maximumPathSplits legal paths to a destination, this set shall be pruned until only maximum-PathSplits remain. The Intermediate system shall discriminate based upon: .. circuit ID: where two or more paths are associated with adjacencies of the same type, and same neighbour ID, an adjacency with a lower circuit ID is retained in prefer-ence to an adjacency with a higher circuit ID, where circuit ID is the value of · ptPtCircuitID for non-broadcast circuits, · l1CircuitID for broadcast circuits when running the Level 1 Decision Process, and · l2CircuitID for broadcast circuits when running the Level 2 Decision Process." ~~~~ here I beleive isisCircPttoPtCircID (isisCircEntry 22) (Circuit Table MIB Object) is to be used as the ptPtCircuitID for non-broadcast circuits to do the removal of excess paths, ..., (Incidentally this isisCircPttoPtCircID is filled after the negotiation of the Hello PDUs, hope i'm right here!!!) BUT, which MIB object is to be used for the l1CircuitID & l2CircuitID for the Broadcast Circuits. correct me if i'm wrong. P.S.:- This mail, when sent to the isis-wg is bouncing back as "host not found" !!! Thanks Rgds' Ramanan 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 kaushik_ari@postmark.net Wed Nov 7 07:13:25 2001 From: kaushik_ari@postmark.net (aridaman kaushik) Date: Wed, 07 Nov 2001 07:13:25 +0000 Subject: [Isis-wg] (no subject) Message-ID: <20011107071325.22916.qmail@venus.postmark.net> aridaman kaushik kaushik_ari@postmark.net Hi all Can anyone help me in clearing my doubt for draft-ietf-isis-ipv6-02.txt 1. Interface address TLVs in LSP's will contain nonlinklocal addresses. What are these addresses? 2. How site local adddress will be supported ? thanks in advance aridaman From nagastabagamba@yahoo.com Wed Nov 14 06:57:29 2001 From: nagastabagamba@yahoo.com (Nagasta Bagamba) Date: Tue, 13 Nov 2001 22:57:29 -0800 (PST) Subject: Fwd: FW: [Isis-wg] Overload & Attached bits Message-ID: <20011114065729.76011.qmail@web21104.mail.yahoo.com> Hello Erez and WG, I want to make some comments about the 2 first issues you brought up. 1. Can a router have both bits set at the same time? I understand you agree the answer for that is Yes. But, I know at least one major vendor which doesn't allow to set this 2 bits at the same time. The reason for that is a kind of a mystery to me... Does anyone have an idea what that reason might be? 2. Should we consider overloaded routers in our search for the nearest attached level-2 intermediate system? You decided that the answer is No. But, I know of at least 2 major vendors which consider overloaded routers in the search for the nearest attached level-2 IS. If vendors-mixture ISIS topology will be built, routing loops may occure. Does anyone have an idea how to avoid routing loops in such a topology? 10x, Nagasta __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From nagastabagamba@yahoo.com Wed Nov 14 08:33:57 2001 From: nagastabagamba@yahoo.com (Nagasta Bagamba) Date: Wed, 14 Nov 2001 00:33:57 -0800 (PST) Subject: FW: [Isis-wg] Overload & Attached bits Message-ID: <20011114083357.37226.qmail@web21102.mail.yahoo.com> Hello Erez and WG, I want to make some comments about the 2 first issues you brought up. 1. Can a router have both bits set at the same time? I understand you agree the answer for that is Yes. But, I know of at least one major vendor which doesn't allow to set this 2 bits at the same time. The reason for that is a kind of a mystery to me... Does anyone have an idea what the reason for that may be? 2. Should we consider overloaded routers in our search for the nearest attached level-2 intermediate system? You decided that the answer is No. But, I know of at least 2 major vendors which consider overloaded routers in the search for the nearest attached level-2 IS. If vendors-mixture ISIS topology will be built, routing loops may occure. Does anyone have an idea how to avoid routing loops in such a topology? 10x, Nagasta __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From KChapman@unispherenetworks.com Tue Nov 20 13:55:17 2001 From: KChapman@unispherenetworks.com (Chapman, Ken) Date: Tue, 20 Nov 2001 08:55:17 -0500 Subject: [Isis-wg] draft-ietf-isis-wg-mib-05.txt Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C031F442C@mailwest.unispherenetworks.com> Jeff, That is much clearer, thanks. I have one more little nit. The term "instance" is overloaded in the SNMP world (e.g. row instance, object instance), so it might be clearer (to people like me who understand SNMP much better than IS-IS) if you qualified it with something like "protocol instance". I realize that it is made clear in the comment section just before the table, but there has been a lot of "push" in the SNMP standards area to make sure that the DESCRIPTION clauses contain complete and accurate description, since the comments sections are not "tied" to any object and therefore are not considered to be "normative". Also, this may not be the only object that suffers from this problem; it just happens to be the one I noticed. :^) Thanks. Ken > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Monday, November 19, 2001 6:25 PM > To: Chapman, Ken > Cc: 'isis-wg@juniper.net' > Subject: RE: [Isis-wg] draft-ietf-isis-wg-mib-05.txt > > > > > RowSatus has no value named "off". > > Do you mean "destroy" or do you mean "notInService" or do you > > mean both? > > I suspect that both should return inconsistentValue. > > You really need to make sure you explain the exact expected > > behaviour for a varbind as complex as RowStatus. > > Ken > > > > RowStatus is something I didn't create. See Dave Perkins book for > > > a discussion of this. Briefly it is used to disambiguate creation > > > and deletion. > > Clearly RowStatus is something I didn't create -or- understand. > > I think you are right: an attempt to take an active entry > to destroy or notInService should generate inconsistentValue. > > isisManAreaAddrExistState OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The state of the isisManAreaAddrEntry. This object > follows the Row Status behavior. If the isisSysAdminState > for this instance is 'on', and an attempt is made to set > this object to the value 'destroy' or 'notInService' when > this is the only isisManAreaAddrEntry for this instance > in state 'active', then the set should return > inconsistentValue." > > DEFVAL { active } > ::= { isisManAreaAddrEntry 2 } > > - jeff parker > - axiowave networks > From swatirstogi@yahoo.com Sat Nov 24 04:41:36 2001 From: swatirstogi@yahoo.com (Swati Rastogi) Date: Sat, 24 Nov 2001 10:11:36 +0530 Subject: [Isis-wg] Question about Internet Draft of IS-IS TE extension References: <000f01c134e5$fd8cc1e0$37c2fe81@etri.re.kr> Message-ID: <021b01c174a2$4cfdccf0$b4036c6b@Manav> This is a multi-part message in MIME format. ------=_NextPart_000_0218_01C174D0.66A3B970 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Hi Yang, The prefix length tells us of the network mask which has a value between = 0 and 32. Thus 6 bits have been reserved for it.=20 0-4 octets are reserved for the actual IP prefix which will be = considered till the value of the prefix length specified in the prefix = length. I hope this helps. Regards, Manav ----- Original Message -----=20 From: Mijung Yang=20 To: isis-wg-request@spider.juniper.net ; isis-wg@juniper.net ; = isis@merit.edu=20 Sent: Tuesday, September 04, 2001 7:34 AM Subject: [Isis-wg] Question about Internet Draft of IS-IS TE extension Dear.. I have some questions about draft-ietf-isis-traffic-04.txt. =20 First, I don't know exact meaning prefix length field(6bits) and IPv4 prefix = field(0~4octets) in the extended IP reachability TLV. I think that the meaning of two fields is same. And, How can I know the reachable network? Please, let me inform the exact meaning and usage of the two fields=20 =20 Second, I want to confirm that sub-TLV 6 and sub-TLV 8 in the extended IS = reachability TLV=20 indicate two end address of the link and this address is router ID = address or not. Awaiting the pleasure of your reply.=20 Regards, ----------------- Mijung Yang / ETRI=20 TEL: +82-42-860-4922=20 FAX: +82-42-860-5440=20 E-mail: mjyang@etri.re.kr=20 ------=_NextPart_000_0218_01C174D0.66A3B970 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
Hi Yang,
The prefix length tells us of the = network mask=20 which has a value between 0 and 32. Thus 6 bits have been reserved for = it.=20
0-4 octets are reserved for the = actual IP=20 prefix which will be considered till the value of the prefix length = specified in=20 the prefix length.
 
I hope this = helps.
 
Regards,
Manav
 
 
----- Original Message -----
From:=20 Mijung = Yang=20
To: isis-wg-request@spider.juniper= .net=20 ; isis-wg@juniper.net ; isis@merit.edu
Sent: Tuesday, September 04, = 2001 7:34=20 AM
Subject: [Isis-wg] Question = about=20 Internet Draft of IS-IS TE extension

 
Dear..
 
I have some questions about=20 draft-ietf-isis-traffic-04.txt.
 
First,
I don't know exact meaning prefix length = field(6bits) and=20 IPv4 prefix field(0~4octets)
in the extended IP reachability TLV.
I think that the meaning of two fields is = same.
And, How can I know the reachable=20 network?
Please, let me inform the exact meaning and usage = of the two=20 fields 
 
Second,
I want to confirm that sub-TLV 6 and sub-TLV 8 in = the=20 extended IS reachability TLV
indicate two end address of the link and this = address is=20 router ID address or not.
 
Awaiting the pleasure of your = reply.=20
Regards,
-----------------
Mijung Yang / ETRI
TEL:=20 +82-42-860-4922
FAX: +82-42-860-5440
E-mail: mjyang@etri.re.kr=20
------=_NextPart_000_0218_01C174D0.66A3B970-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From sprevidi@cisco.com Sat Nov 24 22:09:40 2001 From: sprevidi@cisco.com (stefano previdi) Date: Sat, 24 Nov 2001 23:09:40 +0100 Subject: [Isis-wg] IETF meeting ? Message-ID: <4.3.2.7.2.20011124230705.03844e60@brussels.cisco.com> Hi, are we going to have an isis-wg meeting in SLC ? thanks. s. From tli@procket.com Sun Nov 25 08:34:43 2001 From: tli@procket.com (Tony Li) Date: Sun, 25 Nov 2001 00:34:43 -0800 Subject: [Isis-wg] IETF meeting ? In-Reply-To: <4.3.2.7.2.20011124230705.03844e60@brussels.cisco.com> References: <4.3.2.7.2.20011124230705.03844e60@brussels.cisco.com> Message-ID: <15360.44323.591982.976648@alpha-tli.procket.com> | are we going to have an isis-wg meeting in SLC ? Not planning on it. Tony From Ming.Chan@SpirentCom.COM Sun Nov 25 23:15:08 2001 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming (Adtech ENG)) Date: Sun, 25 Nov 2001 13:15:08 -1000 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP Message-ID: <8AC36D3167EED41184C800508BD9540501EE3BEB@apollo.adtech-inc.com> Hi, I found out that in one vendor's pseudonode LSPs, there is no "Protocols Supported" field included; but it includes the field in the non-pseudonode LSPs. Shall the Protocols Supported field MUST be included in pseudonode LSP according to RFC 1195? Not sure if there is any reason for that particular vender for doing it. Could someone please verify this ? RFC 1195 Section 3.1, paragraph 3: "IP-capable (i.e., all IP-only and dual) routers need to know what network layer protocols are sup-ported by other routers in their area. This information is made available by inclusion of a "proto-cols supported" field in all IS-IS Hello and Link State Packets. This field makes use of the NL-PID (Network Layer Protocol Identifier), which is a one-octet value assigned by ISO to identify network level protocols. NLPID values have been assigned to ISO 8473 and to IP." Thanks, Ming Chan From tli@Procket.com Mon Nov 26 01:06:48 2001 From: tli@Procket.com (Tony Li) Date: Sun, 25 Nov 2001 17:06:48 -0800 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <8AC36D3167EED41184C800508BD9540501EE3BEB@apollo.adtech-inc.com> References: <8AC36D3167EED41184C800508BD9540501EE3BEB@apollo.adtech-inc.com> Message-ID: <15361.38312.708556.117236@alpha-tli.procket.com> | I found out that in one vendor's pseudonode LSPs, there is no "Protocols | Supported" field included; but it includes the field in the non-pseudonode | LSPs. | | Shall the Protocols Supported field MUST be included in pseudonode LSP | according to RFC 1195? | | Not sure if there is any reason for that particular vender for doing it. | | Could someone please verify this ? | | RFC 1195 Section 3.1, paragraph 3: | "IP-capable (i.e., all IP-only and dual) routers need to know what network | layer protocols are sup-ported | by other routers in their area. This information is made available by | inclusion of a "proto-cols | supported" field in all IS-IS Hello and Link State Packets. This field makes | use of the NL-PID | (Network Layer Protocol Identifier), which is a one-octet value assigned by | ISO to identify | network level protocols. NLPID values have been assigned to ISO 8473 and to | IP." Interesting question. Well, the pseudonode LSP is really there to represent the broadcast medium, not any particular router. And since the broadcast medium is presumably protocol independent, it doesn't seem like it actually conveys any useful information. Thus, IMHO, it would make sense if implementations ignored the Procotols Supported TLV in a pseudonode LSP and not require it be present. Tony From jlearman@cisco.com Mon Nov 26 02:20:50 2001 From: jlearman@cisco.com (Jeff Learman) Date: Sun, 25 Nov 2001 21:20:50 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <15361.38312.708556.117236@alpha-tli.procket.com> References: <8AC36D3167EED41184C800508BD9540501EE3BEB@apollo.adtech-inc.com> <8AC36D3167EED41184C800508BD9540501EE3BEB@apollo.adtech-inc.com> Message-ID: <4.3.2.7.2.20011125210113.019c4e20@dingdong.cisco.com> I agree with Tony. There are some additional things to consider, though. In accordance with RFC 1195, an implementation doesn't need to consult an LSP's supported protocols option when running SPF except for links to end systems, and a pseudonode LSP should have only links between intermediate systems. (Rather than relying on the protos supported option, RFC 1195 relies on the deployment rules.) My understanding is that some routers do take the protos-supported option when running SPF. This allows some relaxation of the deployment rules. There is no interoperability problem, because any strict implementation won't work anyway, in situations where this modification helps. However, in networks where this modification is being used, and mixed networks don't meet the deployment requirements in 1195, will it be important to make sure the designated router is a dual router? I can't find anything in 1195 that says to check protos- supported when bringing up an adjacency. If for any reason a system would not form an adjacency with a router with which it shared no protocols, that would cause a problem in the pseudonode LSPs. Hopefully this isn't a problem. Regards, Jeff PS: I don't work in IS-IS at Cisco. My comments do not necessarily reflect Cisco's opinions and I have no detailed knowledge of the Cisco IS-IS implementation. At 08:06 PM 11/25/2001, Tony Li wrote: > | I found out that in one vendor's pseudonode LSPs, there is no "Protocols > | Supported" field included; but it includes the field in the non-pseudonode > | LSPs. > | > | Shall the Protocols Supported field MUST be included in pseudonode LSP > | according to RFC 1195? > | > | Not sure if there is any reason for that particular vender for doing it. > | > | Could someone please verify this ? > | > | RFC 1195 Section 3.1, paragraph 3: > | "IP-capable (i.e., all IP-only and dual) routers need to know what network > | layer protocols are sup-ported > | by other routers in their area. This information is made available by > | inclusion of a "proto-cols > | supported" field in all IS-IS Hello and Link State Packets. This field makes > | use of the NL-PID > | (Network Layer Protocol Identifier), which is a one-octet value assigned by > | ISO to identify > | network level protocols. NLPID values have been assigned to ISO 8473 and to > | IP." > > >Interesting question. > >Well, the pseudonode LSP is really there to represent the broadcast medium, >not any particular router. And since the broadcast medium is presumably >protocol independent, it doesn't seem like it actually conveys any useful >information. > >Thus, IMHO, it would make sense if implementations ignored the Procotols >Supported TLV in a pseudonode LSP and not require it be present. > >Tony >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Internet-Drafts@ietf.org Mon Nov 26 11:14:30 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 26 Nov 2001 06:14:30 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-06.txt Message-ID: <200111261114.GAA19023@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-06.txt Pages : 65 Date : 21-Nov-01 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-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-wg-mib-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-wg-mib-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: <20011121141056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011121141056.I-D@ietf.org> --OtherAccess-- --NextPart-- From Ming.Chan@SpirentCom.COM Mon Nov 26 17:01:52 2001 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming (Adtech ENG)) Date: Mon, 26 Nov 2001 07:01:52 -1000 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP Message-ID: <8AC36D3167EED41184C800508BD9540501EE3BED@apollo.adtech-inc.com> All, Another role for the inclusion of "Protocols Supported" field is to signal the other routers that the router originated the LSP is IP capable ( As I understood it from RFC 1195 Section 5.2, paragraph 2.) Would it be from this point of view that the "Protocols Supported" field is necessary since "logically" pseudo-node LSP is from the Designated-Router to all of its neighbors? The field tells all of its neighbors that it is IP capable. Thanks, Ming Chan -----Original Message----- From: Les Ginsberg [mailto:ginsberg@pluris.com] Sent: Monday, November 26, 2001 2:23 AM To: 'Jeff Learman'; Tony Li Cc: Chan, Chung Ming (Adtech ENG); 'isis-wg@external.juniper.net' Subject: RE: [Isis-wg] Protocols Supported field in pseudonode LSP It is true that RFC 1195 does not explicitly direct ISs to reject adjacencies with neighbors who do not match protocols supported. In most cases we would be better off w/o such a neighbor - it would prevent needless flooding of LSPs which contained no useable routing information. However, on a "misconfigured" LAN, if some combination of IP only and OSI-only routers exist - the fact that all routers will form adjacencies is a benefit in that only a single DIS will be elected. The unfortunate part is that LSPs from OSI-only routers will take up resources in IP-only routers and vice-versa. This makes it important to check the protocols supported option in non-pseudo-node LSPs so as to avoid using an OSI-only router as a transit router for IP traffic (and vice versa...). LSPs from a router which does not advertise support for a particular protocol should be ignored during SPF. The same check in pseudo-node LSPs, as Tony has pointed out, is not important since the pseudo-node LSP only has information about routers connected to the LAN, not what destinations are reachable via those routers. This raises the point that an alarm associated with the formation of an adjacency with a protocol-wise incompatible neighbor as well as an alarm associated with reception of a non-pseudo-node LSP with incompatible protocols would be helpful. (Jeff Parker - are you listening?) Les > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Sunday, November 25, 2001 6:21 PM > To: Tony Li > Cc: Chan, Chung Ming (Adtech ENG); 'isis-wg@external.juniper.net' > Subject: Re: [Isis-wg] Protocols Supported field in pseudonode LSP > > > > I agree with Tony. There are some additional things to consider, > though. > > In accordance with RFC 1195, an implementation doesn't need > to consult an LSP's supported protocols option when running SPF > except for links to end systems, and a pseudonode LSP should have > only links between intermediate systems. (Rather than relying on > the protos supported option, RFC 1195 relies on the deployment > rules.) > > My understanding is that some routers do take the protos-supported > option when running SPF. This allows some relaxation of the > deployment > rules. There is no interoperability problem, because any strict > implementation won't work anyway, in situations where this > modification > helps. > > However, in networks where this modification is being used, and > mixed networks don't meet the deployment requirements in 1195, > will it be important to make sure the designated router is a dual > router? I can't find anything in 1195 that says to check protos- > supported when bringing up an adjacency. If for any reason a > system would not form an adjacency with a router with which it > shared no protocols, that would cause a problem in the pseudonode > LSPs. Hopefully this isn't a problem. > > Regards, > Jeff > > PS: I don't work in IS-IS at Cisco. My comments do not necessarily > reflect Cisco's opinions and I have no detailed knowledge of the Cisco > IS-IS implementation. > > > > > At 08:06 PM 11/25/2001, Tony Li wrote: > > > | I found out that in one vendor's pseudonode LSPs, there > is no "Protocols > > | Supported" field included; but it includes the field in > the non-pseudonode > > | LSPs. > > | > > | Shall the Protocols Supported field MUST be included in > pseudonode LSP > > | according to RFC 1195? > > | > > | Not sure if there is any reason for that particular > vender for doing it. > > | > > | Could someone please verify this ? > > | > > | RFC 1195 Section 3.1, paragraph 3: > > | "IP-capable (i.e., all IP-only and dual) routers need to > know what network > > | layer protocols are sup-ported > > | by other routers in their area. This information is made > available by > > | inclusion of a "proto-cols > > | supported" field in all IS-IS Hello and Link State > Packets. This field makes > > | use of the NL-PID > > | (Network Layer Protocol Identifier), which is a one-octet > value assigned by > > | ISO to identify > > | network level protocols. NLPID values have been assigned > to ISO 8473 and to > > | IP." > > > > > >Interesting question. > > > >Well, the pseudonode LSP is really there to represent the > broadcast medium, > >not any particular router. And since the broadcast medium > is presumably > >protocol independent, it doesn't seem like it actually > conveys any useful > >information. > > > >Thus, IMHO, it would make sense if implementations ignored > the Procotols > >Supported TLV in a pseudonode LSP and not require it be present. > > > >Tony > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From jparker@axiowave.com Mon Nov 26 18:15:00 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 26 Nov 2001 13:15:00 -0500 Subject: [Isis-wg] draft-ietf-isis-wg-mib-05.txt Message-ID: > I'm looking at the ISIS-MIB and think that it would be nice > to include UNITS > for many of the time-related objects. > Most of them have the information in the descriptions, but > rsIsisSysIshHoldTime and rsIsisSysIshConfigTimer do not. > Are they in milliseconds? > Thanks. > Ken Chapman Unisphere Networks, Inc. Ken - Thanks - I have updated the description of isisISAdjHoldTimer. However, I can't find anything close to rsIsisSysIshConfigTimer. Come again? - jeff parker isisISAdjHoldTimer OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The holding time in seconds for this adjacency. This value is based on received IIH PDUs and the elapsed time since receipt. REFERENCE "{ISIS.aoi holdingTimer (85)}" ::= { isisISAdjEntry 7 } From jparker@axiowave.com Mon Nov 26 18:19:55 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 26 Nov 2001 13:19:55 -0500 Subject: [Isis-wg] Simple questions on the use of Authentication TLVs Message-ID: > All, > I'm new to ISIS and hope some one can answer me the following > questions > regarding to the use of Authentication TLV. > Thank you in advance! > > I'm working with ISO/IEC 10589:1992 and RFC 1195. > > In both spec there is Authentication VLF defined with > different Code points, > 10 for ISO10589 and 133 for RFC1195. > > The questions that I've: > > 1) If the router is supporting RFC 1195, SHALL it use 133 or > 10? What is > the guideline for using it? > 2) Or should the router accept code point 10, if it supports RFC1195? > > > Thanks, > > > Ming Chan Ming - You may have received a private reply, but I don't see a response with this subject to the list. Have you had a look at the Internet Draft "IS-IS Cryptographic Authentication"? You will find a reference to this below, and also off the following ietf page for the IS-IS workgroup. http://ietf.org/html.charters/isis-charter.html http://ietf.org/internet-drafts/draft-ietf-isis-hmac-03.txt - jeff parker - axiowave networks From ginsberg@pluris.com Mon Nov 26 07:23:19 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Sun, 25 Nov 2001 23:23:19 -0800 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F5E6@avalon.pluris.com> It is true that RFC 1195 does not explicitly direct ISs to reject adjacencies with neighbors who do not match protocols supported. In most cases we would be better off w/o such a neighbor - it would prevent needless flooding of LSPs which contained no useable routing information. However, on a "misconfigured" LAN, if some combination of IP only and OSI-only routers exist - the fact that all routers will form adjacencies is a benefit in that only a single DIS will be elected. The unfortunate part is that LSPs from OSI-only routers will take up resources in IP-only routers and vice-versa. This makes it important to check the protocols supported option in non-pseudo-node LSPs so as to avoid using an OSI-only router as a transit router for IP traffic (and vice versa...). LSPs from a router which does not advertise support for a particular protocol should be ignored during SPF. The same check in pseudo-node LSPs, as Tony has pointed out, is not important since the pseudo-node LSP only has information about routers connected to the LAN, not what destinations are reachable via those routers. This raises the point that an alarm associated with the formation of an adjacency with a protocol-wise incompatible neighbor as well as an alarm associated with reception of a non-pseudo-node LSP with incompatible protocols would be helpful. (Jeff Parker - are you listening?) Les > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Sunday, November 25, 2001 6:21 PM > To: Tony Li > Cc: Chan, Chung Ming (Adtech ENG); 'isis-wg@external.juniper.net' > Subject: Re: [Isis-wg] Protocols Supported field in pseudonode LSP > > > > I agree with Tony. There are some additional things to consider, > though. > > In accordance with RFC 1195, an implementation doesn't need > to consult an LSP's supported protocols option when running SPF > except for links to end systems, and a pseudonode LSP should have > only links between intermediate systems. (Rather than relying on > the protos supported option, RFC 1195 relies on the deployment > rules.) > > My understanding is that some routers do take the protos-supported > option when running SPF. This allows some relaxation of the > deployment > rules. There is no interoperability problem, because any strict > implementation won't work anyway, in situations where this > modification > helps. > > However, in networks where this modification is being used, and > mixed networks don't meet the deployment requirements in 1195, > will it be important to make sure the designated router is a dual > router? I can't find anything in 1195 that says to check protos- > supported when bringing up an adjacency. If for any reason a > system would not form an adjacency with a router with which it > shared no protocols, that would cause a problem in the pseudonode > LSPs. Hopefully this isn't a problem. > > Regards, > Jeff > > PS: I don't work in IS-IS at Cisco. My comments do not necessarily > reflect Cisco's opinions and I have no detailed knowledge of the Cisco > IS-IS implementation. > > > > > At 08:06 PM 11/25/2001, Tony Li wrote: > > > | I found out that in one vendor's pseudonode LSPs, there > is no "Protocols > > | Supported" field included; but it includes the field in > the non-pseudonode > > | LSPs. > > | > > | Shall the Protocols Supported field MUST be included in > pseudonode LSP > > | according to RFC 1195? > > | > > | Not sure if there is any reason for that particular > vender for doing it. > > | > > | Could someone please verify this ? > > | > > | RFC 1195 Section 3.1, paragraph 3: > > | "IP-capable (i.e., all IP-only and dual) routers need to > know what network > > | layer protocols are sup-ported > > | by other routers in their area. This information is made > available by > > | inclusion of a "proto-cols > > | supported" field in all IS-IS Hello and Link State > Packets. This field makes > > | use of the NL-PID > > | (Network Layer Protocol Identifier), which is a one-octet > value assigned by > > | ISO to identify > > | network level protocols. NLPID values have been assigned > to ISO 8473 and to > > | IP." > > > > > >Interesting question. > > > >Well, the pseudonode LSP is really there to represent the > broadcast medium, > >not any particular router. And since the broadcast medium > is presumably > >protocol independent, it doesn't seem like it actually > conveys any useful > >information. > > > >Thus, IMHO, it would make sense if implementations ignored > the Procotols > >Supported TLV in a pseudonode LSP and not require it be present. > > > >Tony > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From tli@Procket.com Mon Nov 26 19:48:50 2001 From: tli@Procket.com (Tony Li) Date: Mon, 26 Nov 2001 11:48:50 -0800 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <8AC36D3167EED41184C800508BD9540501EE3BED@apollo.adtech-inc.com> References: <8AC36D3167EED41184C800508BD9540501EE3BED@apollo.adtech-inc.com> Message-ID: <15362.40098.114535.697045@alpha-tli.procket.com> | Another role for the inclusion of "Protocols Supported" field is to | signal the other routers that the router originated the LSP is IP capable ( | As I understood it from RFC 1195 Section 5.2, paragraph 2.) | Would it be from this point of view that the "Protocols Supported" | field is necessary since "logically" pseudo-node LSP is from the | Designated-Router to all of its neighbors? | The field tells all of its neighbors that it is IP capable. Well, that would certainly be one interpretation of the spec. However, that would seem to be less interoperable. "Be strict in what you send and liberal in what you receive." - Jon Postel Accordingly, putting a Protocols Supported field in the pseudonode LSP is not something that I interpret as being required by the spec. Tony From jlearman@cisco.com Mon Nov 26 20:03:36 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 26 Nov 2001 15:03:36 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <8AC36D3167EED41184C800508BD9540501EE3BED@apollo.adtech-inc .com> Message-ID: <4.3.2.7.2.20011126144755.019b7008@dingdong.cisco.com> First of all, a pseudonode represents the media, not a real router, as Tony pointed out. For that reason, it can be assumed to support all protocols that are supportable on that media type, and the LSP options are not necessary for this purpose. Furthermore, we cannot require OSI-only routers that do not support 1195 to include a "protocols supported" option identifying IP in their pseudonode LSPs. We should figure out whether an IP-capable router "should" include the IP protocol-supported option. However, there are (allegedly) implementations that are IP-capable which don't put the option in their pseudonode LSPs. Therefore, it's good idea to treat pseudonode LSPs without the option as supporting both IP and OSI. Once again, this would only be an issue in a network that doesn't meet the deployment requirements (e.g., in a mixed area, all L1 routers must be dual-capable). As I understand it, in networks that follow the deployment rules, there is no need to check the protocols-supported option in LSPs when running SPF. Checking it is an optimization: if an LSP doesn't support IP, then there's no need to look for IP addressing info in the LSP, because it won't be there. Regards, Jeff At 12:01 PM 11/26/2001, Chan, Chung Ming (Adtech ENG) wrote: >All, > > Another role for the inclusion of "Protocols Supported" field is to >signal the other routers that the router originated the LSP is IP capable ( >As I understood it from RFC 1195 Section 5.2, paragraph 2.) > Would it be from this point of view that the "Protocols Supported" >field is necessary since "logically" pseudo-node LSP is from the >Designated-Router to all of its neighbors? >The field tells all of its neighbors that it is IP capable. > > Thanks, > > >Ming Chan > > >-----Original Message----- >From: Les Ginsberg [mailto:ginsberg@pluris.com] >Sent: Monday, November 26, 2001 2:23 AM >To: 'Jeff Learman'; Tony Li >Cc: Chan, Chung Ming (Adtech ENG); 'isis-wg@external.juniper.net' >Subject: RE: [Isis-wg] Protocols Supported field in pseudonode LSP > > >It is true that RFC 1195 does not explicitly direct ISs to reject >adjacencies with neighbors who do not match protocols supported. In most >cases we would be better off w/o such a neighbor - it would prevent needless >flooding of LSPs which contained no useable routing information. However, on >a "misconfigured" LAN, if some combination of IP only and OSI-only routers >exist - the fact that all routers will form adjacencies is a benefit in that >only a single DIS will be elected. The unfortunate part is that LSPs from >OSI-only routers will take up resources in IP-only routers and vice-versa. > >This makes it important to check the protocols supported option in >non-pseudo-node LSPs so as to avoid using an OSI-only router as a transit >router for IP traffic (and vice versa...). LSPs from a router which does not >advertise support for a particular protocol should be ignored during SPF. > >The same check in pseudo-node LSPs, as Tony has pointed out, is not >important since the pseudo-node LSP only has information about routers >connected to the LAN, not what destinations are reachable via those routers. > >This raises the point that an alarm associated with the formation of an >adjacency with a protocol-wise incompatible neighbor as well as an alarm >associated with reception of a non-pseudo-node LSP with incompatible >protocols would be helpful. (Jeff Parker - are you listening?) > > Les > >> -----Original Message----- >> From: Jeff Learman [mailto:jlearman@cisco.com] >> Sent: Sunday, November 25, 2001 6:21 PM >> To: Tony Li >> Cc: Chan, Chung Ming (Adtech ENG); 'isis-wg@external.juniper.net' >> Subject: Re: [Isis-wg] Protocols Supported field in pseudonode LSP >> >> >> >> I agree with Tony. There are some additional things to consider, >> though. >> >> In accordance with RFC 1195, an implementation doesn't need >> to consult an LSP's supported protocols option when running SPF >> except for links to end systems, and a pseudonode LSP should have >> only links between intermediate systems. (Rather than relying on >> the protos supported option, RFC 1195 relies on the deployment >> rules.) >> >> My understanding is that some routers do take the protos-supported >> option when running SPF. This allows some relaxation of the >> deployment >> rules. There is no interoperability problem, because any strict >> implementation won't work anyway, in situations where this >> modification >> helps. >> >> However, in networks where this modification is being used, and >> mixed networks don't meet the deployment requirements in 1195, >> will it be important to make sure the designated router is a dual >> router? I can't find anything in 1195 that says to check protos- >> supported when bringing up an adjacency. If for any reason a >> system would not form an adjacency with a router with which it >> shared no protocols, that would cause a problem in the pseudonode >> LSPs. Hopefully this isn't a problem. >> >> Regards, >> Jeff >> >> PS: I don't work in IS-IS at Cisco. My comments do not necessarily >> reflect Cisco's opinions and I have no detailed knowledge of the Cisco >> IS-IS implementation. >> >> >> >> >> At 08:06 PM 11/25/2001, Tony Li wrote: >> >> > | I found out that in one vendor's pseudonode LSPs, there >> is no "Protocols >> > | Supported" field included; but it includes the field in >> the non-pseudonode >> > | LSPs. >> > | >> > | Shall the Protocols Supported field MUST be included in >> pseudonode LSP >> > | according to RFC 1195? >> > | >> > | Not sure if there is any reason for that particular >> vender for doing it. >> > | >> > | Could someone please verify this ? >> > | >> > | RFC 1195 Section 3.1, paragraph 3: >> > | "IP-capable (i.e., all IP-only and dual) routers need to >> know what network >> > | layer protocols are sup-ported >> > | by other routers in their area. This information is made >> available by >> > | inclusion of a "proto-cols >> > | supported" field in all IS-IS Hello and Link State >> Packets. This field makes >> > | use of the NL-PID >> > | (Network Layer Protocol Identifier), which is a one-octet >> value assigned by >> > | ISO to identify >> > | network level protocols. NLPID values have been assigned >> to ISO 8473 and to >> > | IP." >> > >> > >> >Interesting question. >> > >> >Well, the pseudonode LSP is really there to represent the >> broadcast medium, >> >not any particular router. And since the broadcast medium >> is presumably >> >protocol independent, it doesn't seem like it actually >> conveys any useful >> >information. >> > >> >Thus, IMHO, it would make sense if implementations ignored >> the Procotols >> >Supported TLV in a pseudonode LSP and not require it be present. >> > >> >Tony >> >_______________________________________________ >> >Isis-wg mailing list - Isis-wg@external.juniper.net >> >http://external.juniper.net/mailman/listinfo/isis-wg >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg >> From ginsberg@pluris.com Mon Nov 26 20:22:56 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Mon, 26 Nov 2001 12:22:56 -0800 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F5EB@avalon.pluris.com> In addition, the information about protocols supported is available from the non-pseudo-node LSP originated by the system which is DIS. Including such information in a pseudo-node LSP, while certainly not invalid, is at best redundant. (Remembering of course that a router must operate in the same fashion in terms of protocols supported on all links.) Les > -----Original Message----- > From: Tony Li [mailto:tli@Procket.com] > Sent: Monday, November 26, 2001 11:49 AM > To: Chan, Chung Ming (Adtech ENG) > Cc: 'isis-wg@external.juniper.net'; 'Les Ginsberg'; 'Jeff > Learman'; Tony > Li > Subject: RE: [Isis-wg] Protocols Supported field in pseudonode LSP > > > > | Another role for the inclusion of "Protocols Supported" > field is to > | signal the other routers that the router originated the > LSP is IP capable ( > | As I understood it from RFC 1195 Section 5.2, paragraph 2.) > | Would it be from this point of view that the "Protocols > Supported" > | field is necessary since "logically" pseudo-node LSP is from the > | Designated-Router to all of its neighbors? > | The field tells all of its neighbors that it is IP capable. > > > Well, that would certainly be one interpretation of the spec. > However, > that would seem to be less interoperable. > > "Be strict in what you send and liberal in what you receive." > - Jon Postel > > Accordingly, putting a Protocols Supported field in the > pseudonode LSP is > not something that I interpret as being required by the spec. > > Tony > From jlearman@cisco.com Mon Nov 26 20:27:23 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 26 Nov 2001 15:27:23 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F5E6@avalon.pluris.com > Message-ID: <4.3.2.7.2.20011126152244.019934e0@dingdong.cisco.com> Les, At 02:23 AM 11/26/2001, Les Ginsberg wrote: >router for IP traffic (and vice versa...). LSPs from a router which does not >advertise support for a particular protocol should be ignored during SPF. Is this required by 1195? As I understand it, it isn't, as the check would be superfluous in any network that meets the deployment requirements. I think it's unfortunate that 1195 was written this way, but wouldn't it be a mistake to assume any router does this check? If some routers do this and others don't, then there will be routing loops. Of course, if some routers don't do this in a network that doesn't meet the deployment requirements, that network won't work anyway. From jparker@axiowave.com Mon Nov 26 20:43:46 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 26 Nov 2001 15:43:46 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP Message-ID: > As I understand it, in networks that follow > the deployment rules, there is no need to check the > protocols-supported option in LSPs when running SPF. > Checking it is an optimization: if an LSP doesn't > support IP, then there's no need to look for IP > addressing info in the LSP, because it won't be there. > > Jeff [L] Jeff - I thought this was an issue, due to transitive closure. You don't have any IP addresses, but you present an attractive route to a router that does have IP addresses. If I don't check your protocols supported, I might use you on a path. Since you don't forward IP packets, we have a black hole if all routers ignore protocol supported in SPF, or a routing loop if some check and some do not. - jeff parker From tli@Procket.com Mon Nov 26 21:06:45 2001 From: tli@Procket.com (Tony Li) Date: Mon, 26 Nov 2001 13:06:45 -0800 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <4.3.2.7.2.20011126152244.019934e0@dingdong.cisco.com> References: <17C81AD1F1FED411991E006008F6D1CA01B3F5E6@avalon.pluris.com> <4.3.2.7.2.20011126152244.019934e0@dingdong.cisco.com> Message-ID: <15362.44773.326896.768305@alpha-tli.procket.com> | At 02:23 AM 11/26/2001, Les Ginsberg wrote: | >router for IP traffic (and vice versa...). LSPs from a router which | >does not advertise support for a particular protocol should be ignored | >during SPF. | | Is this required by 1195? As I understand it, it isn't, as the check | would be superfluous in any network that meets the deployment | requirements. I think it's unfortunate that 1195 was written this | way, but wouldn't it be a mistake to assume any router does this | check? 1195 specifically says that this check is not necessary. However, that's also making the grand assumption that the domain is following the deployement requirements. Unfortunately, humans make mistakes, so simply assuming that the deployment requirements are met is likely to get an implementor into a conflict with users. Far better to be careful in the computations and forward the traffic along a best effort path. As an aside, one has to wonder if the authors of 1195 didn't expect such a check. If one does make the assumption that the deployment rules are being followed, what is the point in the Protocols Supported TLV in the first place? IMHO, doing the check is a trivial amount of overhead and seems to be well worth the additional security. | If some routers do this and others don't, then there will be routing | loops. Of course, if some routers don't do this in a network that | doesn't meet the deployment requirements, that network won't work | anyway. If some routers do not make this check and are deployed in a dual environment where the deployment rules are not followed, then those routers may make an incorrect forwarding decision. If the next hop is not protocol capable, then the decision will be a black hole. However, if the next hop is a router that does make the SPF check, then there is the possibility of a forwarding loop. While forwarding loops are in many ways more painful than black holes, I suspect that the benefits incurred by making this check and forwarding along the best available path far outweigh the additional danger. Of course, the cost for dual implementations that choose to support this is a separate SPF per protocol type. Tony From jparker@axiowave.com Mon Nov 26 21:10:39 2001 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 26 Nov 2001 16:10:39 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP Message-ID: > This raises the point that an alarm associated with the > formation of an adjacency with a protocol-wise incompatible > neighbor as well as an alarm associated with reception of > a non-pseudo-node LSP with incompatible > protocols would be helpful. (Jeff Parker - are you listening?) > > Les Les - Yes, I am listening. To recap MIBstory, version .06 of the MIB is on the IETF site. I have been circulating a draft version of version .07, which includes Traps, to those who have expressed interest. The two events above seem like natural additions to the list of Traps (Notifications). Will add and send your way. Most of the traps have a "edge triggered" text suggesting that we send one of these traps the -first- time we see the event so the manager doesn't get flooded. - jeff parker - axiowave networks From jlearman@cisco.com Mon Nov 26 21:05:24 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 26 Nov 2001 16:05:24 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: Message-ID: <4.3.2.7.2.20011126160107.01a20b00@dingdong.cisco.com> At 03:43 PM 11/26/2001, Jeff Parker wrote: >> As I understand it, in networks that follow >> the deployment rules, there is no need to check the >> protocols-supported option in LSPs when running SPF. >> Checking it is an optimization: if an LSP doesn't >> support IP, then there's no need to look for IP >> addressing info in the LSP, because it won't be there. >> >> Jeff [L] > >Jeff - > I thought this was an issue, due to transitive >closure. You don't have any IP addresses, but you >present an attractive route to a router that does >have IP addresses. If I don't check your protocols >supported, I might use you on a path. Since >you don't forward IP packets, we have a black hole >if all routers ignore protocol supported in SPF, or >a routing loop if some check and some do not. But this only happens in networks that don't follow the deployment rules. SO: Do people follow the rules? Are the rules really correct, if all routers in the subdomain check the protocols supported option? I think they could be relaxed to "sufficient connectivity" for each protocol within each subdomain. Regards, Jeff >- jeff parker From jlearman@cisco.com Mon Nov 26 21:55:32 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 26 Nov 2001 16:55:32 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <15362.44773.326896.768305@alpha-tli.procket.com> References: <4.3.2.7.2.20011126152244.019934e0@dingdong.cisco.com> <17C81AD1F1FED411991E006008F6D1CA01B3F5E6@avalon.pluris.com> <4.3.2.7.2.20011126152244.019934e0@dingdong.cisco.com> Message-ID: <4.3.2.7.2.20011126163743.019c27c0@dingdong.cisco.com> At 04:06 PM 11/26/2001, Tony Li wrote: > | At 02:23 AM 11/26/2001, Les Ginsberg wrote: > | >router for IP traffic (and vice versa...). LSPs from a router which > | >does not advertise support for a particular protocol should be ignored > | >during SPF. > | > | Is this required by 1195? As I understand it, it isn't, as the check > | would be superfluous in any network that meets the deployment > | requirements. I think it's unfortunate that 1195 was written this > | way, but wouldn't it be a mistake to assume any router does this > | check? > > >1195 specifically says that this check is not necessary. However, that's >also making the grand assumption that the domain is following the >deployement requirements. Unfortunately, humans make mistakes, so simply >assuming that the deployment requirements are met is likely to get an >implementor into a conflict with users. Far better to be careful in the >computations and forward the traffic along a best effort path. > >As an aside, one has to wonder if the authors of 1195 didn't expect such a >check. If one does make the assumption that the deployment rules are being >followed, what is the point in the Protocols Supported TLV in the first >place? > >IMHO, doing the check is a trivial amount of overhead and seems to be well >worth the additional security. I agree wholeheartedly. > | If some routers do this and others don't, then there will be routing > | loops. Of course, if some routers don't do this in a network that > | doesn't meet the deployment requirements, that network won't work > | anyway. > > >If some routers do not make this check and are deployed in a dual >environment where the deployment rules are not followed, then those routers >may make an incorrect forwarding decision. Incorrect? Well, it's operating according to the RFC. The RFC is incorrect or the network is incorrect, not those routers. (Yes, I know I'm being pedantic ;-) I agree that those routers forward the packets where we don't want them to go! My point is simply that we must not assume that other systems make the check. Or, if we find that all known implementations do make the check, then we could dramatically improve 1195 and make it mandatory, and explain the new (relaxed) deployment rules. Regards, Jeff >If the next hop is not protocol >capable, then the decision will be a black hole. However, if the next hop >is a router that does make the SPF check, then there is the possibility of >a forwarding loop. > >While forwarding loops are in many ways more painful than black holes, I >suspect that the benefits incurred by making this check and forwarding >along the best available path far outweigh the additional danger. > >Of course, the cost for dual implementations that choose to support this is >a separate SPF per protocol type. From naiming@redback.com Mon Nov 26 22:13:43 2001 From: naiming@redback.com (Naiming Shen) Date: Mon, 26 Nov 2001 14:13:43 -0800 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: Mail from Les Ginsberg dated Mon, 26 Nov 2001 12:22:56 PST <17C81AD1F1FED411991E006008F6D1CA01B3F5EB@avalon.pluris.com> Message-ID: <20011126221343.93D554BA219@prattle.redback.com> Even if the DIS wants to stuff a Protocol-Supported field in its pseudo-node LSP, what should it say? should it say "some of my adjacencies are OSI-only, some are IP only and some are dual"? this certainly does not help; then it probably should say: my neighbor listed below from 1 through 23 is IP only, 24 through 28 is dual and rest is OSI-only? in either case rfc1195 does not support such a protocol supported description in LSPs. Thus the DIS should just shutup and say nothing. ]In addition, the information about protocols supported is available from the ]non-pseudo-node LSP originated by the system which is DIS. Including such ]information in a pseudo-node LSP, while certainly not invalid, is at best ]redundant. (Remembering of course that a router must operate in the same ]fashion in terms of protocols supported on all links.) ] ] Les ] ] ]> -----Original Message----- ]> From: Tony Li [mailto:tli@Procket.com] ]> Sent: Monday, November 26, 2001 11:49 AM ]> To: Chan, Chung Ming (Adtech ENG) ]> Cc: 'isis-wg@external.juniper.net'; 'Les Ginsberg'; 'Jeff ]> Learman'; Tony ]> Li ]> Subject: RE: [Isis-wg] Protocols Supported field in pseudonode LSP ]> ]> ]> ]> | Another role for the inclusion of "Protocols Supported" ]> field is to ]> | signal the other routers that the router originated the ]> LSP is IP capable ( ]> | As I understood it from RFC 1195 Section 5.2, paragraph 2.) ]> | Would it be from this point of view that the "Protocols ]> Supported" ]> | field is necessary since "logically" pseudo-node LSP is from the ]> | Designated-Router to all of its neighbors? ]> | The field tells all of its neighbors that it is IP capable. ]> ]> ]> Well, that would certainly be one interpretation of the spec. ]> However, ]> that would seem to be less interoperable. ]> ]> "Be strict in what you send and liberal in what you receive." ]> - Jon Postel ]> ]> Accordingly, putting a Protocols Supported field in the ]> pseudonode LSP is ]> not something that I interpret as being required by the spec. ]> ]> Tony ]> ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From jlearman@cisco.com Mon Nov 26 22:20:11 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 26 Nov 2001 17:20:11 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <20011126221343.93D554BA219@prattle.redback.com> References: <17C81AD1F1FED411991E006008F6D1CA01B3F5EB@avalon.pluris.com> Message-ID: <4.3.2.7.2.20011126171558.019c2960@dingdong.cisco.com> The protocols-supported option on an LSP only indicates the status of the issuing router, not of any of the links, etc. Therefore, it is reasonable to assume that a pseudonode LSP, as it represents the media, supports all protocols. The most the issuing system could do is include all the protocols it supports, or perhaps all the protocols that are defined at the time of writing (since the DIS is not involved in relaying packets between other routers on the LAN). I think it's best to omit the option in pseudonodes, since it has incomplete information anyway, and to ignore it in pseudonodes during SPF. Note that a dual router could be included in an IP-only area, and would naturally include OSI as a supported protocol in its LSPs. Placing that information in the pseudonode LSP is meaningless. Regards, Jeff At 05:13 PM 11/26/2001, Naiming Shen wrote: >Even if the DIS wants to stuff a Protocol-Supported field in its >pseudo-node LSP, what should it say? should it say "some of my adjacencies >are OSI-only, some are IP only and some are dual"? this certainly does not >help; then it probably should say: my neighbor listed below from 1 through >23 is IP only, 24 through 28 is dual and rest is OSI-only? in either case >rfc1195 does not support such a protocol supported description in LSPs. > >Thus the DIS should just shutup and say nothing. > > ]In addition, the information about protocols supported is available from the > ]non-pseudo-node LSP originated by the system which is DIS. Including such > ]information in a pseudo-node LSP, while certainly not invalid, is at best > ]redundant. (Remembering of course that a router must operate in the same > ]fashion in terms of protocols supported on all links.) > ] > ] Les > ] > ] > ]> -----Original Message----- > ]> From: Tony Li [mailto:tli@Procket.com] > ]> Sent: Monday, November 26, 2001 11:49 AM > ]> To: Chan, Chung Ming (Adtech ENG) > ]> Cc: 'isis-wg@external.juniper.net'; 'Les Ginsberg'; 'Jeff > ]> Learman'; Tony > ]> Li > ]> Subject: RE: [Isis-wg] Protocols Supported field in pseudonode LSP > ]> > ]> > ]> > ]> | Another role for the inclusion of "Protocols Supported" > ]> field is to > ]> | signal the other routers that the router originated the > ]> LSP is IP capable ( > ]> | As I understood it from RFC 1195 Section 5.2, paragraph 2.) > ]> | Would it be from this point of view that the "Protocols > ]> Supported" > ]> | field is necessary since "logically" pseudo-node LSP is from the > ]> | Designated-Router to all of its neighbors? > ]> | The field tells all of its neighbors that it is IP capable. > ]> > ]> > ]> Well, that would certainly be one interpretation of the spec. > ]> However, > ]> that would seem to be less interoperable. > ]> > ]> "Be strict in what you send and liberal in what you receive." > ]> - Jon Postel > ]> > ]> Accordingly, putting a Protocols Supported field in the > ]> pseudonode LSP is > ]> not something that I interpret as being required by the spec. > ]> > ]> Tony > ]> > ]_______________________________________________ > ]Isis-wg mailing list - Isis-wg@external.juniper.net > ]http://external.juniper.net/mailman/listinfo/isis-wg > >- Naiming From dkatz@juniper.net Mon Nov 26 22:52:11 2001 From: dkatz@juniper.net (Dave Katz) Date: Mon, 26 Nov 2001 14:52:11 -0800 (PST) Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <4.3.2.7.2.20011126160107.01a20b00@dingdong.cisco.com> (message from Jeff Learman on Mon, 26 Nov 2001 16:05:24 -0500) Message-ID: <200111262252.OAA28798@cirrus.juniper.net> But this only happens in networks that don't follow the deployment rules. SO: Do people follow the rules? I guess this begs the question, are there any OSI-only routers out there? There are the goofy ADMs, I suppose There are plenty of IP-only routers running ISIS, which leads one to believe that mixed networks are extremely rare. From jonathan.sadler@tellabs.com Mon Nov 26 23:04:00 2001 From: jonathan.sadler@tellabs.com (Jonathan Sadler) Date: Mon, 26 Nov 2001 17:04:00 -0600 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP References: Message-ID: <3C02CA60.C0C2F525@tellabs.com> Though mixed networks are likely to come with the new focus on GMPLS functionality... Dave Katz wrote: > > But this only happens in networks that don't follow the deployment rules. > SO: Do people follow the rules? > > I guess this begs the question, are there any OSI-only routers out there? > There are the goofy ADMs, I suppose > > There are plenty of IP-only routers running ISIS, which leads one to > believe that mixed networks are extremely rare. > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From jlearman@cisco.com Mon Nov 26 23:11:00 2001 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 26 Nov 2001 18:11:00 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <200111262252.OAA28798@cirrus.juniper.net> References: <4.3.2.7.2.20011126160107.01a20b00@dingdong.cisco.com> Message-ID: <4.3.2.7.2.20011126180801.0194fc80@dingdong.cisco.com> Dave, SONET network management uses OSI with ISIS, and are planning (last I heard) to use integrated IP & OSI networks using RFC 1195. For more information, please contact T1.X1. But we better work out these rules anyway, because IPV6 will raise them yet again. Regards, Jeff At 05:52 PM 11/26/2001, Dave Katz wrote: > But this only happens in networks that don't follow the deployment rules. > SO: Do people follow the rules? > >I guess this begs the question, are there any OSI-only routers out there? >There are the goofy ADMs, I suppose > >There are plenty of IP-only routers running ISIS, which leads one to >believe that mixed networks are extremely rare. From prz@redback.com Mon Nov 26 22:23:50 2001 From: prz@redback.com (Tony Przygienda) Date: Mon, 26 Nov 2001 14:23:50 -0800 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP References: <200111262252.OAA28798@cirrus.juniper.net> Message-ID: <3C02C0F5.72CF0928@redback.com> Dave Katz wrote: > But this only happens in networks that don't follow the deployment rules. > SO: Do people follow the rules? > > I guess this begs the question, are there any OSI-only routers out there? > There are the goofy ADMs, I suppose Well, the "goofy" ADMs still generate serious amounts of money so anybody on this list runs some danger to possibly working on a goofy ADM one of these days. So no point in ticking the TDM folks off ;-) > There are plenty of IP-only routers running ISIS, which leads one to > believe that mixed networks are extremely rare. with GMPLS and IP generally vying to control TDM networks and possibly toasters in the future, I would say it is thinkable .... My take on the protocols-supported field: If you have to stick something in, stick the superset of all protocols supported by all the routers on the LAN. This is because a pseudo-node is not 'belonging' to the DIS, it is representation of the LAN as a shared resource by a chosen member ... In this way, anybody checking for the field in pseudo-node will be happy and it will not hurt anybody who doesn't ... thanks -- tony From jonathan.sadler@tellabs.com Mon Nov 26 23:57:28 2001 From: jonathan.sadler@tellabs.com (Jonathan Sadler) Date: Mon, 26 Nov 2001 17:57:28 -0600 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP References: Message-ID: <3C02D6E8.8E213049@tellabs.com> Jeff, et al. - ITU-T SG15 recently consented G.7712/Y.1703 (nee G.dcn) which defines DCN requirements. A good amount of this document includes requirements for IP in the DCC/DCN. The document includes IS-IS related requirements, including the "mandatory" support for IS-IS (see sec 7.1.10) for both IP and OSI and the requirement that an adjacency not be established when the Protocols Supported field does not match in an IIH (see sec. 7.1.10.1). What is not included in the document, but remains under consideration in Q14 of SG15, is a submission from the United Kingdom (UK) to use the Protocols Supported field when running SPF to automatically determine if a tunnel should be established to pass packets between 2 OSI-only islands that are connected via an IP-only network. (Of course dual-nodes are used at the points where the OSI and IP networks meet.) This is specifically designed to allow more liberal node deployments than specified in RFC 1195. The UK submission further requires support for separate IP and OSI DISes (similar to the separate DISes required for L1 and L2) on LANs to eliminate implied adjacencies between OSI-only and IP-only nodes on the LAN. It should be noted that the approach contained in the UK submission is general enough so that it can be applied to any network that has islands of X-protocol to be connected through an Y-protocol based network, where X and Y could be IPv4, IPv6, or OSI. The following message was sent through formal Liaison channels from ITU-T to the IETF and provides a pointer to the consented document. Unfortunately, the UK submission is only available to ITU members at this time. Jonathan Sadler -------------- Forwarded Mail ---------------- Scott, Kireeti, and Lyndon, I am pleased to inform you that we finally have some concensus within ITU-T that gives us a way to share the files related to the Study Group 15 communications statements with IETF participants. This mechanism will likely evolve in the future (more about this below), but at least for now we have a way to share these files with IETF participants. The relevant communications include two to ccamp: - SDH Signal and Group Structures - New Recommendations for Automatically Switched Optical Netorks and one to sigtran: - Draft Recommendation G.799.1 on interconnecting GSTN and IP Networks The information may be accessed via a web browser using the following URL (from an ITU-T ftp server): ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html In the future, the Telecommunications Standardization Bureau will likely provide a way for IETF participants who wish to collaborate with ITU-T to request their own logins and passwords to access this site, but for now, all can access the information using the common ID and password that you see embedded in the URL. The structure of the information is as follows: Main Page | |-->ccamp-->copyright---->Communication on SDH Signal Structures | | | -->Communication on ASON Recs | | | |-->G.8080_Y.1304.pdf | |-->G.7713_Y.1704.pdf | |-->G.7714_Y.1705.pdf | --->G.7712_Y.1703.pdf | --->sigtran-->copyright-->Communication on G.799.1 (GSTN and IP) | --->G.799-1-DRAFT-V6.pdf Please request that your members enter at the main page - this will help insure that those who access the documents will be aware of the ITU-T copyright restrictions. Jeff Learman wrote: > > Dave, > > SONET network management uses OSI with ISIS, and are planning (last I > heard) to use integrated IP & OSI networks using RFC 1195. For more > information, please contact T1.X1. > > But we better work out these rules anyway, because IPV6 will raise > them yet again. > > Regards, > Jeff > > At 05:52 PM 11/26/2001, Dave Katz wrote: > > But this only happens in networks that don't follow the deployment rules. > > SO: Do people follow the rules? > > > >I guess this begs the question, are there any OSI-only routers out there? > >There are the goofy ADMs, I suppose > > > >There are plenty of IP-only routers running ISIS, which leads one to > >believe that mixed networks are extremely rare. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From mshand@cisco.com Tue Nov 27 08:38:19 2001 From: mshand@cisco.com (mike shand) Date: Tue, 27 Nov 2001 08:38:19 +0000 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <4.3.2.7.2.20011126171558.019c2960@dingdong.cisco.com> References: <20011126221343.93D554BA219@prattle.redback.com> <17C81AD1F1FED411991E006008F6D1CA01B3F5EB@avalon.pluris.com> Message-ID: <4.3.2.7.2.20011127083446.00b82258@jaws.cisco.com> I agree. The pseudonode information is not specific to any one router on the LAN (and especially not the DR). Of the two options (include ALL protocols, or include NO protocols and treat that as ALL), I think I prefer the latter. Clearly the former would work, but seems more error prone UNLESS there already exist implementations which check protocols supported in the pseudonode LSP. Mike At 17:20 26/11/2001 -0500, Jeff Learman wrote: >The protocols-supported option on an LSP only indicates the >status of the issuing router, not of any of the links, etc. >Therefore, it is reasonable to assume that a pseudonode LSP, >as it represents the media, supports all protocols. The most >the issuing system could do is include all the protocols it >supports, or perhaps all the protocols that are defined at >the time of writing (since the DIS is not involved in relaying >packets between other routers on the LAN). > >I think it's best to omit the option in pseudonodes, since it has >incomplete information anyway, and to ignore it in pseudonodes >during SPF. > >Note that a dual router could be included in an IP-only area, and >would naturally include OSI as a supported protocol in its LSPs. >Placing that information in the pseudonode LSP is meaningless. > >Regards, >Jeff > >At 05:13 PM 11/26/2001, Naiming Shen wrote: > > >Even if the DIS wants to stuff a Protocol-Supported field in its > >pseudo-node LSP, what should it say? should it say "some of my adjacencies > >are OSI-only, some are IP only and some are dual"? this certainly does not > >help; then it probably should say: my neighbor listed below from 1 through > >23 is IP only, 24 through 28 is dual and rest is OSI-only? in either case > >rfc1195 does not support such a protocol supported description in LSPs. > > > >Thus the DIS should just shutup and say nothing. > > > > ]In addition, the information about protocols supported is available > from the > > ]non-pseudo-node LSP originated by the system which is DIS. Including such > > ]information in a pseudo-node LSP, while certainly not invalid, is at best > > ]redundant. (Remembering of course that a router must operate in the same > > ]fashion in terms of protocols supported on all links.) > > ] > > ] Les > > ] > > ] > > ]> -----Original Message----- > > ]> From: Tony Li [mailto:tli@Procket.com] > > ]> Sent: Monday, November 26, 2001 11:49 AM > > ]> To: Chan, Chung Ming (Adtech ENG) > > ]> Cc: 'isis-wg@external.juniper.net'; 'Les Ginsberg'; 'Jeff > > ]> Learman'; Tony > > ]> Li > > ]> Subject: RE: [Isis-wg] Protocols Supported field in pseudonode LSP > > ]> > > ]> > > ]> > > ]> | Another role for the inclusion of "Protocols Supported" > > ]> field is to > > ]> | signal the other routers that the router originated the > > ]> LSP is IP capable ( > > ]> | As I understood it from RFC 1195 Section 5.2, paragraph 2.) > > ]> | Would it be from this point of view that the "Protocols > > ]> Supported" > > ]> | field is necessary since "logically" pseudo-node LSP is from the > > ]> | Designated-Router to all of its neighbors? > > ]> | The field tells all of its neighbors that it is IP capable. > > ]> > > ]> > > ]> Well, that would certainly be one interpretation of the spec. > > ]> However, > > ]> that would seem to be less interoperable. > > ]> > > ]> "Be strict in what you send and liberal in what you receive." > > ]> - Jon Postel > > ]> > > ]> Accordingly, putting a Protocols Supported field in the > > ]> pseudonode LSP is > > ]> not something that I interpret as being required by the spec. > > ]> > > ]> Tony > > ]> > > ]_______________________________________________ > > ]Isis-wg mailing list - Isis-wg@external.juniper.net > > ]http://external.juniper.net/mailman/listinfo/isis-wg > > > >- Naiming > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Larmer@CommSense.Net Tue Nov 27 15:31:30 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Tue, 27 Nov 2001 10:31:30 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <3C02D6E8.8E213049@tellabs.com> Message-ID: > The UK submission further requires support for separate IP and OSI DISes > (similar to the separate DISes required for L1 and L2) on LANs to > eliminate implied adjacencies between OSI-only and IP-only nodes on the > LAN. Is there a need for separate DISes at this point or is there a need for separate Pseudonode LSPs from a single DIS? If we generate separate Pseudonode LSPs with the Protocols Supported field advertising the types of protocols supported for the LAN adjacencies contained within the associated LSP, won't that resolve this issue? I.e. only build an OSI SPF tree for OSI adjacencies advertised in Pseudonode LSPs without a Protocols Supported field versus only build an IP SPF tree for IP adjacencies advertised in the Pseudonode LSP (LSP Number = 0) possessing a Protocols Supported field = 0xcc. The draw back as I see it to implementing multiple Pseudonode LSPs is that, when we support more protocols within IS-IS, other than OSI and IP, this mechanism will break because we only check for the presence of the Protocols Supported field in LSPs with LSP number = 0. Of course, the RFC could be amended in this area to resolve this issue? Cheers, Ken Larmer From Internet-Drafts@ietf.org Thu Nov 29 11:06:33 2001 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Thu, 29 Nov 2001 06:06:33 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-05.txt Message-ID: <200111291106.GAA20406@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-05.txt Pages : 9 Date : 28-Nov-01 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-05.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-05.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-05.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: <20011128143718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128143718.I-D@ietf.org> --OtherAccess-- --NextPart-- From mshand@cisco.com Thu Nov 29 11:42:24 2001 From: mshand@cisco.com (mike shand) Date: Thu, 29 Nov 2001 11:42:24 +0000 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: References: <3C02D6E8.8E213049@tellabs.com> Message-ID: <4.3.2.7.2.20011129111325.00ba2bc0@jaws.cisco.com> It seems to me that it is a VERY bad idea to have multiple DRs on a LAN at the same level. This is not just a pseudonode issue, but also affects the role of the DR in providing error recovery for the flooding (update) process. Unlike the level 1/2 case, there are NOT distinct sets of LSPs carrying protocol A and protocol B information (indeed a single LSP can carry both sets of information). SO there is no sense in which the update process is partitioned between the two DRs. Or is the intention here that one of the DRs does the normal DR functions and generates a pseudonode for protocol A, while the other ONLY generates a pseudonode for protocol B? But in any case, I don't see the need for separate pseudonodes. If we are running separate SPFs for protocol A and B, then the pseudonode is simply treated as a node which is both A and B capable. A protocol A (only) capable Node will not use a link to a protocol B (only) capable node even though it passes via the pseudonode which appears to be protocol A and B capable. So why don't we just form adjacencies on the LAN irrespective of the protocols supported? And then use multiple SPFs to sort out the mess. i.e. if you only have single SPF capable routers you MUST follow the deployment rules. If you want mixed A,AB,B capable routers, then you MUST run multiple SPFs for A and B. The only issue I can see is the case where the SPF indicates a node on the LAN as a next hop, but the first node doesn't (currently) have an adjacency to that node. The 10589 required behaviour in that case is to forward that packet to the DR (since the DR MUST have an adjacency otherwise it wouldn't have advertised it in its pseudonode). Clearly, this could fail if the DR wasn't in fact capable of forwarding the protocol in question. But this is an obscure case (and was really only there for the case of OSI end-systems, which because of their relatively long ES-IS timers may take a while to form adjacencies with all routers in the face of packet loss). A simple work around would be to give preference in the DR election to routers which were all protocol capable (either algorithmically, or by the simple expedient of giving them the highest priority). But in any case this should only be a transient condition. I don't think it warrants the complexity of multiple DR elections. or am I missing something? Mik At 10:31 27/11/2001 -0500, Ken Larmer wrote: > > The UK submission further requires support for separate IP and OSI DISes > > (similar to the separate DISes required for L1 and L2) on LANs to > > eliminate implied adjacencies between OSI-only and IP-only nodes on the > > LAN. > > Is there a need for separate DISes at this point or is there a > need for >separate Pseudonode LSPs from a single DIS? If we generate separate >Pseudonode LSPs with the Protocols Supported field advertising the types of >protocols supported for the LAN adjacencies contained within the associated >LSP, won't that resolve this issue? > > I.e. only build an OSI SPF tree for OSI adjacencies advertised in >Pseudonode LSPs without a Protocols Supported field versus only build an IP >SPF tree for IP adjacencies advertised in the Pseudonode LSP (LSP Number = >0) possessing a Protocols Supported field = 0xcc. The draw back as I see it >to implementing multiple Pseudonode LSPs is that, when we support more >protocols within IS-IS, other than OSI and IP, this mechanism will break >because we only check for the presence of the Protocols Supported field in >LSPs with LSP number = 0. Of course, the RFC could be amended in this area >to resolve this issue? > >Cheers, >Ken Larmer > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Larmer@CommSense.Net Thu Nov 29 15:37:30 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 29 Nov 2001 10:37:30 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <4.3.2.7.2.20011129111325.00ba2bc0@jaws.cisco.com> Message-ID: Hi Mike, Very good point about the election possibilities of a DR which does not support both OSI and IP protocols on the same LAN! I agree with your proposed resolution for this issue by giving DR election preference to ISs which support both OSI and IP protocols. The only problem I see is that the Protocols Supported field is not present in an OSI-only node's PDUs. So if you have a Dual-OSI/IP IS versus an IP-Only IS, we will not be able to differentiate between them from their LAN IIH PDUs. One resolution would be to define the Protocols Supported field (which is currently defined in RFC-1195) in ISO-10589 and provide a value for OSI. Am I out to lunch or will your recommendation with the above modifications, along with the separate Pseudonode LSPs for OSI versus IP adjacencies resolve this issue? Cheers, Ken Larmer CommSense Networks > It seems to me that it is a VERY bad idea to have multiple DRs on > a LAN at > the same level. This is not just a pseudonode issue, but also affects the > role of the DR in providing error recovery for the flooding (update) > process. Unlike the level 1/2 case, there are NOT distinct sets of LSPs > carrying protocol A and protocol B information (indeed a single LSP can > carry both sets of information). SO there is no sense in which the update > process is partitioned between the two DRs. > > Or is the intention here that one of the DRs does the normal DR functions > and generates a pseudonode for protocol A, while the other ONLY > generates a > pseudonode for protocol B? > > But in any case, I don't see the need for separate pseudonodes. If we are > running separate SPFs for protocol A and B, then the pseudonode is simply > treated as a node which is both A and B capable. A protocol A (only) > capable Node will not use a link to a protocol B (only) capable node even > though it passes via the pseudonode which appears to be protocol A and B > capable. > > So why don't we just form adjacencies on the LAN irrespective of the > protocols supported? And then use multiple SPFs to sort out the > mess. i.e. > if you only have single SPF capable routers you MUST follow the > deployment > rules. If you want mixed A,AB,B capable routers, then you MUST > run multiple > SPFs for A and B. > > The only issue I can see is the case where the SPF indicates a > node on the > LAN as a next hop, but the first node doesn't (currently) have an > adjacency > to that node. The 10589 required behaviour in that case is to > forward that > packet to the DR (since the DR MUST have an adjacency otherwise > it wouldn't > have advertised it in its pseudonode). Clearly, this could fail if the DR > wasn't in fact capable of forwarding the protocol in question. > > But this is an obscure case (and was really only there for the > case of OSI > end-systems, which because of their relatively long ES-IS timers > may take a > while to form adjacencies with all routers in the face of packet loss). > > A simple work around would be to give preference in the DR election to > routers which were all protocol capable (either algorithmically, > or by the > simple expedient of giving them the highest priority). > > But in any case this should only be a transient condition. > > I don't think it warrants the complexity of multiple DR elections. > > or am I missing something? > > > Mik > At 10:31 27/11/2001 -0500, Ken Larmer wrote: > > > > The UK submission further requires support for separate IP > and OSI DISes > > > (similar to the separate DISes required for L1 and L2) on LANs to > > > eliminate implied adjacencies between OSI-only and IP-only > nodes on the > > > LAN. > > > > Is there a need for separate DISes at this point or is there a > > need for > >separate Pseudonode LSPs from a single DIS? If we generate separate > >Pseudonode LSPs with the Protocols Supported field advertising > the types of > >protocols supported for the LAN adjacencies contained within the > associated > >LSP, won't that resolve this issue? > > > > I.e. only build an OSI SPF tree for OSI adjacencies > advertised in > >Pseudonode LSPs without a Protocols Supported field versus only > build an IP > >SPF tree for IP adjacencies advertised in the Pseudonode LSP > (LSP Number = > >0) possessing a Protocols Supported field = 0xcc. The draw back > as I see it > >to implementing multiple Pseudonode LSPs is that, when we support more > >protocols within IS-IS, other than OSI and IP, this mechanism will break > >because we only check for the presence of the Protocols > Supported field in > >LSPs with LSP number = 0. Of course, the RFC could be amended in > this area > >to resolve this issue? > > > >Cheers, > >Ken Larmer > > > >_______________________________________________ > >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 mshand@cisco.com Thu Nov 29 16:02:01 2001 From: mshand@cisco.com (mike shand) Date: Thu, 29 Nov 2001 16:02:01 +0000 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: References: <4.3.2.7.2.20011129111325.00ba2bc0@jaws.cisco.com> Message-ID: <4.3.2.7.2.20011129155633.0375d9e0@jaws.cisco.com> At 10:37 29/11/2001 -0500, Ken Larmer wrote: >Hi Mike, > > Very good point about the election possibilities of a DR which > does not >support both OSI and IP protocols on the same LAN! I agree with your >proposed resolution for this issue by giving DR election preference to ISs >which support both OSI and IP protocols. The only problem I see is that the >Protocols Supported field is not present in an OSI-only node's PDUs. So if >you have a Dual-OSI/IP IS versus an IP-Only IS, we will not be able to >differentiate between them from their LAN IIH PDUs. One resolution would be >to define the Protocols Supported field (which is currently defined in >RFC-1195) in ISO-10589 and provide a value for OSI. I don't care about the hellos, I do care about the LSPs. But either way I THOUGHT that it was permissible to put any value of NLPID (as defined by ISO TR 9577) in the protocols supported field, and hence we could put one for OSI. So No protocols supported = OSI only IP + OSI protocols supported = dual IP protocols supported = IP only or is my memory failing me? Of course there are backwards compatibility issues in all this. Mike > Am I out to lunch or will your recommendation with the above > modifications, >along with the separate Pseudonode LSPs for OSI versus IP adjacencies >resolve this issue? > >Cheers, >Ken Larmer >CommSense Networks > > > It seems to me that it is a VERY bad idea to have multiple DRs on > > a LAN at > > the same level. This is not just a pseudonode issue, but also affects the > > role of the DR in providing error recovery for the flooding (update) > > process. Unlike the level 1/2 case, there are NOT distinct sets of LSPs > > carrying protocol A and protocol B information (indeed a single LSP can > > carry both sets of information). SO there is no sense in which the update > > process is partitioned between the two DRs. > > > > Or is the intention here that one of the DRs does the normal DR functions > > and generates a pseudonode for protocol A, while the other ONLY > > generates a > > pseudonode for protocol B? > > > > But in any case, I don't see the need for separate pseudonodes. If we are > > running separate SPFs for protocol A and B, then the pseudonode is simply > > treated as a node which is both A and B capable. A protocol A (only) > > capable Node will not use a link to a protocol B (only) capable node even > > though it passes via the pseudonode which appears to be protocol A and B > > capable. > > > > So why don't we just form adjacencies on the LAN irrespective of the > > protocols supported? And then use multiple SPFs to sort out the > > mess. i.e. > > if you only have single SPF capable routers you MUST follow the > > deployment > > rules. If you want mixed A,AB,B capable routers, then you MUST > > run multiple > > SPFs for A and B. > > > > The only issue I can see is the case where the SPF indicates a > > node on the > > LAN as a next hop, but the first node doesn't (currently) have an > > adjacency > > to that node. The 10589 required behaviour in that case is to > > forward that > > packet to the DR (since the DR MUST have an adjacency otherwise > > it wouldn't > > have advertised it in its pseudonode). Clearly, this could fail if the DR > > wasn't in fact capable of forwarding the protocol in question. > > > > But this is an obscure case (and was really only there for the > > case of OSI > > end-systems, which because of their relatively long ES-IS timers > > may take a > > while to form adjacencies with all routers in the face of packet loss). > > > > A simple work around would be to give preference in the DR election to > > routers which were all protocol capable (either algorithmically, > > or by the > > simple expedient of giving them the highest priority). > > > > But in any case this should only be a transient condition. > > > > I don't think it warrants the complexity of multiple DR elections. > > > > or am I missing something? > > > > > > Mik > > At 10:31 27/11/2001 -0500, Ken Larmer wrote: > > > > > > The UK submission further requires support for separate IP > > and OSI DISes > > > > (similar to the separate DISes required for L1 and L2) on LANs to > > > > eliminate implied adjacencies between OSI-only and IP-only > > nodes on the > > > > LAN. > > > > > > Is there a need for separate DISes at this point or is there a > > > need for > > >separate Pseudonode LSPs from a single DIS? If we generate separate > > >Pseudonode LSPs with the Protocols Supported field advertising > > the types of > > >protocols supported for the LAN adjacencies contained within the > > associated > > >LSP, won't that resolve this issue? > > > > > > I.e. only build an OSI SPF tree for OSI adjacencies > > advertised in > > >Pseudonode LSPs without a Protocols Supported field versus only > > build an IP > > >SPF tree for IP adjacencies advertised in the Pseudonode LSP > > (LSP Number = > > >0) possessing a Protocols Supported field = 0xcc. The draw back > > as I see it > > >to implementing multiple Pseudonode LSPs is that, when we support more > > >protocols within IS-IS, other than OSI and IP, this mechanism will break > > >because we only check for the presence of the Protocols > > Supported field in > > >LSPs with LSP number = 0. Of course, the RFC could be amended in > > this area > > >to resolve this issue? > > > > > >Cheers, > > >Ken Larmer > > > > > >_______________________________________________ > > >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 Larmer@CommSense.Net Thu Nov 29 17:09:46 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 29 Nov 2001 12:09:46 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <4.3.2.7.2.20011129155633.0375d9e0@jaws.cisco.com> Message-ID: Hi Mike, > I don't care about the hellos, I do care about the LSPs. I mentioned the hellos for 2 reasons, first we can not differentiate between the protocols which are running on an IS unless there is an entry in the Protocols Supported field of a LAN IIH PDU. Consequently, when running the DR election process, we could not give proper preference to those ISes which support Dual routing (i.e. there is currently no method for differentiating between a Dual IS and an IP-Only IS). So, this field in a hello also needs to possess the correct value advertising it as a Dual IS versus an IP-Only IS. Secondly to stay in compliance with RFC-1195, we must abide by the following statement extracted from RFC-1195: Dual routers must operate in a dual fashion on every link in the routing domain over which they are running IS-IS. Thus, the value of the "protocols supported" field must be identical on every link (i.e., for any one router running IS-IS, all of the Hellos and LSPs transmitted by it must contain the same "protocols supported" values). > But either way I THOUGHT that it was permissible to put any value of NLPID (as defined by > ISO TR 9577) in the protocols supported field, and hence we > could put one > for OSI. So > > No protocols supported = OSI only > IP + OSI protocols supported = dual > IP protocols supported = IP only This makes a great deal of sense and I agree completely! Cheers, Ken Larmer CommSense Networks From mshand@cisco.com Thu Nov 29 17:19:05 2001 From: mshand@cisco.com (mike shand) Date: Thu, 29 Nov 2001 17:19:05 +0000 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: References: <4.3.2.7.2.20011129155633.0375d9e0@jaws.cisco.com> Message-ID: <4.3.2.7.2.20011129171235.03712c30@jaws.cisco.com> At 12:09 29/11/2001 -0500, Ken Larmer wrote: >Hi Mike, > > > I don't care about the hellos, I do care about the LSPs. > >I mentioned the hellos for 2 reasons, first we can not differentiate between >the protocols which are running on an IS unless there is an entry in the >Protocols Supported field of a LAN IIH PDU. Consequently, when running the >DR election process, we could not give proper preference to those ISes which >support Dual routing (i.e. there is currently no method for differentiating >between a Dual IS and an IP-Only IS). So, this field in a hello also needs >to possess the correct value advertising it as a Dual IS versus an IP-Only >IS. Yes, you are right - you do need it to give dual capable nodes preference in an election. And maybe that is what you have to do for backwards compatibility reasons, but what I was saying (and this is completely off the wall) is that you could simply ignore the protocols supportedness in the hellos and always form an adjacency. In that case there would be no need to do anything special with the DR election, since by definition the DR (and hence the pseudonode) would have adjacencies to all routers on the LAN even if it didn't itself support the required protocol. Then we would just leave it to the (separate) SPFs to actually figure out which W"next hops" to use (either natively, or doing some kind of autotunnel if necessary). But maybe I've got this all wrong. I don't think what I'm "proposing" (and I use the word very loosely) has very good backwards compatibility properties in any case. Mike >Secondly to stay in compliance with RFC-1195, we must abide by the following >statement extracted from RFC-1195: > >Dual routers must operate in a dual fashion on every link in the routing >domain over which they are running IS-IS. Thus, the value of the "protocols >supported" field must be identical on every link (i.e., for any one router >running IS-IS, all of the Hellos and LSPs transmitted by it must contain the >same "protocols supported" values). > > > But either way I THOUGHT that it was permissible to put any value of NLPID >(as defined by > > ISO TR 9577) in the protocols supported field, and hence we > > could put one > > for OSI. So > > > > No protocols supported = OSI only > > IP + OSI protocols supported = dual > > IP protocols supported = IP only > >This makes a great deal of sense and I agree completely! > >Cheers, >Ken Larmer >CommSense Networks From Larmer@CommSense.Net Thu Nov 29 20:32:58 2001 From: Larmer@CommSense.Net (Ken Larmer) Date: Thu, 29 Nov 2001 15:32:58 -0500 Subject: [Isis-wg] Protocols Supported field in pseudonode LSP In-Reply-To: <4.3.2.7.2.20011129171235.03712c30@jaws.cisco.com> Message-ID: > Yes, you are right - you do need it to give dual capable nodes preference > in an election. And maybe that is what you have to do for backwards > compatibility reasons, but what I was saying (and this is completely off > the wall) is that you could simply ignore the protocols supportedness in > the hellos and always form an adjacency. In that case there would be no > need to do anything special with the DR election, since by definition the > DR (and hence the pseudonode) would have adjacencies to all > routers on the > LAN even if it didn't itself support the required protocol. > > Then we would just leave it to the (separate) SPFs to actually figure out > which W"next hops" to use (either natively, or doing some kind of > autotunnel if necessary). > > But maybe I've got this all wrong. I don't think what I'm > "proposing" (and > I use the word very loosely) has very good backwards compatibility > properties in any case. Doesn't the fact that most vendors do not support forming adjacencies with an IS who possesses a different IP subnet (even though RFC-1195 clearly states to form an adjacency with such an IS and forward between subnets) and the following statement extracted from the Dijkstra Calculation and forwarding section of RFC-1195, create some problems? What if the DR is an OSI-Only IS? C.1.4 The Algorithm ... 8) Now add systems to which the local router does not have adjacencies, but which are mentioned in neighboring pseudonode LSPs. The adjacency for such systems is set to that of the designated router... In order to relax the configuration rules, I believe the following MAY work fine? 1. Give the DR Election preference to ISes which serve as a Dual-IS. 2. Place the NLPID in the Pseudonode LSP for the supported entries contain within (i.e. 0xcc = IP capable neighbors). 3. DR generation of multiple Pseudonode LSPs for each protocol supported. 4. Creation of additional definitions for future NLPIDs. (IPv6, toaster protocol...) 5. Relax the restriction on checking for the NLPID in LSP #0 only LSPs. The only problem I can see with this scenario is when you have a mixed LAN and there are IP-Only or OSI-Only ISes which can serve as the DR. Though, I suppose you could really break any protocol if it were miss configured sufficiently? Cheers, Ken Larmer CommSense Networks From jparker@axiowave.com Thu Nov 29 22:29:55 2001 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 29 Nov 2001 17:29:55 -0500 Subject: [Isis-wg] Aligning MIB values with Implementation values Message-ID: I've received the following request to align MIB values with implementation values. As Neal notes, I had been following an admonition to avoid the use of 0 as the value of an enumeration. However, I don't think this is a prohibition. There are two things we could do: Make the mapping be the identity (so that Up becomes 0, etc) Make the mapping be addition (subtraction) by 1 Any objections to doing the first? - jeff parker - axiowave networks /////////////////////////////////////////////////// Jeff, The isisISAdjState values are inconsistent with the those in the 3-way handshake draft. Because of this, my code must translate between the two. The MIB has values: Initializing 1 Up 2 Down 4 Whereas the 3-way handshake draft has these different values for adjacency state: Initializing 1 Up 0 Down 2 Any chance the MIB values could be made to be consistent? I note that in the MIB there appears to be a desire to avoid the use of the number "0" as a value for an entry, and so in this case giving values such as Up 1, Initializing 2, Down 3, would be pretty good since there is an easy function to map between the two values. Secondly, the fields for Adjacency usage are inconsistent with those values that one might use to index into the 10589 state tables for received hellos (8.2.4.2). Looking at table 6, which contains all the indecis, the ideal index values for adjusage would be: None: 0 L1: 1 L1andL2: 2 L2-only 3 The mib has values: Undefined: 1 level1 2 level2 3 level1and2 4 As before, if 0 is being avoided values such as none: 1 l1: 2, l1andl2 3 l2-only 4, would be preferable. I realize this isn't terribly important, but there is some confusing code that maps between the table indices and the MIB values that makes this part of the code a little more difficult to read. No translation would improve this bit of code's readability. Thanks for your attention, --Neal From aravindravikumar@yahoo.com Fri Nov 30 10:29:47 2001 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Fri, 30 Nov 2001 02:29:47 -0800 (PST) Subject: [Isis-wg] doubt regarding manual area addresses Message-ID: <20011130102947.76302.qmail@web11207.mail.yahoo.com> --0-1820195145-1007116187=:76279 Content-Type: text/plain; charset=us-ascii Hi, Can any body please clarify the following doubts regarding manual area address What is difference in the information included in manual area address option in the following packets hello packets(level1 ,level2, point to point)level1 lsp number 0,level2 lsp number 0 Is there any difference in the way a router uses the configured area addresses and the area addresses which it learns from other routers Thanking in advance,Aravind --------------------------------- Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. --0-1820195145-1007116187=:76279 Content-Type: text/html; charset=us-ascii

Hi,

Can any body please clarify the following doubts regarding manual area address

What is difference in the information included in manual area address option in the following packets
 
hello packets(level1 ,level2, point to point)
level1 lsp number 0,
level2 lsp number 0
 
Is there any difference in the way  a router uses the configured area addresses and the area addresses which it learns from other routers
 
Thanking in advance,
Aravind
 


Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. --0-1820195145-1007116187=:76279-- From sachidananda_k@hotmail.com Sat Dec 1 10:08:50 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Sat, 01 Dec 2001 10:08:50 +0000 Subject: [Isis-wg] IIHs Optional TLV Message-ID: Hi, I have a doubt regarding the nubmer of times the below mentioned TLVs can appear in the IIH PDUs. 1. Area Address TLVs. 2. IP interface TLVs. 3. Protocol Supported TLVs. Does the standard impose any restriction on the number of times these TLVs can appear in a IIH (LAN or P2P). Pls help me understand ISIS better. Thanking you in advance. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From hannes@juniper.net Sat Dec 1 17:43:40 2001 From: hannes@juniper.net (Hannes Gredler) Date: Sat, 1 Dec 2001 18:43:40 +0100 Subject: [Isis-wg] IIHs Optional TLV In-Reply-To: ; from sachidananda_k@hotmail.com on Sat, Dec 01, 2001 at 10:08:50AM +0000 References: Message-ID: <20011201184340.A11078@juniper.net> On Sat, Dec 01, 2001 at 10:08:50AM +0000, Sachidananda K wrote: | Hi, | | I have a doubt regarding the nubmer of times the below mentioned TLVs can | appear in the IIH PDUs. | 1. Area Address TLVs. | 2. IP interface TLVs. | 3. Protocol Supported TLVs. | | Does the standard impose any restriction on the number of times these TLVs | can appear in a IIH (LAN or P2P). sachi, as long the number of total areas does not contratict the number of areas in the is-is commmon header TLV #1 can occur more than one time; the IP interface TLV and the protcols supported TLV can occur also several times; however, practically speaking the most-common implementations support upto three areas. given the max. NSAP size of 20 bytes and assuming that the sys-len = 6 bytes there are upto 13 bytes to carry; an additional byte is needed for the area-adress length field; so this results in 14*3 = 42 bytes which fit quite easily into a single TLV; most systems today support IPv4 routing, some of them support additionally IPv6; so the typical prot.supported TLV is filled with 2 bytes - again no need for several occurences of TLV #129; given that you do not have more than 21 IP adresses configured on your physical interface you mostly find also just one occurence of TLV #132; /hannes | Pls help me understand ISIS better. | Thanking you in advance. | Sachi | | _________________________________________________________________ | Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp | | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg From bwijnen@lucent.com Sun Dec 2 10:20:09 2001 From: bwijnen@lucent.com (Wijnen, Bert (Bert)) Date: Sun, 2 Dec 2001 11:20:09 +0100 Subject: [Isis-wg] RE: Aligning MIB values with Implementation values Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E05AF10@nl0006exch002u.nl.lucent.com> Inline > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Thursday, November 29, 2001 11:30 PM > To: IS-IS-WG (E-mail) > Cc: Bert Wijnen (Bert) (E-mail); 'KChapman@unispherenetworks.com' > Subject: Aligning MIB values with Implementation values > > > I've received the following request to align MIB values with > implementation values. > > As Neal notes, I had been following an admonition to avoid the > use of 0 as the value of an enumeration. However, I don't > think this is a prohibition. > > There are two things we could do: > Make the mapping be the identity (so that Up becomes 0, etc) > Make the mapping be addition (subtraction) by 1 > > Any objections to doing the first? > It is recommended that enumerations start at 1. But not prohibeted as you state. And you seem to have a valid reason to not follow the receommendation. Maybe you can add some text to the DESCRIPTION clause to explain why you start at zero. Bert > - jeff parker > - axiowave networks > > /////////////////////////////////////////////////// > > Jeff, > > The isisISAdjState values are inconsistent with the those in the 3-way > handshake draft. Because of this, my code must translate > between the two. > > The MIB has values: > > Initializing 1 > Up 2 > Down 4 > > Whereas the 3-way handshake draft has these different values > for adjacency > state: > > Initializing 1 > Up 0 > Down 2 > > Any chance the MIB values could be made to be consistent? I > note that in > the MIB there appears to be a desire to avoid the use of the > number "0" as a > value for an entry, and so in this case giving values such as Up 1, > Initializing 2, Down 3, would be pretty good since there is > an easy function > to map between the two values. > > Secondly, the fields for Adjacency usage are inconsistent > with those values > that one might use to index into the 10589 state tables for > received hellos > (8.2.4.2). Looking at table 6, which contains all the > indecis, the ideal > index values for adjusage would be: > > > None: 0 > L1: 1 > L1andL2: 2 > L2-only 3 > > The mib has values: > Undefined: 1 > level1 2 > level2 3 > level1and2 4 > > As before, if 0 is being avoided values such as none: 1 l1: > 2, l1andl2 3 > l2-only 4, would be preferable. > > I realize this isn't terribly important, but there is some > confusing code > that maps between the table indices and the MIB values that > makes this part > of the code a little more difficult to read. No translation > would improve > this bit of code's readability. > > Thanks for your attention, > > --Neal > From aridaman kaushik" hi all, I hope, anyone would clarify my doubt regarding ipv6 route prefernece in isis. in draft draft-isis-ipv6-02.txt, route preference is given like this(from best to worst). 1. level1 up 2. level2 up 3. level2 down 4. level1 down What is meaning of up/down here. we can assume that level2 down means l2 to l1 leaked route. but what is the meaning of l1 down thanks in advance ari From jparker@axiowave.com Tue Dec 4 14:09:15 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 4 Dec 2001 09:09:15 -0500 Subject: [Isis-wg] (no subject) Message-ID: > 1. level1 up > 2. level2 up > 3. level2 down > 4. level1 down > > What ... is the meaning of l1 down[?] Take a look at RFC 2966, http://www.ietf.org/rfc/rfc2966.txt - jeff parker - axiowave networks From christi@nortelnetworks.com Tue Dec 4 17:34:22 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:34:22 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C4507138D@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_01C17CE9.E8F94900 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE9.E8F94900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE9.E8F94900-- From tli@Procket.com Tue Dec 4 18:40:30 2001 From: tli@Procket.com (Tony Li) Date: Tue, 4 Dec 2001 10:40:30 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> Message-ID: <15373.6302.577326.223821@alpha-tli.procket.com> | This draft specifically declares itself to be useful in SONET networks | (presumably in the embedded DCC channels, although this is not stated). Actually, most of the IP routers running IS-IS do so over POS links, and thus, IS-IS is running in-band. I agree with your comments. Other opinions? Tony From prz@redback.com Tue Dec 4 18:15:38 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 04 Dec 2001 10:15:38 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> Message-ID: <3C0D12CA.2B982FCB@redback.com> Philip Christian wrote: > > > I have a number of concerns and comments about the 3-way-handshake > draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that > this draft is about to become an RFC, although I can find no evidence > of this on the RFC editor's web page. > > Here are my concerns. > > This draft specifically declares itself to be useful in SONET networks > (presumably in the embedded DCC channels, although this is not > stated). However I believe that there is an area of ambiguity in it > which reduces its usefulness somewhat. The draft mentions only IIH > packets, where as SONET and SDH networks (oh yes, SDH is not mentioned > either) are currently based on CLNS and therefore the NEs transmit ISH > packets too. > > I understand that an old CLNS SONET/SDH node will not support > three-way handshaking anyway, and so a new neighbour would engage > legacy mode anyway, BUT.... > > With the advent of G.7712 vendors will be looking at implementing dual > IP and CLNS routers that are able to still interface to the old CLNS > nodes, and which also support three way handshaking. Such a new dual > node may well need to declare itself a CLNS End System, and so will be > transmitting ISHs. This will be necessary to terminate RFC 3147 > encapsulated packets, for example. > > The problem is that I believe that receipt of ISH packets "short > circuits" the three way handshake, and results in the adjacency coming > up whether the neighbour has received IIHs, or not. This is my > understanding of the problem: > > A is connected to B and issues an ISH. > B receives the ISH, and according to ISO 10589 section 8.2.2 creates > an adjacency of type "Initialising". > B now reports to A in the new "Point to point adjacency state" option > that the adjacency is "Initialising". > A receives this and according to the table in the draft, brings the > adjacency "up". > However B may never have received an IIH from A and so the three way > handshake has been short circuited, or have I misunderstood something? > > The draft really needs to state how a router with three way > handshaking should handle receipt of an ISH from a neighbouring IS > that also supports the option. > > I guess that this is not a problem for pure IP routers if they ignore > ISHs, and this could be stated. > > Next concern; what happened to ISHs anyway? RFC 1195 states in section > 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 > ISHs, as the first step in establishing the link between routers. All > IS-IS routers are therefore required to transmit and receive ISO 9542 > ISH packets on point-to-point links.". There is a similar statement in > section 5.1. > > I am told that many implementors do not transmit ISH packets anymore, > as they cannot terminate CLNP and thus are not an CLNS End System > anymore. > > This seems perfectly logical to me, but, if this is the case then I > think that this draft should state it. It is the after-all going to be > (hopefully) the first RFC to actually alter the adjacency creation > process from ISO 10589; RFC 1195 did not change it. If it is now okay > not to transmit ISHs then let's say so. funny enough, I know that multiple vendors shortcut ISHs since a while and I stated in some conversations that I'm concerned. Since I could not prove the specific problem that would cause (since IIHs will bring the adjacency anyway), it was dismissed with a shrug. >From my vintage, yes, it should be fixed, maybe as simply as saying that three-way-hello capable routers drop ISHs and do not send them ? The very details of 1195 slip my mind right now but that should not cause any backwards capability problems? something is definitely worth an addition to the 3-way-hello draft -- tony From naiming@redback.com Tue Dec 4 19:41:37 2001 From: naiming@redback.com (Naiming Shen) Date: Tue, 04 Dec 2001 11:41:37 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: Mail from Tony Li dated Tue, 04 Dec 2001 10:40:30 PST <15373.6302.577326.223821@alpha-tli.procket.com> Message-ID: <20011204194137.405FFCAB6E@prattle.redback.com> this draft reflects many vendors current implementation for the ip routers, we should let this to go through to become an rfc(informational). any need for ish probably should submit a seperate one, maybe a big one to handle all other clns cases where the ip portion has already advanced. ] ] | This draft specifically declares itself to be useful in SONET networks ] | (presumably in the embedded DCC channels, although this is not stated). ] ] ]Actually, most of the IP routers running IS-IS do so over POS links, and ]thus, IS-IS is running in-band. ] ]I agree with your comments. Other opinions? ] ]Tony ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From christi@nortelnetworks.com Tue Dec 4 19:53:59 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 19:53:59 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071390@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_01C17CFD.6A36A220 Content-Type: text/plain; charset="iso-8859-1" I absolutely do not agree. I said that it is acceptable for a pure IP implementation to ignore ISH, and so these "current vendors implementations" need not have a problem with it. We can even say this in the RFC, so for the first time ever, it will say in an RFC "you can ignore ISH". I would have thought that this would be good news for the implementations that you mention. However the draft is useless for routers that do need to terminate CLNS packets, and is therefore useless for sorting out the SONET protection switching events that it claims to help. Do we want RFCs that do not acheive what they claim to? We can sort out one without affecting the other, and therefore should do so. By the way, the draft has expired, but people can still read it at http://www.watersprings.org/pub/id/draft-ietf-isis-3way-03.txt Philip Christian -----Original Message----- From: Naiming Shen [mailto:naiming@redback.com] Sent: 04 December 2001 19:42 To: Tony Li Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net'; Saluja, Rajesh [BL60:432:EXCH] Subject: Re: [Isis-wg] Concerns with 3-way-handshake this draft reflects many vendors current implementation for the ip routers, we should let this to go through to become an rfc(informational). any need for ish probably should submit a seperate one, maybe a big one to handle all other clns cases where the ip portion has already advanced. ] ] | This draft specifically declares itself to be useful in SONET networks ] | (presumably in the embedded DCC channels, although this is not stated). ] ] ]Actually, most of the IP routers running IS-IS do so over POS links, and ]thus, IS-IS is running in-band. ] ]I agree with your comments. Other opinions? ] ]Tony ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming ------_=_NextPart_001_01C17CFD.6A36A220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Concerns with 3-way-handshake

I absolutely do not agree.
I said that it is acceptable for a pure IP = implementation to ignore ISH, and so these "current vendors = implementations" need not have a problem with it.

We can even say this in the RFC, so for the first = time ever, it will say in an RFC "you can ignore ISH". I = would have thought that this would be good news for the implementations = that you mention.

However the draft is useless for routers that do need = to terminate CLNS packets, and is therefore useless for sorting out the = SONET protection switching events that it claims to help.

Do we want RFCs that do not acheive what they claim = to?
We can sort out one without affecting the other, and = therefore should do so.

By the way, the draft has expired, but people can = still read it at
http://www.watersprings.org/pub/id/draft-ietf-isis-3wa= y-03.txt

Philip Christian

-----Original Message-----
From: Naiming Shen [mailto:naiming@redback.com]
Sent: 04 December 2001 19:42
To: Tony Li
Cc: Christian, Philip [HAL02:GI50:EXCH]; = 'isis-wg@spider.juniper.net';
'dkatz@juniper.net'; Saluja, Rajesh = [BL60:432:EXCH]
Subject: Re: [Isis-wg] Concerns with = 3-way-handshake



this draft reflects many vendors current = implementation for the ip
routers, we should let this to go through to become = an rfc(informational).
any need for ish probably should submit a seperate = one, maybe a big
one to handle all other clns cases where the ip = portion has already
advanced.


 ]
 ] | This draft specifically declares itself to = be useful in SONET networks
 ] | (presumably in the embedded DCC channels, = although this is not stated).
 ]
 ]
 ]Actually, most of the IP routers running = IS-IS do so over POS links, and
 ]thus, IS-IS is running in-band.
 ]
 ]I agree with your comments.  Other = opinions?
 ]
 ]Tony
 ]
 ]_______________________________________________
 ]Isis-wg mailing list  -  = Isis-wg@external.juniper.net
 ]http://external.juniper.net/mailman/listinfo/isis-wg

- Naiming

------_=_NextPart_001_01C17CFD.6A36A220-- From christi@nortelnetworks.com Tue Dec 4 20:03:23 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 20:03:23 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071391@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_01C17CFE.BAA29880 Content-Type: text/plain; charset="iso-8859-1" The draft is definitely talking about embedded DCC channels when it says "In addition, SONET links bring a third issue, which is that when SONET protection is used, 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." This has to be referring to when the embedded DCC channel in a SONET signal switches with the K bytes from one fibre to another. The problem mentioned above occurs when the active signal goes through a different regenerator to the protection fibre. Interestingly SDH acts differently with two adjacencies maintained and one of them just disappearing. A protection switch should be invisible to the SONET payload, i.e. a POS circuit between two routers, and so this is not what it is talking about. Philip Christian -----Original Message----- From: Tony Li [mailto:tli@Procket.com] Sent: 04 December 2001 18:41 To: Christian, Philip [HAL02:GI50:EXCH] Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net'; 'rsaluja@nortelnetworks.com' Subject: [Isis-wg] Concerns with 3-way-handshake | This draft specifically declares itself to be useful in SONET networks | (presumably in the embedded DCC channels, although this is not stated). Actually, most of the IP routers running IS-IS do so over POS links, and thus, IS-IS is running in-band. I agree with your comments. Other opinions? Tony ------_=_NextPart_001_01C17CFE.BAA29880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Concerns with 3-way-handshake

The draft is definitely talking about embedded DCC = channels when it says

"In addition, SONET links bring a third issue, = which is that when SONET protection is used, 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."

This has to be referring to when the embedded DCC = channel in a SONET signal switches with the K bytes from one fibre to = another. The problem mentioned above occurs when the active signal goes = through a different regenerator to the protection fibre. Interestingly = SDH acts differently with two adjacencies maintained and one of them = just disappearing.

A protection switch should be invisible to the SONET = payload, i.e. a POS circuit between two routers, and so this is not = what it is talking about.

Philip Christian

-----Original Message-----
From: Tony Li [mailto:tli@Procket.com]
Sent: 04 December 2001 18:41
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'isis-wg@spider.juniper.net'; = 'dkatz@juniper.net';
'rsaluja@nortelnetworks.com'
Subject: [Isis-wg] Concerns with = 3-way-handshake



 | This draft specifically declares itself to be = useful in SONET networks
 | (presumably in the embedded DCC channels, = although this is not stated).


Actually, most of the IP routers running IS-IS do so = over POS links, and
thus, IS-IS is running in-band.

I agree with your comments.  Other = opinions?

Tony

------_=_NextPart_001_01C17CFE.BAA29880-- From jlearman@cisco.com Tue Dec 4 20:24:00 2001 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 04 Dec 2001 15:24:00 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: <15373.6302.577326.223821@alpha-tli.procket.com> References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> Message-ID: <4.3.2.7.2.20011204143729.00ba2418@dingdong.cisco.com> At 01:40 PM 12/4/2001, Tony Li wrote: > | This draft specifically declares itself to be useful in SONET networks > | (presumably in the embedded DCC channels, although this is not stated). > > >Actually, most of the IP routers running IS-IS do so over POS links, and >thus, IS-IS is running in-band. In addition, the draft addresses running IS-IS over an unreliable point-to-point link level protocol, whereas 10598 states that a reliable link is required. I believe the draft states this to be the case (at least, the author promised me it would!) I agree with the recommendation. While the three-way handshake is superfluous on a reliable link, it should be permitted. If I remember correctly, it could be used for a related purpose -- a larger circuit ID or something. Regards, Jeff >I agree with your comments. Other opinions? > >Tony > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From naiming@redback.com Tue Dec 4 20:33:00 2001 From: naiming@redback.com (Naiming Shen) Date: Tue, 04 Dec 2001 12:33:00 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: Mail from "Philip Christian" dated Tue, 04 Dec 2001 19:53:59 GMT <4103264BC8D3D51180B7002048400C45071390@zhard0jd.europe.nortel.com> Message-ID: <20011204203301.0AE58CAB70@prattle.redback.com> I don't think the draft claims to work during the sonet switch level, the sonet switching portion this draft talking about has nothing to do with ISIS. this draft only claims to solve the problem after the sonet switching happened(with some lower layer signalling), how to make sure from layer 3 this link has changed circuit from ISIS point of view. ] ]I absolutely do not agree. ]I said that it is acceptable for a pure IP implementation to ignore ISH, and ]so these "current vendors implementations" need not have a problem with it. ]We can even say this in the RFC, so for the first time ever, it will say in ]an RFC "you can ignore ISH". I would have thought that this would be good ]news for the implementations that you mention. ]However the draft is useless for routers that do need to terminate CLNS ]packets, and is therefore useless for sorting out the SONET protection ]switching events that it claims to help. ]Do we want RFCs that do not acheive what they claim to? ]We can sort out one without affecting the other, and therefore should do so. ] ]By the way, the draft has expired, but people can still read it at ]http://www.watersprings.org/pub/id/draft-ietf-isis-3way-03.txt ] ]Philip Christian ] ]-----Original Message----- ]From: Naiming Shen [mailto:naiming@redback.com] ]Sent: 04 December 2001 19:42 ]To: Tony Li ]Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; ]'dkatz@juniper.net'; Saluja, Rajesh [BL60:432:EXCH] ]Subject: Re: [Isis-wg] Concerns with 3-way-handshake ] ] ] ]this draft reflects many vendors current implementation for the ip ]routers, we should let this to go through to become an rfc(informational). ]any need for ish probably should submit a seperate one, maybe a big ]one to handle all other clns cases where the ip portion has already ]advanced. ] ] ] ] ] ] | This draft specifically declares itself to be useful in SONET networks ] ] | (presumably in the embedded DCC channels, although this is not stated). ] ] ] ] ] ]Actually, most of the IP routers running IS-IS do so over POS links, and ] ]thus, IS-IS is running in-band. ] ] ] ]I agree with your comments. Other opinions? ] ] ] ]Tony ] ] ] ]_______________________________________________ ] ]Isis-wg mailing list - Isis-wg@external.juniper.net ] ]http://external.juniper.net/mailman/listinfo/isis-wg ] ]- Naiming ] - Naiming From jlearman@cisco.com Tue Dec 4 20:31:42 2001 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 04 Dec 2001 15:31:42 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: <4103264BC8D3D51180B7002048400C45071391@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20011204152711.05186e50@dingdong.cisco.com> --=====================_104596201==_.ALT Content-Type: text/plain; charset="us-ascii" At 03:03 PM 12/4/2001, Philip Christian wrote: >The draft is definitely talking about embedded DCC channels when it says > >"In addition, SONET links bring a third issue, which is that when SONET protection is used, 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." > >This has to be referring to when the embedded DCC channel in a SONET signal switches with the K bytes from one fibre to another. The problem mentioned above occurs when the active signal goes through a different regenerator to the protection fibre. Interestingly SDH acts differently with two adjacencies maintained and one of them just disappearing. This would cause the LAPD link to fail with high probability, so I doubt it's what is being referred to in the draft. >A protection switch should be invisible to the SONET payload, i.e. a POS circuit between two routers, and so this is not what it is talking about. For channelized SONET, reprovisioning could cause the VT to be terminated at a different remote system. Since the link layer protocol is unreliable and does not detect the fact that it is now connected to a different system, the 3-way handshake is required. Jeff >Philip Christian > >-----Original Message----- >From: Tony Li [mailto:tli@Procket.com] >Sent: 04 December 2001 18:41 >To: Christian, Philip [HAL02:GI50:EXCH] >Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net'; >'rsaluja@nortelnetworks.com' >Subject: [Isis-wg] Concerns with 3-way-handshake > > > | This draft specifically declares itself to be useful in SONET networks > | (presumably in the embedded DCC channels, although this is not stated). > >Actually, most of the IP routers running IS-IS do so over POS links, and >thus, IS-IS is running in-band. > >I agree with your comments. Other opinions? > >Tony --=====================_104596201==_.ALT Content-Type: text/html; charset="us-ascii" At 03:03 PM 12/4/2001, Philip Christian wrote:

The draft is definitely talking about embedded DCC channels when it says

"In addition, SONET links bring a third issue, which is that when SONET protection is used, 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."

This has to be referring to when the embedded DCC channel in a SONET signal switches with the K bytes from one fibre to another. The problem mentioned above occurs when the active signal goes through a different regenerator to the protection fibre. Interestingly SDH acts differently with two adjacencies maintained and one of them just disappearing.

This would cause the LAPD link to fail with high probability, so I
doubt it's what is being referred to in the draft.

A protection switch should be invisible to the SONET payload, i.e. a POS circuit between two routers, and so this is not what it is talking about.

For channelized SONET, reprovisioning could cause the VT to be terminated
at a different remote system.  Since the link layer protocol is unreliable
and does not detect the fact that it is now connected to a different system,
the 3-way handshake is required.

Jeff


Philip Christian

-----Original Message-----
From: Tony Li [mailto:tli@Procket.com]
Sent: 04 December 2001 18:41
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net';
'rsaluja@nortelnetworks.com'
Subject: [Isis-wg] Concerns with 3-way-handshake


 | This draft specifically declares itself to be useful in SONET networks
 | (presumably in the embedded DCC channels, although this is not stated).

Actually, most of the IP routers running IS-IS do so over POS links, and
thus, IS-IS is running in-band.

I agree with your comments.  Other opinions?

Tony
--=====================_104596201==_.ALT-- From jlearman@cisco.com Tue Dec 4 20:36:47 2001 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 04 Dec 2001 15:36:47 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: <4103264BC8D3D51180B7002048400C45071390@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20011204153429.01cbbe40@dingdong.cisco.com> --=====================_104902642==_.ALT Content-Type: text/plain; charset="us-ascii" Implementations are required to send ISHs by RFC 1195 and ISO 10589. Therefore, wouldn't it be wise for the draft to accommodate this requirement? (Regardless of the fact that many (most?) implementations don't do it.) Jeff At 02:53 PM 12/4/2001, Philip Christian wrote: >I absolutely do not agree. >I said that it is acceptable for a pure IP implementation to ignore ISH, and so these "current vendors implementations" need not have a problem with it. > >We can even say this in the RFC, so for the first time ever, it will say in an RFC "you can ignore ISH". I would have thought that this would be good news for the implementations that you mention. > >However the draft is useless for routers that do need to terminate CLNS packets, and is therefore useless for sorting out the SONET protection switching events that it claims to help. > >Do we want RFCs that do not acheive what they claim to? >We can sort out one without affecting the other, and therefore should do so. > >By the way, the draft has expired, but people can still read it at >http://www.watersprings.org/pub/id/draft-ietf-isis-3way-03.txt > >Philip Christian > >-----Original Message----- >From: Naiming Shen [mailto:naiming@redback.com] >Sent: 04 December 2001 19:42 >To: Tony Li >Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; >'dkatz@juniper.net'; Saluja, Rajesh [BL60:432:EXCH] >Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > >this draft reflects many vendors current implementation for the ip >routers, we should let this to go through to become an rfc(informational). >any need for ish probably should submit a seperate one, maybe a big >one to handle all other clns cases where the ip portion has already >advanced. > > ] > ] | This draft specifically declares itself to be useful in SONET networks > ] | (presumably in the embedded DCC channels, although this is not stated). > ] > ] > ]Actually, most of the IP routers running IS-IS do so over POS links, and > ]thus, IS-IS is running in-band. > ] > ]I agree with your comments. Other opinions? > ] > ]Tony > ] > ]_______________________________________________ > ]Isis-wg mailing list - Isis-wg@external.juniper.net > ]http://external.juniper.net/mailman/listinfo/isis-wg > >- Naiming --=====================_104902642==_.ALT Content-Type: text/html; charset="us-ascii"
Implementations are required to send ISHs by RFC 1195 and ISO 10589.
Therefore, wouldn't it be wise for the draft to accommodate this
requirement?  (Regardless of the fact that many (most?) implementations
don't do it.)

Jeff


At 02:53 PM 12/4/2001, Philip Christian wrote:

I absolutely do not agree.
I said that it is acceptable for a pure IP implementation to ignore ISH, and so these "current vendors implementations" need not have a problem with it.

We can even say this in the RFC, so for the first time ever, it will say in an RFC "you can ignore ISH". I would have thought that this would be good news for the implementations that you mention.

However the draft is useless for routers that do need to terminate CLNS packets, and is therefore useless for sorting out the SONET protection switching events that it claims to help.

Do we want RFCs that do not acheive what they claim to?
We can sort out one without affecting the other, and therefore should do so.

By the way, the draft has expired, but people can still read it at
http://www.watersprings.org/pub/id/draft-ietf-isis-3way-03.txt

Philip Christian

-----Original Message-----
From: Naiming Shen [mailto:naiming@redback.com]
Sent: 04 December 2001 19:42
To: Tony Li
Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net';
'dkatz@juniper.net'; Saluja, Rajesh [BL60:432:EXCH]
Subject: Re: [Isis-wg] Concerns with 3-way-handshake


this draft reflects many vendors current implementation for the ip
routers, we should let this to go through to become an rfc(informational).
any need for ish probably should submit a seperate one, maybe a big
one to handle all other clns cases where the ip portion has already
advanced.

 ]
 ] | This draft specifically declares itself to be useful in SONET networks
 ] | (presumably in the embedded DCC channels, although this is not stated).
 ]
 ]
 ]Actually, most of the IP routers running IS-IS do so over POS links, and
 ]thus, IS-IS is running in-band.
 ]
 ]I agree with your comments.  Other opinions?
 ]
 ]Tony
 ]
 ]_______________________________________________
 ]Isis-wg mailing list  -  Isis-wg@external.juniper.net
 ]http://external.juniper.net/mailman/listinfo/isis-wg

- Naiming
--=====================_104902642==_.ALT-- From ginsberg@pluris.com Tue Dec 4 21:00:47 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Tue, 4 Dec 2001 13:00:47 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F625@avalon.pluris.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_01C17D06.BF367EE0 Content-Type: text/plain; charset="iso-8859-1" The problem has nothing to do with ISHs, but rather with the clarity of the presentation of the draft and some legacy issues from older versions of the 3 way handshake. Philip states: >A is connected to B and issues an ISH. >B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". >B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". >A receives this and according to the table in the draft, brings the adjacency "up". >However B may never have received an IIH from A and so the three way handshake has been short circuited, or have >I misunderstood something? The draft states: "If the option is present, the Neighbor System ID and Neighbor Extended Local Circuit ID fields, if present, shall be examined. If they are present, and the system ID contained therein does not match the local system's ID, or the extended circuit ID does not match the local system's extended circuit ID, the PDU shall be discarded and no further action is taken. If the Neighbor System ID and Neighbor Extended Local Circuit ID fields match those of the local system, or are not present, the procedures described in section 8.2.4.2 are followed ..." A router which supports the latest version of the draft could either omit sending the neighbor's system ID/extended local circuit ID in the 3 way TLV when it doesn't know what they are or send them as all 0's (hopefully no one allows a system ID to be set to all 0's ???) . If the sending system sends all 0's the above rule works. But if the sending system is allowed to omit the neighbor system ID/circuit ID, then for proper operation the rules above have to be modified to indicate that if either the neighbor system ID or neighbor circuit id fields are not present then no adjacency state change should take place. This modification is not quite enough, however, because an older version of the 3 way handshake specified a TLV which only included the local adjacency state. Therefore, a robust implementation has to recognize that the presence of the 3way TLV with only the local adjacency state in a received IIH indicates a system which will never echo the neighbor system-id/circuit id and so it cannot look for a match in these non-existent fields and must resort to the revised state table solely based on the local/remote adjacency state. This legacy usage of the option can encounter the problem outlined by Philip, which results in behavior no different than that which occurs in the absence of the 3 way TLV. Reception of an ISH indicates that the neighbor is NOT an OSI End System and therefore that it is useful to send IIHs on this link. In an IP world, this requirement is less useful and some implementations, whether intentionally or not, have omitted sending ISHs. In the strictest sense this is a violation of ISO 10589, but is workable and in the spirit of "being generous in what you receive" some implementations allow this, which requires that the receiver start sending IIH PDUs on receipt of an IIH PDU ( as well as on a receipt of an ISH). It probably would be better if the draft was updated to discuss the proper behavior when dealing with legacy 3 way implementations and what is the expected behavior when neighbor system ID/extended circuit ID are omitted. In any event, don't blame ISHs. Les -----Original Message----- From: Philip Christian [mailto:christi@nortelnetworks.com] Sent: Tuesday, December 04, 2001 9:34 AM To: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net'; 'rsaluja@nortelnetworks.com' Subject: [Isis-wg] Concerns with 3-way-handshake I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17D06.BF367EE0 Content-Type: text/html; charset="iso-8859-1" Concerns with 3-way-handshake
The problem has nothing to do with ISHs, but rather with the clarity of the presentation of the draft and some legacy issues from older versions of the 3 way handshake.
 
Philip states:
>A is connected to B and issues an ISH. 
>B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". 
>B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". 
>A receives this and according to the table in the draft, brings the adjacency "up". 
>However B may never have received an IIH from A and so the three way handshake has been short circuited, or have >I misunderstood something?
 
The draft states:

    "If the option is present, the Neighbor System ID and Neighbor
     Extended Local Circuit ID fields, if present, shall be examined.
     If they are present, and the system ID contained therein does not
     match the local system's ID, or the extended circuit ID does not
     match the local system's extended circuit ID, the PDU shall be
     discarded and no further action is taken.

     If the Neighbor System ID and Neighbor Extended Local Circuit ID
     fields match those of the local system, or are not present, the
     procedures described in section 8.2.4.2 are followed ..."

A router which supports the latest version of the draft could either omit sending the neighbor's system ID/extended local circuit ID  in the 3 way TLV when it doesn't know  what they are or send them as all 0's (hopefully no one allows a system ID to be set to all 0's ???) . If the sending system sends all 0's the above rule works. But if the sending system is allowed to omit the neighbor system ID/circuit ID, then for proper operation the rules above have to be modified to indicate that if either the neighbor system ID or neighbor circuit id fields are not present then no adjacency state change should take place.

This modification is not quite enough, however, because an older version of the 3 way handshake specified a TLV which only included the local adjacency state. Therefore, a robust implementation has to recognize that the presence of the 3way TLV with only the local adjacency state in a received IIH indicates a system which will never echo the neighbor system-id/circuit id and so it cannot look for a match in these non-existent fields and must resort to the revised state table solely based on the local/remote adjacency state. This legacy usage of the option can encounter the problem outlined by Philip, which results in behavior no different than that which occurs in the absence of the 3 way TLV.

Reception of an ISH indicates that the neighbor is NOT an OSI End System and therefore that it is useful to send IIHs on this link. In an IP world, this requirement is less useful and some implementations, whether intentionally or not, have omitted sending ISHs. In the strictest sense this is a violation of ISO 10589, but is workable and in the spirit of "being generous in what you receive" some implementations allow this, which requires that the receiver start sending IIH PDUs on receipt of an IIH PDU ( as well as on a receipt of an ISH).

It probably would be better if the draft was updated to discuss the proper behavior when dealing with legacy 3 way implementations and what is the expected behavior when neighbor system ID/extended circuit ID are omitted.

In any event, don't blame ISHs.

  Les

 

 

 -----Original Message-----
From: Philip Christian [mailto:christi@nortelnetworks.com]
Sent: Tuesday, December 04, 2001 9:34 AM
To: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net'; 'rsaluja@nortelnetworks.com'
Subject: [Isis-wg] Concerns with 3-way-handshake

I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received  IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising".
B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising".
A receives this and according to the table in the draft, brings the adjacency "up".
However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something?

The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore.

This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17D06.BF367EE0-- From christi@nortelnetworks.com Tue Dec 4 21:15:47 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 21:15:47 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071392@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_01C17D08.D7B183F0 Content-Type: text/plain; charset="iso-8859-1" okay, I can see that. But why does it talk about "SONET protection" rather than reprovisioning ? Philip Christian For channelized SONET, reprovisioning could cause the VT to be terminated at a different remote system. Since the link layer protocol is unreliable and does not detect the fact that it is now connected to a different system, the 3-way handshake is required. Jeff ------_=_NextPart_001_01C17D08.D7B183F0 Content-Type: text/html; charset="iso-8859-1"
okay, I can see that. But why does it talk about "SONET protection" rather than reprovisioning ?
 
Philip Christian
 
 For channelized SONET, reprovisioning could cause the VT to be terminated
at a different remote system.  Since the link layer protocol is unreliable
and does not detect the fact that it is now connected to a different system,
the 3-way handshake is required.

Jeff
 
------_=_NextPart_001_01C17D08.D7B183F0-- From prz@redback.com Wed Dec 5 00:35:19 2001 From: prz@redback.com (Tony Przygienda) Date: Tue, 04 Dec 2001 16:35:19 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> <3C0D6B51.7EBB951D@nortelnetworks.com> Message-ID: <3C0D6BC7.B54EBFDF@redback.com> Rajesh Saluja wrote: > > > > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > > three-way-hello capable routers drop ISHs and do not send them ? The > > very details of 1195 slip my mind right now but that should not cause > > any backwards capability problems? > > > > something is definitely worth an addition to the 3-way-hello draft > > > > -- tony > > I agree with Philip's concerns. Will the following modifications be > acceptable to the group: > 1. As Tony suggested, say that three-way-hello capable routers drop ISHs > and do not send them. you better be very carefull with the MUST and MAYs when writing this. As well, someone thinks carefully whether it won't break more than it fixes (although deployment with dropped ISHs seems to prove that it works and since we will be able to chhose whether we send/receive them, we can force pretty much this situation with the draft). thanks -- tonyt From aridaman kaushik" I have gone through rfc 2966. This is related L2to L1 leaking(L2 down). It does not talk about L1 down.In draft draft-ietf-isis-ipv6-02.txt section #3 1. if a prefix is redistributed from an area to another area at the same level then the up/down bit shall be set to one. What is meaning of it. as there is no redistribution of routes from one area to another area. Routes are learned through L2 routing only. 2. in the next sentance, if the prefix was distributed into isis form another routing protocol, the external bit shall be set to one. This information is useful while distributing routes from is-is other protocols. I am not getting how it is useful. Please Confirm This. 3. when ipv6 routes will be leaked from L2 to l1. How should these routes should be distributed, my mean to say, as external reachiablity information or internal reachiablity information. if it is to be sent as external reachiability information, then external bit the ipv6 prefix TLV should be set to one. But in draft, while leaking routes from L2 to L1, set up/down bit to one. External bit is set only when route is being redisributed from other routing protocol. So leaked route from L2 to L1 should be sent as internal reachiablity information. thanks in advance From ginsberg@pluris.com Wed Dec 5 06:03:05 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Tue, 4 Dec 2001 22:03:05 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F627@avalon.pluris.com> Sorry folks - but IMHO you are focusing on the wrong issue. The problem is not ISHs, but some ambiguity in the current definition of the 3way draft and the fact that a number of vendors still utilize the old version of the 3 way handshake which only sends local adjacency state. (Please see my earlier mail on this subject) Suggesting that ISHs be ignored just creates more potential backwards compatibility problems and ignores the real cause of the problem. That doesn't make sense to me. (The fact that some implementations already do not send ISHs has created compatibility problems in that implementations in strict conformance to ISO 10589 will not interoperate with these implementations i.e. an implementation which expects to receive an ISH before sending an IIH (as per ISO 10589) will never form an adjacency with an implementation that never sends an ISH.) Les > -----Original Message----- > From: Tony Przygienda [mailto:prz@redback.com] > Sent: Tuesday, December 04, 2001 4:35 PM > To: Rajesh Saluja > Cc: Philip Christian; 'isis-wg@spider.juniper.net'; > 'dkatz@juniper.net' > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > Rajesh Saluja wrote: > > > > > > > > > > >From my vintage, yes, it should be fixed, maybe as > simply as saying that > > > three-way-hello capable routers drop ISHs and do not send > them ? The > > > very details of 1195 slip my mind right now but that > should not cause > > > any backwards capability problems? > > > > > > something is definitely worth an addition to the > 3-way-hello draft > > > > > > -- tony > > > > I agree with Philip's concerns. Will the following modifications be > > acceptable to the group: > > 1. As Tony suggested, say that three-way-hello capable > routers drop ISHs > > and do not send them. > > you better be very carefull with the MUST and MAYs when > writing this. As well, > someone thinks carefully whether it won't break more than it > fixes (although > deployment with dropped ISHs seems to prove that it works and > since we will > be able to chhose whether we send/receive them, we can force > pretty much > this situation with the draft). > > thanks > > -- tonyt > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From dkatz@juniper.net Wed Dec 5 06:10:37 2001 From: dkatz@juniper.net (Dave Katz) Date: Tue, 4 Dec 2001 22:10:37 -0800 (PST) Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: <3C0D6B51.7EBB951D@nortelnetworks.com> (rsaluja@nortelnetworks.com) References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> <3C0D6B51.7EBB951D@nortelnetworks.com> Message-ID: <200112050610.fB56Ab507507@cirrus.juniper.net> 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. Sounds reasonable. 2. Reword SONET protection to SONET reprovisioning. This is *not* what was intended when the draft was written. SONET purists will choke on their Cheerios when they read this, but several router vendors have implemented a scheme where two routers act together as a SONET ADM for the purposes of implementing Automatic Protection Switching (APS.) The idea is that the trunk circuit comes into a POP, hits an ADM, and out the other side come the APS Working and Protect circuits, which then go into different routers. This is primarily viewed as a way of protecting against router/interface failure or somebody tripping over the last 100 feet of fiber, while keeping the expensive trunk circuit operating. The routers coordinate via a back channel to instigate and react to APS signalling (via the K1/K2 overhead bytes.) In 1+1 Bidirectional mode, the ADM will send the same bit stream to both routers, but only listen to one of them. Without the addition of the ID stuff, it is theoretically possible that the router on the circuit not selected by the ADM can think that it has an adjacency to the guy at the far end of the trunk, which would cause traffic to be poured down a black hole. Frankly, I think this bastardization of APS is of dubious use, but the customers were willing to pay real cash money for it, so I wrote the APS code. However, it became apparent that a sane (if that's a reasonable word to use in this context) implementation will logically shut down the interface based on APS signalling anyhow, so this detection mechanism is probably redundant, unless folks have come up with something else that it is good for. In any case, this is *not* about DCC, and it is *not* about SONET provisioning, it's about terminating APS protection on routers running ISIS in-band over the SONET circuit. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. Sure. --Dave BTW, for what it's worth, the dominant CLNP router in the world did not couple ISHs to ISIS at all when I last saw the source code (five years ago) and probably still doesn't today. It is just as happy to bring up an ISIS adjacency based on receipt of only an IIH when operating in CLNP mode as it is in IP mode. Doesn't make it right, but there it is. From tli@Procket.com Wed Dec 5 08:36:01 2001 From: tli@Procket.com (Tony Li) Date: Wed, 5 Dec 2001 00:36:01 -0800 Subject: [Isis-wg] isis route preference In-Reply-To: <20011205043828.2677.qmail@mailweb12.rediffmail.com> References: <20011205043828.2677.qmail@mailweb12.rediffmail.com> Message-ID: <15373.56433.93331.6355@alpha-tli.procket.com> | I have gone through rfc 2966. This is related L2to L1 leaking(L2 | down). It does not talk about L1 down.In draft | draft-ietf-isis-ipv6-02.txt section #3 | | 1. if a prefix is redistributed from an area to another area at the same | level then the up/down bit shall be set to one. | | What is meaning of it. as there is no redistribution of routes from one | area to another area. Routes are learned through L2 routing only. Certain implementations allow a router to participate in multiple different L1 areas and interchange routes between the different L1 areas. Clearly this is way past the spirit of ISO 10589, but is also not impossible. It seems like a reasonable condition to add. | 2. in the next sentance, | if the prefix was distributed into isis form another routing protocol, | the external bit shall be set to one. This information is useful while | distributing routes from is-is other protocols. I am not getting how it | is useful. An obvious benefit is the ability to subsequently write policy about those external routes when injecting routes from IS-IS into another routing protocol. Example: suppose that I have a domain that is routed with both IS-IS and OSPF [possibly as the result of an acquistion]. As a migration aid, I wish to interconnect the domain at multiple points yet not convert to one or the other IGP in a flash manner. If I leak OSPF non-externals into IS-IS and mark them external and then I leak IS-IS non-externals into OSPF, I have full connectivity without a feedback loop. | Please Confirm This. 3. when ipv6 routes will be leaked from L2 to | l1. How should these routes should be distributed, my mean to say, as | external reachiablity information or internal reachiablity information. It's still internal. Tony From mshand@cisco.com Wed Dec 5 09:50:27 2001 From: mshand@cisco.com (mike shand) Date: Wed, 05 Dec 2001 09:50:27 +0000 Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20011205094706.033305f8@jaws.cisco.com> At 17:34 04/12/2001 +0000, Philip Christian wrote:
Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example.

I don't understand what you mean here. Sending ISHs has nothing to do with being an ES, and it is CERTAINLY not necessary to declare itself an ES in order to terminate CLNP packets. An IS can do that just as well. The only reason an IS sends ISHs over a pt-pt link is in case the system at thew other end happens to be an ES (only). Becuasre it has to do this, the ISH sending is integrated into the IIH initialization sequence.

        Mike
 From christi@nortelnetworks.com Wed Dec 5 10:00:25 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Wed, 5 Dec 2001 10:00:25 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071395@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_01C17D73.A8EAB670 Content-Type: text/plain; charset="iso-8859-1" Yes, I got this wrong. I believe that the ISHs are there so that an IS can say hello to an ES. Thus an CLNP capable router needs to send ISHs to talk to an CLNS End System, but a pure IP router maybe does not. However the ISHs still have to be there if one wants to build a dual router, and I still believe that they short circuit the 3-way-handshake (as if it isn't there) as it is in its current form. thanks, Philip -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: 05 December 2001 09:50 To: Christian, Philip [HAL02:GI50:EXCH] Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net'; Saluja, Rajesh [BL60:432:EXCH] Subject: Re: [Isis-wg] Concerns with 3-way-handshake At 17:34 04/12/2001 +0000, Philip Christian wrote: Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. I don't understand what you mean here. Sending ISHs has nothing to do with being an ES, and it is CERTAINLY not necessary to declare itself an ES in order to terminate CLNP packets. An IS can do that just as well. The only reason an IS sends ISHs over a pt-pt link is in case the system at thew other end happens to be an ES (only). Becuasre it has to do this, the ISH sending is integrated into the IIH initialization sequence. Mike ------_=_NextPart_001_01C17D73.A8EAB670 Content-Type: text/html; charset="iso-8859-1"
Yes, I got this wrong. I believe that the ISHs are there so that an IS can say hello to an ES. Thus an CLNP capable router needs to send ISHs to talk to an CLNS End System, but a pure IP router maybe does not.
 
However the ISHs still have to be there if one wants to build a dual router, and I still believe that they short circuit the 3-way-handshake (as if it isn't there) as it is in its current form.
 
thanks, Philip
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: 05 December 2001 09:50
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net'; Saluja, Rajesh [BL60:432:EXCH]
Subject: Re: [Isis-wg] Concerns with 3-way-handshake

At 17:34 04/12/2001 +0000, Philip Christian wrote:
Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example.

I don't understand what you mean here. Sending ISHs has nothing to do with being an ES, and it is CERTAINLY not necessary to declare itself an ES in order to terminate CLNP packets. An IS can do that just as well. The only reason an IS sends ISHs over a pt-pt link is in case the system at thew other end happens to be an ES (only). Becuasre it has to do this, the ISH sending is integrated into the IIH initialization sequence.

        Mike
------_=_NextPart_001_01C17D73.A8EAB670-- From christi@nortelnetworks.com Wed Dec 5 10:51:23 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Wed, 5 Dec 2001 10:51:23 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071396@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_01C17D7A.C7C1E620 Content-Type: text/plain; charset="ISO-8859-1" I (and a colleague, credit where it's due) can think of a couple of ways to solve this problem. First we could add an explicit statement such as "Sending and receiving ISHs is required by Intermediate Systems that can route CLNP packets. Intermediate Systems that cannot route CLNP may or may not send and receive ISHs." Now here are the two ideas 1. On Intermediate Systems where receipt of an ISH causes an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State "Down". Once an IIH has been received then the state of the adjacency shall be reported in the option as normal. or 2. On Intermediate Systems where receipt of an ISH caused an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State 3 = "ISH_init" (for example). Intermediate Systems that do not send and receive ISHs are not required to implement reporting of this state, as they will neither send it, nor cause a neighbour to send it back to them. We then have to mess with the table a little, basically saying that if you support ISHs and receive an "ISH_init" then you go to "Initialise" (rather than "up", which was the problem). I think that both of these ideas allow routers that support CLNP forwarding to also use the 3-way-handshake, without upsetting anyone who has already stopped using ISHs on their pure IP implementations. I prefer idea "2", as "1" feels like the IS is misreporting the state, and just doesn't appeal to my sense of correctness so well. The problem with "2" is that if you send an ISH to an IS, then you can expect it to send back this new Adjacency State = 3 ="ISH_init" message back. Now it seems to me that if someone just dumps incoming ISHs then they shouldn't be trasmitting them either, but if someone HAS implemented that, then they are going to get "3=ISH_init"s coming back at them and won't know what to do with them (maybe that doesn't matter anyway, as long as they don't bring the adjacency up). Comments? other ideas? Philip Christian -----Original Message----- From: Les Ginsberg [mailto:ginsberg@pluris.com] Sent: 05 December 2001 06:03 To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH] Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net' Subject: RE: [Isis-wg] Concerns with 3-way-handshake Sorry folks - but IMHO you are focusing on the wrong issue. The problem is not ISHs, but some ambiguity in the current definition of the 3way draft and the fact that a number of vendors still utilize the old version of the 3 way handshake which only sends local adjacency state. (Please see my earlier mail on this subject) Suggesting that ISHs be ignored just creates more potential backwards compatibility problems and ignores the real cause of the problem. That doesn't make sense to me. (The fact that some implementations already do not send ISHs has created compatibility problems in that implementations in strict conformance to ISO 10589 will not interoperate with these implementations i.e. an implementation which expects to receive an ISH before sending an IIH (as per ISO 10589) will never form an adjacency with an implementation that never sends an ISH.) Les > -----Original Message----- > From: Tony Przygienda [mailto:prz@redback.com] > Sent: Tuesday, December 04, 2001 4:35 PM > To: Rajesh Saluja > Cc: Philip Christian; 'isis-wg@spider.juniper.net'; > 'dkatz@juniper.net' > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > Rajesh Saluja wrote: > > > > > > > > > > >From my vintage, yes, it should be fixed, maybe as > simply as saying that > > > three-way-hello capable routers drop ISHs and do not send > them ? The > > > very details of 1195 slip my mind right now but that > should not cause > > > any backwards capability problems? > > > > > > something is definitely worth an addition to the > 3-way-hello draft > > > > > > -- tony > > > > I agree with Philip's concerns. Will the following modifications be > > acceptable to the group: > > 1. As Tony suggested, say that three-way-hello capable > routers drop ISHs > > and do not send them. > > you better be very carefull with the MUST and MAYs when > writing this. As well, > someone thinks carefully whether it won't break more than it > fixes (although > deployment with dropped ISHs seems to prove that it works and > since we will > be able to chhose whether we send/receive them, we can force > pretty much > this situation with the draft). > > thanks > > -- tonyt > > _______________________________________________ > 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_01C17D7A.C7C1E620 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Concerns with 3-way-handshake

I (and a colleague, credit where it's due) can think = of a couple of ways to solve this problem.
First we could add an explicit statement such = as

"Sending and receiving ISHs is required by = Intermediate Systems that can route CLNP packets. Intermediate Systems = that cannot route CLNP may or may not send and receive = ISHs."

Now here are the two ideas

1.
On Intermediate Systems where receipt of an ISH = causes an adjacency to start in the "initialise" state, and = which support the "Point-to-Point Adjacency State" option, = such an adjacency will be reported in the option as being Adjacency = State "Down". Once an IIH has been received then the state of = the adjacency shall be reported in the option as normal.

or

2.
On Intermediate Systems where receipt of an ISH = caused an adjacency to start in the "initialise" state, and = which support the "Point-to-Point Adjacency State" option, = such an adjacency will be reported in the option as being Adjacency = State 3 =3D "ISH_init" (for example). Intermediate Systems = that do not send and receive ISHs are not required to implement = reporting of this state, as they will neither send it, nor cause a = neighbour to send it back to them. We then have to mess with the table = a little, basically saying that if you support ISHs and receive an = "ISH_init" then you go to "Initialise" (rather than = "up", which was the problem).

I think that both of these ideas allow routers that = support CLNP forwarding to also use the 3-way-handshake, without = upsetting anyone who has already stopped using ISHs on their pure IP = implementations.

I prefer idea "2", as "1" feels = like the IS is misreporting the state, and just doesn't appeal to my = sense of correctness so well.

The problem with "2" is that if you send an = ISH to an IS, then you can expect it to send back this new Adjacency = State =3D 3 =3D"ISH_init" message back. Now it seems to me = that if someone just dumps incoming ISHs then they shouldn't be = trasmitting them either, but if someone HAS implemented that, then they = are going to get "3=3DISH_init"s coming back at them and = won't know what to do with them (maybe that doesn't matter anyway, as = long as they don't bring the adjacency up).

Comments? other ideas?

Philip Christian

-----Original Message-----
From: Les Ginsberg [mailto:ginsberg@pluris.com]
Sent: 05 December 2001 06:03
To: 'Tony Przygienda'; Saluja, Rajesh = [BL60:432:EXCH]
Cc: Christian, Philip [HAL02:GI50:EXCH]; = 'isis-wg@spider.juniper.net';
'dkatz@juniper.net'
Subject: RE: [Isis-wg] Concerns with = 3-way-handshake


Sorry folks - but IMHO you are focusing on the wrong = issue. The problem is
not ISHs, but some ambiguity in the current = definition of the 3way draft and
the fact that a number of vendors still utilize the = old version of the 3 way
handshake which only sends local adjacency state. = (Please see my earlier
mail on this subject)

Suggesting that ISHs be ignored just creates more = potential backwards
compatibility problems and ignores the real cause of = the problem. That
doesn't make sense to me.

(The fact that some implementations already do not = send ISHs has created
compatibility problems in that implementations in = strict conformance to ISO
10589 will not interoperate with these = implementations i.e. an
implementation which expects to receive an ISH = before sending an IIH (as per
ISO 10589) will never form an adjacency with an = implementation that never
sends an ISH.)

   Les


> -----Original Message-----
> From: Tony Przygienda [mailto:prz@redback.com]
> Sent: Tuesday, December 04, 2001 4:35 PM
> To: Rajesh Saluja
> Cc: Philip Christian; = 'isis-wg@spider.juniper.net';
> 'dkatz@juniper.net'
> Subject: Re: [Isis-wg] Concerns with = 3-way-handshake
>
>
> Rajesh Saluja wrote:
>
> > >
> > >
> > > >From my vintage, yes, it should = be fixed, maybe as
> simply as saying that
> > > three-way-hello capable routers drop = ISHs and do not send
> them ?  The
> > > very details of 1195 slip my mind = right now but that
> should not cause
> > > any backwards capability = problems?
> > >
> > >     something is = definitely worth an addition to the
> 3-way-hello draft
> > >
> > >     -- = tony
> >
> > I agree with Philip's concerns. Will the = following modifications be
> > acceptable to the group:
> > 1. As Tony suggested, say that  = three-way-hello capable
> routers drop ISHs
> > and do not send them.
>
> you better be very carefull with the MUST and = MAYs when
> writing this. As well,
> someone thinks carefully whether it won't break = more than it
> fixes (although
> deployment with dropped ISHs seems to prove = that it works and
> since we will
>  be able to chhose whether we send/receive = them, we can force
> pretty much
> this situation with the draft).
>
>     thanks
>
>     -- tonyt
>
> = _______________________________________________
> 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_01C17D7A.C7C1E620-- From perumal conf" Hi all I am unable to get the description and usage of "external overload signalling" IS-IS command. Any information about this would be helpful to me. Thanks in advance for your response per From jparker@axiowave.com Wed Dec 5 15:57:56 2001 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 5 Dec 2001 10:57:56 -0500 Subject: [Isis-wg] (no subject) Message-ID: > hi Jeff, > I have gone through rfc 2966. This is related L2to L1 leaking(L2 > down). It does not talk about L1 down.In draft > draft-ietf-isis-ipv6-02.txt section #3 > > 1. if a prefix is redistributed from an area to another area > at the same level then the up/down bit shall be set to one. Isn't an L1 down a route that has been up to L2 and back? > What is meaning of it. as there is no redistribution of > routes from one area > to another area. Routes are learned through L2 routing only. If they are leaked from L1 to L2 back down to L1, then it is a different L1 area, as there would be no point in returning it to the same area. > 2. in the next sentance, > if the prefix was distributed into isis form another routing > protocol, the > external bit shall be set to one. This information is useful while > distributing routes from is-is other protocols. > I am not getting how it is useful. As routes slosh around from say BGP to IS-IS, information is lost, esp. if you are sticking with 1195 metrics. This bit could be used, if you trusted it, to let you know that you are exporting a genuine copy of a distorted metric, and to make adjustments accordingly: perhaps deciding not to use the route if there was anything the looked more plausible. Mark Twain wrote a version of the "Jumping Frog of Calaveras County" that was a translation of a French translation of his story. I found it funnier than the original. While much is lost in translation, even more is lost in a second translation. - jeff parker - axiowave networks From jlearman@cisco.com Wed Dec 5 16:17:10 2001 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 05 Dec 2001 11:17:10 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: <4103264BC8D3D51180B7002048400C45071396@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20011205110907.01f0def8@dingdong.cisco.com> --=====================_4939202==_.ALT Content-Type: text/plain; charset="us-ascii" At 05:51 AM 12/5/2001, Philip Christian wrote: >I (and a colleague, credit where it's due) can think of a couple of ways to solve this problem. >First we could add an explicit statement such as > >"Sending and receiving ISHs is required by Intermediate Systems that can route CLNP packets. Intermediate Systems that cannot route CLNP may or may not send and receive ISHs." Is this intended as a statement of fact or as a proposed normative statement? If it's supposed to be normative, use SHOULD, MAY, and MUST. If it's descriptive of standards, it's inaccurate, because 10589 and 1195 both require sending ISH PDUs. If it's a statement of practical fact, then it should be carefully written to state that -- e.g., "Practically speaking, ISs that support CLNP need to send ISH packets on point-to-point links that might be connected to ESs in order for CLNP ESs to be able to communicate properly. Many existing IP-only implementations fail to send ISH PDUs, even though it's required by 10589 and RFC-1195, and most (many?) IS-IS implementations interoperate with these implementations. We need to be clear and accurate! If I've made any inaccurate statements here, please point them out. Statements below are also not written using MUST, MAY, or SHOULD, and need to be rewritten to say what the author means, because as written, they can be misinterpreted as descriptive statements rather than normative statements, which I assume they're intended to be. Regards, Jeff >Now here are the two ideas > >1. >On Intermediate Systems where receipt of an ISH causes an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State "Down". Once an IIH has been received then the state of the adjacency shall be reported in the option as normal. > >or > >2. >On Intermediate Systems where receipt of an ISH caused an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State 3 = "ISH_init" (for example). Intermediate Systems that do not send and receive ISHs are not required to implement reporting of this state, as they will neither send it, nor cause a neighbour to send it back to them. We then have to mess with the table a little, basically saying that if you support ISHs and receive an "ISH_init" then you go to "Initialise" (rather than "up", which was the problem). > >I think that both of these ideas allow routers that support CLNP forwarding to also use the 3-way-handshake, without upsetting anyone who has already stopped using ISHs on their pure IP implementations. > >I prefer idea "2", as "1" feels like the IS is misreporting the state, and just doesn't appeal to my sense of correctness so well. > >The problem with "2" is that if you send an ISH to an IS, then you can expect it to send back this new Adjacency State = 3 ="ISH_init" message back. Now it seems to me that if someone just dumps incoming ISHs then they shouldn't be trasmitting them either, but if someone HAS implemented that, then they are going to get "3=ISH_init"s coming back at them and won't know what to do with them (maybe that doesn't matter anyway, as long as they don't bring the adjacency up). > >Comments? other ideas? > >Philip Christian > >-----Original Message----- >From: Les Ginsberg [mailto:ginsberg@pluris.com] >Sent: 05 December 2001 06:03 >To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH] >Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; >'dkatz@juniper.net' >Subject: RE: [Isis-wg] Concerns with 3-way-handshake > >Sorry folks - but IMHO you are focusing on the wrong issue. The problem is >not ISHs, but some ambiguity in the current definition of the 3way draft and >the fact that a number of vendors still utilize the old version of the 3 way >handshake which only sends local adjacency state. (Please see my earlier >mail on this subject) > >Suggesting that ISHs be ignored just creates more potential backwards >compatibility problems and ignores the real cause of the problem. That >doesn't make sense to me. > >(The fact that some implementations already do not send ISHs has created >compatibility problems in that implementations in strict conformance to ISO >10589 will not interoperate with these implementations i.e. an >implementation which expects to receive an ISH before sending an IIH (as per >ISO 10589) will never form an adjacency with an implementation that never >sends an ISH.) > > Les > >> -----Original Message----- >> From: Tony Przygienda [mailto:prz@redback.com] >> Sent: Tuesday, December 04, 2001 4:35 PM >> To: Rajesh Saluja >> Cc: Philip Christian; 'isis-wg@spider.juniper.net'; >> 'dkatz@juniper.net' >> Subject: Re: [Isis-wg] Concerns with 3-way-handshake >> >> >> Rajesh Saluja wrote: >> >> > > >> > > >> > > >From my vintage, yes, it should be fixed, maybe as >> simply as saying that >> > > three-way-hello capable routers drop ISHs and do not send >> them ? The >> > > very details of 1195 slip my mind right now but that >> should not cause >> > > any backwards capability problems? >> > > >> > > something is definitely worth an addition to the >> 3-way-hello draft >> > > >> > > -- tony >> > >> > I agree with Philip's concerns. Will the following modifications be >> > acceptable to the group: >> > 1. As Tony suggested, say that three-way-hello capable >> routers drop ISHs >> > and do not send them. >> >> you better be very carefull with the MUST and MAYs when >> writing this. As well, >> someone thinks carefully whether it won't break more than it >> fixes (although >> deployment with dropped ISHs seems to prove that it works and >> since we will >> be able to chhose whether we send/receive them, we can force >> pretty much >> this situation with the draft). >> >> thanks >> >> -- tonyt >> >> _______________________________________________ >> 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 --=====================_4939202==_.ALT Content-Type: text/html; charset="us-ascii" At 05:51 AM 12/5/2001, Philip Christian wrote:

I (and a colleague, credit where it's due) can think of a couple of ways to solve this problem.
First we could add an explicit statement such as

"Sending and receiving ISHs is required by Intermediate Systems that can route CLNP packets. Intermediate Systems that cannot route CLNP may or may not send and receive ISHs."

Is this intended as a statement of fact or as a proposed normative
statement?  If it's supposed to be normative, use SHOULD, MAY, and MUST.
If it's descriptive of standards, it's inaccurate, because 10589
and 1195 both require sending ISH PDUs.  If it's a statement of
practical fact, then it should be carefully written to state that --
e.g.,

  "Practically speaking, ISs that support CLNP need to send ISH
  packets on point-to-point links that might be connected to ESs in
  order for CLNP ESs to be able to communicate properly.  Many existing
  IP-only implementations fail to send ISH PDUs, even though it's required
  by 10589 and RFC-1195, and most (many?) IS-IS implementations interoperate
  with these implementations.

We need to be clear and accurate!  If I've made any inaccurate statements
here, please point them out.

Statements below are also not written using MUST, MAY, or SHOULD, and
need to be rewritten to say what the author means, because as written,
they can be misinterpreted as descriptive statements rather than
normative statements, which I assume they're intended to be.

Regards,
Jeff


Now here are the two ideas

1.
On Intermediate Systems where receipt of an ISH causes an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State "Down". Once an IIH has been received then the state of the adjacency shall be reported in the option as normal.

or

2.
On Intermediate Systems where receipt of an ISH caused an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State 3 = "ISH_init" (for example). Intermediate Systems that do not send and receive ISHs are not required to implement reporting of this state, as they will neither send it, nor cause a neighbour to send it back to them. We then have to mess with the table a little, basically saying that if you support ISHs and receive an "ISH_init" then you go to "Initialise" (rather than "up", which was the problem).

I think that both of these ideas allow routers that support CLNP forwarding to also use the 3-way-handshake, without upsetting anyone who has already stopped using ISHs on their pure IP implementations.

I prefer idea "2", as "1" feels like the IS is misreporting the state, and just doesn't appeal to my sense of correctness so well.

The problem with "2" is that if you send an ISH to an IS, then you can expect it to send back this new Adjacency State = 3 ="ISH_init" message back. Now it seems to me that if someone just dumps incoming ISHs then they shouldn't be trasmitting them either, but if someone HAS implemented that, then they are going to get "3=ISH_init"s coming back at them and won't know what to do with them (maybe that doesn't matter anyway, as long as they don't bring the adjacency up).

Comments? other ideas?

Philip Christian

-----Original Message-----
From: Les Ginsberg [mailto:ginsberg@pluris.com]
Sent: 05 December 2001 06:03
To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH]
Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net';
'dkatz@juniper.net'
Subject: RE: [Isis-wg] Concerns with 3-way-handshake

Sorry folks - but IMHO you are focusing on the wrong issue. The problem is
not ISHs, but some ambiguity in the current definition of the 3way draft and
the fact that a number of vendors still utilize the old version of the 3 way
handshake which only sends local adjacency state. (Please see my earlier
mail on this subject)

Suggesting that ISHs be ignored just creates more potential backwards
compatibility problems and ignores the real cause of the problem. That
doesn't make sense to me.

(The fact that some implementations already do not send ISHs has created
compatibility problems in that implementations in strict conformance to ISO
10589 will not interoperate with these implementations i.e. an
implementation which expects to receive an ISH before sending an IIH (as per
ISO 10589) will never form an adjacency with an implementation that never
sends an ISH.)

   Les

> -----Original Message-----
> From: Tony Przygienda [mailto:prz@redback.com]
> Sent: Tuesday, December 04, 2001 4:35 PM
> To: Rajesh Saluja
> Cc: Philip Christian; 'isis-wg@spider.juniper.net';
> 'dkatz@juniper.net'
> Subject: Re: [Isis-wg] Concerns with 3-way-handshake
>
>
> Rajesh Saluja wrote:
>
> > >
> > >
> > > >From my vintage, yes, it should be fixed, maybe as
> simply as saying that
> > > three-way-hello capable routers drop ISHs and do not send
> them ?  The
> > > very details of 1195 slip my mind right now but that
> should not cause
> > > any backwards capability problems?
> > >
> > >     something is definitely worth an addition to the
> 3-way-hello draft
> > >
> > >     -- tony
> >
> > I agree with Philip's concerns. Will the following modifications be
> > acceptable to the group:
> > 1. As Tony suggested, say that  three-way-hello capable
> routers drop ISHs
> > and do not send them.
>
> you better be very carefull with the MUST and MAYs when
> writing this. As well,
> someone thinks carefully whether it won't break more than it
> fixes (although
> deployment with dropped ISHs seems to prove that it works and
> since we will
>  be able to chhose whether we send/receive them, we can force
> pretty much
> this situation with the draft).
>
>     thanks
>
>     -- tonyt
>
> _______________________________________________
> 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
--=====================_4939202==_.ALT-- From ginsberg@pluris.com Wed Dec 5 21:12:39 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 5 Dec 2001 13:12:39 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F62A@avalon.pluris.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_01C17DD1.91E14120 Content-Type: text/plain; charset="iso-8859-1" All of this is very unnecessary. Let's go back to the beginning. The original problem that Philip stated was: >A is connected to B and issues an ISH. >B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". >B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". >A receives this and according to the table in the draft, brings the adjacency "up". >However B may never have received an IIH from A and so the three way handshake has been short circuited Pretend the 3 way handshake was never invented - so we run according to the original rules in ISO 10589. For clarity I will refer to the 2001 draft because it includes wording that was corrected based on Technical Corrigendum 1. No fundamental change in procedure from the 1992 version was made - just a clearer presentation. What happens? A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now sends an IIH to A A receives the IIH and according to Table 5,6,7, or 8 (whichever applies) brings the adjacency up Note that at this time B has yet to receive an IIH from A (A presumably will soon send one soon) This demonstrates that this behavior involves no interaction between ISHs and 3-way handshake. Now enter the 3-way handshake era. The 3-way draft makes changes in the adjacency state table logic so as to be able to detect neighbor state changes even when run over unreliable link layers. It says nothing about the use/non-use of ISHs because it is not concerned with that - quite correctly. So, using the same scenario, what happens? There are a number of cases here depending on what form the 3-way TLV takes: Type = 0xF0 (decimal 240) Length = 5 to 17 octets Value: Adjacency State (one octet): 0 = Up 1 = Initializing 2 = Down Extended Local Circuit ID (four octets) Neighbor System ID if known (zero to eight octets) Neighbor Extended Local Circuit ID (four octets, if Neighbor System ID is present) As has been noted, there is a legacy version of the 3-way TLV - still in widespread use - which sends only adjacency state (Length = 1). This is not discussed in the current draft and should be. Anyway, we have three cases to consider depending on what has been sent in the 3 way TLV when B sends its first IIH: Case 1)Adjacency state only (length = 1) In this legacy 3-way case, B will never send neighbor system ID/circuit ID so A cannot know whether B has received an IIH from A yet or not - and can never know. So it must bring the adjacency up. Note that this behavior is no different from that which happens in the total absence of the 3-way TLV. Basically, this form of the 3-way handshake hasn't helped in this scenario. (Part of the reason the later form was defined I assume.) Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. The draft is incorrect in this case because it says if the neighbor system ID/circuit ID are "not present" the implementation should go ahead and follow the state change table anyway. This wording needs to be corrected to read something like: "If the option is present, the Neighbor System ID and Neighbor Extended Local Circuit ID fields, if present, shall be examined. If they are present, and the system ID contained therein does not match the local system's ID, or the extended circuit ID does not match the local system's extended circuit ID, the PDU shall be discarded and no further action is taken. If they are NOT present, but the Extended Local Circuit ID is present then the PDU shall be discarded and no further action taken. If the Neighbor System ID and Neighbor Extended Local Circuit ID fields match those of the local system, or are not present and the Extended Local Circuit ID is not present, the procedures described in section 8.2.4.2 are followed with following changes:" Case 3)Adjacency state + Extended Local Circuit ID + neighbor system + Neighbor extended local circuit ID (length = 17) Presumably, if B chose to include neighbor system ID and neighbor circuit ID before it had received an IIH from A, it would use values which are guaranteed to not match A's local values. In my previous mail I suggested using a system ID of all 0's, which is probably fairly safe, but a better choice would be for B to place it's own system ID there. Since there can be no duplicate system IDs this should never match A's local ID and therefore the check would fail and therefore no adjacency state change would occur. I believe changing the draft to include wording described in Case 2 above solves the problem. There should also be some discussion of what the legacy version (adjacency state only) does - that text has fallen into the black hole of expired drafts. Now, the issue of whether sending ISHs should be optional is something that needs to be addressed - thus far this "violation" of the spec has been supported by liberal implementations on the receiver side - but should be agreed upon and defined in a draft. But that issue is distinct and unrelated to the operation of the 3-way handshake. There is no reason to confuse the two. Les Message----- From: Philip Christian [mailto:christi@nortelnetworks.com] Sent: Wednesday, December 05, 2001 2:51 AM To: 'Les Ginsberg'; 'Tony Przygienda'; Rajesh Saluja Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net' Subject: RE: [Isis-wg] Concerns with 3-way-handshake I (and a colleague, credit where it's due) can think of a couple of ways to solve this problem. First we could add an explicit statement such as "Sending and receiving ISHs is required by Intermediate Systems that can route CLNP packets. Intermediate Systems that cannot route CLNP may or may not send and receive ISHs." Now here are the two ideas 1. On Intermediate Systems where receipt of an ISH causes an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State "Down". Once an IIH has been received then the state of the adjacency shall be reported in the option as normal. or 2. On Intermediate Systems where receipt of an ISH caused an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State 3 = "ISH_init" (for example). Intermediate Systems that do not send and receive ISHs are not required to implement reporting of this state, as they will neither send it, nor cause a neighbour to send it back to them. We then have to mess with the table a little, basically saying that if you support ISHs and receive an "ISH_init" then you go to "Initialise" (rather than "up", which was the problem). I think that both of these ideas allow routers that support CLNP forwarding to also use the 3-way-handshake, without upsetting anyone who has already stopped using ISHs on their pure IP implementations. I prefer idea "2", as "1" feels like the IS is misreporting the state, and just doesn't appeal to my sense of correctness so well. The problem with "2" is that if you send an ISH to an IS, then you can expect it to send back this new Adjacency State = 3 ="ISH_init" message back. Now it seems to me that if someone just dumps incoming ISHs then they shouldn't be trasmitting them either, but if someone HAS implemented that, then they are going to get "3=ISH_init"s coming back at them and won't know what to do with them (maybe that doesn't matter anyway, as long as they don't bring the adjacency up). Comments? other ideas? Philip Christian ------_=_NextPart_001_01C17DD1.91E14120 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Concerns with 3-way-handshake
All of this is very unnecessary. Let's go back to the beginning. The original problem that Philip stated was:
 
>A is connected to B and issues an ISH. 
>B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". 
>B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". 
>A receives this and according to the table in the draft, brings the adjacency "up". 
>However B may never have received an IIH from A and so the three way handshake has been short circuited
 
Pretend the 3 way handshake was never invented - so we run according to the original rules in ISO 10589. For clarity I will refer to the 2001 draft because it includes wording that was corrected based on Technical Corrigendum 1. No fundamental change in procedure from the 1992 version was made - just a clearer presentation. What happens?
 
A is connected to B and issues an ISH. 
B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". 
B now sends an IIH to A
A receives the IIH and according to Table 5,6,7, or 8 (whichever applies) brings the adjacency up
Note that at this time B has yet to receive an IIH from A (A presumably will soon send one soon)
 
This demonstrates that this behavior involves no interaction between ISHs and 3-way handshake.
 
Now enter the 3-way handshake era. The 3-way draft makes changes in the adjacency state table logic so as to be able to detect neighbor state changes even when run over unreliable link layers. It says nothing about the use/non-use of ISHs because it is not concerned with that - quite correctly. So, using the same scenario, what happens?
 
There are a number of cases here depending on what form the 3-way TLV takes:
 
      Type = 0xF0 (decimal 240)
          Length = 5 to 17 octets
          Value:
            Adjacency State (one octet):
              0 = Up
              1 = Initializing
              2 = Down
            Extended Local Circuit ID (four octets)
            Neighbor System ID if known (zero to eight octets)
            Neighbor Extended Local Circuit ID (four octets, if Neighbor
              System ID is present)
As has been noted, there is a legacy version of the 3-way TLV - still in widespread use - which sends only adjacency state (Length = 1). This is not discussed in the current draft and should be. Anyway, we have three cases to consider depending on what has been sent in the 3 way TLV when B sends its first IIH:
 
Case 1)Adjacency state only (length = 1)
 
In this legacy 3-way case, B will never send neighbor system ID/circuit ID so A cannot know whether B has received an IIH from A yet or not - and can never know. So it must bring the adjacency up. Note that this behavior is no different from that which happens in the total absence of the 3-way TLV. Basically, this form of the 3-way handshake hasn't helped in this scenario. (Part of the reason the later form was defined I assume.)
 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change.
 
The draft is incorrect in this case because it says if the neighbor system ID/circuit ID are "not present" the implementation should go ahead and follow the state change table anyway. This wording needs to be corrected to read something like:
 
    "If the option is present, the Neighbor System ID and Neighbor
     Extended Local Circuit ID fields, if present, shall be examined.
     If they are present, and the system ID contained therein does not
     match the local system's ID, or the extended circuit ID does not
     match the local system's extended circuit ID, the PDU shall be
     discarded and no further action is taken.
 
     If they are NOT present, but the Extended Local Circuit ID is present
     then the PDU shall be discarded and no further action taken.
 
     If the Neighbor System ID and Neighbor Extended Local Circuit ID
     fields match those of the local system, or are not present and the
     Extended Local Circuit ID is not present, the
     procedures described in section 8.2.4.2 are followed with following
     changes:"
 
 
Case 3)Adjacency state + Extended Local Circuit ID + neighbor system + Neighbor extended local circuit ID (length = 17)
 
Presumably, if B chose to include neighbor system ID and neighbor circuit ID before it had received an IIH from A, it would use values which are guaranteed to not match A's local values. In my previous mail I suggested using a system ID of all 0's, which is probably fairly safe, but a better choice would be for B to place it's own system ID there. Since there can be no duplicate system IDs this should never match A's local ID and therefore the check would fail and therefore no adjacency state change would occur.
 
I believe changing the draft to include wording described in Case 2 above solves the problem. There should also be some discussion of what the legacy version (adjacency state only) does - that text has fallen into the black hole of expired drafts.
 
Now, the issue of whether sending ISHs should be optional is something that needs to be addressed - thus far this "violation" of the spec has been supported by liberal implementations on the receiver side - but should be agreed upon and defined in a draft. But that issue is distinct and unrelated to the operation of the 3-way handshake. There is no reason to confuse the two.
 
   Les
 
 
 Message-----
From: Philip Christian [mailto:christi@nortelnetworks.com]
Sent: Wednesday, December 05, 2001 2:51 AM
To: 'Les Ginsberg'; 'Tony Przygienda'; Rajesh Saluja
Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net'
Subject: RE: [Isis-wg] Concerns with 3-way-handshake

I (and a colleague, credit where it's due) can think of a couple of ways to solve this problem.
First we could add an explicit statement such as

"Sending and receiving ISHs is required by Intermediate Systems that can route CLNP packets. Intermediate Systems that cannot route CLNP may or may not send and receive ISHs."

Now here are the two ideas

1.
On Intermediate Systems where receipt of an ISH causes an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State "Down". Once an IIH has been received then the state of the adjacency shall be reported in the option as normal.

or

2.
On Intermediate Systems where receipt of an ISH caused an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State 3 = "ISH_init" (for example). Intermediate Systems that do not send and receive ISHs are not required to implement reporting of this state, as they will neither send it, nor cause a neighbour to send it back to them. We then have to mess with the table a little, basically saying that if you support ISHs and receive an "ISH_init" then you go to "Initialise" (rather than "up", which was the problem).

I think that both of these ideas allow routers that support CLNP forwarding to also use the 3-way-handshake, without upsetting anyone who has already stopped using ISHs on their pure IP implementations.

I prefer idea "2", as "1" feels like the IS is misreporting the state, and just doesn't appeal to my sense of correctness so well.

The problem with "2" is that if you send an ISH to an IS, then you can expect it to send back this new Adjacency State = 3 ="ISH_init" message back. Now it seems to me that if someone just dumps incoming ISHs then they shouldn't be trasmitting them either, but if someone HAS implemented that, then they are going to get "3=ISH_init"s coming back at them and won't know what to do with them (maybe that doesn't matter anyway, as long as they don't bring the adjacency up).

Comments? other ideas?

Philip Christian

 

------_=_NextPart_001_01C17DD1.91E14120-- From tli@Procket.com Wed Dec 5 21:54:27 2001 From: tli@Procket.com (Tony Li) Date: Wed, 5 Dec 2001 13:54:27 -0800 Subject: [Isis-wg] IS-IS commands - Need info In-Reply-To: <20011205140824.23091.qmail@mailFA9.rediffmail.com> References: <20011205140824.23091.qmail@mailFA9.rediffmail.com> Message-ID: <15374.38803.435266.953078@alpha-tli.procket.com> | I am unable to get the description and usage of "external overload | signalling" IS-IS command. Any information about this would be | helpful to me. | | Thanks in advance for your response Please consult your vendor for questions about their products. This mailing list is for the IETF IS-IS Working Group and is not a technical support resource. Thank you, Tony Li IS-IS WG co-chair From prz@redback.com Wed Dec 5 20:43:29 2001 From: prz@redback.com (Tony Przygienda) Date: Wed, 05 Dec 2001 12:43:29 -0800 Subject: [Isis-wg] pls update this draft ... Message-ID: <3C0E86F1.66854ABC@redback.com> Internet Engineering Task Force T. Przygienda INTERNET DRAFT Nov 2001 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 May 2002 [Page 1] Internet Draft TLV Codepoints Nov 2001 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) 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 Przygienda Expires May 2002 [Page 2] Internet Draft TLV Codepoints Nov 2001 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 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. 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 May 2002 [Page 3] Internet Draft TLV Codepoints Nov 2001 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 May 2002 [Page 4] From cast@allegronetworks.com Wed Dec 5 23:46:55 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Wed, 5 Dec 2001 15:46:55 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: Should an ISH effect adjacency state? The purpose of sending an ISH to an end system is to indicate the availability of the router, and to a router to cause it to start the router-to-router hello protocol (WANs only). ISHs convey neighbor type, address, and availability. Routers send IIHs to convey router to router adjacency information. Having ISH's set adjacency state mixes functions and gets in the way of the IIH protocol managing the adjacency state. To prevent ISHs from setting adjacency state, add a sentence to section 3.2 of the 3-way draft that reads something like: In section 8.2.2 replace each instance of "Initialising" with "Down". --Neal -----Original Message----- From: Les Ginsberg [mailto:ginsberg@pluris.com] Sent: Wednesday, December 05, 2001 1:13 PM To: 'Philip Christian'; Les Ginsberg; 'Tony Przygienda'; Rajesh Saluja Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net' Subject: RE: [Isis-wg] Concerns with 3-way-handshake All of this is very unnecessary. Let's go back to the beginning. The original problem that Philip stated was: >A is connected to B and issues an ISH. >B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". >B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". >A receives this and according to the table in the draft, brings the adjacency "up". >However B may never have received an IIH from A and so the three way handshake has been short circuited Pretend the 3 way handshake was never invented - so we run according to the original rules in ISO 10589. For clarity I will refer to the 2001 draft because it includes wording that was corrected based on Technical Corrigendum 1. No fundamental change in procedure from the 1992 version was made - just a clearer presentation. What happens? A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now sends an IIH to A A receives the IIH and according to Table 5,6,7, or 8 (whichever applies) brings the adjacency up Note that at this time B has yet to receive an IIH from A (A presumably will soon send one soon) This demonstrates that this behavior involves no interaction between ISHs and 3-way handshake. Now enter the 3-way handshake era. The 3-way draft makes changes in the adjacency state table logic so as to be able to detect neighbor state changes even when run over unreliable link layers. It says nothing about the use/non-use of ISHs because it is not concerned with that - quite correctly. So, using the same scenario, what happens? There are a number of cases here depending on what form the 3-way TLV takes: Type = 0xF0 (decimal 240) Length = 5 to 17 octets Value: Adjacency State (one octet): 0 = Up 1 = Initializing 2 = Down Extended Local Circuit ID (four octets) Neighbor System ID if known (zero to eight octets) Neighbor Extended Local Circuit ID (four octets, if Neighbor System ID is present) As has been noted, there is a legacy version of the 3-way TLV - still in widespread use - which sends only adjacency state (Length = 1). This is not discussed in the current draft and should be. Anyway, we have three cases to consider depending on what has been sent in the 3 way TLV when B sends its first IIH: Case 1)Adjacency state only (length = 1) In this legacy 3-way case, B will never send neighbor system ID/circuit ID so A cannot know whether B has received an IIH from A yet or not - and can never know. So it must bring the adjacency up. Note that this behavior is no different from that which happens in the total absence of the 3-way TLV. Basically, this form of the 3-way handshake hasn't helped in this scenario. (Part of the reason the later form was defined I assume.) Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. The draft is incorrect in this case because it says if the neighbor system ID/circuit ID are "not present" the implementation should go ahead and follow the state change table anyway. This wording needs to be corrected to read something like: "If the option is present, the Neighbor System ID and Neighbor Extended Local Circuit ID fields, if present, shall be examined. If they are present, and the system ID contained therein does not match the local system's ID, or the extended circuit ID does not match the local system's extended circuit ID, the PDU shall be discarded and no further action is taken. If they are NOT present, but the Extended Local Circuit ID is present then the PDU shall be discarded and no further action taken. If the Neighbor System ID and Neighbor Extended Local Circuit ID fields match those of the local system, or are not present and the Extended Local Circuit ID is not present, the procedures described in section 8.2.4.2 are followed with following changes:" Case 3)Adjacency state + Extended Local Circuit ID + neighbor system + Neighbor extended local circuit ID (length = 17) Presumably, if B chose to include neighbor system ID and neighbor circuit ID before it had received an IIH from A, it would use values which are guaranteed to not match A's local values. In my previous mail I suggested using a system ID of all 0's, which is probably fairly safe, but a better choice would be for B to place it's own system ID there. Since there can be no duplicate system IDs this should never match A's local ID and therefore the check would fail and therefore no adjacency state change would occur. I believe changing the draft to include wording described in Case 2 above solves the problem. There should also be some discussion of what the legacy version (adjacency state only) does - that text has fallen into the black hole of expired drafts. Now, the issue of whether sending ISHs should be optional is something that needs to be addressed - thus far this "violation" of the spec has been supported by liberal implementations on the receiver side - but should be agreed upon and defined in a draft. But that issue is distinct and unrelated to the operation of the 3-way handshake. There is no reason to confuse the two. Les Message----- From: Philip Christian [mailto:christi@nortelnetworks.com] Sent: Wednesday, December 05, 2001 2:51 AM To: 'Les Ginsberg'; 'Tony Przygienda'; Rajesh Saluja Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net' Subject: RE: [Isis-wg] Concerns with 3-way-handshake I (and a colleague, credit where it's due) can think of a couple of ways to solve this problem. First we could add an explicit statement such as "Sending and receiving ISHs is required by Intermediate Systems that can route CLNP packets. Intermediate Systems that cannot route CLNP may or may not send and receive ISHs." Now here are the two ideas 1. On Intermediate Systems where receipt of an ISH causes an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State "Down". Once an IIH has been received then the state of the adjacency shall be reported in the option as normal. or 2. On Intermediate Systems where receipt of an ISH caused an adjacency to start in the "initialise" state, and which support the "Point-to-Point Adjacency State" option, such an adjacency will be reported in the option as being Adjacency State 3 = "ISH_init" (for example). Intermediate Systems that do not send and receive ISHs are not required to implement reporting of this state, as they will neither send it, nor cause a neighbour to send it back to them. We then have to mess with the table a little, basically saying that if you support ISHs and receive an "ISH_init" then you go to "Initialise" (rather than "up", which was the problem). I think that both of these ideas allow routers that support CLNP forwarding to also use the 3-way-handshake, without upsetting anyone who has already stopped using ISHs on their pure IP implementations. I prefer idea "2", as "1" feels like the IS is misreporting the state, and just doesn't appeal to my sense of correctness so well. The problem with "2" is that if you send an ISH to an IS, then you can expect it to send back this new Adjacency State = 3 ="ISH_init" message back. Now it seems to me that if someone just dumps incoming ISHs then they shouldn't be trasmitting them either, but if someone HAS implemented that, then they are going to get "3=ISH_init"s coming back at them and won't know what to do with them (maybe that doesn't matter anyway, as long as they don't bring the adjacency up). Comments? other ideas? Philip Christian From ginsberg@pluris.com Thu Dec 6 05:37:38 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Wed, 5 Dec 2001 21:37:38 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F62D@avalon.pluris.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_01C17E18.1D890B40 Content-Type: text/plain; charset="iso-8859-1" Rajesh - You have reminded me that the adjacency states defined by the 3way draft and sent in the 3 way TLV are not equivalent to the adjacency states defined in 10589. 10589 defines the following states: INITIALISING: Created on receipt of ISH (or IIH if you allow that) UP FAILED (Only used on DA circuits - let's ignore that) DOWN: A transient state because the adjacency is deleted immediately after 3way defines: DOWN: Can mean no adjacency exists or the state associated with the adjacency when an IIH is received and the action in Tables 5,6,7, or 8 from 10589 is UP INITIALISING: Reached after receiving an IIH when you are in down state (as per table in 3way draft) UP Conceptually it is necessary to maintain these two sets of adjacency states because until you receive an IIH you do not know whether your neighbor supports 3way or not. If your neighbor does not include the 3way TLV then you follow the original 10589 rules, which means that you transition from Initialising to UP when receiving an IIH. If your neighbor does include the 3 way TLV, then after determining via Tables 5,6,7,8 that the action is UP you must set local 3way state to DOWN and then apply the 3way state table. If you are initiating an IIH before you have received one, then you should set the adjacency state field in the 3way TLV to down (NOT initialising), whether you have received an ISH or not. The 3way state can only transition to Initialising after receiving an IIH. All of this makes me think that Philip's original premise is wrong (and unfortunately much of the discussion, including much of my comments) is off the mark. Philip said: >A is connected to B and issues an ISH. >B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". >B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". No - this is incorrect. B should report the 3way state as "Down" because it has yet to receive an IIH. >A receives this and according to the table in the draft, brings the adjacency "up". Now A will, following the table in 3 way draft, change the adjacency to Initialising. >However B may never have received an IIH from A and so the three way handshake has been short circuited This no longer applies. --------------------------- The textual correction that is needed in the 3 way draft is as follows: Add a clause e) to the end of Section 8.2.3: "Set the state to be reported in the Adjacency State field of the Point-to-Point Adjacency State option to down." (NOTE: This would be clause f) in the 10589:2001 draft) The previous textual correction I suggested then is not needed. No further change to ISH sending/processing is needed either. Whether we want to standardize not sending ISHs is a separate issue which should be discussed on a separate thread. Sorry for heading down the wrong road previously. Les -----Original Message----- From: Rajesh Saluja [mailto:rsaluja@nortelnetworks.com] Sent: Wednesday, December 05, 2001 3:49 PM To: 'Les Ginsberg'; Philip Christian; 'Tony Przygienda' Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net' Subject: RE: [Isis-wg] Concerns with 3-way-handshake Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. [Rajesh Saluja] Les, If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH? Thanks, Rajesh ------_=_NextPart_001_01C17E18.1D890B40 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Concerns with 3-way-handshake
Rajesh -
 
You have reminded me that the adjacency states defined by the 3way draft and sent in the 3 way TLV are not equivalent to the adjacency states defined in 10589. 10589 defines the following states:
 
   INITIALISING: Created on receipt of ISH (or IIH if you allow that)
   UP
   FAILED (Only used on DA circuits - let's ignore that)
   DOWN: A transient state because the adjacency is deleted immediately after
 
3way defines:
 
   DOWN: Can mean no adjacency exists or the state associated with the adjacency when an IIH is received and the action in Tables 5,6,7, or 8 from 10589 is UP
  INITIALISING: Reached after receiving an IIH when you are in down state (as per table in 3way draft)
  UP
 
Conceptually it is necessary to maintain these two sets of adjacency states because until you receive an IIH you do not know whether your neighbor supports 3way or not. If your neighbor does not include the 3way TLV then you follow the original 10589 rules, which means that you transition from Initialising to UP when receiving an IIH.
 
If your neighbor does include the 3 way TLV, then after determining via Tables 5,6,7,8 that the action is UP you must set local 3way state to DOWN and then apply the 3way state table.
 
If you are initiating an IIH before you have received one, then you should set the adjacency state field in the 3way TLV to down (NOT initialising), whether you have received an ISH or not. The 3way state can only transition to Initialising after receiving an IIH.
 
All of this makes me think that Philip's original premise is wrong (and unfortunately much of the discussion, including much of my comments) is off the mark. Philip said:
 
 >A is connected to B and issues an ISH. 
>B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". 
>B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". 
 
No - this is incorrect. B should report the 3way state as "Down" because it has yet to receive an IIH.
 
>A receives this and according to the table in the draft, brings the adjacency "up". 
 
Now A will, following the table in 3 way draft, change the adjacency to Initialising.

>However B may never have received an IIH from A and so the three way handshake has been short circuited
 
This no longer applies.
 
---------------------------
 
The textual correction that is needed in the 3 way draft is as follows:
 
   Add a clause e) to the end of Section 8.2.3:
 
   "Set the state to be reported in the Adjacency State field of the Point-to-Point
   Adjacency State option to down."
 
(NOTE: This would be clause f) in the 10589:2001 draft)
 
The previous textual correction I suggested then is not needed. No further change to ISH sending/processing is needed either. Whether we want to standardize not sending ISHs is a separate issue which should be discussed on a separate thread.
 
Sorry for heading down the wrong road previously.
 
   Les
 
 -----Original Message-----
From: Rajesh Saluja [mailto:rsaluja@nortelnetworks.com]
Sent: Wednesday, December 05, 2001 3:49 PM
To: 'Les Ginsberg'; Philip Christian; 'Tony Przygienda'
Cc: 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net'
Subject: RE: [Isis-wg] Concerns with 3-way-handshake

 
 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change.
[Rajesh Saluja] 
Les,
If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH?
 
Thanks,
Rajesh
 
 
------_=_NextPart_001_01C17E18.1D890B40-- From Ming.Chan@SpirentCom.COM Thu Dec 6 23:21:08 2001 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming) Date: Thu, 6 Dec 2001 13:21:08 -1000 Subject: [Isis-wg] Replacing IS-IS Neighbors TLV , etc in TE?? Message-ID: <8AC36D3167EED41184C800508BD9540501EE3C5A@apollo.adtech-inc.com> Hi, I just come across draft-ietf-sis-trafic-0.4.txt and read that the intend of introducing some of new TLVs are to replace the ones defined in ISO10589. e.g., Extended IS Reachability TVL will replace ISIS-Neighbors (code 2) 1) Does it mean that if an Implementation supports this new draft, then it SHALL not use ISIS Neighbor TLV at all? 2) If that is the case, dose any one know where can find any info talks about the migration or this type of related stuffs? Thanks! Ming Chan From fenner@research.att.com Fri Dec 7 00:14:22 2001 From: fenner@research.att.com (Bill Fenner) Date: Thu, 6 Dec 2001 16:14:22 -0800 Subject: [Isis-wg] Reserved TLV Codepoints in ISIS Message-ID: <200112070014.QAA05041@windsor.research.att.com> Tony, > This document will be periodically updated by never versions in the > fashion of [RP94 ] and successors. i.e. not since 1994? =) Forgive me if you've covered this already, but have you contacted the IANA about their willingness to run a registry for this, even though they can't be 100% authoritative? It seems like just like the IANA no longer publishes RFC 1700 that it'd be much easier to have a registry than an RFC that has to be periodically updated. Instead, we could have an "IANA Considerations for ISIS Type Codepoints" spec, which directs the IANA to register code points that the ISO and SIF create as well. How does the ISIS WG decide upon a code point for a new work item? Thanks, Bill From prz@redback.com Thu Dec 6 23:36:28 2001 From: prz@redback.com (Tony Przygienda) Date: Thu, 06 Dec 2001 15:36:28 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake References: <17C81AD1F1FED411991E006008F6D1CA01B3F62D@avalon.pluris.com> Message-ID: <3C1000FB.1D82412F@redback.com> Les, > ajesh - > > You have reminded me that the adjacency states defined by the 3way draft and sent in the 3 way TLV are not equivalent to the adjacency states defined in 10589. > 10589 defines the following states: > > INITIALISING: Created on receipt of ISH (or IIH if you allow that) > UP > FAILED (Only used on DA circuits - let's ignore that) > DOWN: A transient state because the adjacency is deleted immediately after > > 3way defines: > > DOWN: Can mean no adjacency exists or the state associated with the adjacency when an IIH is received and the action in Tables 5,6,7, or 8 from 10589 is UP > INITIALISING: Reached after receiving an IIH when you are in down state (as per table in 3way draft) > UP > > Conceptually it is necessary to maintain these two sets of adjacency states because until you receive an IIH you do not know whether your neighbor supports > 3way or not. If your neighbor does not include the 3way TLV then you follow the original 10589 rules, which means that you transition from Initialising to UP > when receiving an IIH. > > If your neighbor does include the 3 way TLV, then after determining via Tables 5,6,7,8 that the action is UP you must set local 3way state to DOWN and then > apply the 3way state table. > > If you are initiating an IIH before you have received one, then you should set the adjacency state field in the 3way TLV to down (NOT initialising), whether > you have received an ISH or not. The 3way state can only transition to Initialising after receiving an IIH. > > All of this makes me think that Philip's original premise is wrong (and unfortunately much of the discussion, including much of my comments) is off the mark. > Philip said: > > >A is connected to B and issues an ISH. > >B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". > >B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". > > No - this is incorrect. B should report the 3way state as "Down" because it has yet to receive an IIH. > > >A receives this and according to the table in the draft, brings the adjacency "up". > > Now A will, following the table in 3 way draft, change the adjacency to Initialising. > > >However B may never have received an IIH from A and so the three way handshake has been short circuited > > This no longer applies. > fine, so if understood correctly you originate first hello always with 'Down' for 3-way which makes for ISHs impossible to short-cut the 3-way state machine. Any first hello you receive for ISH you sent should therefore be 'Down' for 3-way as well. That solves the problem or rather it seems really non-existent. The textual correction that is needed in the 3 way draft is as follows: Add a clause e) to the end of Section 8.2.3: "Set the state to be reported in the Adjacency State field of the Point-to-Point Adjacency State option to down." (NOTE: This would be clause f) in the 10589:2001 draft) yes, seems to me indeed necessary AND sufficient. I suggest to halt the RFC publication and do another last call after this fix is propagated. Protocol specifications with buggy or unclear state machines shine a poor light on the group involved ;-) > The previous textual correction I suggested then is not needed. No further change to ISH sending/processing is needed either. Whether we want to standardize > not sending ISHs is a separate issue which should be discussed on a separate thread. > yes, it is a fully orthogonal issue and if somebody feels like documenting it, fine, does not seem to me very important or even necessary (seems you can violate the 10589 here in many inventive ways and it is still stable enough to survive it). > > Sorry for heading down the wrong road previously. > good scare, everybody fell for it initially ;-) --- tony From ginsberg@pluris.com Fri Dec 7 02:07:04 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Thu, 6 Dec 2001 18:07:04 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F634@avalon.pluris.com> Tony - Thanks for your comments. I agree with your view that the text should be revised before publication. In addition to the correction mentioned below, there was also discussion of revising it to indicate there is a legacy version of the 3 way TLV which only sends adjacency state. This should require no changes to the state table, which handles it (as indicated in the draft), but it should be noted that the length can be 1-17 (rather than 5-17 as it indicates now) and perhaps some brief description of what form this legacy version takes. Les > -----Original Message----- > From: Tony Przygienda [mailto:prz@redback.com] > Sent: Thursday, December 06, 2001 3:36 PM > To: Les Ginsberg > Cc: 'Rajesh Saluja'; Philip Christian; 'isis-wg@spider.juniper.net'; > 'dkatz@juniper.net' > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > Les, > > > ajesh - > > > > You have reminded me that the adjacency states defined by > the 3way draft and sent in the 3 way TLV are not equivalent > to the adjacency states defined in 10589. > > 10589 defines the following states: > > > > INITIALISING: Created on receipt of ISH (or IIH if you > allow that) > > UP > > FAILED (Only used on DA circuits - let's ignore that) > > DOWN: A transient state because the adjacency is deleted > immediately after > > > > 3way defines: > > > > DOWN: Can mean no adjacency exists or the state > associated with the adjacency when an IIH is received and the > action in Tables 5,6,7, or 8 from 10589 is UP > > INITIALISING: Reached after receiving an IIH when you are > in down state (as per table in 3way draft) > > UP > > > > Conceptually it is necessary to maintain these two sets of > adjacency states because until you receive an IIH you do not > know whether your neighbor supports > > 3way or not. If your neighbor does not include the 3way TLV > then you follow the original 10589 rules, which means that > you transition from Initialising to UP > > when receiving an IIH. > > > > If your neighbor does include the 3 way TLV, then after > determining via Tables 5,6,7,8 that the action is UP you must > set local 3way state to DOWN and then > > apply the 3way state table. > > > > If you are initiating an IIH before you have received one, > then you should set the adjacency state field in the 3way TLV > to down (NOT initialising), whether > > you have received an ISH or not. The 3way state can only > transition to Initialising after receiving an IIH. > > > > All of this makes me think that Philip's original premise > is wrong (and unfortunately much of the discussion, including > much of my comments) is off the mark. > > Philip said: > > > > >A is connected to B and issues an ISH. > > >B receives the ISH, and according to ISO 10589 section > 8.2.2 creates an adjacency of type "Initialising". > > >B now reports to A in the new "Point to point adjacency > state" option that the adjacency is "Initialising". > > > > No - this is incorrect. B should report the 3way state as > "Down" because it has yet to receive an IIH. > > > > >A receives this and according to the table in the draft, > brings the adjacency "up". > > > > Now A will, following the table in 3 way draft, change the > adjacency to Initialising. > > > > >However B may never have received an IIH from A and so the > three way handshake has been short circuited > > > > This no longer applies. > > > > fine, so if understood correctly you originate first hello > always with 'Down' > for 3-way which makes for ISHs impossible to short-cut the > 3-way state machine. > Any first hello you receive for ISH you sent should therefore > be 'Down' for > 3-way as well. That solves the problem or rather it seems > really non-existent. > > The textual correction that is needed in the 3 way draft is > as follows: > > Add a clause e) to the end of Section 8.2.3: > > "Set the state to be reported in the Adjacency State field of the > Point-to-Point > Adjacency State option to down." > > (NOTE: This would be clause f) in the 10589:2001 draft) > > yes, seems to me indeed necessary AND sufficient. I suggest > to halt the > RFC publication and do another last call after this fix is > propagated. Protocol > specifications > with buggy or unclear state machines shine a poor light on > the group involved > ;-) > > > The previous textual correction I suggested then is not > needed. No further change to ISH sending/processing is needed > either. Whether we want to standardize > > not sending ISHs is a separate issue which should be > discussed on a separate thread. > > > > yes, it is a fully orthogonal issue and if somebody feels > like documenting it, > fine, does not seem to me very important or even necessary > (seems you can > violate the 10589 here in many inventive > ways and it is still stable enough to survive it). > > > > > Sorry for heading down the wrong road previously. > > > > good scare, everybody fell for it initially ;-) > > > --- tony > > > From cast@allegronetworks.com Fri Dec 7 02:23:01 2001 From: cast@allegronetworks.com (Neal Castagnoli) Date: Thu, 6 Dec 2001 18:23:01 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: > fine, so if understood correctly you originate first hello > always with 'Down' > for 3-way which makes for ISHs impossible to short-cut the > 3-way state machine. Does this follow? The first transmitted hello could be dropped, the ISH would then come in and update the adjacency state to "Initialising" though you've never received a hello from the other side. > Any first hello you receive for ISH you sent should therefore > be 'Down' for > 3-way as well. That solves the problem or rather it seems > really non-existent. > > The textual correction that is needed in the 3 way draft is > as follows: > > Add a clause e) to the end of Section 8.2.3: > > "Set the state to be reported in the Adjacency State field of the > Point-to-Point > Adjacency State option to down." Section 8.2.3 in the original 10589 describes constructing hellos in general. This text would result in *all* hellos being transmitted with "Down." If this is meant to be added to section 8.2.2, the ISH section, then it seems you would need to change some of the three-way text to create a new 3-way adjacency state in addition to the regular adjacency state, but is this really necessary? Also, if there were an implementation that forgot to turn off transmission of ISHs, then the adjacency would potentially not come up or perhaps cycle up and down. Perhaps it would be better to take advantage of the built in conditionals in section 8.2.2. --Neal From ginsberg@pluris.com Fri Dec 7 02:50:55 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Thu, 6 Dec 2001 18:50:55 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F635@avalon.pluris.com> Neal - Sorry. My error. I indeed was referring to Section 8.2.2 "Receiving ISHs by an Intermediate System". Good catch. So we have: The textual correction that is needed in the 3 way draft is as follows: Add a clause e) to the end of Section 8.2.2: "Set the state to be reported in the Adjacency State field of the Point-to-Point Adjacency State option to down." (NOTE: This would be clause f) in the 10589:2001 draft) I believe after making this correction your concern about the state moving from down to initialised as a result of receiving an ISH goes away. ISHs received after the adjacency has been created are not a problem as 8.2.2b tells you to discard them. ISHs received after an adjacency is UP should be ignored. This was never made explicit in the 1992 version. Much clearer text can be found in 10589:2001 8.2.3 The issue you raise regarding adjacency state vs. 3way adjacency state can be viewed as an implementation issue. There is nothing in the 3way draft that requires that the state advertised in the TLV be identical to the value of "adjacencyState" as defined in 10589. The latter is never directly visible to the neighbor. It can be argued that it would clearer/more intuitive if these states were perfectly aligned. This would require some revisions to the 10589 text to substitute "Down" for "Initialised" in some places. This should not break anything because the 10589 state tables really depend on the notion of the adjacency being "up or not up". But if not done carefully, there would confusion introduced regarding the new use of state "Down" and AdjacencyStateChange(Down) events. I do not object to this clarification in principle - but I am not inclined to go to this trouble. Les > -----Original Message----- > From: Neal Castagnoli [mailto:cast@allegronetworks.com] > Sent: Thursday, December 06, 2001 6:23 PM > To: 'Tony Przygienda'; Les Ginsberg > Cc: 'Rajesh Saluja'; Philip Christian; 'isis-wg@spider.juniper.net'; > 'dkatz@juniper.net' > Subject: RE: [Isis-wg] Concerns with 3-way-handshake > > > > > fine, so if understood correctly you originate first hello > > always with 'Down' > > for 3-way which makes for ISHs impossible to short-cut the > > 3-way state machine. > > Does this follow? The first transmitted hello could be > dropped, the ISH > would then come in and update the adjacency state to > "Initialising" though > you've never received a hello from the other side. > > > > Any first hello you receive for ISH you sent should therefore > > be 'Down' for > > 3-way as well. That solves the problem or rather it seems > > really non-existent. > > > > The textual correction that is needed in the 3 way draft is > > as follows: > > > > Add a clause e) to the end of Section 8.2.3: > > > > "Set the state to be reported in the Adjacency State field of the > > Point-to-Point > > Adjacency State option to down." > > Section 8.2.3 in the original 10589 describes constructing hellos in > general. This text would result in *all* hellos being > transmitted with > "Down." > > If this is meant to be added to section 8.2.2, the ISH > section, then it > seems you would need to change some of the three-way text to > create a new > 3-way adjacency state in addition to the regular adjacency > state, but is > this really necessary? > > Also, if there were an implementation that forgot to turn off > transmission > of ISHs, then the adjacency would potentially not come up or > perhaps cycle > up and down. Perhaps it would be better to take advantage of > the built in > conditionals in section 8.2.2. > > --Neal > From christi@nortelnetworks.com Fri Dec 7 10:13:50 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Fri, 7 Dec 2001 10:13:50 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C4507139F@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_01C17F07.DDD95130 Content-Type: text/plain; charset="iso-8859-1" To be fair to Les, it was me that started the scare. I did misunderstand what was going on, however it will hopefully result in a better RFC. This text of Les' Add a clause e) to the end of Section 8.2.3: "Set the state to be reported in the Adjacency State field of the Point-to-Point Adjacency State option to down." Presumably this is to be added to what is already there in the draft, making the complete text:- "Add a clause e) to the end of section 8.2.3: The IS shall include the Point-to-Point Adjacency State option in the transmitted Point-to-Point IIH PDU. The current state of the adjacency with its neighbor on the link (as defined in section 8.2.4.1.1) shall be reported in the Adjacency State field. If no adjacency exists, the state shall be reported as Down. The Extended Local Circuit ID field shall contain a value assigned by this IS when the circuit is created. This value shall be unique among all the circuits of this Intermediate System. The value is not necessarily related to that carried in the Local Circuit ID field of the IIH PDU. If the system ID and Extended Local Circuit ID of the neighboring system are known (in state Initializing or Up), the neighbor's system ID shall be reported in the Neighbor System ID field, and the neighbor's Extended Local Circuit ID shall be reported in the Neighbor Extended Local Circuit ID field. Set the state to be reported in the Adjacency State field of the Point-to-Point Adjacency State option to Down." Is that right? Philip Christian. > > Sorry for heading down the wrong road previously. > good scare, everybody fell for it initially ;-) --- tony ------_=_NextPart_001_01C17F07.DDD95130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Concerns with 3-way-handshake

To be fair to Les, it was me that started the scare. = I did misunderstand what was going on, however it will hopefully result = in a better RFC.

This text of Les'

 Add a clause e) to the end of Section = 8.2.3:

   "Set the state to be reported in = the Adjacency State field of the
Point-to-Point
   Adjacency State option to = down."

Presumably this is to be added to what is already = there in the draft, making the complete text:-

"Add a clause e) to the end of section = 8.2.3:

     The IS shall include the = Point-to-Point Adjacency State option in
     the transmitted = Point-to-Point IIH PDU.  The current state of the
     adjacency with its neighbor = on the link (as defined in section
     8.2.4.1.1) shall be = reported in the Adjacency State field.  If no
     adjacency exists, the state = shall be reported as Down.

     The Extended Local Circuit = ID field shall contain a value assigned
     by this IS when the circuit = is created.  This value shall be unique
     among all the circuits of = this Intermediate System.  The value is
     not necessarily related to = that carried in the Local Circuit ID
     field of the IIH = PDU.

     If the system ID and = Extended Local Circuit ID of the neighboring
     system are known (in state = Initializing or Up), the neighbor's
     system ID shall be reported = in the Neighbor System ID field, and
     the neighbor's Extended = Local Circuit ID shall be reported in the
     Neighbor Extended Local = Circuit ID field.

     Set the state to be reported = in the Adjacency State field of the
     Point-to-Point Adjacency = State option to Down."

Is that right?

Philip Christian.

>
> Sorry for heading down the wrong road = previously.
>

good scare, everybody fell for it initially = ;-)


    --- tony



------_=_NextPart_001_01C17F07.DDD95130-- From matthew.noble@riverstonenet.com Fri Dec 7 11:25:03 2001 From: matthew.noble@riverstonenet.com (Matthew Noble) Date: Fri, 7 Dec 2001 11:25:03 -0000 Subject: [Isis-wg] IS-IS Restart draft clarification Message-ID: <000001c17f11$e107a230$e9dc14ac@ctron.com> Mike In section 4.3.1.2 second paragraph says that SPF is not run while T3 is running, but in the 5th paragraph of the same section it says that when T2 expires/cancelled, the SPF for that level _is_ run. Now T2 will expire under normal sucessful conditions before T3 expires - so there is a contradiction here. I am assuming that the info in the 5th paragraph is correct, and that that in the second paragraph is wrong. Could you confirm that for me. Thanks Matt From mshand@cisco.com Fri Dec 7 14:24:10 2001 From: mshand@cisco.com (mike shand) Date: Fri, 07 Dec 2001 14:24:10 +0000 Subject: [Isis-wg] IS-IS Restart draft clarification In-Reply-To: <000001c17f11$e107a230$e9dc14ac@ctron.com> Message-ID: <4.3.2.7.2.20011207142041.033b1740@jaws.cisco.com> At 11:25 07/12/2001 +0000, Matthew Noble wrote: >Mike > >In section 4.3.1.2 second paragraph says that SPF is not run while T3 is >running, but in the 5th paragraph of the same section it says that when T2 >expires/cancelled, the SPF for that level _is_ run. Now T2 will expire under >normal sucessful conditions before T3 expires - so there is a contradiction >here. I am assuming that the info in the 5th paragraph is correct, and that >that in the second paragraph is wrong. > >Could you confirm that for me. Without actually looking at the draft, I think the issue is that once we have got synchronization we can safely run SPF at that level. Once we have got synchronization at both levels we can clear T3. But while one level is synchronized and the other is not we still need to keep T3 running. So yes, I think the second para is strictly wrong. But I'll look at it in more detail later. Mike >Thanks >Matt > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From mkontoff@Kontoff.com Fri Dec 7 14:45:47 2001 From: mkontoff@Kontoff.com (Matthew Kontoff) Date: Fri, 07 Dec 2001 09:45:47 -0500 Subject: [Isis-wg] Replacing IS-IS Neighbors TLV , etc in TE?? References: <8AC36D3167EED41184C800508BD9540501EE3C5A@apollo.adtech-inc.com> Message-ID: <3C10D61B.16370A8@Kontoff.com> Hi, "Chan, Chung Ming" wrote: > > Hi, > I just came across draft-ietf-isis-traffic-04.txt and read that the intent of > introducing some of new TLVs are to replace the ones defined in ISO 10589. > e.g., Extended IS Reachability TLV will replace ISIS-Neighbors (code 2) > > 1) Does it mean that if an Implementation supports this new draft, then it > SHALL not use ISIS Neighbor TLV at all? No. Whether or not the ISIS Neighbor TLV is used is up to the implementation but it is a real good idea to be backward compatible with IS-IS routers that don't support the draft. > 2) If that is the case, does any one know where I can find any info > that talks about the migration or this type of related stuff? For a migration to occur smoothly - without losing routes - you need to be able to handle both the old style IS neighbor TLV and the new style (extended IS Reachability TLV). You will need to decide which TLV you will use when running your SPF. Matt From ginsberg@pluris.com Fri Dec 7 21:24:22 2001 From: ginsberg@pluris.com (Les Ginsberg) Date: Fri, 7 Dec 2001 13:24:22 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F637@avalon.pluris.com> As pointed out by Neal Castagnoli yesterday, the text I presented below belongs in Section 8.2.2 Receiving ISH PDUs by an Intermediate System. This was a section reference error on my part which I corrected based on Neal's input. The existing text in the 3 way draft which adds a new item (coincidentally also "e)") still belongs in 8.2.3 Sending point-to-point IIH PDUs as is currently indicated in the draft. Les -----Original Message----- From: Philip Christian To: 'Tony Przygienda'; Les Ginsberg Cc: Rajesh Saluja; 'isis-wg@spider.juniper.net'; 'dkatz@juniper.net' Sent: 12/7/01 2:13 AM Subject: RE: [Isis-wg] Concerns with 3-way-handshake To be fair to Les, it was me that started the scare. I did misunderstand what was going on, however it will hopefully result in a better RFC. This text of Les' Add a clause e) to the end of Section 8.2.3: "Set the state to be reported in the Adjacency State field of the Point-to-Point Adjacency State option to down." Presumably this is to be added to what is already there in the draft, making the complete text:- "Add a clause e) to the end of section 8.2.3: The IS shall include the Point-to-Point Adjacency State option in the transmitted Point-to-Point IIH PDU. The current state of the adjacency with its neighbor on the link (as defined in section 8.2.4.1.1) shall be reported in the Adjacency State field. If no adjacency exists, the state shall be reported as Down. The Extended Local Circuit ID field shall contain a value assigned by this IS when the circuit is created. This value shall be unique among all the circuits of this Intermediate System. The value is not necessarily related to that carried in the Local Circuit ID field of the IIH PDU. If the system ID and Extended Local Circuit ID of the neighboring system are known (in state Initializing or Up), the neighbor's system ID shall be reported in the Neighbor System ID field, and the neighbor's Extended Local Circuit ID shall be reported in the Neighbor Extended Local Circuit ID field. Set the state to be reported in the Adjacency State field of the Point-to-Point Adjacency State option to Down." Is that right? Philip Christian. > > Sorry for heading down the wrong road previously. > good scare, everybody fell for it initially ;-) --- tony From rayq@riverstonenet.com Mon Dec 10 22:15:49 2001 From: rayq@riverstonenet.com (Ray Qiu) Date: Mon, 10 Dec 2001 14:15:49 -0800 Subject: [Isis-wg] overload bit in TE mode Message-ID: <001301c181c8$41bf1a50$0101a8c0@ray> Hi, I got a question about the overload bit in TE mode. In TE mode, the TLV 135 replaces the TLVs 128 and 130, so we can not tell if the prefix is internal or external. If we get prefixes from an overloaded router, how can we make sure that we only install the direct routes? By checking the interface address TLV? Thanks for your clarification. Regards, Ray From john@igtec.net Tue Dec 11 00:26:07 2001 From: john@igtec.net (John Greenhalgh) Date: Tue, 11 Dec 2001 01:26:07 +0100 Subject: [Isis-wg] IS-IS Resource Page Message-ID: <000001c181da$6de23740$8f60bc92@emeaops.eu.frd.uu.net> Hi, I've recently been teaching IS-IS, and put together some of the info I used at http://www.igtec.net/isis It's pretty basic and small, and not aimed directly at the audience of this list, but I would appreciate any comments, ideas, links, etc. Many Thanks, John From sachidananda_k@hotmail.com Tue Dec 11 11:04:03 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Tue, 11 Dec 2001 11:04:03 +0000 Subject: [Isis-wg] (no subject) Message-ID: Hi, I have some questions related to the waiting state. The section 7.3.19 of ISO 10589 states that IS shall enter the waiting state upon being overloaded. The waiting state timer shall be restarted every time the PDU cannot be processed due to lack of resources (I understand this would generally be memory). However, if the IS has ran out of memory, condition would persist for ever, till it is cold-rebooted (Unless some other auto-recovery mechanism is provided by OS). In either case the protocol would have to be re-started from fresh. I would like to know if the IS enters the wait state for such reasons is there any specific sequence of activities to be performed (that standard describes). Please help in this regards. Thanking you in advance. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From sachidananda_k@hotmail.com Tue Dec 11 11:04:21 2001 From: sachidananda_k@hotmail.com (Sachidananda K) Date: Tue, 11 Dec 2001 11:04:21 +0000 Subject: [Isis-wg] Waiting state Message-ID: Hi, I have some questions related to the waiting state. The section 7.3.19 of ISO 10589 states that IS shall enter the waiting state upon being overloaded. The waiting state timer shall be restarted every time the PDU cannot be processed due to lack of resources (I understand this would generally be memory). However, if the IS has ran out of memory, condition would persist for ever, till it is cold-rebooted (Unless some other auto-recovery mechanism is provided by OS). In either case the protocol would have to be re-started from fresh. I would like to know if the IS enters the wait state for such reasons is there any specific sequence of activities to be performed (that standard describes). Please help in this regards. Thanking you in advance. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From mshand@cisco.com Tue Dec 11 11:31:47 2001 From: mshand@cisco.com (mike shand) Date: Tue, 11 Dec 2001 11:31:47 +0000 Subject: [Isis-wg] Waiting state In-Reply-To: Message-ID: <4.3.2.7.2.20011211112849.00baa6b0@jaws.cisco.com> At 11:04 11/12/2001 +0000, Sachidananda K wrote: >Hi, > >I have some questions related to the waiting state. > >The section 7.3.19 of ISO 10589 states that IS shall enter the waiting >state upon being overloaded. The waiting state timer shall be restarted >every time the PDU cannot be processed due to lack of resources (I >understand this would generally be memory). > >However, if the IS has ran out of memory, condition would persist for >ever, till it is cold-rebooted (Unless some other auto-recovery mechanism >is provided by OS). In either case the protocol would have to be >re-started from fresh. > >I would like to know if the IS enters the wait state for such reasons is >there any specific sequence of activities to be performed (that standard >describes). Dynamic overload is all too possible. For example an accidental merging of areas, which are then de-merged. Or even a DR change on a large LAN. The point is that (one hopes) the memory is adequate for the steady state designed topology. If anything happens to exceed that, the waiting state will allow recovery when the perturbation is removed without requiring further intervention. Mike >Please help in this regards. >Thanking you in advance. >Sachi > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From matthew.noble@riverstonenet.com Tue Dec 11 12:10:58 2001 From: matthew.noble@riverstonenet.com (Matthew Noble) Date: Tue, 11 Dec 2001 12:10:58 -0000 Subject: [Isis-wg] IS-IS Restart draft clarification In-Reply-To: <4.3.2.7.2.20011207142041.033b1740@jaws.cisco.com> Message-ID: <000001c1823c$f1115c60$e9dc14ac@ctron.com> Mike Could I get a further clarification on this draft. The draft does not explicitly state what the meaning is for the expiration of timer T2 (as opposed to it being cancelled when we have determined that the LSP database for that level is sync'd). Can I take it that it is considered a sucess (or about as close to a success we can get at the time) and assume that at that point the LSP database for that level is sync'd? This assumes that timer T3 has not yet expired when the timer T2 expires for the given level. Thanks Matt > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Friday, December 07, 2001 2:24 PM > To: Matthew Noble > Cc: 'Isis-Wg (E-mail) > Subject: Re: [Isis-wg] IS-IS Restart draft clarification > > > At 11:25 07/12/2001 +0000, Matthew Noble wrote: > >Mike > > > >In section 4.3.1.2 second paragraph says that SPF is not run > while T3 is > >running, but in the 5th paragraph of the same section it > says that when T2 > >expires/cancelled, the SPF for that level _is_ run. Now T2 > will expire under > >normal sucessful conditions before T3 expires - so there is > a contradiction > >here. I am assuming that the info in the 5th paragraph is > correct, and that > >that in the second paragraph is wrong. > > > >Could you confirm that for me. > > Without actually looking at the draft, I think the issue is > that once we > have got synchronization we can safely run SPF at that level. > Once we have > got synchronization at both levels we can clear T3. But while > one level is > synchronized and the other is not we still need to keep T3 running. > > So yes, I think the second para is strictly wrong. > > But I'll look at it in more detail later. > > Mike > > > > >Thanks > >Matt > > > >_______________________________________________ > >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 mshand@cisco.com Tue Dec 11 12:04:08 2001 From: mshand@cisco.com (mike shand) Date: Tue, 11 Dec 2001 12:04:08 +0000 Subject: [Isis-wg] IS-IS Restart draft clarification In-Reply-To: <000001c1823c$f1115c60$e9dc14ac@ctron.com> References: <4.3.2.7.2.20011207142041.033b1740@jaws.cisco.com> Message-ID: <4.3.2.7.2.20011211120123.0336b4b0@jaws.cisco.com> At 12:10 11/12/2001 +0000, Matthew Noble wrote: >Mike > >Could I get a further clarification on this draft. > >The draft does not explicitly state what the meaning is for the expiration >of timer T2 (as opposed to it being cancelled when we have determined that >the LSP database for that level is sync'd). Can I take it that it is >considered a sucess (or about as close to a success we can get at the time) >and assume that at that point the LSP database for that level is sync'd? Yes. T2 expiration indicates that we have given up on waiting for synchronization. This "shouldn't happen", but of course there may be pathological conditions where it does, and hence we have to have some way of avoiding waiting for ever. >This assumes that timer T3 has not yet expired when the timer T2 expires for >the given level. Yes, in many cases T3 will expire before T2 does. Mike >Thanks >Matt > > > -----Original Message----- > > From: mike shand [mailto:mshand@cisco.com] > > Sent: Friday, December 07, 2001 2:24 PM > > To: Matthew Noble > > Cc: 'Isis-Wg (E-mail) > > Subject: Re: [Isis-wg] IS-IS Restart draft clarification > > > > > > At 11:25 07/12/2001 +0000, Matthew Noble wrote: > > >Mike > > > > > >In section 4.3.1.2 second paragraph says that SPF is not run > > while T3 is > > >running, but in the 5th paragraph of the same section it > > says that when T2 > > >expires/cancelled, the SPF for that level _is_ run. Now T2 > > will expire under > > >normal sucessful conditions before T3 expires - so there is > > a contradiction > > >here. I am assuming that the info in the 5th paragraph is > > correct, and that > > >that in the second paragraph is wrong. > > > > > >Could you confirm that for me. > > > > Without actually looking at the draft, I think the issue is > > that once we > > have got synchronization we can safely run SPF at that level. > > Once we have > > got synchronization at both levels we can clear T3. But while > > one level is > > synchronized and the other is not we still need to keep T3 running. > > > > So yes, I think the second para is strictly wrong. > > > > But I'll look at it in more detail later. > > > > Mike > > > > > > > > >Thanks > > >Matt > > > > > >_______________________________________________ > > >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 Tue Dec 11 14:30:16 2001 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 11 Dec 2001 09:30:16 -0500 Subject: [Isis-wg] RE: Mib Query Message-ID: > Hello, > one Query regarding IISIS-mib-6 > > isisCircLevelHelloTimer OBJECT-TYPE > SYNTAX Integer32 (10..600000) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Maximum period, in milliseconds, between > IIH PDUs on multiaccess networks at this level for > LANs. The value at level 1 is used as the period > between Hellos on point to point circuits. Setting > this value at level 2 on a point to point circuit will > result in an error of InconsistentValue. > This object follows the resettingTimer behaviour." > REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" > > Now my question is > "The value at level 1 is used as the period between > Hellos on point to point circuits" & why setting the > value at level 2 on a point-to-point circuits will > result in an error of Inconsistentvalue, & in that > case what will be the Hello timer value for > point-to-point circuits at level 2. Because nowhere in > the mib i have found any timer for that purpose, i > mean HEllo timer for point-to-point citcuits at > level2. > > definitaly we can have a point-to-point circuits at > level 2, then what value should we put for the Hello > timer for that purpose, and if we put the same value > as isisHelloTimer, why that value will be an > Inconsistent value. plz help; > > thanking u in advance. Nabendu - On a LAN, an IS will send both L1 and L2 hellos. On a p2p circuit, it will send only one. We need to have a way to define that period. I see the choices as L1 timer L2 timer New p2p timer I chose the first and attempted to document that choice. If you can suggest text that will make the choice clearer, I will be happy to add it. - jeff parker - axiowave networks From sam_isis@usa.com Tue Dec 11 20:43:13 2001 From: sam_isis@usa.com (mie lau) Date: Wed, 12 Dec 2001 04:43:13 +0800 Subject: [Isis-wg] test : please ignore Message-ID: <20011211204314.25034.qmail@mail.com> -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup 1 cent a minute calls anywhere in the U.S.! http://www.getpennytalk.com/cgi-bin/adforward.cgi?p_key=RG9853KJ&url=http://www.getpennytalk.com From Ming.Chan@SpirentCom.COM Wed Dec 12 21:57:29 2001 From: Ming.Chan@SpirentCom.COM (Chan, Chung Ming) Date: Wed, 12 Dec 2001 11:57:29 -1000 Subject: [Isis-wg] State transition diagram?? Message-ID: <8AC36D3167EED41184C800508BD9540501EE3CA3@apollo.adtech-inc.com> Hi, Does anyone know where I can find a state transition diagram or table for describing ISO-10589? Like in a lot of ITU's spec, there is SDL diagram to describe the state transition. Or is there anything like that exists? Thanks, Ming From shmulik@cwnt.com Mon Dec 17 08:30:06 2001 From: shmulik@cwnt.com (Shmuel Froimovich) Date: Mon, 17 Dec 2001 10:30:06 +0200 Subject: [Isis-wg] isisCircAdjChanges and isisSysOwnLSPPurges Message-ID: <95734BD21894AC4B9AEF464C5A2985EA5C9D49@bart.cwnt.com> Hi, The isisCircAdjChanges field is described in the MIB as "the number of times an adjacency state change has occurred on this circuit." However, the user might be more interested in the number of times an adjacency went in and out of the "up" state. It may not be useful to include adjacency state changes into "init" or "down" in this sum. Add to this the 3-way-handshake and you may add some more state changes. For example, when an adjacency goes up, it will traverse through the states "down", "init" and "up". When it goes down, it will go through "init" and "down". This will result in 5 state changes instead of two (which actually interest the user). While we're at it, consider the field isisSysOwnLSPPurges which describes the "number of times a zero-age copy of the system's own LSP is received from some other node". The counter's purpose is to indicate abnormal behaviors and warn against problems such as miss-configurations. Do we include also the DR purges? (a new DR purges the old DR's LSPs). This might render the counter useless for warning against network problems. Your thoughts? Thanks, Shmulik. From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From rsaluja@nortelnetworks.com Wed Dec 5 00:33:21 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Tue, 04 Dec 2001 19:33:21 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> Message-ID: <3C0D6B51.7EBB951D@nortelnetworks.com> > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > three-way-hello capable routers drop ISHs and do not send them ? The > very details of 1195 slip my mind right now but that should not cause > any backwards capability problems? > > something is definitely worth an addition to the 3-way-hello draft > > -- tony I agree with Philip's concerns. Will the following modifications be acceptable to the group: 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. 2. Reword SONET protection to SONET reprovisioning. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. If that's the case, I can add these and submit version 0.4. Best regards, Rajesh From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From dkatz@juniper.net Mon Dec 17 22:40:12 2001 From: dkatz@juniper.net (Dave Katz) Date: Mon, 17 Dec 2001 14:40:12 -0800 (PST) Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: <3C0D6B51.7EBB951D@nortelnetworks.com> (rsaluja@nortelnetworks.com) References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> <3C0D6B51.7EBB951D@nortelnetworks.com> Message-ID: <200112172240.fBHMeCq11122@cirrus.juniper.net> Hm, another old message. Something got unstuck somewhere. From: "Rajesh Saluja" X-Accept-Language: en CC: "Philip Christian" , "'isis-wg@spider.juniper.net'" , "'dkatz@juniper.net'" , "Rajesh Saluja" Content-Type: text/plain; charset=us-ascii X-Orig: Sender: isis-wg-admin@new-spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 04 Dec 2001 19:33:21 -0500 > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > three-way-hello capable routers drop ISHs and do not send them ? The > very details of 1195 slip my mind right now but that should not cause > any backwards capability problems? > > something is definitely worth an addition to the 3-way-hello draft > > -- tony I agree with Philip's concerns. Will the following modifications be acceptable to the group: 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. 2. Reword SONET protection to SONET reprovisioning. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. If that's the case, I can add these and submit version 0.4. Best regards, Rajesh _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From dkatz@juniper.net Tue Dec 18 01:51:44 2001 From: dkatz@juniper.net (Dave Katz) Date: Mon, 17 Dec 2001 17:51:44 -0800 (PST) Subject: [Isis-wg] Looping email Message-ID: <200112180151.fBI1piH12274@cirrus.juniper.net> Our sysadmins tell me that they've halted the looping email. Hopefully things will calm down soon. Sorry about that... --Dave From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From rsaluja@nortelnetworks.com Wed Dec 5 00:33:21 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Tue, 04 Dec 2001 19:33:21 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> Message-ID: <3C0D6B51.7EBB951D@nortelnetworks.com> > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > three-way-hello capable routers drop ISHs and do not send them ? The > very details of 1195 slip my mind right now but that should not cause > any backwards capability problems? > > something is definitely worth an addition to the 3-way-hello draft > > -- tony I agree with Philip's concerns. Will the following modifications be acceptable to the group: 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. 2. Reword SONET protection to SONET reprovisioning. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. If that's the case, I can add these and submit version 0.4. Best regards, Rajesh From rsaluja@nortelnetworks.com Wed Dec 5 16:03:05 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 05 Dec 2001 11:03:05 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C45071396@zhard0jd.europe.nortel.com> Message-ID: <3C0E4539.6E2E1849@nortelnetworks.com> I have a simple idea which is actually similar to option 1 described below. What if we keep the adjacency state because of ISH and because of IIH independent? The "point to point adjacency state" will be determined by IIH packets only. The ISH packets maintain the "ISH_adjacency state" which is either down or initialising and it does not play any role in the state machine implemented by three-way-handshake. This way, receipt of ISH causes ISH_adjacency state to "initialising" but point to point adjacency state is down and driven only by IIH packets. Comments? Thanks, Rajesh > > > I (and a colleague, credit where it's due) can think of a couple of > ways to solve this problem. > First we could add an explicit statement such as > > "Sending and receiving ISHs is required by Intermediate Systems that > can route CLNP packets. Intermediate Systems that cannot route CLNP > may or may not send and receive ISHs." > > Now here are the two ideas > > 1. > On Intermediate Systems where receipt of an ISH causes an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State "Down". Once an IIH has been received > then the state of the adjacency shall be reported in the option as > normal. > > or > > 2. > On Intermediate Systems where receipt of an ISH caused an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State 3 = "ISH_init" (for example). > Intermediate Systems that do not send and receive ISHs are not > required to implement reporting of this state, as they will neither > send it, nor cause a neighbour to send it back to them. We then have > to mess with the table a little, basically saying that if you support > ISHs and receive an "ISH_init" then you go to "Initialise" (rather > than "up", which was the problem). > > I think that both of these ideas allow routers that support CLNP > forwarding to also use the 3-way-handshake, without upsetting anyone > who has already stopped using ISHs on their pure IP implementations. > > I prefer idea "2", as "1" feels like the IS is misreporting the state, > and just doesn't appeal to my sense of correctness so well. > > The problem with "2" is that if you send an ISH to an IS, then you can > expect it to send back this new Adjacency State = 3 ="ISH_init" > message back. Now it seems to me that if someone just dumps incoming > ISHs then they shouldn't be trasmitting them either, but if someone > HAS implemented that, then they are going to get "3=ISH_init"s coming > back at them and won't know what to do with them (maybe that doesn't > matter anyway, as long as they don't bring the adjacency up). > > Comments? other ideas? > > Philip Christian > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: 05 December 2001 06:03 > To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH] > Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > Subject: RE: [Isis-wg] Concerns with 3-way-handshake > > Sorry folks - but IMHO you are focusing on the wrong issue. The > problem is > not ISHs, but some ambiguity in the current definition of the 3way > draft and > the fact that a number of vendors still utilize the old version of the > 3 way > handshake which only sends local adjacency state. (Please see my > earlier > mail on this subject) > > Suggesting that ISHs be ignored just creates more potential backwards > compatibility problems and ignores the real cause of the problem. That > > doesn't make sense to me. > > (The fact that some implementations already do not send ISHs has > created > compatibility problems in that implementations in strict conformance > to ISO > 10589 will not interoperate with these implementations i.e. an > implementation which expects to receive an ISH before sending an IIH > (as per > ISO 10589) will never form an adjacency with an implementation that > never > sends an ISH.) > > Les > > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@redback.com] > > Sent: Tuesday, December 04, 2001 4:35 PM > > To: Rajesh Saluja > > Cc: Philip Christian; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > > > > Rajesh Saluja wrote: > > > > > > > > > > > > > > >From my vintage, yes, it should be fixed, maybe as > > simply as saying that > > > > three-way-hello capable routers drop ISHs and do not send > > them ? The > > > > very details of 1195 slip my mind right now but that > > should not cause > > > > any backwards capability problems? > > > > > > > > something is definitely worth an addition to the > > 3-way-hello draft > > > > > > > > -- tony > > > > > > I agree with Philip's concerns. Will the following modifications > be > > > acceptable to the group: > > > 1. As Tony suggested, say that three-way-hello capable > > routers drop ISHs > > > and do not send them. > > > > you better be very carefull with the MUST and MAYs when > > writing this. As well, > > someone thinks carefully whether it won't break more than it > > fixes (although > > deployment with dropped ISHs seems to prove that it works and > > since we will > > be able to chhose whether we send/receive them, we can force > > pretty much > > this situation with the draft). > > > > thanks > > > > -- tonyt > > > > _______________________________________________ > > 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 -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From rsaluja@nortelnetworks.com Wed Dec 5 23:49:17 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 5 Dec 2001 15:49:17 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <8B888AAAAB0FD31189590008C7918443080F5269@zbl6c002.corpeast.baynetworks.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_01C17DE7.739EAA20 Content-Type: text/plain; charset="iso-8859-1" Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. [Rajesh Saluja] Les, If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH? Thanks, Rajesh ------_=_NextPart_001_01C17DE7.739EAA20 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Concerns with 3-way-handshake
 
 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change.
[Rajesh Saluja] 
Les,
If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH?
 
Thanks,
Rajesh
 
 
------_=_NextPart_001_01C17DE7.739EAA20-- From matt@Kontoff.com Fri Dec 7 14:34:43 2001 From: matt@Kontoff.com (Matthew Kontoff) Date: Fri, 07 Dec 2001 09:34:43 -0500 Subject: [Isis-wg] Replacing IS-IS Neighbors TLV , etc in TE?? References: <8AC36D3167EED41184C800508BD9540501EE3C5A@apollo.adtech-inc.com> Message-ID: <3C10D383.6BC77A0@Kontoff.com> "Chan, Chung Ming" wrote: > > Hi, > I just came across draft-ietf-isis-traffic-04.txt and read that the intent of > introducing some of new TLVs are to replace the ones defined in ISO 10589. > e.g., Extended IS Reachability TLV will replace ISIS-Neighbors (code 2) > > 1) Does it mean that if an Implementation supports this new draft, then it > SHALL not use ISIS Neighbor TLV at all? No. Whether or not the ISIS Neighbor TLV is used is up to the implementation but it is a real good idea to be backward compatible with IS-IS routers that don't support the draft. > 2) If that is the case, does any one know where I can find any info > that talks about the migration or this type of related stuff? For a migration to occur smoothly - without losing routes - you need to be able to handle both the old style IS neighbor TLV and the new style (extended IS Reachability TLV). You will need to decide which TLV you will use when running your SPF. Matt From sboddapa@hotmail.com Tue Dec 11 01:00:37 2001 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Tue, 11 Dec 2001 01:00:37 Subject: [Isis-wg] Questions on Attached Bit Message-ID:
Hi,
I have some questions regarding the use of the Attached bit. As I understand it, the Attached bit enables an L1 router to figure out how to get to the nearest L2 router.
 
1) Is it right to assume that the Attached bit is of significance in L1 LSPs only (per section 7.2.9.2 ISO 10589, the IS should regenerate its Level 1 LSP with LSP number zero)? Is there any meaning in setting this bit in L2 LSPs as well? Also, is it right to assume that this bit is of significance in LSP number zero only and should be ignored in all other LSPs? Section 7.3.4.3 ISO 10589 does not explicitly list the Attached bit as one of the fields that are meaningful only when present in LSP number zero. It would be nice if this were stated  more explicitly.
 
2) Per Technical Corrigendum 1, subclause 7.2.9.2,
 
"When executing the level 2 decision process for each supported metric, level 2 IS shall ascertain whether or not it can reach any destinations outside its area using that metric. The IS considers itself attached if either:
a) it can reach at least one other area using the corresponding metric, or
b) it has at least one enabled reachable address prefix with the corresponding metric defined.
 
Otherwise the IS considers itself not attached."
 
I am not clear on (b) in the above paragraph. Does it mean if the IS is generating at least one external route (e.g. through redistribution of some protocol routes into IS-IS), it can declare itself attached, since it is sort of like an ASBR?
 
3) Also, the restriction on being able to reach at least another area is not clear to me. Consider the following scenario.
 
 IS A(L1) -------IS B(L1L2) -------- IS C(L2) -------- IS D(L1L2)------IS E(L1)
 Area X                  Area X                 Area X                    Area Y              Area Z
 
IS A is an L1 IS with configured area X and so on.
 
In the above figure, per the requirements, B will not declare itself attached because it does not have any neighbor who belongs to another area (even though it is attached to the backbone). While IS E will be able to reach IS A because of the fact that E has a neighbor in another area, IS A wont be able to reach IS E because it does not have a default route installed pointing towards B. Is this a bad configuration? Is it required to configure B with an area that is different from C? Am I missing something?
 
Thanks in advance.
 
Regards,
 
Suresh

Get your FREE download of MSN Explorer at http://explorer.msn.com
From dkatz@juniper.net Mon Dec 17 22:35:06 2001 From: dkatz@juniper.net (Dave Katz) Date: Mon, 17 Dec 2001 14:35:06 -0800 (PST) Subject: [Isis-wg] Concerns with 3-way-handshake In-Reply-To: <4103264BC8D3D51180B7002048400C45071389@zhard0jd.europe.nortel.com> (christi@nortelnetworks.com) References: <4103264BC8D3D51180B7002048400C45071389@zhard0jd.europe.nortel.com> Message-ID: <200112172235.fBHMZ6O11096@cirrus.juniper.net> This looks like an old message (12/4) come back from the dead. From: "Philip Christian" Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17CE5.AE75DF40" Sender: isis-wg-admin@new-spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 4 Dec 2001 17:04:05 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From prz@redback.com Tue Dec 18 00:59:39 2001 From: prz@redback.com (Tony Przygienda) Date: Mon, 17 Dec 2001 16:59:39 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C45071389@zhard0jd.europe.nortel.com> Message-ID: <3C1E94FB.A60980F5@redback.com> Philip Christian wrote: > > > I have a number of concerns and comments about the 3-way-handshake draft, > draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is > about to become an RFC, although I can find no evidence of this on the RFC > editor's web page. L&G, after 20 incarnations of this e-mail (at least for me) a short explanation: Juniper moved the server around and looks like some screws came of ... Nothing I can do at the moment -- tony From christi@nortelnetworks.com Tue Dec 18 03:55:53 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 18 Dec 2001 03:55:53 -0000 Subject: [Isis-wg] Looping email Message-ID: <4103264BC8D3D51180B7002048400C450713CF@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_01C18777.E3A20A30 Content-Type: text/plain; charset="iso-8859-1" Please ignore the "Concerns with 3-way-handshake" email that the server has been spitting out, as if they were from me. Things have moved on with this particular topic, and some of the things that I said in that particular e-mail reflect the lack of understanding that I had at the time. It would appear that the list server has chosen to embarass me, or it too has concerns about three-way handshaking and felt like discussing the topic again, two weeks on. Regards, Philip Christian. -----Original Message----- From: Dave Katz [mailto:dkatz@juniper.net] Sent: 18 December 2001 01:52 To: isis-wg@spider.juniper.net Subject: [Isis-wg] Looping email Our sysadmins tell me that they've halted the looping email. Hopefully things will calm down soon. Sorry about that... --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C18777.E3A20A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Looping email

Please ignore the  "Concerns with = 3-way-handshake" email that the server has been spitting out, as = if they were from me.

Things have moved on with this particular topic, and = some of the things that I said in that particular e-mail reflect the = lack of understanding that I had at the time.

It would appear that the list server has chosen to = embarass me, or it too has concerns about three-way handshaking and = felt like discussing the topic again, two weeks on.

Regards, Philip Christian.

-----Original Message-----
From: Dave Katz [mailto:dkatz@juniper.net]
Sent: 18 December 2001 01:52
To: isis-wg@spider.juniper.net
Subject: [Isis-wg] Looping email


Our sysadmins tell me that they've halted the looping = email.  Hopefully
things will calm down soon.  Sorry about = that...

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

------_=_NextPart_001_01C18777.E3A20A30-- From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From rsaluja@nortelnetworks.com Wed Dec 5 00:33:21 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Tue, 04 Dec 2001 19:33:21 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> Message-ID: <3C0D6B51.7EBB951D@nortelnetworks.com> > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > three-way-hello capable routers drop ISHs and do not send them ? The > very details of 1195 slip my mind right now but that should not cause > any backwards capability problems? > > something is definitely worth an addition to the 3-way-hello draft > > -- tony I agree with Philip's concerns. Will the following modifications be acceptable to the group: 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. 2. Reword SONET protection to SONET reprovisioning. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. If that's the case, I can add these and submit version 0.4. Best regards, Rajesh From rsaluja@nortelnetworks.com Wed Dec 5 16:03:05 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 05 Dec 2001 11:03:05 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C45071396@zhard0jd.europe.nortel.com> Message-ID: <3C0E4539.6E2E1849@nortelnetworks.com> I have a simple idea which is actually similar to option 1 described below. What if we keep the adjacency state because of ISH and because of IIH independent? The "point to point adjacency state" will be determined by IIH packets only. The ISH packets maintain the "ISH_adjacency state" which is either down or initialising and it does not play any role in the state machine implemented by three-way-handshake. This way, receipt of ISH causes ISH_adjacency state to "initialising" but point to point adjacency state is down and driven only by IIH packets. Comments? Thanks, Rajesh > > > I (and a colleague, credit where it's due) can think of a couple of > ways to solve this problem. > First we could add an explicit statement such as > > "Sending and receiving ISHs is required by Intermediate Systems that > can route CLNP packets. Intermediate Systems that cannot route CLNP > may or may not send and receive ISHs." > > Now here are the two ideas > > 1. > On Intermediate Systems where receipt of an ISH causes an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State "Down". Once an IIH has been received > then the state of the adjacency shall be reported in the option as > normal. > > or > > 2. > On Intermediate Systems where receipt of an ISH caused an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State 3 = "ISH_init" (for example). > Intermediate Systems that do not send and receive ISHs are not > required to implement reporting of this state, as they will neither > send it, nor cause a neighbour to send it back to them. We then have > to mess with the table a little, basically saying that if you support > ISHs and receive an "ISH_init" then you go to "Initialise" (rather > than "up", which was the problem). > > I think that both of these ideas allow routers that support CLNP > forwarding to also use the 3-way-handshake, without upsetting anyone > who has already stopped using ISHs on their pure IP implementations. > > I prefer idea "2", as "1" feels like the IS is misreporting the state, > and just doesn't appeal to my sense of correctness so well. > > The problem with "2" is that if you send an ISH to an IS, then you can > expect it to send back this new Adjacency State = 3 ="ISH_init" > message back. Now it seems to me that if someone just dumps incoming > ISHs then they shouldn't be trasmitting them either, but if someone > HAS implemented that, then they are going to get "3=ISH_init"s coming > back at them and won't know what to do with them (maybe that doesn't > matter anyway, as long as they don't bring the adjacency up). > > Comments? other ideas? > > Philip Christian > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: 05 December 2001 06:03 > To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH] > Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > Subject: RE: [Isis-wg] Concerns with 3-way-handshake > > Sorry folks - but IMHO you are focusing on the wrong issue. The > problem is > not ISHs, but some ambiguity in the current definition of the 3way > draft and > the fact that a number of vendors still utilize the old version of the > 3 way > handshake which only sends local adjacency state. (Please see my > earlier > mail on this subject) > > Suggesting that ISHs be ignored just creates more potential backwards > compatibility problems and ignores the real cause of the problem. That > > doesn't make sense to me. > > (The fact that some implementations already do not send ISHs has > created > compatibility problems in that implementations in strict conformance > to ISO > 10589 will not interoperate with these implementations i.e. an > implementation which expects to receive an ISH before sending an IIH > (as per > ISO 10589) will never form an adjacency with an implementation that > never > sends an ISH.) > > Les > > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@redback.com] > > Sent: Tuesday, December 04, 2001 4:35 PM > > To: Rajesh Saluja > > Cc: Philip Christian; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > > > > Rajesh Saluja wrote: > > > > > > > > > > > > > > >From my vintage, yes, it should be fixed, maybe as > > simply as saying that > > > > three-way-hello capable routers drop ISHs and do not send > > them ? The > > > > very details of 1195 slip my mind right now but that > > should not cause > > > > any backwards capability problems? > > > > > > > > something is definitely worth an addition to the > > 3-way-hello draft > > > > > > > > -- tony > > > > > > I agree with Philip's concerns. Will the following modifications > be > > > acceptable to the group: > > > 1. As Tony suggested, say that three-way-hello capable > > routers drop ISHs > > > and do not send them. > > > > you better be very carefull with the MUST and MAYs when > > writing this. As well, > > someone thinks carefully whether it won't break more than it > > fixes (although > > deployment with dropped ISHs seems to prove that it works and > > since we will > > be able to chhose whether we send/receive them, we can force > > pretty much > > this situation with the draft). > > > > thanks > > > > -- tonyt > > > > _______________________________________________ > > 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 -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From rsaluja@nortelnetworks.com Wed Dec 5 23:49:17 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 5 Dec 2001 15:49:17 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <8B888AAAAB0FD31189590008C7918443080F5269@zbl6c002.corpeast.baynetworks.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_01C17DE7.739EAA20 Content-Type: text/plain; charset="iso-8859-1" Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. [Rajesh Saluja] Les, If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH? Thanks, Rajesh ------_=_NextPart_001_01C17DE7.739EAA20 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Concerns with 3-way-handshake
 
 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change.
[Rajesh Saluja] 
Les,
If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH?
 
Thanks,
Rajesh
 
 
------_=_NextPart_001_01C17DE7.739EAA20-- From matt@Kontoff.com Fri Dec 7 14:34:43 2001 From: matt@Kontoff.com (Matthew Kontoff) Date: Fri, 07 Dec 2001 09:34:43 -0500 Subject: [Isis-wg] Replacing IS-IS Neighbors TLV , etc in TE?? References: <8AC36D3167EED41184C800508BD9540501EE3C5A@apollo.adtech-inc.com> Message-ID: <3C10D383.6BC77A0@Kontoff.com> "Chan, Chung Ming" wrote: > > Hi, > I just came across draft-ietf-isis-traffic-04.txt and read that the intent of > introducing some of new TLVs are to replace the ones defined in ISO 10589. > e.g., Extended IS Reachability TLV will replace ISIS-Neighbors (code 2) > > 1) Does it mean that if an Implementation supports this new draft, then it > SHALL not use ISIS Neighbor TLV at all? No. Whether or not the ISIS Neighbor TLV is used is up to the implementation but it is a real good idea to be backward compatible with IS-IS routers that don't support the draft. > 2) If that is the case, does any one know where I can find any info > that talks about the migration or this type of related stuff? For a migration to occur smoothly - without losing routes - you need to be able to handle both the old style IS neighbor TLV and the new style (extended IS Reachability TLV). You will need to decide which TLV you will use when running your SPF. Matt From sboddapa@hotmail.com Tue Dec 11 01:00:37 2001 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Tue, 11 Dec 2001 01:00:37 Subject: [Isis-wg] Questions on Attached Bit Message-ID:
Hi,
I have some questions regarding the use of the Attached bit. As I understand it, the Attached bit enables an L1 router to figure out how to get to the nearest L2 router.
 
1) Is it right to assume that the Attached bit is of significance in L1 LSPs only (per section 7.2.9.2 ISO 10589, the IS should regenerate its Level 1 LSP with LSP number zero)? Is there any meaning in setting this bit in L2 LSPs as well? Also, is it right to assume that this bit is of significance in LSP number zero only and should be ignored in all other LSPs? Section 7.3.4.3 ISO 10589 does not explicitly list the Attached bit as one of the fields that are meaningful only when present in LSP number zero. It would be nice if this were stated  more explicitly.
 
2) Per Technical Corrigendum 1, subclause 7.2.9.2,
 
"When executing the level 2 decision process for each supported metric, level 2 IS shall ascertain whether or not it can reach any destinations outside its area using that metric. The IS considers itself attached if either:
a) it can reach at least one other area using the corresponding metric, or
b) it has at least one enabled reachable address prefix with the corresponding metric defined.
 
Otherwise the IS considers itself not attached."
 
I am not clear on (b) in the above paragraph. Does it mean if the IS is generating at least one external route (e.g. through redistribution of some protocol routes into IS-IS), it can declare itself attached, since it is sort of like an ASBR?
 
3) Also, the restriction on being able to reach at least another area is not clear to me. Consider the following scenario.
 
 IS A(L1) -------IS B(L1L2) -------- IS C(L2) -------- IS D(L1L2)------IS E(L1)
 Area X                  Area X                 Area X                    Area Y              Area Z
 
IS A is an L1 IS with configured area X and so on.
 
In the above figure, per the requirements, B will not declare itself attached because it does not have any neighbor who belongs to another area (even though it is attached to the backbone). While IS E will be able to reach IS A because of the fact that E has a neighbor in another area, IS A wont be able to reach IS E because it does not have a default route installed pointing towards B. Is this a bad configuration? Is it required to configure B with an area that is different from C? Am I missing something?
 
Thanks in advance.
 
Regards,
 
Suresh

Get your FREE download of MSN Explorer at http://explorer.msn.com
From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From rsaluja@nortelnetworks.com Wed Dec 5 00:33:21 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Tue, 04 Dec 2001 19:33:21 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> Message-ID: <3C0D6B51.7EBB951D@nortelnetworks.com> > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > three-way-hello capable routers drop ISHs and do not send them ? The > very details of 1195 slip my mind right now but that should not cause > any backwards capability problems? > > something is definitely worth an addition to the 3-way-hello draft > > -- tony I agree with Philip's concerns. Will the following modifications be acceptable to the group: 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. 2. Reword SONET protection to SONET reprovisioning. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. If that's the case, I can add these and submit version 0.4. Best regards, Rajesh From rsaluja@nortelnetworks.com Wed Dec 5 16:03:05 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 05 Dec 2001 11:03:05 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C45071396@zhard0jd.europe.nortel.com> Message-ID: <3C0E4539.6E2E1849@nortelnetworks.com> I have a simple idea which is actually similar to option 1 described below. What if we keep the adjacency state because of ISH and because of IIH independent? The "point to point adjacency state" will be determined by IIH packets only. The ISH packets maintain the "ISH_adjacency state" which is either down or initialising and it does not play any role in the state machine implemented by three-way-handshake. This way, receipt of ISH causes ISH_adjacency state to "initialising" but point to point adjacency state is down and driven only by IIH packets. Comments? Thanks, Rajesh > > > I (and a colleague, credit where it's due) can think of a couple of > ways to solve this problem. > First we could add an explicit statement such as > > "Sending and receiving ISHs is required by Intermediate Systems that > can route CLNP packets. Intermediate Systems that cannot route CLNP > may or may not send and receive ISHs." > > Now here are the two ideas > > 1. > On Intermediate Systems where receipt of an ISH causes an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State "Down". Once an IIH has been received > then the state of the adjacency shall be reported in the option as > normal. > > or > > 2. > On Intermediate Systems where receipt of an ISH caused an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State 3 = "ISH_init" (for example). > Intermediate Systems that do not send and receive ISHs are not > required to implement reporting of this state, as they will neither > send it, nor cause a neighbour to send it back to them. We then have > to mess with the table a little, basically saying that if you support > ISHs and receive an "ISH_init" then you go to "Initialise" (rather > than "up", which was the problem). > > I think that both of these ideas allow routers that support CLNP > forwarding to also use the 3-way-handshake, without upsetting anyone > who has already stopped using ISHs on their pure IP implementations. > > I prefer idea "2", as "1" feels like the IS is misreporting the state, > and just doesn't appeal to my sense of correctness so well. > > The problem with "2" is that if you send an ISH to an IS, then you can > expect it to send back this new Adjacency State = 3 ="ISH_init" > message back. Now it seems to me that if someone just dumps incoming > ISHs then they shouldn't be trasmitting them either, but if someone > HAS implemented that, then they are going to get "3=ISH_init"s coming > back at them and won't know what to do with them (maybe that doesn't > matter anyway, as long as they don't bring the adjacency up). > > Comments? other ideas? > > Philip Christian > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: 05 December 2001 06:03 > To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH] > Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > Subject: RE: [Isis-wg] Concerns with 3-way-handshake > > Sorry folks - but IMHO you are focusing on the wrong issue. The > problem is > not ISHs, but some ambiguity in the current definition of the 3way > draft and > the fact that a number of vendors still utilize the old version of the > 3 way > handshake which only sends local adjacency state. (Please see my > earlier > mail on this subject) > > Suggesting that ISHs be ignored just creates more potential backwards > compatibility problems and ignores the real cause of the problem. That > > doesn't make sense to me. > > (The fact that some implementations already do not send ISHs has > created > compatibility problems in that implementations in strict conformance > to ISO > 10589 will not interoperate with these implementations i.e. an > implementation which expects to receive an ISH before sending an IIH > (as per > ISO 10589) will never form an adjacency with an implementation that > never > sends an ISH.) > > Les > > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@redback.com] > > Sent: Tuesday, December 04, 2001 4:35 PM > > To: Rajesh Saluja > > Cc: Philip Christian; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > > > > Rajesh Saluja wrote: > > > > > > > > > > > > > > >From my vintage, yes, it should be fixed, maybe as > > simply as saying that > > > > three-way-hello capable routers drop ISHs and do not send > > them ? The > > > > very details of 1195 slip my mind right now but that > > should not cause > > > > any backwards capability problems? > > > > > > > > something is definitely worth an addition to the > > 3-way-hello draft > > > > > > > > -- tony > > > > > > I agree with Philip's concerns. Will the following modifications > be > > > acceptable to the group: > > > 1. As Tony suggested, say that three-way-hello capable > > routers drop ISHs > > > and do not send them. > > > > you better be very carefull with the MUST and MAYs when > > writing this. As well, > > someone thinks carefully whether it won't break more than it > > fixes (although > > deployment with dropped ISHs seems to prove that it works and > > since we will > > be able to chhose whether we send/receive them, we can force > > pretty much > > this situation with the draft). > > > > thanks > > > > -- tonyt > > > > _______________________________________________ > > 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 -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From rsaluja@nortelnetworks.com Wed Dec 5 23:49:17 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 5 Dec 2001 15:49:17 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <8B888AAAAB0FD31189590008C7918443080F5269@zbl6c002.corpeast.baynetworks.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_01C17DE7.739EAA20 Content-Type: text/plain; charset="iso-8859-1" Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. [Rajesh Saluja] Les, If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH? Thanks, Rajesh ------_=_NextPart_001_01C17DE7.739EAA20 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Concerns with 3-way-handshake
 
 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change.
[Rajesh Saluja] 
Les,
If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH?
 
Thanks,
Rajesh
 
 
------_=_NextPart_001_01C17DE7.739EAA20-- From matt@Kontoff.com Fri Dec 7 14:34:43 2001 From: matt@Kontoff.com (Matthew Kontoff) Date: Fri, 07 Dec 2001 09:34:43 -0500 Subject: [Isis-wg] Replacing IS-IS Neighbors TLV , etc in TE?? References: <8AC36D3167EED41184C800508BD9540501EE3C5A@apollo.adtech-inc.com> Message-ID: <3C10D383.6BC77A0@Kontoff.com> "Chan, Chung Ming" wrote: > > Hi, > I just came across draft-ietf-isis-traffic-04.txt and read that the intent of > introducing some of new TLVs are to replace the ones defined in ISO 10589. > e.g., Extended IS Reachability TLV will replace ISIS-Neighbors (code 2) > > 1) Does it mean that if an Implementation supports this new draft, then it > SHALL not use ISIS Neighbor TLV at all? No. Whether or not the ISIS Neighbor TLV is used is up to the implementation but it is a real good idea to be backward compatible with IS-IS routers that don't support the draft. > 2) If that is the case, does any one know where I can find any info > that talks about the migration or this type of related stuff? For a migration to occur smoothly - without losing routes - you need to be able to handle both the old style IS neighbor TLV and the new style (extended IS Reachability TLV). You will need to decide which TLV you will use when running your SPF. Matt From sboddapa@hotmail.com Tue Dec 11 01:00:37 2001 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Tue, 11 Dec 2001 01:00:37 Subject: [Isis-wg] Questions on Attached Bit Message-ID:
Hi,
I have some questions regarding the use of the Attached bit. As I understand it, the Attached bit enables an L1 router to figure out how to get to the nearest L2 router.
 
1) Is it right to assume that the Attached bit is of significance in L1 LSPs only (per section 7.2.9.2 ISO 10589, the IS should regenerate its Level 1 LSP with LSP number zero)? Is there any meaning in setting this bit in L2 LSPs as well? Also, is it right to assume that this bit is of significance in LSP number zero only and should be ignored in all other LSPs? Section 7.3.4.3 ISO 10589 does not explicitly list the Attached bit as one of the fields that are meaningful only when present in LSP number zero. It would be nice if this were stated  more explicitly.
 
2) Per Technical Corrigendum 1, subclause 7.2.9.2,
 
"When executing the level 2 decision process for each supported metric, level 2 IS shall ascertain whether or not it can reach any destinations outside its area using that metric. The IS considers itself attached if either:
a) it can reach at least one other area using the corresponding metric, or
b) it has at least one enabled reachable address prefix with the corresponding metric defined.
 
Otherwise the IS considers itself not attached."
 
I am not clear on (b) in the above paragraph. Does it mean if the IS is generating at least one external route (e.g. through redistribution of some protocol routes into IS-IS), it can declare itself attached, since it is sort of like an ASBR?
 
3) Also, the restriction on being able to reach at least another area is not clear to me. Consider the following scenario.
 
 IS A(L1) -------IS B(L1L2) -------- IS C(L2) -------- IS D(L1L2)------IS E(L1)
 Area X                  Area X                 Area X                    Area Y              Area Z
 
IS A is an L1 IS with configured area X and so on.
 
In the above figure, per the requirements, B will not declare itself attached because it does not have any neighbor who belongs to another area (even though it is attached to the backbone). While IS E will be able to reach IS A because of the fact that E has a neighbor in another area, IS A wont be able to reach IS E because it does not have a default route installed pointing towards B. Is this a bad configuration? Is it required to configure B with an area that is different from C? Am I missing something?
 
Thanks in advance.
 
Regards,
 
Suresh

Get your FREE download of MSN Explorer at http://explorer.msn.com
From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From rsaluja@nortelnetworks.com Wed Dec 5 00:33:21 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Tue, 04 Dec 2001 19:33:21 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> Message-ID: <3C0D6B51.7EBB951D@nortelnetworks.com> > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > three-way-hello capable routers drop ISHs and do not send them ? The > very details of 1195 slip my mind right now but that should not cause > any backwards capability problems? > > something is definitely worth an addition to the 3-way-hello draft > > -- tony I agree with Philip's concerns. Will the following modifications be acceptable to the group: 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. 2. Reword SONET protection to SONET reprovisioning. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. If that's the case, I can add these and submit version 0.4. Best regards, Rajesh From rsaluja@nortelnetworks.com Wed Dec 5 16:03:05 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 05 Dec 2001 11:03:05 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C45071396@zhard0jd.europe.nortel.com> Message-ID: <3C0E4539.6E2E1849@nortelnetworks.com> I have a simple idea which is actually similar to option 1 described below. What if we keep the adjacency state because of ISH and because of IIH independent? The "point to point adjacency state" will be determined by IIH packets only. The ISH packets maintain the "ISH_adjacency state" which is either down or initialising and it does not play any role in the state machine implemented by three-way-handshake. This way, receipt of ISH causes ISH_adjacency state to "initialising" but point to point adjacency state is down and driven only by IIH packets. Comments? Thanks, Rajesh > > > I (and a colleague, credit where it's due) can think of a couple of > ways to solve this problem. > First we could add an explicit statement such as > > "Sending and receiving ISHs is required by Intermediate Systems that > can route CLNP packets. Intermediate Systems that cannot route CLNP > may or may not send and receive ISHs." > > Now here are the two ideas > > 1. > On Intermediate Systems where receipt of an ISH causes an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State "Down". Once an IIH has been received > then the state of the adjacency shall be reported in the option as > normal. > > or > > 2. > On Intermediate Systems where receipt of an ISH caused an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State 3 = "ISH_init" (for example). > Intermediate Systems that do not send and receive ISHs are not > required to implement reporting of this state, as they will neither > send it, nor cause a neighbour to send it back to them. We then have > to mess with the table a little, basically saying that if you support > ISHs and receive an "ISH_init" then you go to "Initialise" (rather > than "up", which was the problem). > > I think that both of these ideas allow routers that support CLNP > forwarding to also use the 3-way-handshake, without upsetting anyone > who has already stopped using ISHs on their pure IP implementations. > > I prefer idea "2", as "1" feels like the IS is misreporting the state, > and just doesn't appeal to my sense of correctness so well. > > The problem with "2" is that if you send an ISH to an IS, then you can > expect it to send back this new Adjacency State = 3 ="ISH_init" > message back. Now it seems to me that if someone just dumps incoming > ISHs then they shouldn't be trasmitting them either, but if someone > HAS implemented that, then they are going to get "3=ISH_init"s coming > back at them and won't know what to do with them (maybe that doesn't > matter anyway, as long as they don't bring the adjacency up). > > Comments? other ideas? > > Philip Christian > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: 05 December 2001 06:03 > To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH] > Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > Subject: RE: [Isis-wg] Concerns with 3-way-handshake > > Sorry folks - but IMHO you are focusing on the wrong issue. The > problem is > not ISHs, but some ambiguity in the current definition of the 3way > draft and > the fact that a number of vendors still utilize the old version of the > 3 way > handshake which only sends local adjacency state. (Please see my > earlier > mail on this subject) > > Suggesting that ISHs be ignored just creates more potential backwards > compatibility problems and ignores the real cause of the problem. That > > doesn't make sense to me. > > (The fact that some implementations already do not send ISHs has > created > compatibility problems in that implementations in strict conformance > to ISO > 10589 will not interoperate with these implementations i.e. an > implementation which expects to receive an ISH before sending an IIH > (as per > ISO 10589) will never form an adjacency with an implementation that > never > sends an ISH.) > > Les > > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@redback.com] > > Sent: Tuesday, December 04, 2001 4:35 PM > > To: Rajesh Saluja > > Cc: Philip Christian; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > > > > Rajesh Saluja wrote: > > > > > > > > > > > > > > >From my vintage, yes, it should be fixed, maybe as > > simply as saying that > > > > three-way-hello capable routers drop ISHs and do not send > > them ? The > > > > very details of 1195 slip my mind right now but that > > should not cause > > > > any backwards capability problems? > > > > > > > > something is definitely worth an addition to the > > 3-way-hello draft > > > > > > > > -- tony > > > > > > I agree with Philip's concerns. Will the following modifications > be > > > acceptable to the group: > > > 1. As Tony suggested, say that three-way-hello capable > > routers drop ISHs > > > and do not send them. > > > > you better be very carefull with the MUST and MAYs when > > writing this. As well, > > someone thinks carefully whether it won't break more than it > > fixes (although > > deployment with dropped ISHs seems to prove that it works and > > since we will > > be able to chhose whether we send/receive them, we can force > > pretty much > > this situation with the draft). > > > > thanks > > > > -- tonyt > > > > _______________________________________________ > > 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 -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From rsaluja@nortelnetworks.com Wed Dec 5 23:49:17 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 5 Dec 2001 15:49:17 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <8B888AAAAB0FD31189590008C7918443080F5269@zbl6c002.corpeast.baynetworks.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_01C17DE7.739EAA20 Content-Type: text/plain; charset="iso-8859-1" Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. [Rajesh Saluja] Les, If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH? Thanks, Rajesh ------_=_NextPart_001_01C17DE7.739EAA20 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Concerns with 3-way-handshake
 
 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change.
[Rajesh Saluja] 
Les,
If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH?
 
Thanks,
Rajesh
 
 
------_=_NextPart_001_01C17DE7.739EAA20-- From matt@Kontoff.com Fri Dec 7 14:34:43 2001 From: matt@Kontoff.com (Matthew Kontoff) Date: Fri, 07 Dec 2001 09:34:43 -0500 Subject: [Isis-wg] Replacing IS-IS Neighbors TLV , etc in TE?? References: <8AC36D3167EED41184C800508BD9540501EE3C5A@apollo.adtech-inc.com> Message-ID: <3C10D383.6BC77A0@Kontoff.com> "Chan, Chung Ming" wrote: > > Hi, > I just came across draft-ietf-isis-traffic-04.txt and read that the intent of > introducing some of new TLVs are to replace the ones defined in ISO 10589. > e.g., Extended IS Reachability TLV will replace ISIS-Neighbors (code 2) > > 1) Does it mean that if an Implementation supports this new draft, then it > SHALL not use ISIS Neighbor TLV at all? No. Whether or not the ISIS Neighbor TLV is used is up to the implementation but it is a real good idea to be backward compatible with IS-IS routers that don't support the draft. > 2) If that is the case, does any one know where I can find any info > that talks about the migration or this type of related stuff? For a migration to occur smoothly - without losing routes - you need to be able to handle both the old style IS neighbor TLV and the new style (extended IS Reachability TLV). You will need to decide which TLV you will use when running your SPF. Matt From sboddapa@hotmail.com Tue Dec 11 01:00:37 2001 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Tue, 11 Dec 2001 01:00:37 Subject: [Isis-wg] Questions on Attached Bit Message-ID:
Hi,
I have some questions regarding the use of the Attached bit. As I understand it, the Attached bit enables an L1 router to figure out how to get to the nearest L2 router.
 
1) Is it right to assume that the Attached bit is of significance in L1 LSPs only (per section 7.2.9.2 ISO 10589, the IS should regenerate its Level 1 LSP with LSP number zero)? Is there any meaning in setting this bit in L2 LSPs as well? Also, is it right to assume that this bit is of significance in LSP number zero only and should be ignored in all other LSPs? Section 7.3.4.3 ISO 10589 does not explicitly list the Attached bit as one of the fields that are meaningful only when present in LSP number zero. It would be nice if this were stated  more explicitly.
 
2) Per Technical Corrigendum 1, subclause 7.2.9.2,
 
"When executing the level 2 decision process for each supported metric, level 2 IS shall ascertain whether or not it can reach any destinations outside its area using that metric. The IS considers itself attached if either:
a) it can reach at least one other area using the corresponding metric, or
b) it has at least one enabled reachable address prefix with the corresponding metric defined.
 
Otherwise the IS considers itself not attached."
 
I am not clear on (b) in the above paragraph. Does it mean if the IS is generating at least one external route (e.g. through redistribution of some protocol routes into IS-IS), it can declare itself attached, since it is sort of like an ASBR?
 
3) Also, the restriction on being able to reach at least another area is not clear to me. Consider the following scenario.
 
 IS A(L1) -------IS B(L1L2) -------- IS C(L2) -------- IS D(L1L2)------IS E(L1)
 Area X                  Area X                 Area X                    Area Y              Area Z
 
IS A is an L1 IS with configured area X and so on.
 
In the above figure, per the requirements, B will not declare itself attached because it does not have any neighbor who belongs to another area (even though it is attached to the backbone). While IS E will be able to reach IS A because of the fact that E has a neighbor in another area, IS A wont be able to reach IS E because it does not have a default route installed pointing towards B. Is this a bad configuration? Is it required to configure B with an area that is different from C? Am I missing something?
 
Thanks in advance.
 
Regards,
 
Suresh

Get your FREE download of MSN Explorer at http://explorer.msn.com
From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From rsaluja@nortelnetworks.com Wed Dec 5 00:33:21 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Tue, 04 Dec 2001 19:33:21 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> Message-ID: <3C0D6B51.7EBB951D@nortelnetworks.com> > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > three-way-hello capable routers drop ISHs and do not send them ? The > very details of 1195 slip my mind right now but that should not cause > any backwards capability problems? > > something is definitely worth an addition to the 3-way-hello draft > > -- tony I agree with Philip's concerns. Will the following modifications be acceptable to the group: 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. 2. Reword SONET protection to SONET reprovisioning. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. If that's the case, I can add these and submit version 0.4. Best regards, Rajesh From rsaluja@nortelnetworks.com Wed Dec 5 16:03:05 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 05 Dec 2001 11:03:05 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C45071396@zhard0jd.europe.nortel.com> Message-ID: <3C0E4539.6E2E1849@nortelnetworks.com> I have a simple idea which is actually similar to option 1 described below. What if we keep the adjacency state because of ISH and because of IIH independent? The "point to point adjacency state" will be determined by IIH packets only. The ISH packets maintain the "ISH_adjacency state" which is either down or initialising and it does not play any role in the state machine implemented by three-way-handshake. This way, receipt of ISH causes ISH_adjacency state to "initialising" but point to point adjacency state is down and driven only by IIH packets. Comments? Thanks, Rajesh > > > I (and a colleague, credit where it's due) can think of a couple of > ways to solve this problem. > First we could add an explicit statement such as > > "Sending and receiving ISHs is required by Intermediate Systems that > can route CLNP packets. Intermediate Systems that cannot route CLNP > may or may not send and receive ISHs." > > Now here are the two ideas > > 1. > On Intermediate Systems where receipt of an ISH causes an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State "Down". Once an IIH has been received > then the state of the adjacency shall be reported in the option as > normal. > > or > > 2. > On Intermediate Systems where receipt of an ISH caused an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State 3 = "ISH_init" (for example). > Intermediate Systems that do not send and receive ISHs are not > required to implement reporting of this state, as they will neither > send it, nor cause a neighbour to send it back to them. We then have > to mess with the table a little, basically saying that if you support > ISHs and receive an "ISH_init" then you go to "Initialise" (rather > than "up", which was the problem). > > I think that both of these ideas allow routers that support CLNP > forwarding to also use the 3-way-handshake, without upsetting anyone > who has already stopped using ISHs on their pure IP implementations. > > I prefer idea "2", as "1" feels like the IS is misreporting the state, > and just doesn't appeal to my sense of correctness so well. > > The problem with "2" is that if you send an ISH to an IS, then you can > expect it to send back this new Adjacency State = 3 ="ISH_init" > message back. Now it seems to me that if someone just dumps incoming > ISHs then they shouldn't be trasmitting them either, but if someone > HAS implemented that, then they are going to get "3=ISH_init"s coming > back at them and won't know what to do with them (maybe that doesn't > matter anyway, as long as they don't bring the adjacency up). > > Comments? other ideas? > > Philip Christian > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: 05 December 2001 06:03 > To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH] > Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > Subject: RE: [Isis-wg] Concerns with 3-way-handshake > > Sorry folks - but IMHO you are focusing on the wrong issue. The > problem is > not ISHs, but some ambiguity in the current definition of the 3way > draft and > the fact that a number of vendors still utilize the old version of the > 3 way > handshake which only sends local adjacency state. (Please see my > earlier > mail on this subject) > > Suggesting that ISHs be ignored just creates more potential backwards > compatibility problems and ignores the real cause of the problem. That > > doesn't make sense to me. > > (The fact that some implementations already do not send ISHs has > created > compatibility problems in that implementations in strict conformance > to ISO > 10589 will not interoperate with these implementations i.e. an > implementation which expects to receive an ISH before sending an IIH > (as per > ISO 10589) will never form an adjacency with an implementation that > never > sends an ISH.) > > Les > > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@redback.com] > > Sent: Tuesday, December 04, 2001 4:35 PM > > To: Rajesh Saluja > > Cc: Philip Christian; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > > > > Rajesh Saluja wrote: > > > > > > > > > > > > > > >From my vintage, yes, it should be fixed, maybe as > > simply as saying that > > > > three-way-hello capable routers drop ISHs and do not send > > them ? The > > > > very details of 1195 slip my mind right now but that > > should not cause > > > > any backwards capability problems? > > > > > > > > something is definitely worth an addition to the > > 3-way-hello draft > > > > > > > > -- tony > > > > > > I agree with Philip's concerns. Will the following modifications > be > > > acceptable to the group: > > > 1. As Tony suggested, say that three-way-hello capable > > routers drop ISHs > > > and do not send them. > > > > you better be very carefull with the MUST and MAYs when > > writing this. As well, > > someone thinks carefully whether it won't break more than it > > fixes (although > > deployment with dropped ISHs seems to prove that it works and > > since we will > > be able to chhose whether we send/receive them, we can force > > pretty much > > this situation with the draft). > > > > thanks > > > > -- tonyt > > > > _______________________________________________ > > 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 -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From rsaluja@nortelnetworks.com Wed Dec 5 23:49:17 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 5 Dec 2001 15:49:17 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <8B888AAAAB0FD31189590008C7918443080F5269@zbl6c002.corpeast.baynetworks.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_01C17DE7.739EAA20 Content-Type: text/plain; charset="iso-8859-1" Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. [Rajesh Saluja] Les, If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH? Thanks, Rajesh ------_=_NextPart_001_01C17DE7.739EAA20 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Concerns with 3-way-handshake
 
 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change.
[Rajesh Saluja] 
Les,
If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH?
 
Thanks,
Rajesh
 
 
------_=_NextPart_001_01C17DE7.739EAA20-- From matt@Kontoff.com Fri Dec 7 14:34:43 2001 From: matt@Kontoff.com (Matthew Kontoff) Date: Fri, 07 Dec 2001 09:34:43 -0500 Subject: [Isis-wg] Replacing IS-IS Neighbors TLV , etc in TE?? References: <8AC36D3167EED41184C800508BD9540501EE3C5A@apollo.adtech-inc.com> Message-ID: <3C10D383.6BC77A0@Kontoff.com> "Chan, Chung Ming" wrote: > > Hi, > I just came across draft-ietf-isis-traffic-04.txt and read that the intent of > introducing some of new TLVs are to replace the ones defined in ISO 10589. > e.g., Extended IS Reachability TLV will replace ISIS-Neighbors (code 2) > > 1) Does it mean that if an Implementation supports this new draft, then it > SHALL not use ISIS Neighbor TLV at all? No. Whether or not the ISIS Neighbor TLV is used is up to the implementation but it is a real good idea to be backward compatible with IS-IS routers that don't support the draft. > 2) If that is the case, does any one know where I can find any info > that talks about the migration or this type of related stuff? For a migration to occur smoothly - without losing routes - you need to be able to handle both the old style IS neighbor TLV and the new style (extended IS Reachability TLV). You will need to decide which TLV you will use when running your SPF. Matt From sboddapa@hotmail.com Tue Dec 11 01:00:37 2001 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Tue, 11 Dec 2001 01:00:37 Subject: [Isis-wg] Questions on Attached Bit Message-ID:
Hi,
I have some questions regarding the use of the Attached bit. As I understand it, the Attached bit enables an L1 router to figure out how to get to the nearest L2 router.
 
1) Is it right to assume that the Attached bit is of significance in L1 LSPs only (per section 7.2.9.2 ISO 10589, the IS should regenerate its Level 1 LSP with LSP number zero)? Is there any meaning in setting this bit in L2 LSPs as well? Also, is it right to assume that this bit is of significance in LSP number zero only and should be ignored in all other LSPs? Section 7.3.4.3 ISO 10589 does not explicitly list the Attached bit as one of the fields that are meaningful only when present in LSP number zero. It would be nice if this were stated  more explicitly.
 
2) Per Technical Corrigendum 1, subclause 7.2.9.2,
 
"When executing the level 2 decision process for each supported metric, level 2 IS shall ascertain whether or not it can reach any destinations outside its area using that metric. The IS considers itself attached if either:
a) it can reach at least one other area using the corresponding metric, or
b) it has at least one enabled reachable address prefix with the corresponding metric defined.
 
Otherwise the IS considers itself not attached."
 
I am not clear on (b) in the above paragraph. Does it mean if the IS is generating at least one external route (e.g. through redistribution of some protocol routes into IS-IS), it can declare itself attached, since it is sort of like an ASBR?
 
3) Also, the restriction on being able to reach at least another area is not clear to me. Consider the following scenario.
 
 IS A(L1) -------IS B(L1L2) -------- IS C(L2) -------- IS D(L1L2)------IS E(L1)
 Area X                  Area X                 Area X                    Area Y              Area Z
 
IS A is an L1 IS with configured area X and so on.
 
In the above figure, per the requirements, B will not declare itself attached because it does not have any neighbor who belongs to another area (even though it is attached to the backbone). While IS E will be able to reach IS A because of the fact that E has a neighbor in another area, IS A wont be able to reach IS E because it does not have a default route installed pointing towards B. Is this a bad configuration? Is it required to configure B with an area that is different from C? Am I missing something?
 
Thanks in advance.
 
Regards,
 
Suresh

Get your FREE download of MSN Explorer at http://explorer.msn.com
From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From rsaluja@nortelnetworks.com Wed Dec 5 00:33:21 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Tue, 04 Dec 2001 19:33:21 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> Message-ID: <3C0D6B51.7EBB951D@nortelnetworks.com> > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > three-way-hello capable routers drop ISHs and do not send them ? The > very details of 1195 slip my mind right now but that should not cause > any backwards capability problems? > > something is definitely worth an addition to the 3-way-hello draft > > -- tony I agree with Philip's concerns. Will the following modifications be acceptable to the group: 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. 2. Reword SONET protection to SONET reprovisioning. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. If that's the case, I can add these and submit version 0.4. Best regards, Rajesh From rsaluja@nortelnetworks.com Wed Dec 5 16:03:05 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 05 Dec 2001 11:03:05 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C45071396@zhard0jd.europe.nortel.com> Message-ID: <3C0E4539.6E2E1849@nortelnetworks.com> I have a simple idea which is actually similar to option 1 described below. What if we keep the adjacency state because of ISH and because of IIH independent? The "point to point adjacency state" will be determined by IIH packets only. The ISH packets maintain the "ISH_adjacency state" which is either down or initialising and it does not play any role in the state machine implemented by three-way-handshake. This way, receipt of ISH causes ISH_adjacency state to "initialising" but point to point adjacency state is down and driven only by IIH packets. Comments? Thanks, Rajesh > > > I (and a colleague, credit where it's due) can think of a couple of > ways to solve this problem. > First we could add an explicit statement such as > > "Sending and receiving ISHs is required by Intermediate Systems that > can route CLNP packets. Intermediate Systems that cannot route CLNP > may or may not send and receive ISHs." > > Now here are the two ideas > > 1. > On Intermediate Systems where receipt of an ISH causes an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State "Down". Once an IIH has been received > then the state of the adjacency shall be reported in the option as > normal. > > or > > 2. > On Intermediate Systems where receipt of an ISH caused an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State 3 = "ISH_init" (for example). > Intermediate Systems that do not send and receive ISHs are not > required to implement reporting of this state, as they will neither > send it, nor cause a neighbour to send it back to them. We then have > to mess with the table a little, basically saying that if you support > ISHs and receive an "ISH_init" then you go to "Initialise" (rather > than "up", which was the problem). > > I think that both of these ideas allow routers that support CLNP > forwarding to also use the 3-way-handshake, without upsetting anyone > who has already stopped using ISHs on their pure IP implementations. > > I prefer idea "2", as "1" feels like the IS is misreporting the state, > and just doesn't appeal to my sense of correctness so well. > > The problem with "2" is that if you send an ISH to an IS, then you can > expect it to send back this new Adjacency State = 3 ="ISH_init" > message back. Now it seems to me that if someone just dumps incoming > ISHs then they shouldn't be trasmitting them either, but if someone > HAS implemented that, then they are going to get "3=ISH_init"s coming > back at them and won't know what to do with them (maybe that doesn't > matter anyway, as long as they don't bring the adjacency up). > > Comments? other ideas? > > Philip Christian > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: 05 December 2001 06:03 > To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH] > Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > Subject: RE: [Isis-wg] Concerns with 3-way-handshake > > Sorry folks - but IMHO you are focusing on the wrong issue. The > problem is > not ISHs, but some ambiguity in the current definition of the 3way > draft and > the fact that a number of vendors still utilize the old version of the > 3 way > handshake which only sends local adjacency state. (Please see my > earlier > mail on this subject) > > Suggesting that ISHs be ignored just creates more potential backwards > compatibility problems and ignores the real cause of the problem. That > > doesn't make sense to me. > > (The fact that some implementations already do not send ISHs has > created > compatibility problems in that implementations in strict conformance > to ISO > 10589 will not interoperate with these implementations i.e. an > implementation which expects to receive an ISH before sending an IIH > (as per > ISO 10589) will never form an adjacency with an implementation that > never > sends an ISH.) > > Les > > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@redback.com] > > Sent: Tuesday, December 04, 2001 4:35 PM > > To: Rajesh Saluja > > Cc: Philip Christian; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > > > > Rajesh Saluja wrote: > > > > > > > > > > > > > > >From my vintage, yes, it should be fixed, maybe as > > simply as saying that > > > > three-way-hello capable routers drop ISHs and do not send > > them ? The > > > > very details of 1195 slip my mind right now but that > > should not cause > > > > any backwards capability problems? > > > > > > > > something is definitely worth an addition to the > > 3-way-hello draft > > > > > > > > -- tony > > > > > > I agree with Philip's concerns. Will the following modifications > be > > > acceptable to the group: > > > 1. As Tony suggested, say that three-way-hello capable > > routers drop ISHs > > > and do not send them. > > > > you better be very carefull with the MUST and MAYs when > > writing this. As well, > > someone thinks carefully whether it won't break more than it > > fixes (although > > deployment with dropped ISHs seems to prove that it works and > > since we will > > be able to chhose whether we send/receive them, we can force > > pretty much > > this situation with the draft). > > > > thanks > > > > -- tonyt > > > > _______________________________________________ > > 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 -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From rsaluja@nortelnetworks.com Wed Dec 5 23:49:17 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 5 Dec 2001 15:49:17 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <8B888AAAAB0FD31189590008C7918443080F5269@zbl6c002.corpeast.baynetworks.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_01C17DE7.739EAA20 Content-Type: text/plain; charset="iso-8859-1" Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. [Rajesh Saluja] Les, If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH? Thanks, Rajesh ------_=_NextPart_001_01C17DE7.739EAA20 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Concerns with 3-way-handshake
 
 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change.
[Rajesh Saluja] 
Les,
If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH?
 
Thanks,
Rajesh
 
 
------_=_NextPart_001_01C17DE7.739EAA20-- From matt@Kontoff.com Fri Dec 7 14:34:43 2001 From: matt@Kontoff.com (Matthew Kontoff) Date: Fri, 07 Dec 2001 09:34:43 -0500 Subject: [Isis-wg] Replacing IS-IS Neighbors TLV , etc in TE?? References: <8AC36D3167EED41184C800508BD9540501EE3C5A@apollo.adtech-inc.com> Message-ID: <3C10D383.6BC77A0@Kontoff.com> "Chan, Chung Ming" wrote: > > Hi, > I just came across draft-ietf-isis-traffic-04.txt and read that the intent of > introducing some of new TLVs are to replace the ones defined in ISO 10589. > e.g., Extended IS Reachability TLV will replace ISIS-Neighbors (code 2) > > 1) Does it mean that if an Implementation supports this new draft, then it > SHALL not use ISIS Neighbor TLV at all? No. Whether or not the ISIS Neighbor TLV is used is up to the implementation but it is a real good idea to be backward compatible with IS-IS routers that don't support the draft. > 2) If that is the case, does any one know where I can find any info > that talks about the migration or this type of related stuff? For a migration to occur smoothly - without losing routes - you need to be able to handle both the old style IS neighbor TLV and the new style (extended IS Reachability TLV). You will need to decide which TLV you will use when running your SPF. Matt From sboddapa@hotmail.com Tue Dec 11 01:00:37 2001 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Tue, 11 Dec 2001 01:00:37 Subject: [Isis-wg] Questions on Attached Bit Message-ID:
Hi,
I have some questions regarding the use of the Attached bit. As I understand it, the Attached bit enables an L1 router to figure out how to get to the nearest L2 router.
 
1) Is it right to assume that the Attached bit is of significance in L1 LSPs only (per section 7.2.9.2 ISO 10589, the IS should regenerate its Level 1 LSP with LSP number zero)? Is there any meaning in setting this bit in L2 LSPs as well? Also, is it right to assume that this bit is of significance in LSP number zero only and should be ignored in all other LSPs? Section 7.3.4.3 ISO 10589 does not explicitly list the Attached bit as one of the fields that are meaningful only when present in LSP number zero. It would be nice if this were stated  more explicitly.
 
2) Per Technical Corrigendum 1, subclause 7.2.9.2,
 
"When executing the level 2 decision process for each supported metric, level 2 IS shall ascertain whether or not it can reach any destinations outside its area using that metric. The IS considers itself attached if either:
a) it can reach at least one other area using the corresponding metric, or
b) it has at least one enabled reachable address prefix with the corresponding metric defined.
 
Otherwise the IS considers itself not attached."
 
I am not clear on (b) in the above paragraph. Does it mean if the IS is generating at least one external route (e.g. through redistribution of some protocol routes into IS-IS), it can declare itself attached, since it is sort of like an ASBR?
 
3) Also, the restriction on being able to reach at least another area is not clear to me. Consider the following scenario.
 
 IS A(L1) -------IS B(L1L2) -------- IS C(L2) -------- IS D(L1L2)------IS E(L1)
 Area X                  Area X                 Area X                    Area Y              Area Z
 
IS A is an L1 IS with configured area X and so on.
 
In the above figure, per the requirements, B will not declare itself attached because it does not have any neighbor who belongs to another area (even though it is attached to the backbone). While IS E will be able to reach IS A because of the fact that E has a neighbor in another area, IS A wont be able to reach IS E because it does not have a default route installed pointing towards B. Is this a bad configuration? Is it required to configure B with an area that is different from C? Am I missing something?
 
Thanks in advance.
 
Regards,
 
Suresh

Get your FREE download of MSN Explorer at http://explorer.msn.com
From christi@nortelnetworks.com Tue Dec 4 17:04:05 2001 From: christi@nortelnetworks.com (Philip Christian) Date: Tue, 4 Dec 2001 17:04:05 -0000 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <4103264BC8D3D51180B7002048400C45071389@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_01C17CE5.AE75DF40 Content-Type: text/plain; charset="iso-8859-1" I have a number of concerns and comments about the 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember hearing that this draft is about to become an RFC, although I can find no evidence of this on the RFC editor's web page. Here are my concerns. This draft specifically declares itself to be useful in SONET networks (presumably in the embedded DCC channels, although this is not stated). However I believe that there is an area of ambiguity in it which reduces its usefulness somewhat. The draft mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH is not mentioned either) are currently based on CLNS and therefore the NEs transmit ISH packets too. I understand that an old CLNS SONET/SDH node will not support three-way handshaking anyway, and so a new neighbour would engage legacy mode anyway, BUT.... With the advent of G.7712 vendors will be looking at implementing dual IP and CLNS routers that are able to still interface to the old CLNS nodes, and which also support three way handshaking. Such a new dual node may well need to declare itself a CLNS End System, and so will be transmitting ISHs. This will be necessary to terminate RFC 3147 encapsulated packets, for example. The problem is that I believe that receipt of ISH packets "short circuits" the three way handshake, and results in the adjacency coming up whether the neighbour has received IIHs, or not. This is my understanding of the problem: A is connected to B and issues an ISH. B receives the ISH, and according to ISO 10589 section 8.2.2 creates an adjacency of type "Initialising". B now reports to A in the new "Point to point adjacency state" option that the adjacency is "Initialising". A receives this and according to the table in the draft, brings the adjacency "up". However B may never have received an IIH from A and so the three way handshake has been short circuited, or have I misunderstood something? The draft really needs to state how a router with three way handshaking should handle receipt of an ISH from a neighbouring IS that also supports the option. I guess that this is not a problem for pure IP routers if they ignore ISHs, and this could be stated. Next concern; what happened to ISHs anyway? RFC 1195 states in section 4.4 "For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.". There is a similar statement in section 5.1. I am told that many implementors do not transmit ISH packets anymore, as they cannot terminate CLNP and thus are not an CLNS End System anymore. This seems perfectly logical to me, but, if this is the case then I think that this draft should state it. It is the after-all going to be (hopefully) the first RFC to actually alter the adjacency creation process from ISO 10589; RFC 1195 did not change it. If it is now okay not to transmit ISHs then let's say so. I think that this issues could be addressed just in a few sentences, once we have agreed how to handle ISHs on nodes that need to. I am ready to help with some drafting in order to help get this right. Regards, Philip Christian. ------_=_NextPart_001_01C17CE5.AE75DF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerns with 3-way-handshake

I have a number of concerns and comments about the = 3-way-handshake draft, draft-ietf-isis-3way-03.txt. I'm sure I remember = hearing that this draft is about to become an RFC, although I can find = no evidence of this on the RFC editor's web page.

Here are my concerns.

This draft specifically declares itself to be useful = in SONET networks (presumably in the embedded DCC channels, although = this is not stated). However I believe that there is an area of = ambiguity in it which reduces its usefulness somewhat. The draft = mentions only IIH packets, where as SONET and SDH networks (oh yes, SDH = is not mentioned either) are currently based on CLNS and therefore the = NEs transmit ISH packets too.

I understand that an old CLNS SONET/SDH node will not = support three-way handshaking anyway, and so a new neighbour would = engage legacy mode anyway, BUT....

With the advent of G.7712 vendors will be looking at = implementing dual IP and CLNS routers that are able to still interface = to the old CLNS nodes, and which also support three way handshaking. = Such a new dual node may well need to declare itself a CLNS End System, = and so will be transmitting ISHs. This will be necessary to terminate = RFC 3147 encapsulated packets, for example.

The problem is that I believe that receipt of ISH = packets "short circuits" the three way handshake, and results = in the adjacency coming up whether the neighbour has received  = IIHs, or not. This is my understanding of the problem:

A is connected to B and issues an ISH.
B receives the ISH, and according to ISO 10589 = section 8.2.2 creates an adjacency of type = "Initialising".
B now reports to A in the new "Point to point = adjacency state" option that the adjacency is = "Initialising".
A receives this and according to the table in the = draft, brings the adjacency "up".
However B may never have received an IIH from A and = so the three way handshake has been short circuited, or have I = misunderstood something?

The draft really needs to state how a router with = three way handshaking should handle receipt of an ISH from a = neighbouring IS that also supports the option.

I guess that this is not a problem for pure IP = routers if they ignore ISHs, and this could be stated.

Next concern; what happened to ISHs anyway? RFC 1195 = states in section 4.4 "For point-to-point links, IS-IS requires = exchange of ISO 9542 ISHs, as the first step in establishing the link = between routers. All IS-IS routers are therefore required to transmit = and receive ISO 9542 ISH packets on point-to-point links.". There = is a similar statement in section 5.1.

I am told that many implementors do not transmit ISH = packets anymore, as they cannot terminate CLNP and thus are not an CLNS = End System anymore.

This seems perfectly logical to me, but, if this is = the case then I think that this draft should state it. It is the = after-all going to be (hopefully) the first RFC to actually alter the = adjacency creation process from ISO 10589; RFC 1195 did not change it. = If it is now okay not to transmit ISHs then let's say so.

I think that this issues could be addressed just in a = few sentences, once we have agreed how to handle ISHs on nodes that = need to. I am ready to help with some drafting in order to help get = this right.

Regards, Philip Christian.

------_=_NextPart_001_01C17CE5.AE75DF40-- From rsaluja@nortelnetworks.com Wed Dec 5 00:33:21 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Tue, 04 Dec 2001 19:33:21 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C4507138D@zhard0jd.europe.nortel.com> <3C0D12CA.2B982FCB@redback.com> Message-ID: <3C0D6B51.7EBB951D@nortelnetworks.com> > > > >From my vintage, yes, it should be fixed, maybe as simply as saying that > three-way-hello capable routers drop ISHs and do not send them ? The > very details of 1195 slip my mind right now but that should not cause > any backwards capability problems? > > something is definitely worth an addition to the 3-way-hello draft > > -- tony I agree with Philip's concerns. Will the following modifications be acceptable to the group: 1. As Tony suggested, say that three-way-hello capable routers drop ISHs and do not send them. 2. Reword SONET protection to SONET reprovisioning. 3. Allowing length of option from 1 (not 5) to 17 octets so that it can work with old three way implementations. If that's the case, I can add these and submit version 0.4. Best regards, Rajesh From rsaluja@nortelnetworks.com Wed Dec 5 16:03:05 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 05 Dec 2001 11:03:05 -0500 Subject: [Isis-wg] Concerns with 3-way-handshake References: <4103264BC8D3D51180B7002048400C45071396@zhard0jd.europe.nortel.com> Message-ID: <3C0E4539.6E2E1849@nortelnetworks.com> I have a simple idea which is actually similar to option 1 described below. What if we keep the adjacency state because of ISH and because of IIH independent? The "point to point adjacency state" will be determined by IIH packets only. The ISH packets maintain the "ISH_adjacency state" which is either down or initialising and it does not play any role in the state machine implemented by three-way-handshake. This way, receipt of ISH causes ISH_adjacency state to "initialising" but point to point adjacency state is down and driven only by IIH packets. Comments? Thanks, Rajesh > > > I (and a colleague, credit where it's due) can think of a couple of > ways to solve this problem. > First we could add an explicit statement such as > > "Sending and receiving ISHs is required by Intermediate Systems that > can route CLNP packets. Intermediate Systems that cannot route CLNP > may or may not send and receive ISHs." > > Now here are the two ideas > > 1. > On Intermediate Systems where receipt of an ISH causes an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State "Down". Once an IIH has been received > then the state of the adjacency shall be reported in the option as > normal. > > or > > 2. > On Intermediate Systems where receipt of an ISH caused an adjacency to > start in the "initialise" state, and which support the "Point-to-Point > Adjacency State" option, such an adjacency will be reported in the > option as being Adjacency State 3 = "ISH_init" (for example). > Intermediate Systems that do not send and receive ISHs are not > required to implement reporting of this state, as they will neither > send it, nor cause a neighbour to send it back to them. We then have > to mess with the table a little, basically saying that if you support > ISHs and receive an "ISH_init" then you go to "Initialise" (rather > than "up", which was the problem). > > I think that both of these ideas allow routers that support CLNP > forwarding to also use the 3-way-handshake, without upsetting anyone > who has already stopped using ISHs on their pure IP implementations. > > I prefer idea "2", as "1" feels like the IS is misreporting the state, > and just doesn't appeal to my sense of correctness so well. > > The problem with "2" is that if you send an ISH to an IS, then you can > expect it to send back this new Adjacency State = 3 ="ISH_init" > message back. Now it seems to me that if someone just dumps incoming > ISHs then they shouldn't be trasmitting them either, but if someone > HAS implemented that, then they are going to get "3=ISH_init"s coming > back at them and won't know what to do with them (maybe that doesn't > matter anyway, as long as they don't bring the adjacency up). > > Comments? other ideas? > > Philip Christian > > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: 05 December 2001 06:03 > To: 'Tony Przygienda'; Saluja, Rajesh [BL60:432:EXCH] > Cc: Christian, Philip [HAL02:GI50:EXCH]; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > Subject: RE: [Isis-wg] Concerns with 3-way-handshake > > Sorry folks - but IMHO you are focusing on the wrong issue. The > problem is > not ISHs, but some ambiguity in the current definition of the 3way > draft and > the fact that a number of vendors still utilize the old version of the > 3 way > handshake which only sends local adjacency state. (Please see my > earlier > mail on this subject) > > Suggesting that ISHs be ignored just creates more potential backwards > compatibility problems and ignores the real cause of the problem. That > > doesn't make sense to me. > > (The fact that some implementations already do not send ISHs has > created > compatibility problems in that implementations in strict conformance > to ISO > 10589 will not interoperate with these implementations i.e. an > implementation which expects to receive an ISH before sending an IIH > (as per > ISO 10589) will never form an adjacency with an implementation that > never > sends an ISH.) > > Les > > > -----Original Message----- > > From: Tony Przygienda [mailto:prz@redback.com] > > Sent: Tuesday, December 04, 2001 4:35 PM > > To: Rajesh Saluja > > Cc: Philip Christian; 'isis-wg@spider.juniper.net'; > > 'dkatz@juniper.net' > > Subject: Re: [Isis-wg] Concerns with 3-way-handshake > > > > > > Rajesh Saluja wrote: > > > > > > > > > > > > > > >From my vintage, yes, it should be fixed, maybe as > > simply as saying that > > > > three-way-hello capable routers drop ISHs and do not send > > them ? The > > > > very details of 1195 slip my mind right now but that > > should not cause > > > > any backwards capability problems? > > > > > > > > something is definitely worth an addition to the > > 3-way-hello draft > > > > > > > > -- tony > > > > > > I agree with Philip's concerns. Will the following modifications > be > > > acceptable to the group: > > > 1. As Tony suggested, say that three-way-hello capable > > routers drop ISHs > > > and do not send them. > > > > you better be very carefull with the MUST and MAYs when > > writing this. As well, > > someone thinks carefully whether it won't break more than it > > fixes (although > > deployment with dropped ISHs seems to prove that it works and > > since we will > > be able to chhose whether we send/receive them, we can force > > pretty much > > this situation with the draft). > > > > thanks > > > > -- tonyt > > > > _______________________________________________ > > 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 -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From rsaluja@nortelnetworks.com Wed Dec 5 23:49:17 2001 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 5 Dec 2001 15:49:17 -0800 Subject: [Isis-wg] Concerns with 3-way-handshake Message-ID: <8B888AAAAB0FD31189590008C7918443080F5269@zbl6c002.corpeast.baynetworks.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_01C17DE7.739EAA20 Content-Type: text/plain; charset="iso-8859-1" Case 2)Adjacency state + Extended Local Circuit ID (length = 5) In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change. [Rajesh Saluja] Les, If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH? Thanks, Rajesh ------_=_NextPart_001_01C17DE7.739EAA20 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Concerns with 3-way-handshake
 
 
Case 2)Adjacency state + Extended Local Circuit ID (length = 5)
 
In this case A should assume that B has not yet received an IIH from A - otherwise B would have inserted the neighbor system ID/circuit id. A should only record B's advertised info (system ID/circuit ID) for use in its own IIH but not make any adjacency state change.
[Rajesh Saluja] 
Les,
If a router has not heard from its neighbor, the first IIH will always contain just the extended local circuit id and then the adjacency goes from down to initialising. If we do not make any adjacency change, we will actually need one extra IIH to come to UP state. Also how does this help in solving the original problem to interoperate with ISH?
 
Thanks,
Rajesh
 
 
------_=_NextPart_001_01C17DE7.739EAA20-- From matt@Kontoff.com Fri Dec 7 14:34:43 2001 From: matt@Kontoff.com (Matthew Kontoff) Date: Fri, 07 Dec 2001 09:34:43 -0500 Subject: [Isis-wg] Replacing IS-IS Neighbors TLV , etc in TE?? References: <8AC36D3167EED41184C800508BD9540501EE3C5A@apollo.adtech-inc.com> Message-ID: <3C10D383.6BC77A0@Kontoff.com> "Chan, Chung Ming" wrote: > > Hi, > I just came across draft-ietf-isis-traffic-04.txt and read that the intent of > introducing some of new TLVs are to replace the ones defined in ISO 10589. > e.g., Extended IS Reachability TLV will replace ISIS-Neighbors (code 2) > > 1) Does it mean that if an Implementation supports this new draft, then it > SHALL not use ISIS Neighbor TLV at all? No. Whether or not the ISIS Neighbor TLV is used is up to the implementation but it is a real good idea to be backward compatible with IS-IS routers that don't support the draft. > 2) If that is the case, does any one know where I can find any info > that talks about the migration or this type of related stuff? For a migration to occur smoothly - without losing routes - you need to be able to handle both the old style IS neighbor TLV and the new style (extended IS Reachability TLV). You will need to decide which TLV you will use when running your SPF. Matt From sboddapa@hotmail.com Tue Dec 11 01:00:37 2001 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Tue, 11 Dec 2001 01:00:37 Subject: [Isis-wg] Questions on Attached Bit Message-ID:
Hi,
I have some questions regarding the use of the Attached bit. As I understand it, the Attached bit enables an L1 router to figure out how to get to the nearest L2 router.
 
1) Is it right to assume that the Attached bit is of significance in L1 LSPs only (per section 7.2.9.2 ISO 10589, the IS should regenerate its Level 1 LSP with LSP number zero)? Is there any meaning in setting this bit in L2 LSPs as well? Also, is it right to assume that this bit is of significance in LSP number zero only and should be ignored in all other LSPs? Section 7.3.4.3 ISO 10589 does not explicitly list the Attached bit as one of the fields that are meaningful only when present in LSP number zero. It would be nice if this were stated  more explicitly.
 
2) Per Technical Corrigendum 1, subclause 7.2.9.2,
 
"When executing the level 2 decision process for each supported metric, level 2 IS shall ascertain whether or not it can reach any destinations outside its area using that metric. The IS considers itself attached if either:
a) it can reach at least one other area using the corresponding metric, or
b) it has at least one enabled reachable address prefix with the corresponding metric defined.
 
Otherwise the IS considers itself not attached."
 
I am not clear on (b) in the above paragraph. Does it mean if the IS is generating at least one external route (e.g. through redistribution of some protocol routes into IS-IS), it can declare itself attached, since it is sort of like an ASBR?
 
3) Also, the restriction on being able to reach at least another area is not clear to me. Consider the following scenario.
 
 IS A(L1) -------IS B(L1L2) -------- IS C(L2) -------- IS D(L1L2)------IS E(L1)
 Area X                  Area X                 Area X                    Area Y              Area Z
 
IS A is an L1 IS with configured area X and so on.
 
In the above figure, per the requirements, B will not declare itself attached because it does not have any neighbor who belongs to another area (even though it is attached to the backbone). While IS E will be able to reach IS A because of the fact that E has a neighbor in another area, IS A wont be able to reach IS E because it does not have a default route installed pointing towards B. Is this a bad configuration? Is it required to configure B with an area that is different from C? Am I missing something?
 
Thanks in advance.
 
Regards,
 
Suresh

Get your FREE download of MSN Explorer at http://explorer.msn.com
From sboddapa@hotmail.com Wed Dec 19 20:28:00 2001 From: sboddapa@hotmail.com (Suresh Boddapati) Date: Wed, 19 Dec 2001 20:28:00 Subject: [Isis-wg] Questions on Attached Bit Message-ID: Hi, I have a few questions on the usage of the Attached bit. As I understand it, the attached bit enables an L1 router to figure out who its closest L2 router is. 1)Is it right to assume that the attached bit is meaningfuly only when set in L1 LSPs and not in L2 LSPs? If not, when would it be set in L2 LSPs? 2)Is the attached bit meaningful only in LSP Zero and not in any other LSPs? Section 7.2.9.2 of ISO 10589 says "regenerate its Level 1 LSP with LSP number zero" upon detecting a change in the attached bit status. But Section 7.3.4.3 does not list the attached bit as one of the fields that are meaningful ONLY if present in LSP zero. 3) Technical Corrigendum 1 modifies subclause 7.2.9.2 and states "...The IS considers itself attached if either a) it can reach at least one other area using the corresponding routing metric or b) it has at least one enabled reachable address prefix with the corresponding metric defined." Can someone elaborate on b). Is it referring to at least one external prefix being advertised by the IS itself, due to say redistribution from other protocols? Also, the requirement of being able to reach at least one other area is not clear. Consider the following example. IS A(L1) ------IS B(L1L2)------IS C(L2)--------IS D(L1L2)-----IS E(L1) Area X Area X Area X Area X,Y Area Y IS A is an L1 router with manually configured area X and so on.... Even though IS B is connected to the L2 backbone, it will not advertise itself as attached (since it can reach only Area X) and therefore IS A cannot reach any system in Area Y as it will not install a default route pointing towards IS B. Is this a bad configuration? Am I missing something? Thanks a bunch in advance. Regards, Suresh _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx