From isis-wg-admin@spider.juniper.net Tue Jan 2 16:17:01 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22794 for ; Tue, 2 Jan 2001 16:17:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA99463; Tue, 2 Jan 2001 13:40:01 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA99448 for ; Tue, 2 Jan 2001 13:39:46 -0800 (PST) Message-ID: From: Jeff Parker To: "'tli@procket.com'" , "'henk@procket.com'" Cc: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] 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: Tue, 2 Jan 2001 16:11:57 -0500 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 2 23:08:46 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27377 for ; Tue, 2 Jan 2001 23:08:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA01272; Tue, 2 Jan 2001 20:34:01 -0800 (PST) Received: from alpha-tony.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA01260 for ; Tue, 2 Jan 2001 20:33:14 -0800 (PST) Received: (from tli@localhost) by alpha-tony.procket.com (8.9.3/8.9.3) id UAA08952; Tue, 2 Jan 2001 20:05:30 -0800 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tony.procket.com: tli set sender to tli@alpha-tony.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14930.42250.217268.222455@alpha-tony.procket.com> To: Jeff Parker Cc: "'tli@procket.com'" , "'henk@procket.com'" , "'isis-wg@spider.juniper.net'" In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.5.1 Subject: [Isis-wg] 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: Tue, 2 Jan 2001 20:05:30 -0800 (PST) Content-Transfer-Encoding: 7bit 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 3 10:02:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24325 for ; Wed, 3 Jan 2001 10:02:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA04003; Wed, 3 Jan 2001 07:28:01 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA03991 for ; Wed, 3 Jan 2001 07:27:35 -0800 (PST) Message-ID: 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 From isis-wg-admin@spider.juniper.net Wed Jan 3 13:17:45 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00717 for ; Wed, 3 Jan 2001 13:17:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA04772; Wed, 3 Jan 2001 10:43:01 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA04760 for ; Wed, 3 Jan 2001 10:42:12 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21042; Wed, 3 Jan 2001 10:14:18 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA18146; Wed, 3 Jan 2001 13:14:13 -0500 (EST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id NAA13691; Wed, 3 Jan 2001 13:14:12 -0500 (EST) Message-Id: <200101031814.NAA13691@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] RE: Encoding of TE Sub-TLVs To: tli@procket.com, jparker@axiowave.com Cc: henk@procket.com, isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8Li4cXPZbKVhhamStz2GRQ== 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: Wed, 3 Jan 2001 13:14:12 -0500 (EST) 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 3 13:52:29 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01700 for ; Wed, 3 Jan 2001 13:52:27 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA04952; Wed, 3 Jan 2001 11:18:01 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA04940 for ; Wed, 3 Jan 2001 11:17:48 -0800 (PST) Message-ID: From: Jeff Parker To: "'Radia Perlman - Boston Center for Networking'" Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: Encoding of TE Sub-TLVs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 3 Jan 2001 13:49:53 -0500 > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 3 14:32:39 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02809 for ; Wed, 3 Jan 2001 14:32:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA05153; Wed, 3 Jan 2001 11:58:02 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA05141 for ; Wed, 3 Jan 2001 11:57:25 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09740 for ; Wed, 3 Jan 2001 11:29:38 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA10204 for ; Wed, 3 Jan 2001 14:29:37 -0500 (EST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id OAA14069 for ; Wed, 3 Jan 2001 14:29:37 -0500 (EST) Message-Id: <200101031929.OAA14069@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: [Isis-wg] RE: Encoding of TE Sub-TLVs To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lcKEKYB5PJPIJLXYSWaLbw== 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: Wed, 3 Jan 2001 14:29:36 -0500 (EST) 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 3 15:03:23 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03501 for ; Wed, 3 Jan 2001 15:03:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA05323; Wed, 3 Jan 2001 12:29:01 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA05311 for ; Wed, 3 Jan 2001 12:28:05 -0800 (PST) Message-ID: From: Jeff Parker To: "'Radia Perlman - Boston Center for Networking'" , isis-wg@spider.juniper.net Cc: "Jeff Parker (E-mail)" Subject: RE: [Isis-wg] RE: Encoding of TE Sub-TLVs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 3 Jan 2001 15:00:11 -0500 > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 3 16:29:40 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05410 for ; Wed, 3 Jan 2001 16:29:39 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA05725; Wed, 3 Jan 2001 13:55:01 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA05710 for ; Wed, 3 Jan 2001 13:54:45 -0800 (PST) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA21916; Wed, 3 Jan 2001 13:26:55 -0800 (PST) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 13:26:54 -0800 Message-ID: From: Les Ginsberg To: "'Jeff Parker'" , "'Radia Perlman - Boston Center for Networking'" Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: Encoding of TE Sub-TLVs 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: Wed, 3 Jan 2001 13:26:48 -0800 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 isis-wg-admin@spider.juniper.net Wed Jan 3 17:01:11 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06043 for ; Wed, 3 Jan 2001 17:01:09 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA05881; Wed, 3 Jan 2001 14:23:01 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA05869 for ; Wed, 3 Jan 2001 14:22:42 -0800 (PST) Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA24058; Wed, 3 Jan 2001 16:54:43 -0500 (EST) Received: from jlearman-nt (dhcp-64-102-83-127.cisco.com [64.102.83.127]) by dingdong.cisco.com (Mirapoint) with SMTP id AAV12122; Wed, 3 Jan 2001 16:54:52 -0500 (EST) Message-Id: <4.1.20010103165200.00a5f2f0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Les Ginsberg , "'Jeff Parker'" , "'Radia Perlman - Boston Center for Networking'" From: Jeff Learman Subject: RE: [Isis-wg] RE: Encoding of TE Sub-TLVs Cc: isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 03 Jan 2001 16:53:01 -0500 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 3 17:19:05 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06387 for ; Wed, 3 Jan 2001 17:19:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA06002; Wed, 3 Jan 2001 14:41:01 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA05990 for ; Wed, 3 Jan 2001 14:40:15 -0800 (PST) Message-ID: From: Jeff Parker To: "'Jeff Learman'" , Les Ginsberg , Jeff Parker , "'Radia Perlman - Boston Center for Networking'" Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] RE: Encoding of TE Sub-TLVs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 3 Jan 2001 17:11:50 -0500 > >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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 4 03:04:12 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00110 for ; Thu, 4 Jan 2001 03:04:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA08296; Thu, 4 Jan 2001 00:23:02 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA08281 for ; Thu, 4 Jan 2001 00:21:15 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id IAA31114 for isis-wg@external.juniper.net; Thu, 4 Jan 2001 08:45:26 +0100 From: Tony Przygienda Message-Id: <200101040745.IAA31114@net4u.net4u.ch> To: isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Isis-wg] 2 more last calls ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 4 Jan 2001 08:45:26 +0100 (MET) Content-Transfer-Encoding: 7bit 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 4 06:08:42 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01500 for ; Thu, 4 Jan 2001 06:08:42 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA09234; Thu, 4 Jan 2001 03:34:01 -0800 (PST) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA09222 for ; Thu, 4 Jan 2001 03:33:52 -0800 (PST) Received: from mshand-8kcdt.cisco.com (lon-sto4-lan-vlan133-dhcp21.cisco.com [144.254.108.88]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA09490; Thu, 4 Jan 2001 11:05:56 GMT Message-Id: <4.3.2.7.2.20010104105719.00a88b40@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Radia Perlman - Boston Center for Networking , isis-wg@spider.juniper.net From: Mike Shand Subject: RE: [Isis-wg] RE: Encoding of TE Sub-TLVs In-Reply-To: <200101031929.OAA14069@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: Thu, 04 Jan 2001 11:07:47 +0000 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 9 14:29:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20091 for ; Tue, 9 Jan 2001 14:29:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA42733; Tue, 9 Jan 2001 11:55:01 -0800 (PST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA42718 for ; Tue, 9 Jan 2001 11:54:32 -0800 (PST) Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 9 Jan 2001 14:19:29 -0500 Received: from zmerd004.ca.nortel.com ([47.124.0.133]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CRXST0NS; Tue, 9 Jan 2001 14:19:31 -0500 Received: from nortelnetworks.com (iduncan-2.ca.nortel.com [47.130.167.42]) by zmerd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id ZFR78D2G; Tue, 9 Jan 2001 14:19:15 -0500 Message-ID: <3A5B6382.EA6741F6@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Ian Duncan" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Przygienda CC: "Metz, E.T." , tli@procket.com, cwhyte@cisco.com, rbush@bainbridge.verio.net, prz@redback.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012292003.VAA05987@net4u.net4u.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 09 Jan 2001 14:16:18 -0500 Content-Transfer-Encoding: 7bit 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 10 14:57:09 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25673 for ; Wed, 10 Jan 2001 14:57:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA48588; Wed, 10 Jan 2001 12:22:01 -0800 (PST) Received: from server.nayna.com (node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA48576 for ; Wed, 10 Jan 2001 12:21:52 -0800 (PST) Received: from nayna.com (sonicwall [64.145.162.226]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA07618 for ; Wed, 10 Jan 2001 11:53:15 -0800 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be nayna.com Message-ID: <3A5CBF53.7090406@nayna.com> From: Sudheer Dharanikota Reply-To: sudheer@nayna.com Organization: Nayna Networks, Inc. User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: isiswg Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Isis-wg] San Diego Minutes? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 10 Jan 2001 12:00:19 -0800 Content-Transfer-Encoding: 7bit Has the minutes for the previous IETF sent on the mailing list? Could someone repost/post them please. - sudheer _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 10 15:45:40 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26455 for ; Wed, 10 Jan 2001 15:45:39 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA48845; Wed, 10 Jan 2001 13:12:01 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA48833 for ; Wed, 10 Jan 2001 13:11:38 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id VAA00521; Wed, 10 Jan 2001 21:34:07 +0100 From: Tony Przygienda Message-Id: <200101102034.VAA00521@net4u.net4u.ch> Subject: Re: [Isis-wg] San Diego Minutes? In-Reply-To: <3A5CBF53.7090406@nayna.com> from Sudheer Dharanikota at "Jan 10, 2001 12: 0:19 pm" To: sudheer@nayna.com Cc: isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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: Wed, 10 Jan 2001 21:34:07 +0100 (MET) Content-Transfer-Encoding: 7bit > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 10 17:43:50 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01669 for ; Wed, 10 Jan 2001 17:43:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA49422; Wed, 10 Jan 2001 15:10:02 -0800 (PST) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA49407 for ; Wed, 10 Jan 2001 15:09:20 -0800 (PST) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 14:40:42 -0800 Message-ID: From: Neal Castagnoli To: "'isis-wg@external.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 10 Jan 2001 14:40:41 -0800 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. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 11 12:49:49 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10551 for ; Thu, 11 Jan 2001 12:49:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA53981; Thu, 11 Jan 2001 10:16:01 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA53969 for ; Thu, 11 Jan 2001 10:15:29 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00602; Thu, 11 Jan 2001 09:46:45 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA00819; Thu, 11 Jan 2001 12:46:44 -0500 (EST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id MAA14080; Thu, 11 Jan 2001 12:46:43 -0500 (EST) Message-Id: <200101111746.MAA14080@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics To: isis-wg@spider.juniper.net, cast@allegronetworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LzN4lowqUkx5AaMGWyvh7Q== 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: Thu, 11 Jan 2001 12:46:43 -0500 (EST) 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 11 14:45:38 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13333 for ; Thu, 11 Jan 2001 14:45:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA54458; Thu, 11 Jan 2001 12:12:01 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA54446 for ; Thu, 11 Jan 2001 12:11:03 -0800 (PST) Received: from brussels.cisco.com (brussels.cisco.com [144.254.15.68]) by ogma.cisco.com (Postfix) with ESMTP id 153EFFB; Thu, 11 Jan 2001 20:42:19 +0100 (MET) Received: from sprevidi-8kcdt.cisco.com (sprevidi-isdn-home.cisco.com [10.49.0.58]) by brussels.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA22101; Thu, 11 Jan 2001 20:42:17 +0100 (MET) Message-Id: <4.3.2.7.2.20010111101454.00b40380@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Neal Castagnoli , "'isis-wg@external.juniper.net'" From: stefano previdi Subject: Re: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 11 Jan 2001 18:34:49 +0100 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 11 16:11:07 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14774 for ; Thu, 11 Jan 2001 16:11:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA54868; Thu, 11 Jan 2001 13:37:01 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA54856 for ; Thu, 11 Jan 2001 13:36:29 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id VAA28050; Thu, 11 Jan 2001 21:58:42 +0100 From: Tony Przygienda Message-Id: <200101112058.VAA28050@net4u.net4u.ch> Subject: Re: [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" To: Radia.Perlman@East.Sun.COM Cc: isis-wg@spider.juniper.net, cast@allegronetworks.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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: Thu, 11 Jan 2001 21:58:42 +0100 (MET) Content-Transfer-Encoding: 7bit > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 11 17:52:41 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15951 for ; Thu, 11 Jan 2001 17:52:39 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA55299; Thu, 11 Jan 2001 15:19:01 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA55286 for ; Thu, 11 Jan 2001 15:18:13 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06682 for ; Thu, 11 Jan 2001 14:49:28 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA21944 for ; Thu, 11 Jan 2001 17:49:27 -0500 (EST) Received: from bcn (bcn [129.148.75.4]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id RAA15552 for ; Thu, 11 Jan 2001 17:49:27 -0500 (EST) Message-Id: <200101112249.RAA15552@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8c2GQy2UepT3jdFqdY5K/w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 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: Thu, 11 Jan 2001 17:49:27 -0500 (EST) 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 12 03:15:17 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06042 for ; Fri, 12 Jan 2001 03:15:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA57428; Fri, 12 Jan 2001 00:41:02 -0800 (PST) Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA57416 for ; Fri, 12 Jan 2001 00:40:18 -0800 (PST) Received: from localnet.cwnt.co.il (ras9-p30.hfa.netvision.net.il [62.0.104.30]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id KAA10571 for ; Fri, 12 Jan 2001 10:11:24 +0200 (IST) Received: from 192.168.0.44 ([192.168.0.44]) by localnet.cwnt.co.il (WinRoute 3.04g) with SMTP; Thu, 11 Jan 2001 21:06:57 +0200 Message-ID: <00d801c07c13$844d5fa0$2c00a8c0@amir> From: "Amir H." To: "ISIS-wg" Organization: Charlotte's Web Networks LTD MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D5_01C07C13.84336F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] New Internet-Draft Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 11 Jan 2001 21:14:43 -0000 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-Disposition: attachment; filename="draft-hermelin-ext-lsp-frags-00.txt" Content-Transfer-Encoding: quoted-printable 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-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 12 16:57:12 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25584 for ; Fri, 12 Jan 2001 16:57:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA60771; Fri, 12 Jan 2001 14:23:02 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA60759 for ; Fri, 12 Jan 2001 14:22:41 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id WAA21995; Fri, 12 Jan 2001 22:44:38 +0100 From: Tony Przygienda Message-Id: <200101122144.WAA21995@net4u.net4u.ch> Subject: Re: [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" To: Radia.Perlman@East.Sun.COM Cc: isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 12 Jan 2001 22:44:38 +0100 (MET) Content-Transfer-Encoding: 7bit > > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 12 19:37:07 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27293 for ; Fri, 12 Jan 2001 19:37:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA61458; Fri, 12 Jan 2001 17:03:02 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA61446 for ; Fri, 12 Jan 2001 17:02:12 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id BAA24064 for isis-wg@external.juniper.net; Sat, 13 Jan 2001 01:24:10 +0100 From: Tony Przygienda Message-Id: <200101130024.BAA24064@net4u.net4u.ch> To: isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Meeting minutes ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 13 Jan 2001 01:24:09 +0100 (MET) Content-Transfer-Encoding: 7bit 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. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jan 14 17:33:50 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10915 for ; Sun, 14 Jan 2001 17:33:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA74086; Sun, 14 Jan 2001 15:00:02 -0800 (PST) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA49303 for ; Wed, 10 Jan 2001 14:58:45 -0800 (PST) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 14:30:08 -0800 Message-ID: From: Neal Castagnoli To: isis-wg@spider.juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Computing routes with wide (TE Draft) metrics Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 10 Jan 2001 14:30:08 -0800 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 16 10:01:51 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13629 for ; Tue, 16 Jan 2001 10:01:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA83569; Tue, 16 Jan 2001 07:28:01 -0800 (PST) Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA83557 for ; Tue, 16 Jan 2001 07:27:17 -0800 (PST) Received: from localnet.cwnt.co.il (ras6-p185.hfa.netvision.net.il [62.0.101.185]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id QAA31580; Tue, 16 Jan 2001 16:57:16 +0200 (IST) Received: from 192.168.0.44 ([192.168.0.44]) by localnet.cwnt.co.il (WinRoute 3.04g) with SMTP; Tue, 16 Jan 2001 16:49:08 +0200 Message-ID: <008301c07fdd$5b7f6730$2c00a8c0@amir> From: "Amir H." To: Cc: "ISIS-wg" References: <3A5F2DFD.5D858D87@tellabs.com> Subject: Re: [Isis-wg] draft-hermelin-ext-lsp-frags-00.txt Organization: Charlotte's Web Networks LTD MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Jan 2001 16:57:06 -0000 Content-Transfer-Encoding: 7bit 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 > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 16 16:36:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22100 for ; Tue, 16 Jan 2001 16:36:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA85104; Tue, 16 Jan 2001 14:03:02 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA85092 for ; Tue, 16 Jan 2001 14:02:37 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25661; Tue, 16 Jan 2001 13:32:52 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA02604; Tue, 16 Jan 2001 16:32:51 -0500 (EST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id QAA04373; Tue, 16 Jan 2001 16:32:51 -0500 (EST) Message-Id: <200101162132.QAA04373@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] draft-hermelin-ext-lsp-frags-00.txt To: Jonathan.Sadler@tellabs.com, amir@cwnt.com Cc: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HF/R5Uw3hwbbapJLc/wbgw== 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, 16 Jan 2001 16:32:49 -0500 (EST) 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 17 08:13:15 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16687 for ; Wed, 17 Jan 2001 08:13:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA88897; Wed, 17 Jan 2001 05:40:01 -0800 (PST) Received: from cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA88882 for ; Wed, 17 Jan 2001 05:39:29 -0800 (PST) Received: from amir ([192.168.0.44]) by cwnt.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 17 Jan 2001 15:10:02 +0200 Message-ID: <029501c08098$ae146390$2c00a8c0@amir> From: "Amir H." To: "stefano previdi" Cc: "ISIS-wg" References: <4.3.2.7.2.20010111101454.00b40380@brussels.cisco.com> Subject: Re: [Isis-wg] Computing hop by hop routes with wide (TE Draft) metrics Organization: Charlotte Networks Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 17 Jan 2001 13:10:02.0235 (UTC) FILETIME=[CD28CCB0:01C08086] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 17 Jan 2001 15:18:00 -0000 Content-Transfer-Encoding: 7bit > > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 17 09:13:57 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18361 for ; Wed, 17 Jan 2001 09:13:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA89176; Wed, 17 Jan 2001 06:41:02 -0800 (PST) Received: from cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA89164 for ; Wed, 17 Jan 2001 06:40:10 -0800 (PST) Received: from amir ([192.168.0.44]) by cwnt.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 17 Jan 2001 16:10:43 +0200 Message-ID: <02ab01c080a1$286ce8d0$2c00a8c0@amir> From: "Amir H." To: "Radia Perlman - Boston Center for Networking" Cc: "ISIS-wg" References: <200101162132.QAA04373@bcn.East.Sun.COM> Subject: Re: [Isis-wg] draft-hermelin-ext-lsp-frags-00.txt Organization: Charlotte Networks Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 17 Jan 2001 14:10:43.0353 (UTC) FILETIME=[476F5090:01C0808F] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 17 Jan 2001 16:18:20 -0000 Content-Transfer-Encoding: 7bit > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 17 13:29:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23657 for ; Wed, 17 Jan 2001 13:29:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA90192; Wed, 17 Jan 2001 10:56:02 -0800 (PST) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA90180 for ; Wed, 17 Jan 2001 10:55:24 -0800 (PST) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id TAA05457; Wed, 17 Jan 2001 19:16:01 +0100 From: Tony Przygienda Message-Id: <200101171816.TAA05457@net4u.net4u.ch> Subject: Re: [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" To: amir@cwnt.com (Amir H.) Cc: sprevidi@cisco.com, isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] 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: Wed, 17 Jan 2001 19:16:01 +0100 (MET) Content-Transfer-Encoding: 7bit > > > > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 18 07:34:14 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22450 for ; Thu, 18 Jan 2001 07:34:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA94569; Thu, 18 Jan 2001 05:01:02 -0800 (PST) Received: from cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA94554 for ; Thu, 18 Jan 2001 05:00:39 -0800 (PST) Received: from amir ([192.168.0.44]) by cwnt.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 18 Jan 2001 14:31:03 +0200 Message-ID: <007a01c0815c$669f63b0$2c00a8c0@amir> From: "Amir H." To: "Tony Li" Cc: "ISIS-wg" References: <00cf01c07c12$d610e1a0$2c00a8c0@amir> <3A5EAF01.EA33E840@redback.com> <3A5ED096.9D31AE28@home.net> <017201c07e1f$60166420$2c00a8c0@amir> <3A6698D6.46026042@home.net> Organization: Charlotte Networks Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 18 Jan 2001 12:31:03.0591 (UTC) FILETIME=[85A1CB70:01C0814A] Subject: [Isis-wg] Re: New Internet-Draft Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 18 Jan 2001 14:39:02 -0000 Content-Transfer-Encoding: 7bit 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 > > > > > > > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Jan 19 02:03:34 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21092 for ; Fri, 19 Jan 2001 02:03:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA98841; Thu, 18 Jan 2001 23:30:02 -0800 (PST) Received: from alpha-tli.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA98826 for ; Thu, 18 Jan 2001 23:29:24 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id WAA21287; Thu, 18 Jan 2001 22:59:17 -0800 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14951.58821.205281.903582@alpha-tli.procket.com> To: "Amir H." Cc: "Tony Li" , "ISIS-wg" 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> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 18 Jan 2001 22:59:17 -0800 (PST) Content-Transfer-Encoding: 7bit | 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Jan 21 07:47:50 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08343 for ; Sun, 21 Jan 2001 07:47:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA13650; Sun, 21 Jan 2001 05:15:02 -0800 (PST) Received: from cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA13635 for ; Sun, 21 Jan 2001 05:14:29 -0800 (PST) Received: from amir ([192.168.0.44]) by cwnt.com with Microsoft SMTPSVC(5.0.2195.1600); Sun, 21 Jan 2001 14:44:33 +0200 Message-ID: <019101c083b9$ca0ad5b0$2c00a8c0@amir> From: "Amir H." To: "Tony Li" Cc: "ISIS-wg" 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> Subject: Re: [Isis-wg] Re: New Internet-Draft Organization: Charlotte Networks Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 21 Jan 2001 12:44:33.0624 (UTC) FILETIME=[E7B04580:01C083A7] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 21 Jan 2001 14:52:34 -0000 Content-Transfer-Encoding: 7bit > > 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 From isis-wg-admin@spider.juniper.net Mon Jan 22 05:56:14 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01417 for ; Mon, 22 Jan 2001 05:56:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA18813; Mon, 22 Jan 2001 03:24:02 -0800 (PST) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA18801 for ; Mon, 22 Jan 2001 03:23:10 -0800 (PST) Received: from mshand-8kcdt.cisco.com ([10.49.188.188]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA22917; Mon, 22 Jan 2001 10:52:49 GMT Message-Id: <4.3.2.7.2.20010122103745.00bc1100@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Amir H." , "Tony Li" From: Mike Shand Subject: Re: [Isis-wg] Re: New Internet-Draft Cc: "ISIS-wg" 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Jan 2001 10:47:46 +0000 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 22 07:28:01 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02444 for ; Mon, 22 Jan 2001 07:28:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA19217; Mon, 22 Jan 2001 04:56:01 -0800 (PST) Received: from cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA19205 for ; Mon, 22 Jan 2001 04:55:08 -0800 (PST) Received: from amir ([192.168.0.44]) by cwnt.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 22 Jan 2001 14:25:03 +0200 Message-ID: <009901c08480$3b295a20$2c00a8c0@amir> From: "Amir H." To: "Mike Shand" Cc: "ISIS-wg" 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> Subject: Re: [Isis-wg] Re: draft-hermelin-ext-lsp-frags-00.txt Organization: Charlotte Networks Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 22 Jan 2001 12:25:03.0937 (UTC) FILETIME=[58E9F310:01C0846E] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Jan 2001 14:33:04 -0000 Content-Transfer-Encoding: 7bit > > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 23 22:35:22 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00893 for ; Tue, 23 Jan 2001 22:35:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA28282; Tue, 23 Jan 2001 20:03:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA27963 for ; Tue, 23 Jan 2001 18:51:37 -0800 (PST) X-JNPR-Received-From: outside Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.66.129.230]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id SAA80257 for ; Tue, 23 Jan 2001 18:20:32 -0800 (PST) (envelope-from curtis@workhorse.fictitious.org) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA18338; Tue, 23 Jan 2001 21:20:38 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101240220.VAA18338@workhorse.fictitious.org> To: tli@procket.com, henk@procket.com cc: curtis@avici.com, isis-wg@juniper.net Reply-To: curtis@avici.com From: Curtis Villamizar Subject: [Isis-wg] unnumberred interfaces in draft-ietf-isis-traffic-02 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 23 Jan 2001 21:20:38 -0500 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 23 23:15:36 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01337 for ; Tue, 23 Jan 2001 23:15:34 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA28488; Tue, 23 Jan 2001 20:44:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA28476 for ; Tue, 23 Jan 2001 20:43:10 -0800 (PST) X-JNPR-Received-From: outside Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id UAA82199 for ; Tue, 23 Jan 2001 20:12:05 -0800 (PST) (envelope-from akyol@pluris.com) Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA09523; Tue, 23 Jan 2001 20:12:56 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14958.22077.592000.706649@gargle.gargle.HOWL> To: curtis@avici.com Cc: tli@procket.com, henk@procket.com, isis-wg@juniper.net 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> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Jan 2001 20:12:45 -0800 Content-Transfer-Encoding: 7bit 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 23 23:32:29 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01889 for ; Tue, 23 Jan 2001 23:32:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA28588; Tue, 23 Jan 2001 21:01:01 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA28576 for ; Tue, 23 Jan 2001 21:00:45 -0800 (PST) X-JNPR-Received-From: outside Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id UAA82536 for ; Tue, 23 Jan 2001 20:29:41 -0800 (PST) (envelope-from akyol@pluris.com) Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA10632; Tue, 23 Jan 2001 20:30:31 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14958.23132.499000.343630@gargle.gargle.HOWL> To: Bora Akyol Cc: curtis@avici.com, tli@procket.com, henk@procket.com, isis-wg@juniper.net, mpls@uu.net 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> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Jan 2001 20:30:20 -0800 Content-Transfer-Encoding: 7bit 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 24 12:55:00 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26557 for ; Wed, 24 Jan 2001 12:54:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA31887; Wed, 24 Jan 2001 10:23:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA31182 for ; Wed, 24 Jan 2001 07:26:55 -0800 (PST) X-JNPR-Received-From: outside Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.66.129.230]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id GAA92998 for ; Wed, 24 Jan 2001 06:55:45 -0800 (PST) (envelope-from curtis@workhorse.fictitious.org) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA19873; Wed, 24 Jan 2001 09:56:17 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101241456.JAA19873@workhorse.fictitious.org> To: Bora Akyol cc: curtis@avici.com, tli@procket.com, henk@procket.com, isis-wg@juniper.net Reply-To: curtis@avici.com Subject: Re: [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> From: Curtis Villamizar Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 24 Jan 2001 09:56:17 -0500 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 24 13:34:24 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27370 for ; Wed, 24 Jan 2001 13:34:24 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA32073; Wed, 24 Jan 2001 11:03:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA32061 for ; Wed, 24 Jan 2001 11:02:23 -0800 (PST) X-JNPR-Received-From: outside Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id KAA01294 for ; Wed, 24 Jan 2001 10:31:13 -0800 (PST) (envelope-from akyol@pluris.com) Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA12454; Wed, 24 Jan 2001 10:32:02 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14959.8098.474000.969288@gargle.gargle.HOWL> To: curtis@avici.com Cc: Bora Akyol , tli@procket.com, henk@procket.com, isis-wg@juniper.net Subject: Re: [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> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Jan 2001 10:32:02 -0800 Content-Transfer-Encoding: 7bit 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Jan 24 15:41:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00307 for ; Wed, 24 Jan 2001 15:41:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA32640; Wed, 24 Jan 2001 13:10:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA32625 for ; Wed, 24 Jan 2001 13:09:35 -0800 (PST) X-JNPR-Received-From: outside Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id MAA07019 for ; Wed, 24 Jan 2001 12:38:23 -0800 (PST) (envelope-from akyol@pluris.com) Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA23406; Wed, 24 Jan 2001 12:39:17 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14959.15733.125000.314592@gargle.gargle.HOWL> To: curtis@avici.com Cc: Bora Akyol , isis-wg@juniper.net Subject: Re: [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> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Jan 2001 12:39:17 -0800 Content-Transfer-Encoding: 7bit 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 25 01:58:38 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14347 for ; Thu, 25 Jan 2001 01:58:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA34985; Wed, 24 Jan 2001 23:26:02 -0800 (PST) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA34973 for ; Wed, 24 Jan 2001 23:25:59 -0800 (PST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by postal.redback.com (Postfix) with ESMTP id 6072817BC0B; Wed, 24 Jan 2001 22:55:39 -0800 (PST) To: "Amir H." Cc: "Tony Li" , "ISIS-wg" Subject: Re: [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> From: Naiming Shen Message-Id: <20010125065539.6072817BC0B@postal.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Jan 2001 22:55:08 -0800 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 25 05:26:47 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22952 for ; Thu, 25 Jan 2001 05:26:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA35979; Thu, 25 Jan 2001 02:53:02 -0800 (PST) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA35967 for ; Thu, 25 Jan 2001 02:52:44 -0800 (PST) Received: from mshand-w2k.cisco.com (uxb-dhcp-198-135-1-182.cisco.com [198.135.1.182]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA25115; Thu, 25 Jan 2001 10:21:47 GMT Message-Id: <4.3.2.7.2.20010125094650.019351f8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Naiming Shen From: mike shand Subject: Re: [Isis-wg] Re: New Internet-Draft Cc: "Amir H." , "Tony Li" , "ISIS-wg" In-Reply-To: <20010125065539.6072817BC0B@postal.redback.com> References: <019101c083b9$ca0ad5b0$2c00a8c0@amir> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jan 2001 10:22:00 +0000 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 25 09:52:31 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27602 for ; Thu, 25 Jan 2001 09:52:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA37072; Thu, 25 Jan 2001 07:21:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA37060 for ; Thu, 25 Jan 2001 07:20:05 -0800 (PST) X-JNPR-Received-From: outside Received: from cc.zeroknowledge.com (cc.zeroknowledge.com [209.5.124.205]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id GAA31531 for ; Thu, 25 Jan 2001 06:48:46 -0800 (PST) (envelope-from jerome@zeroknowledge.com) Received: from smartypants.zks.net (smartypants.zks.net [192.168.1.4]) by cc.zeroknowledge.com (8.9.3/8.9.3) with ESMTP id JAA12863; Thu, 25 Jan 2001 09:49:41 -0500 Received: from host-36.dyn.cia.zks.net (host-36.dyn.cia.zks.net [10.16.65.36]) by smartypants.zks.net (8.9.3/8.9.3) with ESMTP id JAA15783; Thu, 25 Jan 2001 09:49:38 -0500 Received: (from jerome@localhost) by host-36.dyn.cia.zks.net (8.9.3/8.9.3) id JAA08503; Thu, 25 Jan 2001 09:49:37 -0500 From: Jerome Etienne To: David Wang Cc: "'isis-wg@juniper.net'" , "'ietf@ietf.org'" Message-ID: <20010125094937.A8493@host-36.dyn.cia.zks.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from david.wang@metro-optix.com on Thu, Jan 25, 2001 at 08:35:15AM -0600 Subject: [Isis-wg] Re: How many routers an OSPF or IS-IS area can have Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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 09:49:37 -0500 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 25 13:05:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05291 for ; Thu, 25 Jan 2001 13:05:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA37838; Thu, 25 Jan 2001 10:34:01 -0800 (PST) Received: from alpha-tli.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA37826 for ; Thu, 25 Jan 2001 10:33:53 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id KAA05815; Thu, 25 Jan 2001 10:03:15 -0800 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14960.27235.756698.965617@alpha-tli.procket.com> To: mike shand Cc: Naiming Shen , "Amir H." , "Tony Li" , "ISIS-wg" Subject: Re: [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> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jan 2001 10:03:15 -0800 (PST) Content-Transfer-Encoding: 7bit | 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 25 14:25:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06550 for ; Thu, 25 Jan 2001 14:25:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA38222; Thu, 25 Jan 2001 11:54:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA38210 for ; Thu, 25 Jan 2001 11:53:40 -0800 (PST) X-JNPR-Received-From: outside Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id LAA42173 for ; Thu, 25 Jan 2001 11:22:19 -0800 (PST) (envelope-from akyol@pluris.com) Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA08252; Thu, 25 Jan 2001 11:23:12 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14960.32031.615000.692048@gargle.gargle.HOWL> To: Jerome Etienne Cc: David Wang , "'isis-wg@juniper.net'" , "'ietf@ietf.org'" In-Reply-To: <20010125094937.A8493@host-36.dyn.cia.zks.net> References: <20010125094937.A8493@host-36.dyn.cia.zks.net> X-Mailer: VM 6.90 under Emacs 20.7.1 Subject: [Isis-wg] Re: How many routers an OSPF or IS-IS area can have Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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 11:23:11 -0800 Content-Transfer-Encoding: 7bit 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 From isis-wg-admin@spider.juniper.net Thu Jan 25 14:34:17 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06754 for ; Thu, 25 Jan 2001 14:34:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38299; Thu, 25 Jan 2001 12:03:02 -0800 (PST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38287 for ; Thu, 25 Jan 2001 12:02:54 -0800 (PST) Received: from redback.com ([63.200.51.86]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G7Q009J0EGTO2@mta5.snfc21.pbi.net> for isis-wg@spider.juniper.net; Thu, 25 Jan 2001 10:38:53 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] Re: New Internet-Draft To: Tony Li Cc: mike shand , Naiming Shen , "Amir H." , ISIS-wg Message-id: <3A706392.FDFCFEDE@redback.com> Organization: Siara Systems MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <019101c083b9$ca0ad5b0$2c00a8c0@amir> <4.3.2.7.2.20010125094650.019351f8@jaws.cisco.com> <14960.27235.756698.965617@alpha-tli.procket.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jan 2001 09:34:10 -0800 Content-Transfer-Encoding: 7bit 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 25 15:10:38 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07839 for ; Thu, 25 Jan 2001 15:10:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38542; Thu, 25 Jan 2001 12:39:02 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA32580 for ; Wed, 24 Jan 2001 13:01:26 -0800 (PST) X-JNPR-Received-From: outside Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.66.129.230]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id MAA06621 for ; Wed, 24 Jan 2001 12:30:14 -0800 (PST) (envelope-from curtis@workhorse.fictitious.org) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA22301; Wed, 24 Jan 2001 15:30:25 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101242030.PAA22301@workhorse.fictitious.org> To: Bora Akyol cc: curtis@avici.com, tli@procket.com, henk@procket.com, isis-wg@juniper.net Reply-To: curtis@avici.com Subject: Re: [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> From: Curtis Villamizar Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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, 24 Jan 2001 15:30:25 -0500 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 25 15:10:54 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07854 for ; Thu, 25 Jan 2001 15:10:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38574; Thu, 25 Jan 2001 12:39:34 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38498 for ; Thu, 25 Jan 2001 12:34:31 -0800 (PST) X-JNPR-Received-From: outside Received: from ectexch.ctd.anl.gov (exchange.anl.gov [146.137.194.75]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id MAA43693 for ; Thu, 25 Jan 2001 12:03:09 -0800 (PST) (envelope-from MELuallen@anl.gov) Received: by exchange.anl.gov with Internet Mail Service (5.5.2650.21) id ; Thu, 25 Jan 2001 14:04:05 -0600 Message-ID: From: "Luallen, Matthew E." To: "'Bora Akyol'" , Jerome Etienne Cc: David Wang , "'isis-wg@juniper.net'" , "'ietf@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: How many routers an OSPF or IS-IS area can have Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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 14:04:04 -0600 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 From isis-wg-admin@spider.juniper.net Thu Jan 25 15:10:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07864 for ; Thu, 25 Jan 2001 15:10:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38558; Thu, 25 Jan 2001 12:39:25 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA36981 for ; Thu, 25 Jan 2001 07:06:50 -0800 (PST) X-JNPR-Received-From: outside Received: from mailhost.metro-optix.com ([64.219.248.6]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id GAA31164 for ; Thu, 25 Jan 2001 06:35:32 -0800 (PST) (envelope-from david.wang@metro-optix.com) Received: by mailhost.metro-optix.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 Jan 2001 08:35:18 -0600 Message-ID: From: David Wang To: "'isis-wg@juniper.net'" , "'ietf@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] How many routers an OSPF or IS-IS area can have Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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 08:35:15 -0600 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 From isis-wg-admin@spider.juniper.net Thu Jan 25 15:25:23 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08171 for ; Thu, 25 Jan 2001 15:25:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38757; Thu, 25 Jan 2001 12:54:02 -0800 (PST) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38745 for ; Thu, 25 Jan 2001 12:53:00 -0800 (PST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by postal.redback.com (Postfix) with ESMTP id BC43317BC25; Thu, 25 Jan 2001 12:22:35 -0800 (PST) To: Tony Przygienda Cc: Tony Li , mike shand , "Amir H." , ISIS-wg Subject: Re: [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> From: Naiming Shen Message-Id: <20010125202235.BC43317BC25@postal.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jan 2001 12:22:04 -0800 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Jan 25 16:39:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09382 for ; Thu, 25 Jan 2001 16:39:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA39162; Thu, 25 Jan 2001 14:08:02 -0800 (PST) Received: from mail.makesys.com (mail.makesys.com [204.30.100.64]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA39150 for ; Thu, 25 Jan 2001 14:07:24 -0800 (PST) Received: (from nobody@localhost) by mail.makesys.com (8.11.1/8.10.1) id f0PLaxq19464; Thu, 25 Jan 2001 16:36:59 -0500 (EST) From: Volkan Ozdemir Message-Id: <200101252136.f0PLaxq19464@mail.makesys.com> X-Authentication-Warning: mail.makesys.com: nobody set sender to volkan@makesys.com using -f To: isis-wg@spider.juniper.net Reply-To: volkan@makesys.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP3 Imap webMail Program 2.0.11 X-Originating-IP: 204.30.100.82 Subject: [Isis-wg] (no subject) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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 16:36:59 -0500 (EST) Content-Transfer-Encoding: 8bit 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 isis-wg-admin@spider.juniper.net Thu Jan 25 16:51:17 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09641 for ; Thu, 25 Jan 2001 16:51:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA39279; Thu, 25 Jan 2001 14:20:02 -0800 (PST) Received: from alpha-tli.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA39264 for ; Thu, 25 Jan 2001 14:19:59 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id NAA06393; Thu, 25 Jan 2001 13:49:16 -0800 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14960.40796.883342.559022@alpha-tli.procket.com> To: volkan@makesys.com Cc: isis-wg@spider.juniper.net Subject: [Isis-wg] (no subject) In-Reply-To: <200101252136.f0PLaxq19464@mail.makesys.com> References: <200101252136.f0PLaxq19464@mail.makesys.com> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jan 2001 13:49:16 -0800 (PST) Content-Transfer-Encoding: 7bit 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 29 05:34:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28735 for ; Mon, 29 Jan 2001 05:34:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA60965; Mon, 29 Jan 2001 03:03:02 -0800 (PST) Received: from hotmail.com (f202.law11.hotmail.com [64.4.17.202]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA38737 for ; Thu, 25 Jan 2001 12:52:58 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Jan 2001 12:22:33 -0800 Received: from 63.108.78.2 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 25 Jan 2001 20:22:33 GMT X-Originating-IP: [63.108.78.2] From: "Charles Smith" 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 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jan 2001 20:22:33.0672 (UTC) FILETIME=[8CB9D480:01C0870C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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 20:22:33 -0000 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 29 05:37:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28751 for ; Mon, 29 Jan 2001 05:37:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA60993; Mon, 29 Jan 2001 03:06:19 -0800 (PST) Received: from hotmail.com (f122.law11.hotmail.com [64.4.17.122]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA39031 for ; Thu, 25 Jan 2001 13:44:35 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Jan 2001 13:14:10 -0800 Received: from 63.108.78.2 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 25 Jan 2001 21:14:10 GMT X-Originating-IP: [63.108.78.2] From: "Charles Smith" To: John.Moy@sycamorenet.com, akyol@pluris.com, MELuallen@anl.gov, isis-wg@spider.juniper.net Cc: OSPF@DISCUSS.MICROSOFT.COM Subject: RE: [Isis-wg] RE: How many routers an OSPF or IS-IS area can have Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jan 2001 21:14:10.0266 (UTC) FILETIME=[C27093A0:01C08713] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-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 21:14:10 -0000 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 29 05:38:50 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28766 for ; Mon, 29 Jan 2001 05:38:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA61017; Mon, 29 Jan 2001 03:07:52 -0800 (PST) Received: from cypher.onfiber.com (austin.onfiber.com [63.108.78.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA39233 for ; Thu, 25 Jan 2001 14:15:15 -0800 (PST) Received: by cypher.onfiber.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 Jan 2001 15:45:14 -0600 Message-ID: <2AD266216F4FD41192FC00508BD9378E74596C@cypher.onfiber.com> From: Chris Flores To: "'volkan@makesys.com'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] (no subject) 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 isis-wg-admin@spider.juniper.net Mon Jan 29 08:08:21 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01527 for ; Mon, 29 Jan 2001 08:08:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA61707; Mon, 29 Jan 2001 05:37:02 -0800 (PST) Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA61695 for ; Mon, 29 Jan 2001 05:36:54 -0800 (PST) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JZHD90UQ9G0007U5@research.kpn.com> for isis-wg@spider.juniper.net; Mon, 29 Jan 2001 14:06:01 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jan 2001 14:05:59 +0100 Content-return: allowed From: "Metz, E.T." Subject: RE: [Isis-wg] (no subject) To: "'Chris Flores'" , "'volkan@makesys.com'" , isis-wg@spider.juniper.net Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A7FC@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 14:05:54 +0100 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 > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 29 14:20:26 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08080 for ; Mon, 29 Jan 2001 14:20:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA63179; Mon, 29 Jan 2001 11:49:02 -0800 (PST) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA63167 for ; Mon, 29 Jan 2001 11:48:13 -0800 (PST) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA09337; Mon, 29 Jan 2001 11:17:00 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id LAA01702; Mon, 29 Jan 2001 11:17:00 -0800 (PST) Message-Id: <200101291917.LAA01702@cirrus.juniper.net> From: Dave Katz To: chris.flores@onfiber.com CC: volkan@makesys.com, isis-wg@spider.juniper.net In-reply-to: <2AD266216F4FD41192FC00508BD9378E74596C@cypher.onfiber.com> (message from Chris Flores on Thu, 25 Jan 2001 15:45:13 -0600) Subject: Re: [Isis-wg] (no subject) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 11:17:00 -0800 (PST) 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 isis-wg-admin@spider.juniper.net Mon Jan 29 15:25:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09422 for ; Mon, 29 Jan 2001 15:25:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA63478; Mon, 29 Jan 2001 12:55:02 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA62428 for ; Mon, 29 Jan 2001 08:40:36 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03966 for ; Mon, 29 Jan 2001 08:09:43 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28835 for ; Mon, 29 Jan 2001 11:09:42 -0500 (EST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id LAA02515 for ; Mon, 29 Jan 2001 11:09:41 -0500 (EST) Message-Id: <200101291609.LAA02515@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: [Isis-wg] (no subject) area/router boundary To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jBVkIynr9Sue7L69CkUNOw== 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: Mon, 29 Jan 2001 11:09:40 -0500 (EST) 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 29 15:55:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09875 for ; Mon, 29 Jan 2001 15:55:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA63643; Mon, 29 Jan 2001 13:25:02 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA63628 for ; Mon, 29 Jan 2001 13:24:48 -0800 (PST) Message-ID: From: Jeff Parker To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] LSP Buffersize Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 15:53:52 -0500 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 isis-wg-admin@spider.juniper.net Mon Jan 29 17:09:03 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10663 for ; Mon, 29 Jan 2001 17:09:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA63962; Mon, 29 Jan 2001 14:38:01 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA63950 for ; Mon, 29 Jan 2001 14:37:06 -0800 (PST) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA18520; Mon, 29 Jan 2001 17:05:42 -0500 (EST) Received: from jlearman-nt (dhcp-64-102-83-114.cisco.com [64.102.83.114]) by dingdong.cisco.com (Mirapoint) with SMTP id AAT15111; Mon, 29 Jan 2001 17:06:03 -0500 (EST) Message-Id: <4.1.20010129165647.00a869b0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Jeff Parker , "'isis-wg@spider.juniper.net'" From: Jeff Learman Subject: Re: [Isis-wg] LSP Buffersize In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 17:05:43 -0500 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 isis-wg-admin@spider.juniper.net Mon Jan 29 17:27:58 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10869 for ; Mon, 29 Jan 2001 17:27:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA64086; Mon, 29 Jan 2001 14:57:02 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA64052 for ; Mon, 29 Jan 2001 14:56:19 -0800 (PST) Received: from brussels.cisco.com (brussels.cisco.com [144.254.15.68]) by ogma.cisco.com (Postfix) with ESMTP id ECA9286; Mon, 29 Jan 2001 23:25:24 +0100 (MET) Received: from sprevidi-8kcdt.cisco.com (sprevidi-isdn-home.cisco.com [10.49.0.58]) by brussels.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA13184; Mon, 29 Jan 2001 23:25:23 +0100 (MET) Message-Id: <4.3.2.7.2.20010129231659.00b0b920@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Dave Katz , chris.flores@onfiber.com From: stefano previdi Subject: Re: [Isis-wg] (no subject) Cc: volkan@makesys.com, isis-wg@spider.juniper.net In-Reply-To: <200101291917.LAA01702@cirrus.juniper.net> References: <2AD266216F4FD41192FC00508BD9378E74596C@cypher.onfiber.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 23:24:52 +0100 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 29 17:47:49 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11306 for ; Mon, 29 Jan 2001 17:47:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64197; Mon, 29 Jan 2001 15:17:02 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64185 for ; Mon, 29 Jan 2001 15:16:49 -0800 (PST) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA09798; Mon, 29 Jan 2001 14:45:51 -0800 (PST) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 14:45:51 -0800 Message-ID: From: Les Ginsberg To: "'Jeff Learman'" , Jeff Parker , "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] LSP Buffersize 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: Mon, 29 Jan 2001 14:45:51 -0800 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 > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 29 18:06:09 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11606 for ; Mon, 29 Jan 2001 18:06:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64316; Mon, 29 Jan 2001 15:35:02 -0800 (PST) Received: from gnat.inet.org (209-9-249-62.sdsl.cais.net [209.9.249.62]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64301 for ; Mon, 29 Jan 2001 15:34:36 -0800 (PST) Received: from mosquito.extremenetworks.com (mosquito.inet.org [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 496878264F for ; Mon, 29 Jan 2001 18:02:19 -0500 (EST) Message-Id: <5.0.0.25.2.20010129174902.009f39e0@10.30.15.2> X-Sender: rja@nowhere (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: isis-wg@spider.juniper.net From: Ran Atkinson Subject: Re: [Isis-wg] LSP Buffersize In-Reply-To: <4.1.20010129165647.00a869b0@dingdong.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 17:54:03 -0500 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 isis-wg-admin@spider.juniper.net Mon Jan 29 18:12:00 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11756 for ; Mon, 29 Jan 2001 18:11:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64414; Mon, 29 Jan 2001 15:41:02 -0800 (PST) Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64402 for ; Mon, 29 Jan 2001 15:40:20 -0800 (PST) Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAB51767; Mon, 29 Jan 2001 16:44:22 -0600 (CST) Received: from tellabs.com (bb50285d.bb.tellabs.com [138.111.163.75]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA29385; Mon, 29 Jan 2001 16:43:15 -0600 (CST) Message-ID: <3A75F202.877D5B7F@tellabs.com> 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 To: dkatz@juniper.net CC: chris.flores@onfiber.com, volkan@makesys.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] (no subject) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 16:43:14 -0600 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 isis-wg-admin@spider.juniper.net Mon Jan 29 18:18:50 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11862 for ; Mon, 29 Jan 2001 18:18:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64489; Mon, 29 Jan 2001 15:48:02 -0800 (PST) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64477 for ; Mon, 29 Jan 2001 15:47:55 -0800 (PST) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id PAA27759; Mon, 29 Jan 2001 15:16:55 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id PAA02917; Mon, 29 Jan 2001 15:16:54 -0800 (PST) Message-Id: <200101292316.PAA02917@cirrus.juniper.net> From: Dave Katz To: Jonathan.Sadler@tellabs.com CC: chris.flores@onfiber.com, volkan@makesys.com, isis-wg@spider.juniper.net In-reply-to: <3A75F202.877D5B7F@tellabs.com> (message from Jonathan Sadler on Mon, 29 Jan 2001 16:43:14 -0600) Subject: Re: [Isis-wg] (no subject) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 15:16:54 -0800 (PST) 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 isis-wg-admin@spider.juniper.net Mon Jan 29 18:25:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11966 for ; Mon, 29 Jan 2001 18:25:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64583; Mon, 29 Jan 2001 15:55:02 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64568 for ; Mon, 29 Jan 2001 15:54:40 -0800 (PST) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id PAA13036; Mon, 29 Jan 2001 15:23:42 -0800 (PST) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 15:23:43 -0800 Message-ID: From: Les Ginsberg To: "'Ran Atkinson'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] LSP Buffersize 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: Mon, 29 Jan 2001 15:23:42 -0800 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 isis-wg-admin@spider.juniper.net Mon Jan 29 18:27:45 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11977 for ; Mon, 29 Jan 2001 18:27:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64610; Mon, 29 Jan 2001 15:57:02 -0800 (PST) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA64598 for ; Mon, 29 Jan 2001 15:56:48 -0800 (PST) Message-ID: From: Jeff Parker To: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] LSP Buffersize MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 18:25:45 -0500 > 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Jan 29 23:43:13 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17269 for ; Mon, 29 Jan 2001 23:43:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA66045; Mon, 29 Jan 2001 21:12:02 -0800 (PST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA66033 for ; Mon, 29 Jan 2001 21:11:56 -0800 (PST) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id UAA26934; Mon, 29 Jan 2001 20:40:57 -0800 (PST) From: Mike Truskowski Message-Id: <200101300440.UAA26934@diablo.cisco.com> Subject: Re: [Isis-wg] (no subject) To: dkatz@juniper.net (Dave Katz) Cc: Jonathan.Sadler@tellabs.com, chris.flores@onfiber.com, volkan@makesys.com, isis-wg@spider.juniper.net In-Reply-To: <200101292316.PAA02917@cirrus.juniper.net>; from "Dave Katz" at Jan 29, 101 3:18 pm X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 29 Jan 2001 20:40:57 PST 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 > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Jan 30 10:26:17 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10234 for ; Tue, 30 Jan 2001 10:26:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA68686; Tue, 30 Jan 2001 07:55:02 -0800 (PST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA68671 for ; Tue, 30 Jan 2001 07:54:57 -0800 (PST) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA06971; Tue, 30 Jan 2001 10:23:35 -0500 (EST) Received: from jlearman-nt (dhcp-64-102-83-114.cisco.com [64.102.83.114]) by dingdong.cisco.com (Mirapoint) with SMTP id AAT27440; Tue, 30 Jan 2001 10:23:55 -0500 (EST) Message-Id: <4.1.20010130101547.00a5d9b0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Les Ginsberg , "'Ran Atkinson'" , isis-wg@spider.juniper.net From: Jeff Learman Subject: RE: [Isis-wg] LSP Buffersize In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 30 Jan 2001 10:16:28 -0500 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 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg