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> Messa