From pst@juniper.net Wed, 25 Aug 1999 11:29:19 -0700 (PDT) Date: Wed, 25 Aug 1999 11:29:19 -0700 (PDT) From: Paul Traina pst@juniper.net Subject: [Isis-wg] test test e-mail archives From lester-ginsberg@vertel.com Sat, 28 Aug 1999 17:05:46 -0700 (PDT) Date: Sat, 28 Aug 1999 17:05:46 -0700 (PDT) From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] ISO 10589 Editorship Over the past year I have been reporting on the status of the Second Edition Draft of the ISIS specification - ISO 10589. In December of 1998, ISO JTC1/SC6 voted to convene an email editing meeting to review the deficiencies of the draft and work towards correcting them. Since that time little progress has been made. The email editing meeting, after a brief beginning, simply did not occur. In July of 1999, SC6 voted to extend the email editing meeting into September 1999, but this did not result in any activity by the email editing group. Also, the editor of 10589 submitted his resignation due to health reasons. It is quite clear that without an editor, this project within SC6/WG7 will not progress, despite the fact that there are a number of companies/individuals with interest in this project. Although the original scope of the second edition draft was editorial in nature i.e. it attempted to fold in the various Technical Corrigenda and Defect Reports that had been approved over the years, there have been some preliminary discussions regarding expanding the scope of a second edition to include the ongoing work in the IETF ISIS-WG. This raises the possibility that the eventual output of a new edition of 10589 could align the standard with the work both within the IETF and in other more OSI oriented forums (e.g. SIF). Given the likelihood that the use of Integrated IS-IS in networks with OSI and IP will increase in the future, this would seem to be a worthy goal. The Secretariat of SC6 has issued a call for volunteers for the position of project editor for this document. Nominations for this position must be submitted via an SC6 national body. Although the original deadline for nominations was September 1, 1999, I have been assured by the SC6 Secretariat that the deadline is flexible. Anyone interested in serving in this capacity may contact me. I can then forward your interest via the US WG7 TAG or arrange contact with the appropriate body in another country if appropriate. Thanx for your attention. Les -- ------------------------------------------------------------------- VERTEL [ formerly Telegenics / Retix ] ------------------------------------------------------------------- Les Ginsberg "Before enlightenment, chopping wood les-ginsberg@vertel.com and drawing water. Vertel After enlightenment, chopping wood 21300 Victory Blvd and drawing water." Suite 1200 Woodland Hills, Ca. 91367 818 227-1405 (Direct Dial) 818 227-1400 (Main) 818 888-0725(FAX) From grant.mills@lucent.com Fri, 03 Sep 1999 12:58:45 +0100 Date: Fri, 03 Sep 1999 12:58:45 +0100 From: Grant Mills grant.mills@lucent.com Subject: [Isis-wg] IS-IS Extensions for Traffic Engineering A quick query regarding draft-ietf-isis-traffic-01. In RFC 1195 we implement the Internal and External IP reachibilty TLVs in LSPs for ISIS routes (Internal), Non ISIS routes (External), for example (depending on route propagation policies). In addition the TLV allows the specification of metrics as being internal or external as well. In the traffic engineering draft a single TLV (135) is used to hold IP reachibility information. However I do not see any bit field for specifying External/Internal for these routes. The internal/external bit for metrics I can live without but how do I map the old scheme to the daft proposal? Is there an unspecified Sub-TLV for doing this? Is the idea to go from old world Level1 Internal, Level2 Internal/External routes to just flat Level1 and Level2 routes? Regards, Grant. -- ______________________________________________________________________ Grant Mills, Tel: +44 (1252) 360013 Lucent Technologies Inc., __ Fax: +44 (1252) 360077 InterNetworking Systems UK, // \\ Suites 11/12, First Base, || || URL: http://www.lucent.com Beacontree Plaza, \\__// Gillette Way, Email: Reading, Berks, RG2 0BS, grant.mills@lucent.com United Kingdom. grant.mills@bell-labs.com ______________________________________________________________________ From grant.mills@lucent.com Fri, 03 Sep 1999 13:14:27 +0100 Date: Fri, 03 Sep 1999 13:14:27 +0100 From: Grant Mills grant.mills@lucent.com Subject: [Isis-wg] IS-IS Extensions for Traffic Engineering Ooops please excuse the "daft" typo >... but how do I map the old >scheme to the daft proposal? Grant Mills wrote: > > A quick query regarding draft-ietf-isis-traffic-01. > > In RFC 1195 we implement the Internal and External IP reachibilty TLVs in LSPs for ISIS routes (Internal), Non ISIS routes > (External), for example (depending on route propagation policies). In addition the TLV allows the specification of metrics as being > internal or external as well. > > In the traffic engineering draft a single TLV (135) is used to hold IP reachibility information. However I do not see any bit field > for specifying External/Internal for these routes. The internal/external bit for metrics I can live without but how do I map the old > scheme to the daft proposal? Is there an unspecified Sub-TLV for doing this? Is the idea to go from old world Level1 Internal, > Level2 Internal/External routes to just flat Level1 and Level2 routes? > > Regards, > > Grant. > > -- > ______________________________________________________________________ > > Grant Mills, Tel: +44 (1252) 360013 > Lucent Technologies Inc., __ Fax: +44 (1252) 360077 > InterNetworking Systems UK, // \\ > Suites 11/12, First Base, || || URL: http://www.lucent.com > Beacontree Plaza, \\__// > Gillette Way, Email: > Reading, Berks, RG2 0BS, grant.mills@lucent.com > United Kingdom. grant.mills@bell-labs.com > ______________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ______________________________________________________________________ Grant Mills, Tel: +44 (1252) 360013 Lucent Technologies Inc., __ Fax: +44 (1252) 360077 InterNetworking Systems UK, // \\ Suites 11/12, First Base, || || URL: http://www.lucent.com Beacontree Plaza, \\__// Gillette Way, Email: Reading, Berks, RG2 0BS, grant.mills@lucent.com United Kingdom. grant.mills@bell-labs.com ______________________________________________________________________ From hsmit@cisco.com Fri, 3 Sep 1999 14:15:14 +0200 (MET DST) Date: Fri, 3 Sep 1999 14:15:14 +0200 (MET DST) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] IS-IS Extensions for Traffic Engineering > A quick query regarding draft-ietf-isis-traffic-01. > > In RFC 1195 we implement the Internal and External IP reachibilty > TLVs in LSPs for ISIS routes (Internal), Non ISIS routes (External), > for example (depending on route propagation policies). In addition > the TLV allows the specification of metrics as being internal or > external as well. > > In the traffic engineering draft a single TLV (135) is used to hold > IP reachibility information. However I do not see any bit field for > specifying External/Internal for these routes. The internal/external > bit for metrics I can live without Thank you. One of the reasons that we didn't put this in our draft is that the I/E metric bit is implemented wrongly in our IOS implementation. No customer ever really complained about it. So it seems the I/E metric bit is not used at all. At least not by our customers. > but how do I map the old scheme > to the daft proposal? Is there an unspecified Sub-TLV for doing > this? Is the idea to go from old world Level1 Internal, Level2 > Internal/External routes to just flat Level1 and Level2 routes? Yes. Please note that in RFC1195, paragraph 3.10.2, 2c), there is a note, saying: NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field), and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation. So why do you want to see the difference between internal prefixes and external prefixes ? It doesn't matter for route selection. So I assume you want to use this to prevent "redistribution feedback" when doing mutual redistributing with another IGP at two or more places ? Or do you have another reason ? draft-ietf-isis-traffic-01 allows us to specify sub-TLVs for IP prefixes. One thing we plan to do is define a sub-TLV to tag or color IP prefixes. Those tags/colors can be used to distinquish between internal and external routes. Then you can use those tags/colors to control redistribution. We could even define one or more "well-known colors", like well-known BGP communities like no-advertise, etc. Hope this helps, Henk. > Regards, > > > Grant. > > > -- > ______________________________________________________________________ > > Grant Mills, Tel: +44 (1252) 360013 > Lucent Technologies Inc., __ Fax: +44 (1252) 360077 > InterNetworking Systems UK, // \\ > Suites 11/12, First Base, || || URL: http://www.lucent.com > Beacontree Plaza, \\__// > Gillette Way, Email: > Reading, Berks, RG2 0BS, grant.mills@lucent.com > United Kingdom. grant.mills@bell-labs.com > ______________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From grant.mills@lucent.com Fri, 03 Sep 1999 13:58:56 +0100 Date: Fri, 03 Sep 1999 13:58:56 +0100 From: Grant Mills grant.mills@lucent.com Subject: [Isis-wg] IS-IS Extensions for Traffic Engineering Henk, thanks for the reply. > Thank you. > One of the reasons that we didn't put this in our draft is that > the I/E metric bit is implemented wrongly in our IOS implementation. > No customer ever really complained about it. So it seems the I/E > metric bit is not used at all. At least not by our customers. I'm glad you said that. ;-) We have a Cisco metrics mode which we can turn on if we wish to interoperate properly with Cisco ISIS. And turn it off to work the Digital/ISO way. ;-) > So why do you want to see the difference between internal prefixes > and external prefixes ? It doesn't matter for route selection. > So I assume you want to use this to prevent "redistribution > feedback" when doing mutual redistributing with another IGP > at two or more places ? Or do you have another reason ? True route selection is not the issue. As you say it is useful when injecting foreign routes from another IGP, e.g. OSPF, BGP, etc and have those routes tagged at a different route priority or effected by targeted route policies than the ISIS routes. > draft-ietf-isis-traffic-01 allows us to specify sub-TLVs for > IP prefixes. One thing we plan to do is define a sub-TLV to > tag or color IP prefixes. Those tags/colors can be used to > distinquish between internal and external routes. Then you > can use those tags/colors to control redistribution. We could > even define one or more "well-known colors", like well-known > BGP communities like no-advertise, etc. When do you plan to publish the sub-TLV options. I assume this sub-TLV is similar to the one that appears in the extended IS reachability TLV? Cheers, Grant. -- ______________________________________________________________________ Grant Mills, Tel: +44 (1252) 360013 Lucent Technologies Inc., __ Fax: +44 (1252) 360077 InterNetworking Systems UK, // \\ Suites 11/12, First Base, || || URL: http://www.lucent.com Beacontree Plaza, \\__// Gillette Way, Email: Reading, Berks, RG2 0BS, grant.mills@lucent.com United Kingdom. grant.mills@bell-labs.com ______________________________________________________________________ From hsmit@cisco.com Fri, 3 Sep 1999 16:20:51 +0200 (MET DST) Date: Fri, 3 Sep 1999 16:20:51 +0200 (MET DST) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] IS-IS Extensions for Traffic Engineering > > draft-ietf-isis-traffic-01 allows us to specify sub-TLVs for > > IP prefixes. One thing we plan to do is define a sub-TLV to > > tag or color IP prefixes. Those tags/colors can be used to > > distinquish between internal and external routes. Then you > > can use those tags/colors to control redistribution. We could > > even define one or more "well-known colors", like well-known > > BGP communities like no-advertise, etc. > > When do you plan to publish the sub-TLV options. I assume this > sub-TLV is similar to the one that appears in the extended IS > reachability TLV? The idea was that draft-ietf-isis-traffic-01 only defines the things that are needed to do traffic engineering (with MPLS). That would be the new IS neighbor TLV that has the ability to do sub-TLVs. Plus the sub-TLVs that are needed for TE. While we were at this, we wanted to extend the metric space. To make sure the wider metric space was usable between areas, we also needed to define a new IP prefix TLV. This is where we stopped with our new additions. Anything else new that is not directly related to TE should go into a separate drafts. The downside would be that we end up with many new RFCs and drafts. The upside would be that we can continue moving the older drafts through the standards track while developing new technologies. If you want to implement a new sub-TLV for route tagging/coloring, feel free to document your implementation in a new draft. Otherwise it would probably take a few months before I, or someone else at cisco, would implement and document this. Cheers, henk. From naiming@cisco.com Tue, 07 Sep 1999 17:14:32 -0700 Date: Tue, 07 Sep 1999 17:14:32 -0700 From: Naiming Shen naiming@cisco.com Subject: [Isis-wg] updated version of draft-ietf-isis-dyname just sent I have just send out the updated version of isis-dyname: draft-ietf-isis-dyname-01.txt to ietf directory. It can also be fetched from anonymous ftp server: ftp-eng.cisco.com:naiming/draft-ietf-isis-dyname-01.txt Thanks. - Naiming From Snehal.Desai@aud.alcatel.com Thu, 9 Sep 1999 18:19:58 -0500 Date: Thu, 9 Sep 1999 18:19:58 -0500 From: Snehal Desai Snehal.Desai@aud.alcatel.com Subject: [Isis-wg] mesh groups Is there a draft somewhere about mesh groups in IS-IS?? If so, can someone direct me to it. Thanks, Snehal From jparker@nexabit.com Fri, 10 Sep 1999 10:43:15 -0400 Date: Fri, 10 Sep 1999 10:43:15 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] mesh groups Yes, there is. draft-balay-katz-parker-mesh-00.txt At the WG meeting, it was moved to change the status of this to a WG item as a documentation of existing practice, but the editors have not done so yet. - jparker@nexabit.com - Lucent INS - Isn't there any other part of the matzo you can eat? - Marilyn Monroe, after being served matzo ball soup three meals in a row. > -----Original Message----- > From: Snehal.Desai@aud.alcatel.com > [mailto:Snehal.Desai@aud.alcatel.com] > Sent: Thursday, September 09, 1999 7:20 PM > To: isis-wg@external.juniper.net; desas1@aud.alcatel.com > Subject: [Isis-wg] mesh groups > > > Is there a draft somewhere about mesh groups in IS-IS?? If > so, can someone > direct me to it. > > Thanks, > Snehal > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Snehal.Desai@aud.alcatel.com Fri, 10 Sep 1999 12:40:04 -0500 Date: Fri, 10 Sep 1999 12:40:04 -0500 From: Snehal Desai Snehal.Desai@aud.alcatel.com Subject: [Isis-wg] other isis mailing lists Is there a Cisco's IS-IS mailing list. If so how can I subscribe to it. It seems to me that there is some interesting discussion going on in IS-IS outside this mailing list. Also can someone point me towards the "Larger Metrics" draft, if such a draft exists. Thanks, Snehal From jparker@nexabit.com Fri, 10 Sep 1999 13:49:23 -0400 Date: Fri, 10 Sep 1999 13:49:23 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] other isis mailing lists Snehal - I assume you are talking about draft-ietf-isis-traffic-01.txt, which describes a TLV that includes 32 bits for a metric. - jparker@nexabit.com - Lucent INS - Isn't there any other part of the matzo you can eat? - Marilyn Monroe, after being served matzo ball soup three meals in a row. > -----Original Message----- > From: Snehal.Desai@aud.alcatel.com > [mailto:Snehal.Desai@aud.alcatel.com] > Sent: Friday, September 10, 1999 1:40 PM > To: isis-wg@external.juniper.net; desas1@aud.alcatel.com > Subject: [Isis-wg] other isis mailing lists > > > > Is there a Cisco's IS-IS mailing list. If so how can I subscribe to > it. It seems to me that there is some interesting discussion > going on > in IS-IS outside this mailing list. > > Also can someone point me towards the "Larger Metrics" draft, if such > a draft exists. > > Thanks, > Snehal > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From hsmit@cisco.com Fri, 10 Sep 1999 20:52:54 +0200 (MET DST) Date: Fri, 10 Sep 1999 20:52:54 +0200 (MET DST) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] other isis mailing lists > Is there a Cisco's IS-IS mailing list. > If so how can I subscribe to it. Nope, there is no such list. > It seems to me that there is some interesting discussion going on > in IS-IS outside this mailing list. Not that I know of. There is the SIF forum (Sonet Interoperability Forum). For the rest all progress is reported to this list, and discussed at the IETF ISIS WG meetings. Henk. From satish@pluris.com Fri, 10 Sep 1999 13:48:40 -0700 Date: Fri, 10 Sep 1999 13:48:40 -0700 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] other isis mailing lists How to subscribe to SIF? thanks, satish Henk Smit wrote: > > Is there a Cisco's IS-IS mailing list. > > If so how can I subscribe to it. > > Nope, there is no such list. > > > It seems to me that there is some interesting discussion going on > > in IS-IS outside this mailing list. > > Not that I know of. > There is the SIF forum (Sonet Interoperability Forum). > For the rest all progress is reported to this list, and discussed > at the IETF ISIS WG meetings. > > Henk. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From hsmit@cisco.com Sat, 11 Sep 1999 03:18:22 +0200 (MET DST) Date: Sat, 11 Sep 1999 03:18:22 +0200 (MET DST) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] other isis mailing lists Send email to Majordomo@lists.atis.org, with the following command in the body of your email message: subscribe sif-arch Please note that mainly other stuff is discussed on this archive. Not just ISIS. TARP, OSI-IP mediation, etc. In fact since I joined there has been little discussion about ISIS itself. I joined because the SIF wanted to bring in a recommendation to change the default maxLSPBuffersize from 1492 to 512 bytes. I didn't like that idea, so that is why I subscribed. I mentioned the SIF only because it is the only place I know of where ISIS might get discussed. Sonet ADMs are managed via OSI protocols. They use CLNS as their transport. And thus ISIS as the routing protocol. That is why SIF has an interest in ISIS. The SIF forum is mainly about OSI protocols, and thus only discusses the CLNS side of ISIS. For IP related stuff, the IETF isis-wg is the place to be. Hope this helps, Henk. > How to subscribe to SIF? > thanks, > satish > > > Henk Smit wrote: > > > > Is there a Cisco's IS-IS mailing list. > > > If so how can I subscribe to it. > > > > Nope, there is no such list. > > > > > It seems to me that there is some interesting discussion going on > > > in IS-IS outside this mailing list. > > > > Not that I know of. > > There is the SIF forum (Sonet Interoperability Forum). > > For the rest all progress is reported to this list, and discussed > > at the IETF ISIS WG meetings. > > > > Henk. > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.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 ctklish@nortelnetworks.com Mon, 13 Sep 1999 09:25:59 -0400 Date: Mon, 13 Sep 1999 09:25:59 -0400 From: Cypryan Klish ctklish@nortelnetworks.com Subject: [Isis-wg] other isis mailing lists See also: http://www.atis.org/atis/sif/sifdoc99.htm for SIF contributions related to IS-IS: SIF-AR-9905-056 SIF-AR-9907-082 SIF-AR-9907-090 Kip Klish SIF Architecture Work Group Chair > -----Original Message----- > From: Henk Smit [SMTP:hsmit@cisco.com] > Sent: Friday, September 10, 1999 9:18 PM > To: satish@pluris.com > Cc: isis-wg@external.juniper.net > Subject: Re: [Isis-wg] other isis mailing lists > > > Send email to Majordomo@lists.atis.org, with the following > command in the body of your email message: > subscribe sif-arch > > Please note that mainly other stuff is discussed on this archive. > Not just ISIS. TARP, OSI-IP mediation, etc. > In fact since I joined there has been little discussion about ISIS > itself. > I joined because the SIF wanted to bring in a recommendation to change > the default maxLSPBuffersize from 1492 to 512 bytes. I didn't like > that idea, so that is why I subscribed. > I mentioned the SIF only because it is the only place I know of where > ISIS might get discussed. > > Sonet ADMs are managed via OSI protocols. They use CLNS as their > transport. And thus ISIS as the routing protocol. That is why SIF > has an interest in ISIS. The SIF forum is mainly about OSI protocols, > and thus only discusses the CLNS side of ISIS. > For IP related stuff, the IETF isis-wg is the place to be. > Hope this helps, > > Henk. > > > > > How to subscribe to SIF? > > thanks, > > satish > > > > > > Henk Smit wrote: > > > > > > Is there a Cisco's IS-IS mailing list. > > > > If so how can I subscribe to it. > > > > > > Nope, there is no such list. > > > > > > > It seems to me that there is some interesting discussion going on > > > > in IS-IS outside this mailing list. > > > > > > Not that I know of. > > > There is the SIF forum (Sonet Interoperability Forum). > > > For the rest all progress is reported to this list, and discussed > > > at the IETF ISIS WG meetings. > > > > > > Henk. > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.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 tli@procket.com Mon, 20 Sep 1999 09:58:00 -0700 Date: Mon, 20 Sep 1999 09:58:00 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] New WG document Folks, We've been asked to make draft-kaplan-isis-ext-eth-00.txt as IS-IS WG document. I believe that this was discussed in Oslo, but just in case there are a few people who didn't make it to Oslo ;-), it seems sane just to check one more time. If you have any objection to making this a WG document, please respond by this Friday. Once again, the reason that this document makes sense as an IS-IS WG document is that it's quite self-contained, shouldn't be very contentious (we hope ;-), and of the things currently in the Internet, affects IS-IS the most. Tony & Tony From jjl@one.com Mon, 20 Sep 1999 15:05:14 -0400 Date: Mon, 20 Sep 1999 15:05:14 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] New WG document A few minor comments: 1. The term "Ethertype" is used but not defined. Of course we all know what it means, but it would be easy to define it in Section 4 (perhaps as the label for the "type" field in the Ethernet II packet format.) 2. In section 6, it says "There is no loss of information from 802.3/802.2 frames. Although the 802.3 length field is missing, the frame length is known by virtue of the frame being accepted by the network interface." This is true only if the physical layer does not have a minimum frame size less than 1500 bytes. For example, Ethernet II has a minimum frame size of 64 due to transmission characteristics and collision detection, so small frames are padded to that size before transmission -- ergo the lenght field in the 802.3 format. ISIS and ESIS packets rely on a valid frame size from the Datalink layer. Therefore, this RFC should be explicitly limited in application to physical layers that have a minimum frame size of 1500 bytes or less (excluding source & destination MAC addresses and Ethertype fields). Hopefully, this is not too restrictive to be applicable to anticipated bit rates, transmission line lengths, and collision detection methods. If it is too restrictive, then it might be better to deal with it now and save trouble later. 3. I am curious why IS-IS frames larger than 1500 would be desirable. It looks like this draft RFC takes a straightforward approach to a straightforward issue: running IS-IS on subnetworks that support MTU sizes greater than 1500. (Of course, it's commendable to take the straightforward approach ;-) But it might be worthwhile to look at an alternative: to set a different MTU size for IS-IS than for the data protocols it supports routing for. A way of evaluating this is to ask why it might be useful for IS-IS to be able to send large packets. The following are potential reasons why it would be better to support large IS-IS PDUs (per the draft) than to have separate MTU sizes for IS-IS and the data protocols (the alternative) A) Checking consistency of MTU size settings between routers on a LAN. I understand that IS-IS's ability to verify that frames of a certain size can be exchanged on a link is useful, but it is far more important for maintaining the integrity of route exchange than data exchange, because of the nasty problems that result from incomplete route propagation (far worse to diagnose and repair than simple data loss). B) Optimizing LSP traffic The use of very large LSPs might be useful, but only in a subdomain where all links supported the larger MTU size. I doubt that this is what is intended, since no mention of is made of maxLspReceiveBufferSize. C) Optimizing CSNP traffic In a very large subdomain, fewer CSNP PDUs would be required if they could be larger. But since only the DR transmits them, the difference in efficiency should be negligible. D) Permitting more than 200 routers on a LAN For IIH PDUs, the size of the IIH limits the number of ISs that can be present on a LAN (about 200 for 1500-byte IIHs with no authentication field). Is this limit significant? Maybe so. E) Permitting rediculously large ISH or ESH PDUs. I hope nobody is seriously considering this! F) Just following the rules The IS-IS spec has requirements about the MTU size, and doesn't have any provision for separate max sizes for routing and data protocols. It might be best just to follow those rules. But if none of these issues is very important, it might be simpler to keep the 1500-byte MTU size for ES-IS and IS-IS PDUs regardless of the MTU size for IP and other protocols. Note that this would NOT necessarily invalidate the draft RFC, which could still be used (e.g., to permit a large MTU size for CLNP). It might make it a bit less significant. Note also that since IIH PDUs on a broadcast LAN are required to be the max MTU size, if the max MTU size increases by a higher ratio than the bandwidth then IS-IS would take a higher percentage of the LAN bandwidth than it does now. Of course, this is not much of an issue unless there is a large number of routers on the LAN. Regards, Jeff At 09:58 AM 9/20/99 -0700, Tony Li wrote: > >Folks, > >We've been asked to make draft-kaplan-isis-ext-eth-00.txt as IS-IS WG >document. I believe that this was discussed in Oslo, but just in case >there are a few people who didn't make it to Oslo ;-), it seems sane just >to check one more time. > >If you have any objection to making this a WG document, please respond by >this Friday. > >Once again, the reason that this document makes sense as an IS-IS WG >document is that it's quite self-contained, shouldn't be very contentious >(we hope ;-), and of the things currently in the Internet, affects IS-IS >the most. > >Tony & Tony > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From tli@procket.com Mon, 20 Sep 1999 13:52:27 -0700 Date: Mon, 20 Sep 1999 13:52:27 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] New WG document Jeff, | Therefore, this RFC should be explicitly limited in application to | physical layers that have a minimum frame size of 1500 bytes or | less (excluding source & destination MAC addresses and Ethertype | fields). Thanks, yes. FWIW, the primary driver behind this is Jumbo Frames on Gigabit Ethernet. The above caveat is reasonable in case someone ever generalizes stuff. | 3. I am curious why IS-IS frames larger than 1500 would be desirable. Jumbo Frames are going to get deployed to avoid MTU issues in the backbone. As IS-IS tends to use the available MTU, we need some well-defined way of encapsulating PDUs. | The following are potential reasons why it would be better to | support large IS-IS PDUs (per the draft) than to have separate | MTU sizes for IS-IS and the data protocols (the alternative) | | A) Checking consistency of MTU size settings between routers on | a LAN. | | I understand that IS-IS's ability to verify that frames of a | certain size can be exchanged on a link is useful, but it is | far more important for maintaining the integrity of route | exchange than data exchange, because of the nasty problems | that result from incomplete route propagation (far worse to | diagnose and repair than simple data loss). Insuring that the data exchange happens is the key point. MTU issues in the data plane are no fun and IS-IS as it stands today obviates the issue. We would like to preserve this property. Tony From bwarijsman@lucent.com Wed, 22 Sep 1999 14:59:11 -0400 Date: Wed, 22 Sep 1999 14:59:11 -0400 From: Rijsman, Bruno (Bruno) bwarijsman@lucent.com Subject: [Isis-wg] Vendor proprietary LSP option codes We are considering to use a proprietary LSP option for one of our applications and we a considering which LSP option code we could use for this application. We want to pick an option code which guarantueed not to conflict with any existing or future option codes used in integrated IS-IS and proprietary option codes of other vendors. It seems to me that (a) there is currently no official way for allocating unique option codes (b) option codes are a scarce resource (only 255 codes available) To solve this, it would be a good idea to: (a) allocate a single option code for "vendor proprietary options" (b) to require that the first three bytes in such "vendor proprietary options" must be an ethernet OUI allocated to that vendor (c) to strongly recommend that "vendor proprietary options" be small in size and do not change frequently (to avoid impact on "innocent" nodes). (d) to require that "vendor proprietary options" which are not recognized must be silently ignored but propagated anyway (actually, this is already part of ISO 10589). If such an option already exists, could someone point me to it. If it doesn't exist yet, what would be the proper process for me to standardize such an option? PS - It might be relevant to know that for this particular application we are using IS-IS in an OSI CLNP network (the OSI network is used for management of SDH/SONET network elements). Bruno Rijsman Lucent Technologies - Optical Networking Group From tli@procket.com Thu, 23 Sep 1999 10:52:09 -0700 Date: Thu, 23 Sep 1999 10:52:09 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] Vendor proprietary LSP option codes Bruno, Are you looking for a TLV type or a sub-TLV type to the proposed extended IS/IP reachability TLV? If it's the former, then you are correct, there is no 'clean' way of getting a number out of ISO today because so little work is going on in ISO. I suppose that you could take a proposal to them, or you could circulate a proposal within the IETF. For the latter, we can help you out. You might note that Cisco has several reserved codes. IMHO, creating a single TLV type or sub-TLV type for 'vendor proprietary options' is probably a poor choice as it has some future difficulties. If you ever do make your extension public (and you DO want to make it public eventually...) and it gets a 'normal' TLV type, then you have to make a migration to the new TLV. If you don't use a 'normal' TLV, then all sorts of interesting extensions end up in the 'vendor proprietary' bucket and we have a soup that serves no one well. Our goal has to be to create an open protocol, not foster incompatible extensions. Tony From tli@procket.com Thu, 23 Sep 1999 10:58:06 -0700 Date: Thu, 23 Sep 1999 10:58:06 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] Dynamic naming Just a note to close the WG last call for "Dynamic Hostname Exchange Mechanism for IS-IS". This document will be passed up to our area directors.... Tony & Tony From tli@procket.com Thu, 23 Sep 1999 11:17:17 -0700 Date: Thu, 23 Sep 1999 11:17:17 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] Vendor proprietary LSP option codes | in my opinion, the migration is the issue specific to a specific vendor only if he chooses | to make the extensions public. OUI is the best way to get people a sandbox in | which they can try things. It's indefinitely better than having people "just using | some TLV codes" due to the lack of a reserved one and collide in the field. I agree between those two alternatives but still find both inferior to simply allocating TLV types to vendors, with the hope that they eventually make the semantics public. Tony From tli@procket.com Thu, 23 Sep 1999 11:31:22 -0700 Date: Thu, 23 Sep 1999 11:31:22 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] Vendor proprietary LSP option codes | However, I wouldn't | want to do things like standardizing the way to pass company's X | equipment serial numbers for | inventory purposes ;-) We are, of course, in violent agreement. Hopefully no one would burden the routing protocol with becoming their generic transport mechanism even with a proprietary TLV type. Tony From jjl@one.com Thu, 23 Sep 1999 17:28:10 -0400 Date: Thu, 23 Sep 1999 17:28:10 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Vendor proprietary LSP option codes I agree with Tony P. There needs to be a safe way of allocating TLV codes, whether for vender-proprietary purposes or prototypes for new functions that might be standardized. Migration from a vendor-specific code to a standard code is the problem of the vendor. There is no authority stepping forward to manage the 8-bit TLV code space for IS-IS. Clearly, ISO methods are far too slow. The IETF has the advantages that it is quick-acting and is a respected authority. A TLV code should be selected for "OUI-identified options", and simply state that the option is defined by the authority specified by the OUI. The 8-bit code space is rather limited, so if there was a good allocation method, any company with a possible interest might feel compelled to get one ASAP. The 8-bit code space should be reserved for standard options, with a grandfather clause for current practice (provided there is public disclosure of such TLV codes, to avoid future collisions). Regards, Jeff At 11:03 AM 9/23/99 -0700, Tony Przygienda wrote: >Tony Li wrote: > >> Bruno, >> >> Are you looking for a TLV type or a sub-TLV type to the proposed >> extended IS/IP reachability TLV? >> >> If it's the former, then you are correct, there is no 'clean' way of >> getting a number out of ISO today because so little work is going on in >> ISO. I suppose that you could take a proposal to them, or you could >> circulate a proposal within the IETF. >> >> For the latter, we can help you out. You might note that Cisco has several >> reserved codes. >> >> IMHO, creating a single TLV type or sub-TLV type for 'vendor proprietary >> options' is probably a poor choice as it has some future difficulties. If >> you ever do make your extension public (and you DO want to make it public >> eventually...) and it gets a 'normal' TLV type, then you have to make a >> migration to the new TLV. If you don't use a 'normal' TLV, then all sorts >> of interesting extensions end up in the 'vendor proprietary' bucket and we >> have a soup that serves no one well. Our goal has to be to create an open >> protocol, not foster incompatible extensions. > >Disagree here, > >in my opinion, the migration is the issue specific to a specific vendor only if he chooses >to make the extensions public. OUI is the best way to get people a sandbox in >which they can try things. It's indefinitely better than having people "just using >some TLV codes" due to the lack of a reserved one and collide in the field. > >-- > thanks > > --- tony > > > > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From qv@juniper.net Wed, 29 Sep 1999 14:08:00 -0700 (PDT) Date: Wed, 29 Sep 1999 14:08:00 -0700 (PDT) From: Quaizar Vohra qv@juniper.net Subject: [Isis-wg] Clarification needed on domain-wide prefix distribution Folks, Here are some issues related to domain-wide prefix distribution draft and TE draft I would like clarification on. I did like to clarify the preference order among different types of routes for inter-operability purpose. Here is one possible way to do it which actually is enforced implicitly by both the drafts. Here is a list of possible route types (assuming external routes with internal metric type are the only ones supported). 1) L1 intra-area 2) L1 external (imported from other protocols) 3) L1 -> L2 inter-area (L2 intra-area leaked into L1) 4) L1 -> L2 external (L1 external leaked into L2). 5) L2 intra-area 6) L2 external 7) L2 -> L1 inter-area (L2 intra-area leaked into L1) 8) L2 -> L1 external (L2 external leaaked into L1) There is no way to distinguish between 7) and 8) in the domain-wide draft. From TE draft one can't differentiate between 1) & 2), nor between 3), 4), 5) & 6), nor between 7) and 8). external routes. Now if one notes rfc 1195, it recognizes a subset of the above route types and treats them in the following order of decreasing preference : 1) 3) == 5) == 6) 9) L2 external routes with external metric type Note that it treats L2 intra-area and L1->l2 inter-area and L2 external routes with internal metric type equivalently, i.e. they have the same preference and the lower metric wins. If one follows the same philosophy, i.e. treating external routes with internal metric type learnt in an area same as intra-area route, and by the virtue of both the drafts we are forced with the following order of decreasing preference. 1) == 2) 3) == 4) == 5) == 6) == 7) == 8) This said, I want the WG to consider the following : We still want the external routes to be distinguishable so as to allow filtering capcabilities when leaking routes from L2 to L1. So it would be be nice if the TE draft could be updated to either reserve a bit or add a subtlv to allow for this distinction. Also I wonder if there is any reason for not considering reserved bit (bit 8) of the default metric in the IP reachabilty TLV in rfc1195 for the purpose of a downbit in the domain-wide prefix distribution draft. This would have left things cleaner. Also it would be nice to have external routes with external metric types. One can imagine the following additional types of routes 9) L2 external with external metric type (rfc1195 supports this). 10) L2 -> L1 external with ext metric type 11) L1 external with external metric type 12) L1 -> L2 external with ext metric type 9) and 11) could still be supported with the existing domain wide prefix dist draft without any change. It would be nice if TE draft could add capability for such a distinction. 10) and 12) cant be supported without loss of knowledge of the distance to the exit router which originated the route as we do not keep any metric in the IP prefix TLV which preserves the distance from the exit router who originated the route, to the guy who's leaking the route across levels. OSPF deals with that in one fashion. We could deal with it by introducing a subtlv which preserves this knowledge. Anyway 10), 11) , 12) need not be supported till a need for them is known. 9) is easy to support and in fact thats the only thing rfc1195 supports. Also it would make more sense to have the following order of decreasing preference of routes from implementation perspective. One might further specify tie-breaking rules for routes with same preference but different types. 1) L1-intra 2) L2-intra, L1->L2 inter-area, L2->L1 inter-area 3) L1-ext, L2-ext, L1->L2 ext, L2->L1 ext (all with internal metric type). 4) all external routes with external metric types. This is incompatible with rfc1195 by not treating L2-intra and L2-external routes with internal metric type equivalently. But all the deployed base I know of happens to violate rfc1195 on this issue. Quaizar From hsmit@cisco.com Fri, 1 Oct 1999 17:29:52 +0200 (MET DST) Date: Fri, 1 Oct 1999 17:29:52 +0200 (MET DST) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] Clarification needed on domain-wide prefix distribution > Folks, > Here are some issues related to domain-wide prefix > distribution draft and TE draft I would like clarification on. > > I did like to clarify the preference order among different types of > routes for inter-operability purpose. Here is one possible way to do > it which actually is enforced implicitly by both the drafts. I'm one of the authors of both drafts. I was planning on adjusting draft-ietf-isis-domain-wide-01.txt, but unfortunately I haven't found the time to do it yet. > Here is a list of possible route types (assuming external routes with > internal metric type are the only ones supported). Why do you assume this ? RFC1195 specifies external routes with external metric type. Personally I don't think that is a very useful feature. As many of you know, our cisco IS-IS implementation never looked at the I/E bit. During the last several years, no customer has ever asked us to fix this. So I always assumed the I/E bit has limited use in real networks. Unfortunately (for me) one of our customers pushed recently to add a knob to recognize the I/E bit. For interoperability reasons. I am not too familiar with other IS-IS implementation, but I have been told that others either do recognize the I/E bit, or have knob to choose between recognizing and ignoring the I/E bit. > 1) L1 intra-area > 2) L1 external (imported from other protocols) So I think we must split this one in two. > 3) L1 -> L2 inter-area (L2 intra-area leaked into L1) Guess this is a typo ? You mean (L1 intra-area leaked into L2) ? > 4) L1 -> L2 external (L1 external leaked into L2). Yes, you could see this one as different from 3). But because RFC1195 does not specify L1 externals, RFC1195 does not specify whether L1 externals should be advertised into L2 as TLV128 or TLV130. FYI our cisco IOS advertises L1 externals into L2 as TLV128. I am sorry if someone does not like me mentioning how our cisco IOS does certain things that are not fully specified in rfc1195. But the goal of draft-ietf-isis-domain-wide-01.txt is to do something that is backwards compatible with the current installed base. So I think it is sometimes useful to describe current IOS behaviour. > 5) L2 intra-area > 6) L2 external Again, I think we must split this one in two. > 7) L2 -> L1 inter-area (L2 intra-area leaked into L1) > 8) L2 -> L1 external (L2 external leaaked into L1) > > There is no way to distinguish between 7) and 8) in the domain-wide > draft. Agreed. > From TE draft one can't differentiate between 1) & 2), Agreed. Note that rfc1195 says that there should be no difference in preference between IP prefixes advertised in TLV128 and TLV130. Our implementation does not even store the difference in the RIB. So Tony Li's first idea was that if there is no difference, why maintain it in the new draft ? I agree with him. > nor between 3), 4), 5) & 6), nor between 7) and 8). Agreed. > external routes. Can't parse this sentence. ;-) > Now if one notes rfc 1195, it recognizes a subset of the above > route types and treats them in the following order of > decreasing preference : > > 1) > 3) == 5) == 6) > 9) L2 external routes with external metric type Agreed. I see you added a 9th route type. > Note that it treats L2 intra-area and L1->l2 inter-area and L2 external > routes with internal metric type equivalently, i.e. they have the same > preference and the lower metric wins. Agreed. > If one follows the same philosophy, i.e. treating external routes with > internal metric type learnt in an area same as intra-area route, and > by the virtue of both the drafts we are forced with the following > order of decreasing preference. > > > 1) == 2) > 3) == 4) == 5) == 6) == 7) == 8) I don't agree here. I think L2->L1 inter-area routes should have the lowest preference. That means: 1) == 2) 3) == 4) == 5) == 6) 7) == 8) > This said, I want the WG to consider the following : > > We still want the external routes to be distinguishable so as > to allow filtering capcabilities when leaking routes from L2 to L1. > So it would be be nice if the TE draft could be updated to either > reserve a bit or add a subtlv to allow for this distinction. We thought about that. Tony came up with the nice idea that the prefix lenght only needs 6 bits, so we had two bits to play with. Having the up/down bit is clearly very useful. Now what to do with the second bit ? We thought about using it for either a) Internal/external route-type bit (like TLV128 vs TLV130) b) Internal/external metric-type bit (like the old I/E bit) c) as a flag to indicate the existence of sub-TLVs a) is specified in rfc1195, but not used. so why waste the bit on this ? b) is specified and used in rfc1195. but in real life nobody uses it. so why waste the bit on this one ? c) using the prefix notation from BGP in ISIS gives us a win in the number of bytes used per IP prefix. In rfc1195 we use 12 bytes per prefix. 256 fragments * 1492 - a little / 12 bytes per prefix means that the maximum number of IP routes advertised by a single router is something like 30K prefixes. With the BGP notation it would be something like 48K prefixes. Always including the sub-TLV byte would bring this down to 42K. Tony Li liked to keep the number of bytes per prefix low. Because a) and b) didn't make much sense\ in our opinion I agree with him. > Also I wonder if there is any reason for not considering reserved bit > (bit 8) of the default metric in the IP reachabilty TLV in rfc1195 for > the purpose of a downbit in the domain-wide prefix distribution > draft. This would have left things cleaner. We thought about that. One of the main goals of draft-ietf-isis-domain-wide-01.txt is to be backwards compatible with current implementations running on L1-only routers. The "reserved bit" must not be set on transmision, and should be ignored on reception. But we feared that not all implementations could deal with this bit being set. Another reason is this: suppose you have a L2 prefix P, advertised by router A. Then two L1L2 routers B and C will leak it down into L1. Another L1-only router D will pick it up. P is advertised as external metric 5. The path-cost between A and B is 10. The path-cost between A and C is 20. Suppose you could advertise the metric-type into the inter-area route. How are B and C going to advertise this into their L1 LSPs ? With the I/E bit set, and metric 5 ? Now D will not be able to see the real cost towards A. The reason we introduced L2->L1 interarea routes is so that L1-only routers know more about the cost of the L2 path. When external metrics are involved, the cost of the L2 path becomes less important. Thus L2->L1 inter-area routes become less important. So why even leak them ? Yes, we could change draft-ietf-isis-domain-wide-01.txt to use bit 8, in stead of the I/E bit. If there are others on this list who also like to do this, let us know. > Also it would be nice to have external routes with external metric > types. One can imagine the following additional types of routes > > 9) L2 external with external metric type (rfc1195 supports this). Agreed. > 10) L2 -> L1 external with ext metric type Yes, this could be added. RFC1195 does not specify if a L1 external should be advertised into L2 in TLV128 or TLV130. Yes, it would be useful to maintain this distinction between L1 and L2. Allas, unfortunately we can't maintain this distinction when doing L2 -> L1, as L2->L1 interara is always advertised into TLV128. Actually now that I think about it once more, this is a perfect reason to switch to your proposal to use bit 8 in stead of the I/E bit. If we use bit 8, we can do L2->L1 interarea routes in TLV128 and TLV130. > 11) L1 external with external metric type > 12) L1 -> L2 external with ext metric type > > 9) and 11) could still be supported with the existing domain wide > prefix dist draft without any change. It would be nice if TE > draft could add capability for such a distinction. > > 10) and 12) cant be supported without loss of knowledge of the > distance to the exit router which originated the route as we do not > keep any metric in the IP prefix TLV which preserves the distance from > the exit router who originated the route, to the guy who's leaking the > route across levels. OSPF deals with that in one fashion. We could > deal with it by introducing a subtlv which preserves this knowledge. Personally I don't like the idea of putting stuff in sub-TLVs that influences the basic SPF. > Anyway 10), 11) , 12) need not be supported till a need for them > is known. 9) is easy to support and in fact thats the only > thing rfc1195 supports. Yes, 9) is easy to support if you use the trick from 10589. (multiply the external metric by 1024, and add the path cost). However it becomes a little more tricky when you mix TLV128/TLV130 with TLV135. > Also it would make more sense to have the following order of > decreasing preference of routes from implementation perspective. > One might further specify tie-breaking rules for routes with > same preference but different types. > > 1) L1-intra > 2) L2-intra, L1->L2 inter-area, L2->L1 inter-area > 3) L1-ext, L2-ext, L1->L2 ext, L2->L1 ext (all with internal metric > type). > 4) all external routes with external metric types. > > This is incompatible with rfc1195 by not treating L2-intra and > L2-external routes with internal metric type equivalently. But all > the deployed base I know of happens to violate rfc1195 on this issue. I think L2->L1 should be the worst preference. Internal and external route-types should have the same preference. So I think the correct order would be: 1) L1 intra-area, L1 external with internal metric 2) L1 external with external metric 3) L2 intra-area, L2 external with internal metric, L1->L2 inter-area 4) L2 external with external metric 5) L2->L1 inter-area This preference can be used on L1L2 routers, and then the L1-only routers with current implementations do not need to be upgraded. As this was one of the goals of draft-ietf-isis-domain-wide-01.txt, therefor I prefer the second scheme. I can't remember why Tony Li decided to use the I/E bit, and not bit 8. Tony, can you refresh our memory ? Henk. From qv@juniper.net Fri, 1 Oct 1999 14:26:23 -0700 (PDT) Date: Fri, 1 Oct 1999 14:26:23 -0700 (PDT) From: Quaizar Vohra qv@juniper.net Subject: [Isis-wg] Clarification needed on domain-wide prefix distribution > > > > Here is a list of possible route types (assuming external routes with > > internal metric type are the only ones supported). > > Why do you assume this ? > RFC1195 specifies external routes with external metric type. > Personally I don't think that is a very useful feature. > As many of you know, our cisco IS-IS implementation never looked > at the I/E bit. During the last several years, no customer has > ever asked us to fix this. So I always assumed the I/E bit has > limited use in real networks. > > Unfortunately (for me) one of our customers pushed recently to > add a knob to recognize the I/E bit. For interoperability reasons. > I am not too familiar with other IS-IS implementation, but I have > been told that others either do recognize the I/E bit, or have > knob to choose between recognizing and ignoring the I/E bit. I have heard of OSPF deployments where type 2 routes are used. We have had request from the customers requesting type 2 routes. I personally feel that we should leave ISIS flexible to support this. > > > 1) L1 intra-area > > 2) L1 external (imported from other protocols) > > So I think we must split this one in two. > > > 3) L1 -> L2 inter-area (L2 intra-area leaked into L1) > > Guess this is a typo ? > You mean (L1 intra-area leaked into L2) ? > Sorry, that's a typo. > > 4) L1 -> L2 external (L1 external leaked into L2). > > Yes, you could see this one as different from 3). > But because RFC1195 does not specify L1 externals, RFC1195 does > not specify whether L1 externals should be advertised into L2 as > TLV128 or TLV130. > FYI our cisco IOS advertises L1 externals into L2 as TLV128. > > I am sorry if someone does not like me mentioning how our cisco IOS > does certain things that are not fully specified in rfc1195. > But the goal of draft-ietf-isis-domain-wide-01.txt is to do something > that is backwards compatible with the current installed base. So I > think it is sometimes useful to describe current IOS behaviour. > > > > 5) L2 intra-area > > 6) L2 external > > Again, I think we must split this one in two. > > > 7) L2 -> L1 inter-area (L2 intra-area leaked into L1) > > 8) L2 -> L1 external (L2 external leaaked into L1) > > > > There is no way to distinguish between 7) and 8) in the domain-wide > > draft. > > Agreed. > > > From TE draft one can't differentiate between 1) & 2), > > Agreed. > Note that rfc1195 says that there should be no difference in preference > between IP prefixes advertised in TLV128 and TLV130. Our implementation > does not even store the difference in the RIB. So Tony Li's first idea > was that if there is no difference, why maintain it in the new draft ? > I agree with him. I personally disagree with rfc1195 on this preference order. One of the reason is that if you are importing a route into ISIS from another protocol, e.g. OSPF, you can come up with a scenario where the imported route ends up getting preferred over the OSPF route. I guess I need to be more clear :-) Lets say you want to give higher preference to ISIS internal routes over OSPF internal routes. But you import OSPF routes into ISIS preserving the metric (though it might be unclean to do so) you might end up preferring the imported route simply because you choose to give it the same preference as an ISIS internal route. This causes pain when you are running ISIS and OSPF adjacently with 2 or more routers on the boundary leaking routes either ways. (I am no proponent of doing this :-) but I have seen customers running into such situations and it would be clean if the protocol helped in preventing such situations). Our implementation had so far not given the same preference to ISIS L2-intra routes as L2-external routes. > > > nor between 3), 4), 5) & 6), nor between 7) and 8). > > Agreed. > > > external routes. > > Can't parse this sentence. ;-) > > > Now if one notes rfc 1195, it recognizes a subset of the above > > route types and treats them in the following order of > > decreasing preference : > > > > 1) > > 3) == 5) == 6) > > 9) L2 external routes with external metric type > > Agreed. > I see you added a 9th route type. > > > Note that it treats L2 intra-area and L1->l2 inter-area and L2 external > > routes with internal metric type equivalently, i.e. they have the same > > preference and the lower metric wins. > > Agreed. > > > If one follows the same philosophy, i.e. treating external routes with > > internal metric type learnt in an area same as intra-area route, and > > by the virtue of both the drafts we are forced with the following > > order of decreasing preference. > > > > > > 1) == 2) > > 3) == 4) == 5) == 6) == 7) == 8) > > I don't agree here. > I think L2->L1 inter-area routes should have the lowest preference. > That means: > > 1) == 2) > 3) == 4) == 5) == 6) > 7) == 8) > > > > This said, I want the WG to consider the following : > > > > We still want the external routes to be distinguishable so as > > to allow filtering capcabilities when leaking routes from L2 to L1. > > So it would be be nice if the TE draft could be updated to either > > reserve a bit or add a subtlv to allow for this distinction. > > We thought about that. > Tony came up with the nice idea that the prefix lenght only needs > 6 bits, so we had two bits to play with. > Having the up/down bit is clearly very useful. > Now what to do with the second bit ? > We thought about using it for either > a) Internal/external route-type bit (like TLV128 vs TLV130) > b) Internal/external metric-type bit (like the old I/E bit) > c) as a flag to indicate the existence of sub-TLVs > > a) is specified in rfc1195, but not used. so why waste the bit on this ? > b) is specified and used in rfc1195. but in real life nobody uses it. > so why waste the bit on this one ? > c) using the prefix notation from BGP in ISIS gives us a win in the > number of bytes used per IP prefix. In rfc1195 we use 12 bytes per > prefix. 256 fragments * 1492 - a little / 12 bytes per prefix > means that the maximum number of IP routes advertised by a single > router is something like 30K prefixes. With the BGP notation it > would be something like 48K prefixes. Always including the sub-TLV > byte would bring this down to 42K. Tony Li liked to keep the number > of bytes per prefix low. Because a) and b) didn't make much sense\ > in our opinion I agree with him. > > > Also I wonder if there is any reason for not considering reserved bit > > (bit 8) of the default metric in the IP reachabilty TLV in rfc1195 for > > the purpose of a downbit in the domain-wide prefix distribution > > draft. This would have left things cleaner. > > We thought about that. > One of the main goals of draft-ietf-isis-domain-wide-01.txt is to > be backwards compatible with current implementations running on > L1-only routers. The "reserved bit" must not be set on transmision, > and should be ignored on reception. But we feared that not all > implementations could deal with this bit being set. > But wouldn't this be as worse as having the E bit set in TLV128 when rfc1195 says that it must be set to zero. > Another reason is this: > suppose you have a L2 prefix P, advertised by router A. Then two > L1L2 routers B and C will leak it down into L1. Another L1-only > router D will pick it up. > P is advertised as external metric 5. > The path-cost between A and B is 10. > The path-cost between A and C is 20. > Suppose you could advertise the metric-type into the inter-area route. > How are B and C going to advertise this into their L1 LSPs ? > With the I/E bit set, and metric 5 ? Now D will not be able to see > the real cost towards A. > > The reason we introduced L2->L1 interarea routes is so that L1-only > routers know more about the cost of the L2 path. When external metrics > are involved, the cost of the L2 path becomes less important. Thus > L2->L1 inter-area routes become less important. So why even leak them ? > Yes, for external routes originated with external metric type it is not possible to preserve the path length to the originator in the L2 area when that route is leaked into L1. But if you were using internal metric type then we can still preserve the path length to the originator. > Yes, we could change draft-ietf-isis-domain-wide-01.txt to use bit 8, > in stead of the I/E bit. If there are others on this list who also like > to do this, let us know. > > > Also it would be nice to have external routes with external metric > > types. One can imagine the following additional types of routes > > > > 9) L2 external with external metric type (rfc1195 supports this). > > Agreed. > > > 10) L2 -> L1 external with ext metric type > > Yes, this could be added. > RFC1195 does not specify if a L1 external should be advertised into L2 > in TLV128 or TLV130. Yes, it would be useful to maintain this distinction > between L1 and L2. Allas, unfortunately we can't maintain this distinction > when doing L2 -> L1, as L2->L1 interara is always advertised into TLV128. > > Actually now that I think about it once more, this is a perfect reason > to switch to your proposal to use bit 8 in stead of the I/E bit. If > we use bit 8, we can do L2->L1 interarea routes in TLV128 and TLV130. Yes, by using bit 8 as the down bit, you can preserve the external/internal semantics of a route. > > > 11) L1 external with external metric type > > 12) L1 -> L2 external with ext metric type > > > > 9) and 11) could still be supported with the existing domain wide > > prefix dist draft without any change. It would be nice if TE > > draft could add capability for such a distinction. > > > > 10) and 12) cant be supported without loss of knowledge of the > > distance to the exit router which originated the route as we do not > > keep any metric in the IP prefix TLV which preserves the distance from > > the exit router who originated the route, to the guy who's leaking the > > route across levels. OSPF deals with that in one fashion. We could > > deal with it by introducing a subtlv which preserves this knowledge. > > Personally I don't like the idea of putting stuff in sub-TLVs that > influences the basic SPF. Well OSPF deals with this by originating ASBR summary LSAs. Personally, I dont care about this too much for the time being. All I care is that we have the external metric type semantic still intact in the protocol such that it can be utilized if required in future. > > > Anyway 10), 11) , 12) need not be supported till a need for them > > is known. 9) is easy to support and in fact thats the only > > thing rfc1195 supports. > > Yes, 9) is easy to support if you use the trick from 10589. > (multiply the external metric by 1024, and add the path cost). > However it becomes a little more tricky when you mix TLV128/TLV130 > with TLV135. > > > Also it would make more sense to have the following order of > > decreasing preference of routes from implementation perspective. > > One might further specify tie-breaking rules for routes with > > same preference but different types. > > > > 1) L1-intra > > 2) L2-intra, L1->L2 inter-area, L2->L1 inter-area > > 3) L1-ext, L2-ext, L1->L2 ext, L2->L1 ext (all with internal metric > > type). > > 4) all external routes with external metric types. > > > > This is incompatible with rfc1195 by not treating L2-intra and > > L2-external routes with internal metric type equivalently. But all > > the deployed base I know of happens to violate rfc1195 on this issue. > > I think L2->L1 should be the worst preference. > Internal and external route-types should have the same preference. > So I think the correct order would be: > > 1) L1 intra-area, L1 external with internal metric > 2) L1 external with external metric > 3) L2 intra-area, L2 external with internal metric, L1->L2 inter-area > 4) L2 external with external metric > 5) L2->L1 inter-area > > This preference can be used on L1L2 routers, and then the L1-only > routers with current implementations do not need to be upgraded. > As this was one of the goals of draft-ietf-isis-domain-wide-01.txt, > therefor I prefer the second scheme. The reason I gave above about preferring internal routes over external routes is true here too so I would like purely internal routes preferred over external routes, even if they are leaked from L2 to L1. Also I would always prefer routes with internal metric type over external metric type, even if they are imported from L2 into L1. Actually I do tiebreaks to prefer L1 routes over L2 if the preference orders is same for two different route types. So the reasons for my order are : 1) Internal metric type should always be preferred over external metric no matter how the routes are leaked. 2) Routes learnt internally, within the ISIS domain should always be preferred over external rotes (to avoid the above situation I described). 3) Since we are doing this to allow for more optimal routing, I dont see why L2 intra-area routes leaked into L1 should not have same preference as L1 intra-area routes leaked into L2. 4) L1 intra-area routes are preferred over L2 intra-area routes and all inter-area routes. 5) If there are routes of more than one type with equal preference, best metric wins. 6) Among routes of equal minimal metric, one could either laod balance or apply tie-breaking rules (whichever happens to simplify the implementation), e.g. L1 wins over L2. Note that the reasons are listed in decreasing order of decision preference. I think this order as very clean. This might not be backward compatible. I am not sure if this incompatibility is an issue at all. Our deployments have given preference to internal routes over external routes. I would like to think that this statement, "Even if in the past you had given equal preference to internal and external routes, lowering the preference of external routes will not break things" holds true. Anyways, I lack enough experience to say with certainity that my suggested preference order is perfect. It may be far from perfect. But to me it intutively makes sense. So I will leave it to you guys to clean things :-). Quaizar > > I can't remember why Tony Li decided to use the I/E bit, and not bit 8. > Tony, can you refresh our memory ? > > Henk. > > From rsaluja@BayNetworks.COM Mon, 04 Oct 1999 15:40:51 -0400 Date: Mon, 04 Oct 1999 15:40:51 -0400 From: Rajesh Saluja rsaluja@BayNetworks.COM Subject: [Isis-wg] Clarification needed on domain-wide prefix distribution Folks, I am surprised to know that there can be L1 external routes also. I thought that only L2 routers can advertise the external routes. If there are L1 external routes, then how does a router in L2 knows about the advertising router present in L1 domain for calculating the metric. I do not see equivalent of OSPF type 4 summary LSA in IISIS. Also the domain-wide prefix distribution draft talks about the following types of routes. - L1 intra-area - L2->L1 inter-area - L2->L1 external - L2 intra-area - L2 external - L1->L2 inter-area and each can be distinguished according to the table given in the draft. Is there any proposal to have L1 external routes and redistribution of such routes into L2? Thanks, Rajesh From qv@juniper.net Mon, 4 Oct 1999 13:41:20 -0700 (PDT) Date: Mon, 4 Oct 1999 13:41:20 -0700 (PDT) From: Quaizar Vohra qv@juniper.net Subject: [Isis-wg] Clarification needed on domain-wide prefix distribution In case of external routes with internal metric type, one can update the advertised prefix when leaking the route from L1 into L2 to account for the cost of path from L1/L2 router to the originating router. With external metric type this is a problem. Well domain-wide prefix distribution draft seems not to preclude external routes from being originated in L1. Section 3.0 rule 1) says "Only L1 intra-area prefixes and external prefixes are redistributed from L1 into L2". > Folks, > I am surprised to know that there can be L1 external routes also. > I thought that only L2 routers can advertise the external routes. > If there are L1 external routes, then how does a router in L2 > knows about the advertising router present in L1 domain for > calculating the metric. I do not see equivalent of OSPF type 4 > summary LSA in IISIS. > Also the domain-wide prefix distribution draft talks about > the following types of routes. > - L1 intra-area > - L2->L1 inter-area > - L2->L1 external > - L2 intra-area > - L2 external > - L1->L2 inter-area > and each can be distinguished according to the table given > in the draft. > > Is there any proposal to have L1 external routes and redistribution > of such routes into L2? > > Thanks, > Rajesh > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From tli@procket.com Tue, 5 Oct 1999 01:05:43 -0700 Date: Tue, 5 Oct 1999 01:05:43 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] draft-kaplan-isis-ext-eth-00.txt Hi, The discussion about the above document has concluded (oops, a week ago, actually) and no comments against making this a WG draft were received. Accordingly, we will request that this draft become a WG document. Regards, Tony^2 From tli@procket.com Tue, 5 Oct 1999 01:10:20 -0700 Date: Tue, 5 Oct 1999 01:10:20 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Next order of business: There's been a request that the WG consider "IS-IS extensions for Traffic Engineering" for publication as an Informational RFC. We would like to start a WG last call on this document. Please comment by Friday, Oct. 15, 1999, 12:01 Pacific Time. Thanks, Tony & Tony From cristina@unisphere.cc Tue, 5 Oct 1999 10:09:17 -0400 Date: Tue, 5 Oct 1999 10:09:17 -0400 From: Radulescu-Banu, Cristina cristina@unisphere.cc Subject: FW: [Isis-wg] draft-ietf-isis-traffic-01.txt I have a question about IsIs/Ospf traffic engineering drafts; Ospf and Isis TE drafts are pretty similar, however, the OSPF TE domain is area scoped; (the TE info from an area is not summarized in other areas). I didn't see any similar constraint in the IsIs draft; how can you map Ospf and Isis TE topologies if you have a much bigger Is-Is TE topology than the Ospf TE topology (this last one ends at area boundaries)? Thanks in advance, Cristina Cristina Radulescu-Banu Redstone Communications, Inc. 5 Carlisle Road Westford, MA 01886 cristina@redstonecom.com (978) 692 1999 x147 (978) 692 9992 fax -----Original Message----- From: Tony Li [mailto:tli@procket.com] Sent: Tuesday, October 05, 1999 4:10 AM To: isis-wg@external.juniper.net Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Next order of business: There's been a request that the WG consider "IS-IS extensions for Traffic Engineering" for publication as an Informational RFC. We would like to start a WG last call on this document. Please comment by Friday, Oct. 15, 1999, 12:01 Pacific Time. Thanks, Tony & Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From rsaluja@BayNetworks.COM Tue, 05 Oct 1999 10:27:56 -0400 Date: Tue, 05 Oct 1999 10:27:56 -0400 From: Rajesh Saluja rsaluja@BayNetworks.COM Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Tony Li wrote: > > Next order of business: > > There's been a request that the WG consider "IS-IS extensions for Traffic > Engineering" for publication as an Informational RFC. > > We would like to start a WG last call on this document. Please comment by > Friday, Oct. 15, 1999, 12:01 Pacific Time. > > Thanks, > Tony & Tony I have few comments on the traffic engineering draft. 1. There is no support of I/E bit in the draft and Henk agrees that there may be some implementations which support I/E bit and it should be taken care. 2. The draft currently does not give a replacement for external IP reachability though it has extended IP reachability TLV as a replacement of internal IP reachability. It will be nice if there is extended internal IP reachability TLV and extended external IP reachability TLV. 3. Instead of having two solutions (traffic engineering and domain wide) for route redistribution from L2 to L1, won't it be nice to agree on a common solution? The traffic engineering draft definitely does not address all types of routes and preference order (as pointed out in earlier mails). Probably using I/E bit in place of Up/Down bit and then using domain-wide draft proposal, it is possible to reach a common solution. 4. I find interoperability and implementation a big problem with this draft.If I understand correctly, a router supporting traffic engineering draft will calculate even the conventional routes using the new extended TLVs and new extended metric. Also the routers in the whole domain need to be changed for consistent behavior. IMHO it will be really wise to add a section on "Transition issues" in this draft. 5. It seems that the traffic engineering draft is trying to focus on lots of problems at the sametime namely extended metric, route redistribution and traffic engineering. IMHO it can be cleaner if it focusses only on traffic engineering extensions while working peacefully with existing implementations. Thanks, Rajesh From hsmit@cisco.com Tue, 5 Oct 1999 17:28:00 +0200 (MET DST) Date: Tue, 5 Oct 1999 17:28:00 +0200 (MET DST) From: Henk Smit hsmit@cisco.com Subject: FW: [Isis-wg] draft-ietf-isis-traffic-01.txt Why do you want to run OSPF and ISIS on the same topology ? Isn't one IGP enough ? I might be mistaken here, but AFAIK both ISIS and OSPF TE extensions are only defined within one area. Henk. > I have a question about IsIs/Ospf traffic engineering drafts; Ospf and Isis > TE drafts are pretty similar, however, the OSPF TE domain is area scoped; > (the TE info from an area is not summarized in other areas). > I didn't see any similar constraint in the IsIs draft; how can you map Ospf > and Isis TE topologies if you have a much bigger Is-Is TE topology than the > Ospf TE topology (this last one ends at area boundaries)? > Thanks in advance, > Cristina From hsmit@cisco.com Tue, 5 Oct 1999 17:26:21 +0200 (MET DST) Date: Tue, 5 Oct 1999 17:26:21 +0200 (MET DST) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Hi Rajesh, > I have few comments on the traffic engineering draft. > > 1. There is no support of I/E bit in the draft and > Henk agrees that there may be some implementations which > support I/E bit and it should be taken care. Nope, I didn't agree that we should have an I/E bit in the traffic engineering draft. Personally I don't like the idea of external metrics. An indication is that no customers use external metrics in their current designs. Either you add metrics, like you do with internal metrics, or you give redistributed routes a metric of 0. Depending on fancy redistribution features points to bad network design anyway (IMHO). I do agree that if we are doing draft-ietf-isis-domain-wide-01.txt, then maybe we should use the reserved bit 8, in stead of the I/E bit 7, as the up/down bit. This would allow us to leak L2->L1 into both TLV128 and TLV130. If we (vendors and customers) decide this is worthwile to do, we got to hurry, because some customers are testing this currently for deployment in the near future. For draft-ietf-isis-traffic-01.txt, I don't want to add an I/E bit. There are no free bits available. I don't like to put a generic I/E bit in all metrics, like 10589 does, because it makes no sense to have an external metric on a link. > 2. The draft currently does not give a replacement for > external IP reachability though it has extended IP reachability > TLV as a replacement of internal IP reachability. It will be > nice if there is extended internal IP reachability TLV and > extended external IP reachability TLV. If you want to mark an IP prefix as external, we can do it via sub-TLVs. My collegues Naiming Shen has been working on tagging/coloring IP prefixes. Similar to OSPF tags or BGP communities. Maybe we can introduce some "well known" tags, to indicate that some prefixes were redistributed from outside into ISIS. > 3. Instead of having two solutions (traffic engineering > and domain wide) for route redistribution from L2 to L1, > won't it be nice to agree on a common solution? The traffic > engineering draft definitely does not address all types of > routes and preference order (as pointed out in earlier mails). > Probably using I/E bit in place of Up/Down bit and then using > domain-wide draft proposal, it is possible to reach a common > solution. Both drafts are trying to solve two different problems. If you want to solve existing (or new) problems in the TE draft, that is fine with me. Personally I prefer to have one type of IP prefix. The up/down bit is needed for route-leaking. It is enough to solve that problem. All other route preference stuff is IMHO overkill. I would hate to see ISIS get the same complexity as OSPF has. I already saw someone suggesting introducing sub-TLVs for ASBRs. Wonder when someone wants to introduce forwarding addresses. ;-) But the draft-ietf-isis-domain-wide-01.txt was done to solve one and only one problem. Some customer(s) wants to leak L2 prefixes into L1, using the old-style TLVs. The reason is that they can not or do not want to upgrade SW or HW. By doing a small trick in draft-ietf-isis-domain-wide-01.txt on only the L1L2 routers, we can do that. But we should not redefine other stuff. The goal is to keep L1-only routers behave the same way as they do today. Also please note that route-leaking into TLV128 or TLV130 is not optimal anyway, because the advertised path metric can be 63 at most. This solution is only useful if you have a relatively flat network where the diameter of a L1 area plus the diameter of your L2 backbone is below 63. I expect to see little deployment of draft-ietf-isis-domain-wide-01.txt. I will recommend my customers to go to the new TLVs if they want route-leaking. If you want to fix problems in rfc1195, we should do it with the new TLVs 22 and 135. The new TLVs are a framework that adds the possibility to add new stuff in the future via sub-TLVs. IMHO route-tagging and redistribution of externals is a seperate issue which can be solved in a seperate drafts. draft-ietf-isis-traffic-01.txt is intended as the frame-work. It was not my choice to add the TE specific stuff to this drafts, but because the TE requirements are the thing that pushed draft-ietf-isis-traffic-01.txt into existence, it makes sense to combine the basic framework of the new TLVs plus the TE specific sub-TLVs. > 4. I find interoperability and implementation a big problem > with this draft.If I understand correctly, a router > supporting traffic engineering draft will calculate even > the conventional routes using the new extended TLVs and new > extended metric. Also the routers in the whole domain need > to be changed for consistent behavior. IMHO it will be > really wise to add a section on "Transition issues" in this > draft. > > 5. It seems that the traffic engineering draft is trying to > focus on lots of problems at the sametime namely extended metric, > route redistribution and traffic engineering. IMHO it can be cleaner > if it focusses only on traffic engineering extensions while working > peacefully with existing implementations. I don't understand your point. Existing implementations do not support the new TLVs that have the capability of sub-TLVs. Do you want to split draft-ietf-isis-traffic-01.txt into three parts, one with for the new TLVs 22 and 135, and another draft about the TE specific sub-TLVs and TLV 134 ? And a third draft about route-leaking ? See my point above. Henk. From hsmit@cisco.com Tue, 5 Oct 1999 17:40:03 +0200 (MET DST) Date: Tue, 5 Oct 1999 17:40:03 +0200 (MET DST) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] Clarification needed on domain-wide prefix distribution > Folks, > I am surprised to know that there can be L1 external routes also. > I thought that only L2 routers can advertise the external routes. That is what rfc1195 says. Real world is different. One of the things I like about ISIS is that fact that it is simple and elegant. One of the reasons for that is that almost all protocol rules are within a single area (L1 or L2 area). Communication between L1 and L2 is maybe not always well defined, but it is easy to understand. This will make multiple levels (L3/L8) easy to do when the time has come. It is simple to take external routes from L2 and put them into L1. Just put TLV130 into your L1 LSPs. In the past some customers had network which ran in one flat area, which was a L1 area. A problem was that they could not do redistibution into L1. Yup, they should have migrated to a L2 area. But it was easier to just put TLV130 into L1 LSPs. Heck, we could have even put the redistributed routes into TLV128 if we wanted to. > If there are L1 external routes, then how does a router in L2 > knows about the advertising router present in L1 domain for > calculating the metric. I do not see equivalent of OSPF type 4 > summary LSA in IISIS. Knowing where the ASBR is is not necessary for external routes. It is only necessary when the external routes are advertised with external metrics. As you probably have noticed yourself: external route-type != external metric-type. Yet another reason not to do external metrics. They add more troubles then that they solve real issues. > Also the domain-wide prefix distribution draft talks about > the following types of routes. > - L1 intra-area > - L2->L1 inter-area > - L2->L1 external > - L2 intra-area > - L2 external > - L1->L2 inter-area > and each can be distinguished according to the table given > in the draft. > > Is there any proposal to have L1 external routes and redistribution > of such routes into L2? I have promised to adjust draft-ietf-isis-domain-wide-01.txt to be more specific about route preferences. I am sorry that I have not found the time yet to do so. Henk. From cristina@unisphere.cc Tue, 5 Oct 1999 11:59:21 -0400 Date: Tue, 5 Oct 1999 11:59:21 -0400 From: Radulescu-Banu, Cristina cristina@unisphere.cc Subject: FW: [Isis-wg] draft-ietf-isis-traffic-01.txt I, God forbidden, don't want to run 2 IGPs at the same time; however, the IsIs TE spec says: "If Ospf is also active in the domain, TE can compute the mapping between OSPF and IsIs topologies" (domain == AS) So, if you can, they have to have the same TE scope (one area). Even if you run only one IGP at the time, you still want to have the same definition for TE topology boundaries. I didn't see any mention in the ISIS TE spec that it is area scoped, so I just wanted to make sure I really just missed it. I also saw mentions of prefixes being redistributed from/into areas, i.e.: "If a prefix is redistributed from an area to another area at the same level, then the up/down bit shall be set to 1." in 4.0, The extended IP reachability TLV- . So, I guess I'm still confused if the TE topogy is area bounded or not. Can you clarify (again ;-) that TE info doesn't get summarized from an area into another? Thanks again, (sorry if this was a clear issue for everybody else), Cristina Cristina Radulescu-Banu Redstone Communications, Inc. 5 Carlisle Road Westford, MA 01886 cristina@redstonecom.com (978) 692 1999 x147 (978) 692 9992 fax -----Original Message----- From: Henk Smit [mailto:hsmit@cisco.com] Sent: Tuesday, October 05, 1999 11:28 AM To: cristina@unisphere.cc Cc: isis-wg@external.juniper.net Subject: Re: FW: [Isis-wg] draft-ietf-isis-traffic-01.txt Why do you want to run OSPF and ISIS on the same topology ? Isn't one IGP enough ? I might be mistaken here, but AFAIK both ISIS and OSPF TE extensions are only defined within one area. Henk. > I have a question about IsIs/Ospf traffic engineering drafts; Ospf and Isis > TE drafts are pretty similar, however, the OSPF TE domain is area scoped; > (the TE info from an area is not summarized in other areas). > I didn't see any similar constraint in the IsIs draft; how can you map Ospf > and Isis TE topologies if you have a much bigger Is-Is TE topology than the > Ospf TE topology (this last one ends at area boundaries)? > Thanks in advance, > Cristina From rsaluja@BayNetworks.COM Tue, 05 Oct 1999 14:05:22 -0400 Date: Tue, 05 Oct 1999 14:05:22 -0400 From: Rajesh Saluja rsaluja@BayNetworks.COM Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Henk Smit wrote: > > > 2. The draft currently does not give a replacement for > > external IP reachability though it has extended IP reachability > > TLV as a replacement of internal IP reachability. It will be > > nice if there is extended internal IP reachability TLV and > > extended external IP reachability TLV. > > If you want to mark an IP prefix as external, we can do it via sub-TLVs. > My collegues Naiming Shen has been working on tagging/coloring IP > prefixes. Similar to OSPF tags or BGP communities. Maybe we can > introduce some "well known" tags, to indicate that some prefixes > were redistributed from outside into ISIS. Yes, it can be done via sub-TLVs also but using explicit TLV for external routes (as in RFC 1195) is probably cleaner. > > 3. Instead of having two solutions (traffic engineering > > and domain wide) for route redistribution from L2 to L1, > > won't it be nice to agree on a common solution? The traffic > > engineering draft definitely does not address all types of > > routes and preference order (as pointed out in earlier mails). > > Probably using I/E bit in place of Up/Down bit and then using > > domain-wide draft proposal, it is possible to reach a common > > solution. > > Both drafts are trying to solve two different problems. > If you want to solve existing (or new) problems in the TE draft, > that is fine with me. Personally I prefer to have one type of > IP prefix. The up/down bit is needed for route-leaking. It is > enough to solve that problem. All other route preference stuff > is IMHO overkill. Is up/down bit enough for route selection? Probably not. It is enough for avoiding routing loops. But just relying on up/down bit can result in choosing external route over interarea route. It is probably necessary to define the preferences and also necessary to identify the external routes as a part of this draft. > > 4. I find interoperability and implementation a big problem > > with this draft.If I understand correctly, a router > > supporting traffic engineering draft will calculate even > > the conventional routes using the new extended TLVs and new > > extended metric. Also the routers in the whole domain need > > to be changed for consistent behavior. IMHO it will be > > really wise to add a section on "Transition issues" in this > > draft. > > > > 5. It seems that the traffic engineering draft is trying to > > focus on lots of problems at the sametime namely extended metric, > > route redistribution and traffic engineering. IMHO it can be cleaner > > if it focusses only on traffic engineering extensions while working > > peacefully with existing implementations. > > I don't understand your point. > Existing implementations do not support the new TLVs that have > the capability of sub-TLVs. > Do you want to split draft-ietf-isis-traffic-01.txt into three > parts, one with for the new TLVs 22 and 135, and another draft > about the TE specific sub-TLVs and TLV 134 ? And a third draft > about route-leaking ? See my point above. > Henk. Any implementation supporting new TLVs will calculate the routes based on only new TLVs with extended metric which means that the a router supporting new TLV will not be able to coexist with a router supporting old TLV. It means that traffic engineering draft needs all routers to change at a time. Isn't it? or is there any nice transition plan? Thank you very much for your answers. -Rajesh From qv@juniper.net Tue, 5 Oct 1999 11:54:21 -0700 (PDT) Date: Tue, 5 Oct 1999 11:54:21 -0700 (PDT) From: Quaizar Vohra qv@juniper.net Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt > > Hi Rajesh, > > > I have few comments on the traffic engineering draft. > > > > 1. There is no support of I/E bit in the draft and > > Henk agrees that there may be some implementations which > > support I/E bit and it should be taken care. > > Nope, I didn't agree that we should have an I/E bit in the traffic > engineering draft. Personally I don't like the idea of external metrics. > An indication is that no customers use external metrics in their current > designs. > Either you add metrics, like you do with internal metrics, or you give > redistributed routes a metric of 0. > Depending on fancy redistribution features points to bad network > design anyway (IMHO). > > I do agree that if we are doing draft-ietf-isis-domain-wide-01.txt, > then maybe we should use the reserved bit 8, in stead of the I/E > bit 7, as the up/down bit. This would allow us to leak L2->L1 into > both TLV128 and TLV130. If we (vendors and customers) decide this > is worthwile to do, we got to hurry, because some customers are > testing this currently for deployment in the near future. You have my vote on using the 8th bit. We have customers who will be leaking external routes and want the capabiltity to tell external routes from internal. Using bit 8 leaves everything clean. We dont want customers coming to us and asking us to support something we cant because of restictions in the domain-wide draft. > Both drafts are trying to solve two different problems. > If you want to solve existing (or new) problems in the TE draft, > that is fine with me. Personally I prefer to have one type of > IP prefix. The up/down bit is needed for route-leaking. It is > enough to solve that problem. All other route preference stuff > is IMHO overkill. Unfortunately, I see requirements for distinguishing external routes from internal. Hence a lots of different types of routes and a complicated set of preferences. But I agree that the issue of preserving the external semantics can be addressed in a seperate draft. > I would hate to see ISIS get the same complexity as OSPF has. > I already saw someone suggesting introducing sub-TLVs for ASBRs. > Wonder when someone wants to introduce forwarding addresses. ;-) I was the one who mentioned this in my previous mail. In no way did I suggest that this should or must be done. I had just mentioned that this can be done if needed. Currently I dont see a need and the fact that TE draft allows for extensibilty is enough for me. > > But the draft-ietf-isis-domain-wide-01.txt was done to solve > one and only one problem. Some customer(s) wants to leak L2 > prefixes into L1, using the old-style TLVs. The reason is that > they can not or do not want to upgrade SW or HW. By doing a small > trick in draft-ietf-isis-domain-wide-01.txt on only the L1L2 > routers, we can do that. But we should not redefine other stuff. > The goal is to keep L1-only routers behave the same way as they > do today. > Also please note that route-leaking into TLV128 or TLV130 is not > optimal anyway, because the advertised path metric can be 63 at most. > This solution is only useful if you have a relatively flat network > where the diameter of a L1 area plus the diameter of your L2 backbone > is below 63. I expect to see little deployment of > draft-ietf-isis-domain-wide-01.txt. I will recommend my customers to > go to the new TLVs if they want route-leaking. > > If you want to fix problems in rfc1195, we should do it with > the new TLVs 22 and 135. The new TLVs are a framework that adds > the possibility to add new stuff in the future via sub-TLVs. > IMHO route-tagging and redistribution of externals is a seperate > issue which can be solved in a seperate drafts. > draft-ietf-isis-traffic-01.txt is intended as the frame-work. > It was not my choice to add the TE specific stuff to this drafts, > but because the TE requirements are the thing that pushed > draft-ietf-isis-traffic-01.txt into existence, it makes sense > to combine the basic framework of the new TLVs plus the TE > specific sub-TLVs. > > > 4. I find interoperability and implementation a big problem > > with this draft.If I understand correctly, a router > > supporting traffic engineering draft will calculate even > > the conventional routes using the new extended TLVs and new > > extended metric. Also the routers in the whole domain need > > to be changed for consistent behavior. IMHO it will be > > really wise to add a section on "Transition issues" in this > > draft. I think that it would be clean to exlude up/down bit from the TE draft and address the whole issue of route leaking in another draft. We have customers who are going to run TE extensions with domain-wide extensions and rfc1195. I think the transition and interoperabilty issues are fairly obvious but might be worth mentioning and best specified in a seperate draft. > > > > 5. It seems that the traffic engineering draft is trying to > > focus on lots of problems at the sametime namely extended metric, > > route redistribution and traffic engineering. IMHO it can be cleaner > > if it focusses only on traffic engineering extensions while working > > peacefully with existing implementations. > > I don't understand your point. > Existing implementations do not support the new TLVs that have > the capability of sub-TLVs. > Do you want to split draft-ietf-isis-traffic-01.txt into three > parts, one with for the new TLVs 22 and 135, and another draft > about the TE specific sub-TLVs and TLV 134 ? And a third draft > about route-leaking ? See my point above. > > Henk. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From qv@juniper.net Tue, 5 Oct 1999 12:57:16 -0700 (PDT) Date: Tue, 5 Oct 1999 12:57:16 -0700 (PDT) From: Quaizar Vohra qv@juniper.net Subject: [Isis-wg] Clarification needed on domain-wide prefix distribution > > Let's steer the recent threads a little bit here: > > 1. draft-ietf-isis-domain-wide solves one single problem for deployments that don't have the need to migrate towards > TE extensions or don't want a "flag-day" solution but wnat to preserve 1195 compatibility. So discussion about TE > draft and this draft are orthogonal. > 2. I'm attaching the last version of the domain-wide draft to this mail that Henk didn't post yet so people can get on > the same page. This is _not_ an official draft but a floating version between authors that was stable now for a > while. Route preferences are clearly stated Henk, please submit the new version ASAP. Thank you. > 3. I'm against using bit 8 in draft-ietf-isis-domain-wide since this will break 1195. It breaks rfc 1195 as much as setting the I/E bit in TLV 128. > 4. the numbering discussion is getting very confusing and I definitely got suspicious after a 9th and higher type of > routes type started to show up. There are 2 levels of 2 TLVs (128 and 130) with 2 bit combinations (I/E = 0 or > 1) so maximum number of different route types 2^3 = 8 and from there encoding forces you to not differentiate > things anymore! I would strongly suggest to align the terminology to something saying Level:TLV Type:Bit like > written in the attached draft to clarify the discussion, otherwise we'll name the same bit combinations with many > different names (and if we do, let's update the table in the draft so one can translate easily). With preferences, > Henk was pretty much on the point except that I think that the fact was missed that L2,128,Internal routes MUST be > preffered over anything level 1 external (of course only of interest for L1L2 and L2-only routers), otherwise we > have external metric types overriding the internal ones and that has to lead to routing loops. I'd suggest to refer > to the figure specifying the prefernce across the 8 types and let's discuss it from there. Route preference is > absolutely critical (as are the 3 rules) so let's get that one > nailed clearly. Well if one starts distinguishing routes which are leaked down, i.e. from L2 to L1, you end up getting 4 more types of routes. The domain wide draft tries to create the leaking down distinction by screwing external vs internal route distinction. Usage of 8th bit does that more cleanly by not obliterating old semantics. The route preference I had come up with was exactly in agreement to what you are saying, that internal routes be preferred over external routes. Quaizar > 5. critique on OSPF does not contribute to the quality of the discussions on this list :-) > > -- > thanks > > --- tony > > > > > Network Working Group Tony Li > INTERNET DRAFT Juniper Networks > > Tony Przygienda > Bell Labs > > Henk Smit > Cisco Systems > April 1999 > > > Domain-wide Prefix Distribution with Multi-Level IS-IS > > > > > 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. > > > 1.0 Abstract > > This document describes extensions to the IS-IS protocol to support > optimal routing within a multi-level domain. The IS-IS protocol is > specified in ISO 10589 [1], with extensions for supporting IPv4 > specified in RFC 1195 [2]. > > This document extends the semantics presented in RFC 1195 so that a > routing domain running with both Level 1 and Level 2 Intermediate > Systems (IS) [routers] can distribute IP prefixes between Level 1 and > Level 2 and vice versa. This distribution requires certain > restrictions to insure that persistent forwarding loops do not form. > The goal of this domain-wide prefix distribution is to increase the > granularity of the routing information within the domain. > > > 2.0 Introduction > > An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) > can be partitioned into multiple level 1 (L1) areas, and a level 2 > (L2) connected subset of the topology that interconnects all of the > L1 areas. Within each L1 area, all routers exchange link state > information. L2 routers also exchange L2 link state information to > compute routes between areas. > > RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that are > used to transport IPv4 routing information in IS-IS. RFC 1195 also > specifies the semantics and procedures for interactions between > levels. Specifically, routers in a L1 area will exchange information > within the L1 area. For IP destinations not found in the prefixes in > the L1 database, the L1 router should forward packets to the nearest > router that is in both L1 and L2 (i.e., an L1L2 router) with the > 'attach' bit set in its L1 Link State Protocol Data Unit (LSP). > > Also per RFC 1195, an L1L2 router should be manually configured with > a set of prefixes that summarize the IP prefixes found in that L1 > area. These summaries are injected into L2. RFC 1195 specifies no > further interactions between L1 and L2 for IPv4 prefixes. > > > 2.1 Motivations for domain-wide prefix distribution > > The mechanisms specified in RFC 1195 are appropriate in many > situations, and lead to excellent scalability properties. However, > in certain circumstances, the domain administrator may wish to > sacrifice some amount of scalability and distribute more specific > information than is described by RFC 1195. This section discusses > the various reasons why the domain administrator may wish to make > such a tradeoff. > > One major reason for distributing more prefix information is to > improve the quality of the resulting routes. A well know property of > prefix summarization or any abstraction mechanism is that it > necessarily results in a loss of information. This loss of > information in turn results in the computation of a route based upon > less information, which will frequently result in routes that are not > optimal. > > A simple example can serve to demonstrate this adequately. Suppose > that a L1 area has two L1L2 routers that both advertise a single > summary of all prefixes within the L1 area. To reach a destination > inside the L1 area, any other L2 router is going to compute the > shortest path to one of the two L1L2 routers for that area. Suppose, > for example, that both of the L1L2 routers are equidistant from the > L2 source, and that the L2 source arbitrarily selects one L1L2 > router. This router may not be the optimal router when viewed from > the L1 topology. In fact, it may be the case that the path from the > selected L1L2 router to the destination router may traverse the L1L2 > router that was not selected. If more detailed topological > information or more detailed metric information was available to the > L2 source router, it could make a more optimal route computation. > > This situation is symmetric in that an L1 router has no information > about prefixes in L2 or within a different L1 area. In using the > nearest L1L2 router, that L1L2 is effectively injecting a default > route without metric information into the L1 area. The route > computation that the L1 router performs is similarly suboptimal. > > Besides the optimality of the routes computed, there two other > significant drivers for the domain wide distribution of prefix > information. > > When a router learns multiple possible paths to external destinations > via BGP, it will select only one of those routes to be installed in > the forwarding table. One of the factors in the BGP route selection > is the IGP cost to the BGP next hop address. Many ISP networks > depend on this technique, which is known as "shortest exit routing". > If a L1 router does not know the exact IGP metric to all BGP speakers > in other L1 areas, it cannot do effective shortest exit routing. > > The third driver is the current practice of using the IGP (IS-IS) > metric as part of the BGP Multi-Exit Discriminator (MED). The value > in the MED is advertised to other domains and is used to inform other > domains of the optimal entry point into the current domain. Current > practice is to take the IS-IS metric and insert it as the MED value. > This tends to cause external traffic to enter the domain at the point > closest to the exit router. Note that the receiving domain may, > based upon policy, choose to ignore the MED that is advertised. > However, current practice is to distribute the IGP metric in this way > in order to optimize routing wherever possible. This is possible in > current networks that only are a single area, but becomes problematic > if hierarchy is to be installed into the network. This is again > because the loss of end-to-end metric information means that the MED > value will not reflect the true distance across the advertising > domain. Full distribution of prefix information within the domain > would alleviate this problem as it would allow accurate computation > of the IS-IS metric across the domain, resulting in an accurate value > presented in the MED. > > > 2.2 Scalability > > The disadvantage to performing the domain-wide prefix distribution > described above is that it has an impact to the scalability of IS-IS. > Areas within IS-IS help scalability in that LSPs are contained within > a single area. This limits the size of the link state database, that > in turn limits the complexity of the shortest path computation. > > Further, the summarization of the prefix information aids scalability > in that the abstraction of the prefix information removes the sheer > number of data items to be transported and the number of routes to be > computed. > > It should be noted quite strongly that the distribution of prefixes > on a domain wide basis impacts the scalability of IS-IS in the second > respect. It will increase the number of prefixes throughout the > domain. This will result in increased memory consumption, > transmission requirements and computation requirements throughout the > domain. > > It must also be noted that the domain-wide distribution of prefixes > has no effect whatsoever on the first aspect of scalability, namely > the existence of areas and the limitation of the distribution of the > link state database. > > Thus, the net result is that the introduction of domain-wide prefix > distribution into a formerly flat, single area network is a clear > benefit to the scalability of that network. However, it is a > compromise and does not provide the maximum scalability available > with IS-IS. Domains that choose to make use of this facility should > be aware of the tradeoff that they are making between scalability and > optimality and provision and monitor their networks accordingly. > Normal provisioning guidelines that would apply to a fully > hierarchical deployment of IS-IS will not apply to this type of > configuration. > > > 3.0 New semantics for external type metrics > > RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is > defined to carry 'internal' prefixes and TLV 130 is defined to carry > 'external' prefixes. The original intent of RFC 1195 was to carry > intra-domain routes within the internal prefix TLV and inter-domain > routes or intra-domain routes from alternate IGPs in an external > prefix TLV. Interestingly, TLV type 130 is not documented to exist > in Level 1 LSPs. > > In addition to this distinction, RFC 1195 provides for a bit in each > of these TLVs that distinguishes between an internal metric type and > an external metric type. Similarly, the clear intent was that the > internal metric type should reflect a total metric that is the sum of > the metrics to the advertising router plus the metric to the prefix. > Further, for an external metric type, the total metric should simply > be the metric advertised to the prefix, not including the total > metric necessary to reach the exit router. Prefixes with internal > metrics are always preferred over external metrics, regardless of the > value of the metrics. > > It should be noted that the combination of an internal prefix with an > external metric type is not obviously useful, and is not allowed by > RFC 1195. > > It should also be noted that as of this writing, the author knows of > no deployed implementations that make use of either the external > prefix or the external metric type. The implication is that this > proposal is free to redefine the semantics of the external metric > type bit without conflicting with existing protocol deployment. > > An essential property when redistributing prefixes between levels is > to insure that no persistent loops form in the distribution of > information (i.e., a routing loop), as this would lead to the > indefinite propagation of the information, even in the event that the > information was no longer originated by some system in the domain. > Further, a routing loop is likely to form a forwarding loop, where > actual traffic traverses the network in a cycle in the topology. > Forwarding loops are known to consume large amounts of resources and > are to be avoided. > > > 3.1 Proposed semantics for inter-area routes > > To provide the above properties, this proposal defines the following > syntax and semantics. The encoding is being extended compared to > RFC1195 and is almost symmetric. > > An intra-area route is a route computed based on a prefix advertised > by some IS-IS router in the area. Thus, a prefix advertised in the > L1 link state database may become a L1 intra-area route within the > area of the advertiser. Similarly, a prefix advertised in the L2 > link state database may become a L2 intra-area route within L2. > Prefixes associated with an intra-area route are also said to be > intra-area prefixes. These types of prefixes are being encoded in the > same way as in RFC1195 within TLV 128 using internal metric types. > > An inter-area route is a route computed based on a prefix advertised > by an IS-IS router not in the local area. Inter-area routes exist > either in L2, in which case they are L1->L2 inter-area routes, or in > L1, in which case they are L2->L1 inter-area routes. Prefixes > associated with an inter-area route area also said to be inter-area > prefixes. Such prefixes are encoded within L1 within TLV 128 using > external metric type which is an extension to RFC 1195. Within L2 > these prefixes are indistinguishable from L2 intra-area routes and > are therefore encoded within TLV 128 with internal metrics. > > External prefixes are reserved for prefixes originating outside of > the IS-IS system, usually learned from another routing protocol. To > allow for leaking of routes originating outside the ISIS domain > within L1, TLV 130 is allowed in L1 with both internal and external > metric types. Observe that introducing externals in L1 makes sense > since those can be leaked into L2 and into other L1 areas. > > The following tables describe all types of prefixes now defined > within IS-IS and how they are encoded: > > Level-1 LSPs | Internal TLV (128) | External TLV (130) > ---------------------------------------------------------------------- > Internal metric-type | L1 intra-area | external | > ---------------------------------------------------------------------- > External metric-type | L2->L1 inter-area | external | > ---------------------------------------------------------------------- > > > Level-2 LSPs | Internal TLV (128) | External TLV (130) > ---------------------------------------------------------------------- > Internal metric-type | L2 intra-area or | external | > | L1->L2 inter-area | | > ---------------------------------------------------------------------- > External metric-type | should not exist | external | > ---------------------------------------------------------------------- > > Based on these definitions and encodings, this proposal defines the > following redistribution rules: > > 1) Only L1 intra-area prefixes and external prefixes are > redistributed from L1 into L2. > > 2) All prefixes can be redistributed from L2 into L1 and become > L2->L1 inter-area routes. All prefixes can be redistributed from L2 > into L1 and become L2->L1 inter-area routes. A L2 prefix must not be > redistributed into a L1 area if that same prefix exists as L1 intra > area route or L1 external route to prevent routing loops. > > 3) Within L1, an intra-area prefix is preferred over an inter-area > prefix, regardless of the comparison of the metrics. > > Based on these rules, we first observe that this proposal is free > from routing loops. No prefix can be redistributed from L2 to L1 and > back into L2, because the route first becomes an L1 inter-area prefix > by rule (2) and by rule (1) cannot be redistributed into L2. > Similarly, a prefix redistributed from L1 to L2 becomes an L2 inter- > area prefix by rule (1) but will not be redistributed into the > original L1 area by rule (2). > > Even when following all the indicated rules, there is the possibility > of a transient routing loop when the original prefix is withdrawn and > the inter-area prefix is selected. However, all link state protocols > are subject to transient routing loops, so this is no worse than the > status quo. > > Note that this proposal is not radically different than the current > semantics for RFC 1195: internal metric types are always preferred > over externals, so rule (3) is an extension that allows external > metric types in internal prefix TLVs. It does not introduce a new > comparison between internal and external metric values. Expressed in > a more abstract way by introducing a relationship denoted by '>' that > stands for 'is preffered over', all the possible routes can be > ordered unambiguosly, starting with intra-area L1 route and ending > with external L2 route with external metric. The routes in the > following figures are denoted in the notation bit>. > > > <-- more preffered --- > > L1:128:I>L2:128:I>L1:128:E>L1:130:I>L2:130:I>L1:130:E>L2:130:E > > --- less preffered --> > > > Rule (2) asserts that a route cannot override an already present, > more preffered route in a L1 area when being leaked into it. > > > 3.2 Transition issues > > Because no implementations currently make use of the external metric > type, the deployment of prefixes with an external metric type is > somewhat problematic. There is the possibility that the new type of > advertisement may result in software instability in systems that do > not deal with even the original semantics correctly. Further, there > is a danger that haphazard deployment of systems supporting this > proposal and legacy systems would have an unfortunate interaction. > It is required, for any L1 area that should perform the mutual > redistribution described in this proposal, that the L1L2 systems be > updated first. If these systems operate correctly, this is > sufficient to ensure that there are no persistent routing loops. In > case where not all L1L2 systems are being upgraded, persistent > routing loops are possible. Consider the following figure that gives > an example of such a looping scenario with a setup where (A) has been > upgraded and (B) has not. > > > > > > > > > > > > > route through L2 > to 1/8 at cost 200 > | > | +-- L2 link cost 1 --+ > | | | > | computes 1/8 | > | at 64 through (B) | > [1] | | > V V ^ > +--+--------+ +-----+-----+ > | new style | | old style | > (A) | L1/L2 | | L1/L2 | (B) > | leaks 1/8 | | leaks up | > | at 63 Ext | | at 63 Ext | > +----+------+ +-------+---+ > V ^ > | | > | computes L1 route > | 1/8 at cost 128 > | | > +---- L1 link with cost 1 -+ > > > Originally a prefix 1/8 in L2 with a cost of 200 is being computed by > upgraded L1L2 router (A) as best route towards 1/8 through interface > 1. The prefix leaks at maximum cost of 63 (and with the I/E bit being > set) into L1 domain and is used by L1L2 router (B) (which has not > been upgraded) to compute best route to 1/8 at cost 128 in L1. We > assume that (B) is not masking the I/E bit out but is using it as > part of the metric, however the scenario holds as well in case (B) > believes the metric to be 63. This L1 route will be obviously > preferred by (B) to a computed L2 route. Assuming that (B) leaks 1/8 > into L2 domain again, (A) will use it for another L2 computation that > ends up with a shorter L2 route to 1/8 through (B) and probably leaks > it again into L1. Hence, a routing and forwarding loop has been > formed. > > As described in the previous section, rule (2) must be followed to > prevent looping when this extension is deployed using L1 routers > understanding the semantics of the L1 inter-area route mixed with L1 > routers that treat all routes within 128 TLV as intra-area. The > following example visualizes a forwarding loop encountered in a > scenario where (A) leaks an L1 inter-area route despite the fact that > (D) advertises the same route as L1 intra-area. > > > > > > > > > > > > > > > > > route through L2 to > 1/8 at cost 200 > / > / > v > +============+ > | L1/L2 | routing table for 1/8 > | leaking | (top is active route) > (A) | 1/8 down | L1 at 131 active > | with cost | L2 at 200 > | of 63 as | L1 inter-area at 127 > | inter-area | > +====+====+-=+ > | \ > | \ > | \ cost 1 > | \ > cost 1 | +-+--+ routing table > | (C) | L1 | inter-area L1 at 128 active > | +---++ L1 at 130 > | \ > | \ > | path with > | total cost > routing table +---+-+ of 130 > inter-area L1 | L1 | (B) \ > at 128 active +---+-+ \ > L1 at 131 | \ > | \ > | +-+--+ > +- path with -------+ L1 | advertises > total cost +----+ 1/8 as L1 > of 131 (D) attached > prefix > > (A) is an upgraded L1L2 router and leaks into L1 a prefix 1/8 that it > computed through L2 at the maximum cost of 127 (or expressed > differently, as inter-area with cost 63) which violates rule (2). > Router (B), (C), (D) are all purely RFC1195 compliant routers so they > perceive the leaked prefix as internal L1. At the same time, (D) > advertises the same prefix 1/8 as L1 directly attached subnet into > L1. To distinguish the different copies, the leaked prefix is shown > as inter-area L1. (B) computes the inter-area L1 route at a cost of > 127+1 and prefers it to the one through (D) since such a router has a > cost of 131 and (B) does not understand that L1 intra-area routes > should be always preffered over L1 inter-area routes. Therefore (B) > forwards a packet to 1/8 towards (A). (A) cannot prefer the inter- > area L1 route since it could not really forward using it but has to > use L2 to get the packet into the L2 backbone. However, it must > prefer L1 computed to (D) over L2 route. Hence, (A) forwards the > packet towards (C). (C) has the L1 inter-area as preferred (since it > looks to it like a cheaper L1 intra-area route to 1/8 than the L1 > route through (D)) and forwards the packet back to (A). > > Finally, it should be obvious that if a deployment uses L1 external > routes in an area that still contains strictly RFC1195 compliant > routers, forwarding loops can be easily formed. Routers that are able > to interpret TLV 130 in L1 may try to forward towards the announcer > of such external routes whereas RFC1195 compliant routers will always > forward towards the closest, connected L2 capable router. > > > 4.0 Comparisons with other proposals > > Another proposal is currently being discussed which is similar to > this one in nature. > > In [3], a new TLV is proposed to transport IP prefix information. > Because this is a new TLV, it is somewhat harder to deploy, requiring > that all systems understand the new TLV before it can become > effective. For this reason, this proposal provides an alternative > that can be deployed sooner. There is no effective semantic > difference between the two proposals. In [3], a bit is defined to > mark a prefix as 'up' or 'down'. This is essentially the same > semantics as is proposed here. > > 5.0 Security Considerations > > This document raises no new security issues for IS-IS. > > 6.0 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)" [Also republished as RFC 1142] > > [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual > environments", R.W. Callon, Dec. 1990 > > [3] Smit, H., Li, T. "IS-IS extensions for Traffic Engineering", > draft-ietf-isis-traffic-00.txt, work in progress > > 7.0 Authors' Addresses > > Tony Li > Juniper Networks, Inc. > 385 Ravendale Dr. > Mountain View, CA 94043 > Email: tli@juniper.net > Fax: +1 650 526 8001 > Voice: +1 650 526 8006 > > Tony Przygienda > Bell Labs, Lucent Technologies > 101 Crawfords Corner Road > Holmdel, NJ 07733-3030 > Email: prz@dnrc.bell-labs.com > > Henk Smit > Cisco Systems, Inc. > 210 West Tasman Drive > San Jose, CA 95134 > Email: hsmit@cisco.com > Voice: +31 20 342 3736 > > > > > From tli@procket.com Tue, 5 Oct 1999 14:09:51 -0700 Date: Tue, 5 Oct 1999 14:09:51 -0700 From: Tony Li tli@procket.com Subject: FW: [Isis-wg] draft-ietf-isis-traffic-01.txt Cristina, I think we first need to be _very_ careful about what you mean by "scoping". IS-IS TLVs by their very nature are not automatically exchanged between areas or between levels. This is no different for TE information and the draft need not say anything specific about this. The TLVs were not designed to carry topological information independent of the LSP that they exist in, so their use in other areas or levels would be non-trivial. This was definitely not the intent. That said, the topology information that one extracts out of the TE information can be used independently of any area or level boundaries. It is simply a graph or 'map' if you like. One possible application of this is to do multi-level traffic engineering. Suppose that you had IS-IS areas interconnected using an OSPF (or IS-IS level 2) backbone. A traffic engineering path could compute a strict route across one IS-IS area. Then the boundary router between the protocols would compute a strict path across the backbone, and the exit boundary router would compute a strict path across the exit area. Other wierd and wonderful things are also possible. The spec is written specifically to minimize future limitations while providing the functionality that we want today. Tony From cristina@unisphere.cc Wed, 6 Oct 1999 08:51:03 -0400 Date: Wed, 6 Oct 1999 08:51:03 -0400 From: Radulescu-Banu, Cristina cristina@unisphere.cc Subject: FW: [Isis-wg] draft-ietf-isis-traffic-01.txt >That said, the topology information that one extracts out of the TE >information can be used independently of any area or level boundaries. It >is simply a graph or 'map' if you like. Thank you all for your answers. I guess I was confused by the extended IP reachability TLV, which I thought changed to carry also some TE attributes (maybe to avoid confusion, this extended TLV shouldn't be in the TE draft, since the changes are just for redistribution in between levels/areas - kind of summarization between areas for Ospf-). After a careful reading ;-), yes, the TE topology is "area" bounded (by that I mean that a set of routers in a given area only see a TE topology (synonym "graph, or "map" ;-) only inside the area, although they have non-TE reachability to networks( and routers ) in other areas. Thanks again, Cristina Cristina Radulescu-Banu Redstone Communications, Inc. 5 Carlisle Road Westford, MA 01886 cristina@redstonecom.com (978) 692 1999 x147 (978) 692 9992 fax -----Original Message----- From: Tony Li [mailto:tli@procket.com] Sent: Tuesday, October 05, 1999 5:10 PM To: cristina@unisphere.cc Cc: hsmit@cisco.com; isis-wg@external.juniper.net Subject: Re: FW: [Isis-wg] draft-ietf-isis-traffic-01.txt Cristina, I think we first need to be _very_ careful about what you mean by "scoping". IS-IS TLVs by their very nature are not automatically exchanged between areas or between levels. This is no different for TE information and the draft need not say anything specific about this. The TLVs were not designed to carry topological information independent of the LSP that they exist in, so their use in other areas or levels would be non-trivial. This was definitely not the intent. That said, the topology information that one extracts out of the TE information can be used independently of any area or level boundaries. It is simply a graph or 'map' if you like. One possible application of this is to do multi-level traffic engineering. Suppose that you had IS-IS areas interconnected using an OSPF (or IS-IS level 2) backbone. A traffic engineering path could compute a strict route across one IS-IS area. Then the boundary router between the protocols would compute a strict path across the backbone, and the exit boundary router would compute a strict path across the exit area. Other wierd and wonderful things are also possible. The spec is written specifically to minimize future limitations while providing the functionality that we want today. Tony From rsaluja@BayNetworks.COM Wed, 06 Oct 1999 11:36:07 -0400 Date: Wed, 06 Oct 1999 11:36:07 -0400 From: Rajesh Saluja rsaluja@BayNetworks.COM Subject: [Isis-wg] Clarification needed on domain-wide prefix distribution Tony Przygienda wrote: > Let's steer the recent threads a little bit here: > > 1. draft-ietf-isis-domain-wide solves one single problem for deployments that don't have the need to migrate towards > TE extensions or don't want a "flag-day" solution but wnat to preserve 1195 compatibility. So discussion about TE > draft and this draft are orthogonal. For my understanding, can you verify if the following sentences are correct for domain-wide draft: 1. It needs changes only in L1L2 router. There is no change in L1 router implementation from RFC1195. 2. External routes are allowed in L1 domain. Which means that L1 routers can advertise external reachability information. 3. The external routes can only have internal metric type. 4. In the given proposal, we can not distinguish between L1 externals from L2->L1 externals ( both will be 130:L1:I ) between L2 externals from L1->L2 externals (both will be 130:L2:I). If 3 is correct, then why does the preference suggested in proposal talks about L1:130:I and L1:130:E and same for L2. If 3 is not correct (i.e. external routes in L1 domain can still have internal and external metric types) then it means that L1 routers should have the capability to prefer internal metric types to external metric types and according to RFC1195, they do not have this capability ( 3.10.1 ) Thanks, Rajesh From rsaluja@BayNetworks.COM Wed, 06 Oct 1999 16:15:03 -0400 Date: Wed, 06 Oct 1999 16:15:03 -0400 From: Rajesh Saluja rsaluja@BayNetworks.COM Subject: [Isis-wg] Clarification needed on domain-wide prefix distribution Tony Przygienda wrote: > > If 3 is not correct (i.e. external routes in L1 domain can still have > > internal > > and external metric types) then it means that L1 routers should have the > > capability to prefer internal metric types to external metric types and > > according to RFC1195, they do not have this capability ( 3.10.1 ) > > L1 routers in 1195 don't have 130 TLVs. 130s are exclusively L2 in 1195. That's why you cannot mix L1 areas when updating! Tony, Thanks for your response. I just went through the draft that you sent out on mailing list yesterday and it says that " If a deployment uses L1 external routes in an area that still contains strictly RFC 1195 compliant routers, forwarding loops can easily be formed ". This means that deployment of domain-wide draft needs changes in the RFC1195 compliant routers. Only the L1 routers which understand TLV 130 and accordingly understand internal/external routes and metric types need no upgrade. Is this correct? Other than Cisco routers, are there other routers which support externals in L1? This RFC1195 noncompliant behavior is not mentioned in any spec. I thought that the one of the goals of this draft was not to upgrade RFC 1195 compliant L1 routers which is not true anymore. Thanks, Rajesh From rsaluja@BayNetworks.COM Fri, 08 Oct 1999 10:04:48 -0400 Date: Fri, 08 Oct 1999 10:04:48 -0400 From: Rajesh Saluja rsaluja@BayNetworks.COM Subject: [Isis-wg] Re: 3way draft questions Tony, Thanks for bringing it up. I was assuming that these issues will be reflected in the latest draft. Basically section 3.2,Elements of Procedure of the three way handshake draft will change to include the modifications suggested by me. I can work with Dave to update the draft to reflect these changes. I will wait for Dave to tell us what he thinks. Best regards, Rajesh Tony Przygienda wrote: > > Rajesh Saluja wrote: > > > Dave, > > I can think of the following sequence while processing the received > > Point-to-Point Hello packets: > > - If Adjacency exists and the option is present, examine > > Neighbor System ID and Neighbor Extended Local Circuit ID. > > If they are present and there is a mismatch, > > PDU should be discarded. ( as explained in 3way draft ) > > - 8.2.4.2 a > > - 8.2.4.2 b > > - if action is UP or ACCEPT as a result of 8.2.4.2 a and b then > > if option is not present > > 8.2.4.2c > > 8.2.4.2d > > otherwise if option is present > > implement state table as given in 3way draft > > - 8.2.4.2e > > > > Also, in the state table, Other than the previous suggestion ( If Adj State > > is Down and Received State is Initializing, final state should be UP ), > > I am not convinced with one more transition: If Adj State is "Down" > > and Received State is "UP", why should the final state be "Down" > > and not "Initializing". > > > > One more thing. I assume that CSNP should be sent whenever the state > > transitions to "UP" state and CSNP should be processed even if the state > > is "Initializing" ( otherwise CSNP can get lost ). It will be nice if this can > > be elaborated in the spec. > > > > did I just get swamped with my e-mail or was there no follow-up (on the list) > on these issues ? Newest version of the draft (-01) still doesn't seem to reflect any of that > and any of the things below ? > > thanks > > -= tony > > > > Dave Katz wrote: > > > > > I am concerned about the case when one endpoint supports this > > > and other does not. > > > The draft says :"If the system ID of the neighboring system is > > > known ( in state Initializing or Up), it shall be reported in the > > > Neighbor system ID field, and the neighbor's Extended Local > > > Circuit ID shall be reported in the Neighbor's Extended Circuit > > > Id field". > > > Suppose A supports 3way ( point-to-point Adjacency State > > > option) and B does not. When A receives first Hello from B, it > > > will know about the System ID of B and not about the Extended > > > Circuit ID. What should A do out of following 3 options: > > > 1. Do not send this TLV any more since B does not support this. > > > 2. Send this TLV with adjacency state, Extended Local Circuit ID > > > and Neighbor System Id. > > > 3. Send this TLV with adjacency state and Extended Local Circuit > > > ID. > > > > > > Yep, you identified a small hole. The short answer is that it doesn't > > > matter in the least what it sends since the other guy is ignoring > > > the fields anyhow. The spec should be more explicit, however. > > > > > > Is the following ordering correct: > > > 1. Do PDU acceptance tests. > > > 2. If the option is present, implement state table as described in 3way > > > draft. > > > 3. If option not present or if the state as result of 2 is "UP" do the > > > following: > > > - Check for Area Address Mismatch and implement state tables as > > > described in the spec ( table 5,6 or 7 ) ( 8.2.4.2.a and b) > > > - If the action is "UP" or "Accept", calculate circuitID status. ( 8.2.4.2 c) > > > - If the action is "Accept" and circuit ID status is different, delete > > > adjacency ( 8.2.4.2.d) > > > - If action is "UP" or "Accept", update other fields. > > > > > > My questions on this ordering are: > > > 1. If the result of item 2 is "INITIALIZING", you hear Hello from a neighbor > > > for the first time, isn't it necessary to check for 8.2.4.2 a and b? The 3way > > > draft suggests to do nothing but I think that 8.2.4.2 should be processed. > > > > > > 2. Even if result of item 2 is "UP", it is possible that adjacency can fail > > > because > > > of 8.2.4.2 a or b. Then why should you first look into TLV and then verify the > > > > > > header? ( I mean Area Address mismatch, Circuit Type ) > > > > > > I see what you're getting at, I think. If there is a level or area address > > > mismatch, it will take a couple of packets to detect this, and an adjacency > > > will be created and then destroyed. Yeah, I guess I need to revisit this > > > verbiage (which of course bears no resemblance to any code in two different > > > implementations, which is why it's slightly broken...) > > > > > > 3. Since option processing will take care of circuit ID changes, why should > > > you > > > again process 8.2.4.2 c and d? > > > > > > This is indeed redundant but I was trying not to take apart the existing > > > verbiage too much. Obviously I need to rework this. > > > > > > I have one more question on 3way draft state table: > > > If Adj State is Down and Received State is "Initializing", why should the new > > > state be "Initializing" and not "Up" because receiving state "Initializing" > > > implies that the receiver has heard Hello from this system. > > > > > > It is this way because I copped it straight from NLSP four years ago and > > > didn't think about it too much. I think you're right, it's a bit more > > > conservative than it needs to be (and turns it into a four way handshake). > > > I'll convince myself that it won't break anything, and then change it. > > > > > > --Dave > > -- > thanks > > --- tony -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From dwfedyk@nortelnetworks.com Sat, 9 Oct 1999 17:33:55 -0400 Date: Sat, 9 Oct 1999 17:33:55 -0400 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt I have read the draft and the scanned the working group to understand what is happening to the metric(s). While it makes sense that the metrics for IS-IS were made larger and the 3 not commonly used metrics eliminated, I do not understand the proposal of a single Traffic Engineering Metric. In my experience multiple traffic engineering metrics for path selection allow better traffic engineering capabilities. Has any thought been given to multiple TE metrics? Can the current proposal be expanded in the future ? Don -----Original Message----- From: Tony Li [mailto:tli@procket.com] Sent: Tuesday, October 05, 1999 4:10 AM To: isis-wg@external.juniper.net Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Next order of business: There's been a request that the WG consider "IS-IS extensions for Traffic Engineering" for publication as an Informational RFC. We would like to start a WG last call on this document. Please comment by Friday, Oct. 15, 1999, 12:01 Pacific Time. Thanks, Tony & Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From tli@procket.com Sat, 9 Oct 1999 15:16:52 -0700 Date: Sat, 9 Oct 1999 15:16:52 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Don, | I have read the draft and the scanned the working group to understand what | is happening to the metric(s). While it makes sense that the metrics for | IS-IS | were made larger and the 3 not commonly used metrics eliminated, I do not | understand the proposal of a single Traffic Engineering Metric. Well, it's what we felt was needed. Note that the existing metrics can continue to be used if the network administrator/implementation allows it. There's no reason that you can't run the traffic engineering TLVs in parallel with the existing TLVs. | In my | experience multiple traffic engineering metrics for path selection allow | better traffic engineering capabilities. Please say more. The customer base didn't request this flexibility. | Has any thought been given to multiple TE metrics? Can the current proposal | be expanded in the future ? One of the great glories of TLV encoding is the flexibility for future extensions. ;-) Tony From dwfedyk@nortelnetworks.com Sun, 10 Oct 1999 09:29:53 -0400 Date: Sun, 10 Oct 1999 09:29:53 -0400 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Tony, > -----Original Message----- > From: Tony Li [mailto:tli@procket.com] > Sent: Saturday, October 09, 1999 6:17 PM > To: Fedyk, Don [BL3:2001-I:EXCH] > Cc: isis-wg@external.juniper.net; te-wg@UU.NET > Subject: Re: [Isis-wg] draft-ietf-isis-traffic-01.txt > > > > Don, > > > | I have read the draft and the scanned the working group to > understand what > | is happening to the metric(s). While it makes sense that > the metrics for > | IS-IS > | were made larger and the 3 not commonly used metrics > eliminated, I do not > | understand the proposal of a single Traffic Engineering Metric. > > > Well, it's what we felt was needed. Note that the existing > metrics can > continue to be used if the network > administrator/implementation allows it. > There's no reason that you can't run the traffic engineering TLVs in > parallel with the existing TLVs. It is an either/or situation though for the new 24 bit metric and the old 6 bit metrics, correct? The new connectionless metric does not have a specific traffic qualifier (such as delay, throughput etc) but I would assume its a combination of throughput and delay. Is this ever specified ? We implemented thoughput and delay based routing on both a connectionless and a path oriented system. The result for the connectionless system was that the delay based routing occupies forwarding table space for all possible destinations. We ended up implementing only two metrics. But with MPLS it is only a path minimization criteria during LSP selection. > > > | In my > | experience multiple traffic engineering metrics for path > selection allow > | better traffic engineering capabilities. > > > Please say more. The customer base didn't request this flexibility We are defining TE beyond just ISIS. In general it depends on the size of the network and the diversity of the links. The bandwidth allocation records are a type of metric in a sense since they take the place of the typical throughput based metric in a connectionless system. Of course not all MPLS connections will specify traffic parameters. I would be quite willing to elaborate on what metrics I think are useful and why in a small draft for the next IETF. > > > | Has any thought been given to multiple TE metrics? Can the > current proposal > | be expanded in the future ? > > > One of the great glories of TLV encoding is the flexibility for future > extensions. ;-) Agreed, but can also be one of its curses if we don't do it right. > > Tony > From tli@procket.com Sun, 10 Oct 1999 10:45:20 -0700 Date: Sun, 10 Oct 1999 10:45:20 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Don, | > There's no reason that you can't run the traffic engineering TLVs in | > parallel with the existing TLVs. | It is an either/or situation though for the new 24 bit metric and the old 6 | bit metrics, correct? Not strictly. You can run both. If you do, you probably want to advertise the same value in the 24 bit metric as you do in the default 6 bit metric. You still get to append all of the TE subTLVs that we've specified, you just lose out on the dynamic range of the metric. | The new connectionless metric does not have a specific traffic | qualifier (such as delay, throughput etc) but I would assume its | a combination of throughput and delay. Is this ever specified ? It is the default metric, with identical semantics to the default 6 bit metric, except for the range. This is to say that it's an administrative value, which may or may not have any bearing on reality, on a per-network basis. | We implemented thoughput and delay based routing on both a connectionless | and a path oriented system. | The result for the connectionless system was that the delay based routing | occupies forwarding table space for all possible destinations. | We ended up implementing only two metrics. But with MPLS it is only | a path minimization criteria during LSP selection. Are you thinking of modeling the static delay or dynamic delay? I'll assume the latter. One of the significant concerns with this type of approach is the stability of the routing system when you impart dynamic metric information into it. This has been discussed within the WG before. Previous experiments from the QoSR WG have demonstrated that we haven't been able to apply sufficient control theory to the protocols to achieve stability. | > | In my | > | experience multiple traffic engineering metrics for path | > selection allow | > | better traffic engineering capabilities. | > | > Please say more. The customer base didn't request this flexibility | We are defining TE beyond just ISIS. In general it depends on the size | of the network and the diversity of the links. The bandwidth allocation | records are a type of metric in a sense since they take the place of the | typical throughput based metric in a connectionless system. Of course | not all MPLS connections will specify traffic parameters. | I would be quite willing to elaborate on what metrics I think are useful | and why in a small draft for the next IETF. Thanks, we'll take you up on that. Also, if you'd like to lead a discussion and argue your case with the entire WG, we can do that. | > One of the great glories of TLV encoding is the flexibility for future | > extensions. ;-) | | Agreed, but can also be one of its curses if we don't do it right. History has shown that we never get it perfectly right, so we do our best and move on. ;-) Tony From tli@procket.com Sun, 10 Oct 1999 10:53:48 -0700 Date: Sun, 10 Oct 1999 10:53:48 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] Administrative issues 1) The next IETF is coming up very shortly. It's time to put together an agenda. If you have an agenda item, please send mail to the WG chairs immediately. Our slot is currently Mon. evening, 1930-2200. 2) There have been a couple of administrative comments about the traffic engineering draft. The significant one is that we've been asked to let IANA manage the subTLV type space. If there are no objections, we will simply incorporate appropriate boilerplate for this. As this has no direct technical impact, I'd like to propose that we continue the last call as is. Again, the last call closes this Friday. Tony From Radia.Perlman@East.Sun.COM Fri, 15 Oct 1999 17:06:06 -0400 (EDT) Date: Fri, 15 Oct 1999 17:06:06 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Re: internet-drafts/draft-ietf-isis-wg-255adj-02.txt >> When using this technique a node can use arbitrary number of circuits >> only being restricted by the fact that it cannot be DIS on more >> than 255 circuits since PNodes would become indistinguishable for >> different LANs. To solve that problem, different techniques, such >> as using multiple router IDs would be necessary, are however outside >> the scope of this draft. It really is quite simple to use multiple router IDs and then you don't have the restriction preventing being DIS on more than 255 circuits. I mentioned this in email before. A router will usually have multiple MAC addresses, and certainly it can be given multiple addresses if it's attached to more than 256 LANs. The only restriciton on the 7-byte LAN ID is that it be unique within the area, so if the router has MAC addresses A1, A2, and A3, then it can use A1.1, A1.2, ...A1.255, A2.1, A2.2, ... A2.255, A3.1, etc. There also isn't any reason not to play with the "global/local" and "group/individual" bits in the OUI, so even if a router only had 1 MAC address, it could form 4 different 6-byte addresses that no other routers in the area would own. Again, the only thing necessary for proper operation of IS-IS as a routing protocol is that the 7-byte LAN ID be unique in the area. There's no necessity for the first 6 bytes to be the same as the ID of a router on the LAN...it was just that using a router's 6-byte ID as a prefix was a convenient way to obtain a unique LAN name. Radia From Radia.Perlman@east.sun.com Sun, 17 Oct 1999 22:29:52 -0400 (EDT) Date: Sun, 17 Oct 1999 22:29:52 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@east.sun.com Subject: [Isis-wg] Re: internet-drafts/draft-ietf-isis-wg-255adj-02.txt OK, Here's some proposed text for adding the ability to be DIS on more than 255 broadcast links. If you're actually editing it, I'll mention that "More trickier" isn't proper English. (I wouldn't have bothered except if you're editing anyway...) You should say "A tricker case". Anyway here is proposed text for the >255 LANs. I think the easiest way to shoehorn it in without too much editing is to add a new section called: Being DIS on more than 255 broadcast links and have the section that says it's "out of scope to discuss this" to point to that section. And the new section should say something like: Being DIS on more than 255 LANs It is possible to be DIS on more than 255 LANs provided that a 7-byte pseudonode ID, unique in the area, can be selected. The IS-IS specification states that the DIS's system ID is the first 6 bytes of the pseudonode ID. However, the only property of the 7-byte Pnode ID necessary for correct operation of the routing algorithm is that the 7-byte ID be unique in the area. If router R has multiple MAC addresses, say MAC1, MAC2, MAC3, then R can easily derive 255*3 unique Pnode addresses, since it can use MAC1.1, MAC1.2, ... MAC1.255, MAC2.1, ... MAC2.255, MAC3.1, ... MAC3.255. A router that might be DIS on more than 255 broadcast links can also be configured with multiple EUI-48 addresses for this purpose, even if they are not used as layer 2 addresses. If R only has a single EUI-48 address, it can still generate 4 unique 6-byte prefixes for Pnode IDs, because it can use the global/local bit and the group/individual bit in its EUI-48. In other words, it can use any setting of those 2 bits in its EUI-48 address for this purpose. Note that although there is no reason why the first 6 bytes of the Pnode ID must be the system ID of the DIS, it is true that the IS-IS specification does say that this will be the case, and although we know of no problems that this will cause, it is possible that some management tools might rely on that assumption. From hsmit@cisco.com Thu, 21 Oct 1999 21:20:57 +0200 (MET DST) Date: Thu, 21 Oct 1999 21:20:57 +0200 (MET DST) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] New version of draft-ietf-isis-domain-wide-02.txt Here is the new draft for route-leaking with old-style TLVs. We missed the deadline for the official submission of this draft. If there is enough interest, I could do a short presentation at the ISIS WG meeting on monday night at the IETF. The main difference is that we decided to use bit 8 in the default metric field as the up/down bit. That allows us to leak L2 external routes into L1 while maintaining the difference between TLV128 and TLV130. We also added some text on the current practice of allowing externals (TLV130) in L1. Henk. ---- Network Working Group Tony Li INTERNET DRAFT Procket Networks Tony Przygienda Siara Systems Henk Smit Cisco Systems October 1999 Domain-wide Prefix Distribution with Two-Level IS-IS Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1.0 Abstract This document describes extensions to the IS-IS protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589 [1], with extensions for supporting IPv4 specified in RFC 1195 [2]. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. 2.0 Introduction An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) can be partitioned into multiple level 1 (L1) areas, and a level 2 (L2) connected subset of the topology that interconnects all of the L1 areas. Within each L1 area, all routers exchange link state information. L2 routers also exchange L2 link state information to compute routes between areas. RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that are used to transport IPv4 routing information in IS-IS. RFC 1195 also specifies the semantics and procedures for interactions between levels. Specifically, routers in a L1 area will exchange information within the L1 area. For IP destinations not found in the prefixes in the L1 database, the L1 router should forward packets to the nearest router that is in both L1 and L2 (i.e., an L1L2 router) with the "attached bit" set in its L1 Link State Protocol Data Unit (LSP). Also per RFC 1195, an L1L2 router should be manually configured with a set of prefixes that summarizes the IP prefixes reachable in that L1 area. These summaries are injected into L2. RFC 1195 specifies no further interactions between L1 and L2 for IPv4 prefixes. 2.1 Motivations for domain-wide prefix distribution The mechanisms specified in RFC 1195 are appropriate in many situations, and lead to excellent scalability properties. However, in certain circumstances, the domain administrator may wish to sacrifice some amount of scalability and distribute more specific information than is described by RFC 1195. This section discusses the various reasons why the domain administrator may wish to make such a tradeoff. One major reason for distributing more prefix information is to improve the quality of the resulting routes. A well know property of prefix summarization or any abstraction mechanism is that it necessarily results in a loss of information. This loss of information in turn results in the computation of a route based upon less information, which will frequently result in routes that are not optimal. A simple example can serve to demonstrate this adequately. Suppose that a L1 area has two L1L2 routers that both advertise a single summary of all prefixes within the L1 area. To reach a destination inside the L1 area, any other L2 router is going to compute the shortest path to one of the two L1L2 routers for that area. Suppose, for example, that both of the L1L2 routers are equidistant from the L2 source, and that the L2 source arbitrarily selects one L1L2 router. This router may not be the optimal router when viewed from the L1 topology. In fact, it may be the case that the path from the selected L1L2 router to the destination router may traverse the L1L2 router that was not selected. If more detailed topological information or more detailed metric information was available to the L2 source router, it could make a more optimal route computation. This situation is symmetric in that an L1 router has no information about prefixes in L2 or within a different L1 area. In using the nearest L1L2 router, that L1L2 is effectively injecting a default route without metric information into the L1 area. The route computation that the L1 router performs is similarly suboptimal. Besides the optimality of the routes computed, there are two other significant drivers for the domain wide distribution of prefix information. When a router learns multiple possible paths to external destinations via BGP, it will select only one of those routes to be installed in the forwarding table. One of the factors in the BGP route selection is the IGP cost to the BGP next hop address. Many ISP networks depend on this technique, which is known as "shortest exit routing". If a L1 router does not know the exact IGP metric to all BGP speakers in other L1 areas, it cannot do effective shortest exit routing. The third driver is the current practice of using the IGP (IS-IS) metric as part of the BGP Multi-Exit Discriminator (MED). The value in the MED is advertised to other domains and is used to inform other domains of the optimal entry point into the current domain. Current practice is to take the IS-IS metric and insert it as the MED value. This tends to cause external traffic to enter the domain at the point closest to the exit router. Note that the receiving domain may, based upon policy, choose to ignore the MED that is advertised. However, current practice is to distribute the IGP metric in this way in order to optimize routing wherever possible. This is possible in current networks that only are a single area, but becomes problematic if hierarchy is to be installed into the network. This is again because the loss of end-to-end metric information means that the MED value will not reflect the true distance across the advertising domain. Full distribution of prefix information within the domain would alleviate this problem as it would allow accurate computation of the IS-IS metric across the domain, resulting in an accurate value presented in the MED. 2.2 Scalability The disadvantage to performing the domain-wide prefix distribution described above is that it has an impact to the scalability of IS-IS. Areas within IS-IS help scalability in that LSPs are contained within a single area. This limits the size of the link state database, that in turn limits the complexity of the shortest path computation. Further, the summarization of the prefix information aids scalability in that the abstraction of the prefix information removes the sheer number of data items to be transported and the number of routes to be computed. It should be noted quite strongly that the distribution of prefixes on a domain wide basis impacts the scalability of IS-IS in the second respect. It will increase the number of prefixes throughout the domain. This will result in increased memory consumption, transmission requirements and computation requirements throughout the domain. It must also be noted that the domain-wide distribution of prefixes has no effect whatsoever on the first aspect of scalability, namely the existence of areas and the limitation of the distribution of the link state database. Thus, the net result is that the introduction of domain-wide prefix distribution into a formerly flat, single area network is a clear benefit to the scalability of that network. However, it is a compromise and does not provide the maximum scalability available with IS-IS. Domains that choose to make use of this facility should be aware of the tradeoff that they are making between scalability and optimality and provision and monitor their networks accordingly. Normal provisioning guidelines that would apply to a fully hierarchical deployment of IS-IS will not apply to this type of configuration. 3.0 Proposed syntax and semantics for L2->L1 inter-area routes This document defines the syntax of how to advertise level 2 routes in level 1 LSPs. The encoding is an extension of the encoding in RFC 1195. To some extent, in IS-IS the level 2 backbone can be seen as a separate area itself. RFC 1195 defines that L1L2 routers can advertise IP routes that were learned via L1 routing into L2. These routes can be regarded as inter-area routes. RFC 1195 defines that these L1->L2 inter-area routes must be advertised in L2 LSPs in the "IP Internal Reachability Information" TLV (TLV 128). Intra-area L2 routes are also advertised in L2 LSPs in an "IP Internal Reachability Information" TLV. Therefor L1->L2 inter-area routes are indistinguishable from L2 intra-area routes. RFC 1195 does not define L2->L1 inter-area routes. A simple extension would be to allow a L1L2 router to advertise routes learned via L2 routing in its L1 LSP. However, to prevent routing-loops, L1L2 routers must never advertise L2->L1 inter-area routes that they learn via L1 routing, back into L2. Therefor there must be a way to distinguish L2->L1 inter-area routes from L1 intra-area routes. Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for this purpose. RFC 1195 defines TLVs 128 and 130 to contain IP routes. TVLs 128 and 130 have a metric field that consists of 4 TOS metrics. The first metric, the so-called "default metric", has the high-order bit reserved (bit 8). Routers must set this bit to zero on transmission, and ignore it on receipt. This document redefines this high-order bit in the default metric field in TLVs 128 and 130 to be the up/down bit. L1L2 routers must set this bit to one for prefixes that are derived from L2 routing and are advertised into L1 LSPs. The bit must be set to zero for all other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down bit set that are learned via L1 routing, must never be advertised by L1L2 routers back into L2. 3.1 Clarification of external route-type and external metric-type RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is defined as "IP Internal Reachability Information", and should be used to carry IP prefixes that are directly connected to IS-IS routers. TLV 130 is defined as "IP External Reachability Information", and should be used to carry routes learned from outside the IS-IS domain. RFC 1195 documents TLV type 130 only for level 2 LSPs. RFC 1195 also defines two types of metrics. Metrics of the internal metric-type should be used when the metric is comparable to metrics used to weigh links inside the ISIS domain. Metrics of the external metric-type should be used if the metric of an IP prefix cannot be directly compared to internal metrics. External metric-type can only be used for external IP prefixes. A direct result is that metrics of external metric-type should never be seen in TLV 128. To prevent confusion, this document states again that when a router computes IP routes, it must give the same preference to IP routes advertised in an "IP Internal Reachability Information" TLV and IP routes advertised in an "IP External Reachability Information" TLV. RFC 1195 states this quite clearly in the note in paragraph 3.10.2, item 2c). This document does not alter this rule of preference. NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field), and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation. However, IP routes advertised in "IP External Reachability Information" with external metric-type must be given less preference than the same IP routes advertised with internal-metric type, regardless of the value of the metrics. While IS-IS routers must not give different preference to IP prefixes learned via "IP Internal Reachability Information" and "IP External Reachability Information" when executing the Dijkstra calculation, routers that implement multiple IGPs are free to use this distinction between internal and external routes when comparing routes derived from different IGPs for inclusion in their global RIB. 3.2 Definition of external IP prefixes in level 1 LSPs RFC 1195 does not define the "IP External Reachability Information" TLV for L1 LSPs. However, there is no reason why an IS-IS implementation could not allow for redistribution of external routes into L1. Some IS-IS implementations already allow network administrators to do this. This document loosens the restrictions in RFC 1195, and allows for the inclusion of the "IP External Reachability Information" TLV in L1 LSPs. RFC 1195 defines that IP routes learned via L1 routing must always be advertised in L2 LSPs in a "IP Internal Reachability Information" TLV. Now that this document allows "IP External Reachability Information" TLVs in L1 LSPs, and allows for the advertisement of routes learned via L2 routing into L1, the above rule needs a extensions. When a L1L2 router advertises a L1 route into L2, where that L1 route was learned via a prefix advertised in a "IP External Reachability Information" TLV, that L1L2 router should advertise that prefix in its L2 LSP within an "IP External Reachability Information" TLV. L1 routes learned via an "IP Internal Reachability Information" TLV should still be advertised within a "IP Internal Reachability Information" TLV. These rules should also be applied when advertising IP routes derived from L2 routing into L1. Of course in this case also the up/down bit must be set. RFC 1195 defines that if a router sees the same external prefix advertised by two or more routers with the same external metric, it must select the route that is advertised by the router that is closest to itself. It should be noted that now that external routes can be advertised from L1 into L2, and vice versa, that the router that advertises an external prefix in its LSP might not be the router that originally injected this prefix into the IS-IS domain. Therefor it is less useful to advertise external routes with external metrics into other levels. 4.0 Types of IP routes in IS-IS and their order of preference RFC 1195 and this document defines several ways of advertising IP routes in IS-IS. There are four variables involved. 1) The level of the LSP in which the route is advertised. There are currently two possible values: level 1 and level 2 2) The route-type, which can be derived from the type of TLV in which the prefix is advertised. Internal routes are advertised in IP Internal Reachability Information TLVs (TLV 128), and external routes are advertised in IP External Reachability Information TLVs (TLV 130). 3) The metric-type: Internal or External. The metric-type is derived from the Internal/External metric-type bit in the metric field (bit 7). 4) The fact whether this route is leaked down in the hierarchy, and thus can not be advertised back up. This information can be derived from the newly defined up/down bit in the default metric field. 4.1 Overview of all types of IP prefixes in IS-IS Link State PDUs The combination IP Internal Reachability Information and external metric-type is not allowed. Also the up/down bit is never set in L2 LSPs. This leaves us with 8 different types of IP advertisements in IS-IS. However, there are more than 8 reasons for IP prefixes to be advertised in IS-IS. The following tables describe the types of IP prefixes and how they are encoded. 1) L1 intra-area routes These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router. 2) L1 external routes These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. 3) L2 intra-area routes These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area routes. 4) L2 external routes These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes. 5) L1->L2 inter-area routes These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 128. These prefixes can not be distinguished from L2 intra-area routes. 6) L1->L2 inter-area external routes These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130. These prefixes can not be distinguished from L2 external routes. 7) L2->L1 inter-area routes These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in TLV 128. 8) L2->L1 inter-area external routes These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in L2 LSPs in TLV 130. 9) L1 external routes with external metric These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. 10) L2 external routes with external metric These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes with external metric. 11) L1->L2 inter-area external routes with external metric These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130 with external metrics. These prefixes can not be distinguished from L2 external routes with external metric. 12) L2->L1 inter-area external routes with external metric These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is external metric. These IP prefixes are learned via L2 routing, and were derived during the L1 SPF computation from prefixes advertised in L2 LSPs in TLV 130 with external metrics. 4.2 Order of preference for all types of IP routes in IS-IS Unfortunately IS-IS cannot depend on metrics alone for route selection. Some types of routes must always preferred over others, regardless of the costs that were computed in the Dijkstra calculation. One of the reasons for this is that inter-area routes can only be advertised with a maximum metric of 63. Another reason is that this maximum value of 63 does not mean infinity (e.g. like a hop count of 16 in RIP denotes unreachable). Introducing a value for infinity cost in IS-IS inter-area routes would introduce counting- to-infinity behavior via two or more L1L2 routers, which would have a bad impact on network stability. The order of preference of IP routes in IS-IS is based on a few assumptions. - RFC 1195 defines that routes derived from L1 routing are preferred over routes derived from L2 routing. - The note in RFC 1195 paragraph 3.10.2, item 2c) defines that internal routes with internal metric-type and external prefixes with internal metric-type have the same preference. - RFC 1195 defines that external routes with internal metric-type are preferred over external routes with external metric type. - Routes derived from L2 routing are preferred over L2->L1 routes derived from L1 routing. Based on these assumptions, this document defines the following route preferences. 1) L1 intra-area routes with internal metric L1 external routes with internal metric 2) L2 intra-area routes with internal metric L2 external routes with internal metric L1->L2 inter-area routes with internal metric L1->L2 inter-area external routes with internal metric 3) L2->L1 inter-area routes with internal metric L2->L1 inter-area external routes with internal metric 4) L1 external routes with external metric 5) L2 external routes with external metric L1->L2 inter-area external routes with external metric 6) L2->L1 inter-area external routes with external metric 4.3 Additional notes on what prefixes to accept or advertise Paragraphs 4.1 and 4.2 enumerate all used IP route types in IS-IS. Besides these defined route types, the encoding used would allow for a few more potential combinations. One of them is the combination of "IP Internal Reachability Information" and external metric type. This combination should never be used when building an LSP. Upon receipt of an IP prefix with this combination, routers must ignore this prefix. Another issue would be the usage of the up/down bit in L2 LSPs. Because IS-IS is currently defined with two levels of hierarchy, there should never be a need to set the up/down bit in L2 LSPs. However, if IS-IS would ever be extended with more than two levels of hierarchy, L2-only (or L1L2) routers will need to be able to accept L2 IP routes with the up/down bit set. Therefor it is recommended that implementations ignore the up/down bit in L2 LSPs, and accept the prefixes in L2 LSPs regardless whether the up/down bit is set. This will allow for simpler migration once more than two levels of hierarchy are defined. Another detail that implementors should be aware of is the fact that L1L2 routers should only advertise in their L2 LSP those L1 routes that they use for forwarding themselves. They should not unconditionally advertise into L2 all prefixes from LSPs in the L1 database. Not all prefixes need to be advertised up or down the hierarchy. Implementations might allow for additional manual filtering or summarization to further bring down the number of inter-area prefixes they advertise in their LSPs. It is also recommended that the default configuration of L1L2 routers is to not advertise any L2 routes into L1 (see also paragraph 5.0). 5.0 Inter-operability with older implementations The solution in this document is not fully compatible with RFC 1195. It is an extension to RFC 1195. If routers do not use the new functionality of external L1 routes, nor L2->L1 inter-area routes, older implementations that strictly follow RFC 1195 will be compatible with newer implementations that follow this document. Implementations that do not accept the "IP External Reachability Information" TLV in L1 LSPs will not be able to compute external L1 routes. This could cause routing loops between L1-only routers that do understand external L1 routes for a particular destination, and L1-only routers that use the default route pointing the closest attached L1L2 router for that destination. Implementations that follow RFC 1195 should ignore bit 8 in the default metric field when computing routes. Therefor even older implementations that do not know of the up/down bit should be able to accept the new L2->L1 inter-area routes. These older implementations will install the new L2->L1 inter-area routes as L1 intra-area routes, but that in itself does not cause routing loops among L1-only routers. However, it is vital that the up/down bit is recognized by L1L2 routers. As has been stated before, L1L2 routers must never advertise L2->L1 inter-area routes back into L2. Therefor if L2 routes are advertised down into L1 area, it is required that all L1L2 routers in that area run software that understands the new up/down bit. Older implementations that follow RFC 1195 and do not understand the new up/down bit will threat the L2->L1 inter-area routes as L1 intra-area routes, and they will advertise these routes back into L2. This can cause routing loops, sub-optimal routing or extra routing instability. For this reason it is recommended that implementations by default do not advertise any L2 routes into L1. Implementations should force the network administrator to manually configure L1L2 routers to advertise any L2 routes into L1. 6.0 Comparisons with other proposals In [3], a new TLV is defined to transport IP prefix information. This TLV format also defines an up/down bit to allow for L2->L1 inter-area routes. [3] also defines a new TLV to describe links. Both TLVs have wider metric space, and have the possibility to define sub-TLVs to advertise extra information belonging to the link or prefix. The wider metric space in IP prefix TLVs allows for more granular metric information about inter-area path costs. To make full use of the wider metric space, network administrators must deploy both new TLVs at the same time. Deployment of [3] requires an upgrade of all routers in the network and a transition to the new TLVs. Such a network-wide upgrade and transition might not be an easy task. In this case, the solution defined in this document, which requires only an upgrade of L1L2 routers in selected areas, might be a good alternative to the solution defined in [3]. 5.0 Security Considerations This document raises no new security issues for IS-IS. 6.0 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)" [Also republished as RFC 1142] [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 [3] Smit, H., Li, T. "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-01.txt, work in progress 7.0 Authors' Addresses Tony Li Procket Networks 3910 Freedom Circle, Ste. 102A Santa Clara, CA 95054 Email: tli@procket.net Tony Przygienda Siara Systems 300 Ferguson Drive, 2nd Floor Mountain View, CA 94043 Email: prz@siara.com Voice: +1 650 237 2173 Fax: +1 650 237 2179 Henk Smit Cisco Systems, Inc. 210 West Tasman Drive San Jose, CA 95134 Email: hsmit@cisco.com Voice: +31 20 342 3736 From dwfedyk@nortelnetworks.com Thu, 21 Oct 1999 16:07:32 -0400 Date: Thu, 21 Oct 1999 16:07:32 -0400 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] FYI Draft Metrics and Resource Classes for TE We have submitted the draft: draft-fedyk-mpls-te-metrics-00.txt for review to the following working groups: - Traffic engineering - MPLS - IS-IS - OSPF We asked to present it to the TE and ISIS working groups. Abstract There has recently been a lot of activity in defining the components for MPLS-based traffic engineering. This includes the recent extensions of the Interior Gateway Protocols (IGPs) to carry metrics and resource class information about links. This memo explores additional metrics that are useful for traffic engineering. We also describe some of the subtleties associated with the use of the resource class (or color) vector that has been defined in the IGP extensions. For those interested, a copy is avialable at: http://www.ee.duke.edu/~ag/final-papers/mpls-te-metrics.txt Thanks, -Don Fedyk and Anoop Ghanwani From awduche@UU.NET Thu, 21 Oct 1999 16:26:11 -0400 (EDT) Date: Thu, 21 Oct 1999 16:26:11 -0400 (EDT) From: Daniel Awduche awduche@UU.NET Subject: [Isis-wg] Re: FYI Draft Metrics and Resource Classes for TE Jon, A note on your draft... You made the following assertion in the draft.. "On the other hand, it is also possible to look at bandwidth as an additive metric by using link costs that are in inverse proportion to available bandwidth; in such cases, the shortest path corresponds to the path with the most bandwidth." This assertion is, of-course, false (that is that the shortest path based on inverse bandwidths is the one with the most bandwidth). You may wish to correct it in the next iteration of your draft. Regards, /Dan Don Fedyk said: > > We have submitted the draft: draft-fedyk-mpls-te-metrics-00.txt > for review to the following working groups: > - Traffic engineering > - MPLS > - IS-IS > - OSPF > > We asked to present it to the TE and ISIS working groups. > > Abstract > > There has recently been a lot of activity in defining the components > for MPLS-based traffic engineering. This includes the recent > extensions of the Interior Gateway Protocols (IGPs) to carry metrics > and resource class information about links. This memo explores > additional metrics that are useful for traffic engineering. We also > describe some of the subtleties associated with the use of the > resource class (or color) vector that has been defined in the IGP > extensions. > > For those interested, a copy is avialable at: > http://www.ee.duke.edu/~ag/final-papers/mpls-te-metrics.txt > Thanks, > -Don Fedyk and Anoop Ghanwani > From dwfedyk@nortelnetworks.com Thu, 21 Oct 1999 16:26:56 -0500 Date: Thu, 21 Oct 1999 16:26:56 -0500 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] RE: FYI Draft Metrics and Resource Classes for TE Dan and Angela: Yes, As you both pointed out it maximizes the bandwidth only on a next hop link basis not a path basis. I will correct the text. This is not key to the arguments of the draft but it does illustrate how bandwidth allocation is advantageous. Thanks, Don > -----Original Message----- > From: Chiu, Angela L, ALSVC [mailto:alchiu@att.com] > Sent: Thursday, October 21, 1999 4:53 PM > To: awduche@UU.NET; Fedyk, Don [BL3:2001-I:EXCH] > Cc: te-wg@UU.NET; isis-wg@external.juniper.net > Subject: RE: FYI Draft Metrics and Resource Classes for TE > > > Jon, > > I echo what Dan pointed out earlier. By making link cost to > be the inverse > proportional to available bandwidth, it only says that the > least cost link > is the one with the most available bandwidth. > > Your statement that > "the shortest path corresponds to the path with the > most bandwidth" > is not even true for paths with the same number of hops. For > example, let > link cost to be the inverse of the available bandwidth. > Available link bandwidth on path A: 1, 6, 6, 6, 6, 6, 6 => > path available > bandwidth = 1, with path cost = 2 > Available link bandwidth on path B: 2, 3, 3, 3, 3, 3, 3 => > path available > bandwidth = 2, with path cost = 2.5 > > Hope the example helps. > > Angela Chiu > > AT&T Labs > Room C4-3A22 > 200 Laurel Ave. > Middletown, NJ 07748 > Tel. (732) 420-2290 > Fax (732) 368-1746 > Email: alchiu@att.com > > > -----Original Message----- > > From: awduche@UU.NET [SMTP:awduche@UU.NET] > > Sent: Thursday, October 21, 1999 4:26 PM > > To: dwfedyk@nortelnetworks.com > > Cc: te-wg@UU.NET; isis-wg@external.juniper.net; awduche@UU.NET > > Subject: Re: FYI Draft Metrics and Resource Classes for TE > > > > Jon, > > > > A note on your draft... > > > > You made the following assertion in the draft.. > > > > "On the other hand, it is also possible to look at bandwidth as an > > additive metric by using link costs that are in inverse proportion > > to available bandwidth; in such cases, the shortest path > > corresponds to the path with the most bandwidth." > > > > This assertion is, of-course, false (that is that the shortest > > path based on inverse bandwidths is the one with the most > > bandwidth). You may wish to correct it in the next iteration > > of your draft. > > > > Regards, > > /Dan > > > > > > Don Fedyk said: > > > > > > We have submitted the draft: draft-fedyk-mpls-te-metrics-00.txt > > > for review to the following working groups: > > > - Traffic engineering > > > - MPLS > > > - IS-IS > > > - OSPF > > > > > > We asked to present it to the TE and ISIS working groups. > > > > > > Abstract > > > > > > There has recently been a lot of activity in defining > the components > > > for MPLS-based traffic engineering. This includes the recent > > > extensions of the Interior Gateway Protocols (IGPs) to > carry metrics > > > and resource class information about links. This memo explores > > > additional metrics that are useful for traffic > engineering. We also > > > describe some of the subtleties associated with the use of the > > > resource class (or color) vector that has been defined > in the IGP > > > extensions. > > > > > > For those interested, a copy is avialable at: > > > http://www.ee.duke.edu/~ag/final-papers/mpls-te-metrics.txt > > > Thanks, > > > -Don Fedyk and Anoop Ghanwani > > > > From dwfedyk@nortelnetworks.com Fri, 22 Oct 1999 10:43:34 -0400 Date: Fri, 22 Oct 1999 10:43:34 -0400 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] RE: FYI Draft Metrics and Resource Classes for TE > -----Original Message----- > From: Tony Przygienda [mailto:prz@siara.com] > Sent: Thursday, October 21, 1999 9:30 PM > To: Fedyk, Don [BL3:2001-I:EXCH] > Cc: Chiu, Angela L, ALSVC; awduche@UU.NET; te-wg@UU.NET; > isis-wg@external.juniper.net > Subject: Re: [Isis-wg] RE: FYI Draft Metrics and Resource > Classes for TE > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg stuff deleted > > first, I think that the draft is dearly missing the reference > to the QoSR > RFC 2386 by Raj & Bala that does much more thorough (and error-free) > job of explaining the problem and well-known research results > in terms of > algorithmic complexities and available design space and would > make some of it > superfluous. We will add the reference. Thank you. It is evident that there is some confusion. We are only addressing connection oriented traffic engineering metrics not connectionless metrics. I will try to be more clear. In my experience I have effectively used multiple connection oriented TE metrics. I believe this is worthwhile going forward. We have customers that request it. The multiple metrics we ask for are for traffic engineering MPLS not IGP. > second, it may be better to aim for a presentation at the > routing area meeting > rather than in ISIS and OSPF & other groups disjointly since > the interested parties > will be there and this is not a draft asking for specific TLVs / LSA > additions but somehow for extensions to the generic scope of > the work. As well, > presenting to 4 groups is kind of a strain ;-) We only asked for MPLS TE and IS-IS at this point. > > third, IMHO I'd be reluctant to put into the protocol metrics > that are a > "network administrative decision". An IGP is _not_ a network > management tool. > Metrics have crisp meanings. Otherwise issues of metric > translation, ranges, > consistent computation algorithms and so on will be an > interesting albeit > not very constructive exercise on a live network. I am confused. The IS-IS draft has TE metrics and resources this is what we were trying to address. > > fourth, Tony Li's name is misspelled until he changed his > name with his job ;-) Yes, Henk Smit pointed this out already. I apologized to Tony Li. I will update the document. > > > thanks > > - tony > Thanks, Don From zinin@amt.ru Tue, 26 Oct 1999 11:47:58 +0300 Date: Tue, 26 Oct 1999 11:47:58 +0300 From: Alex Zinin zinin@amt.ru Subject: [Isis-wg] Ccomments on Draft "Metrics and Resource Classes for TE" Don, My 2c on this (just to make sure it's bitten to death ;) : We have: >2. Routing Metrics > > A metric is a weight that is assigned to links in the network to > indicate the relative preference of a link during path computation. > Usually, metrics are selected so that they allow the computation of > paths that meet certain constraints. Metrics for path selection can > be classified using the following two criteria: I think it would be more correct to say that metric is a characteristic of a route or a routing table entry, not a link. Link cost, BW, delay, etc. are the attributes that are taken into consideration while calculating the metric of a path/route, for example, the summary number of hopes (RIP) or the summary link cost (LS protocols). So these are the attributes that can be additive/non-additive and static/dynamic. > - Additive/non-additive: This refers to whether or not the path > metric is obtained by adding the metric value for all links in the > path. Examples of additive constraints include delay and hop > count. Bandwidth is an example of a non-additive constraint. On > the other hand, it is also possible to look at bandwidth as an > additive metric by using link costs that are in inverse proportion > to available bandwidth; in such cases, the shortest path > corresponds to the path with the most bandwidth. 1. When you treat costs in inverse proportion to the BW as additive, you effectively minimize the summary serialization delay (not including the propogation one) of the path, but you do not maximize the bandwidth, i.e., the semantics is changed. 2. Consequently, there's no reason to calculate the inverse proportion of the *available* bandwidth when you add the costs >3.1 Multiple traffic engineering (TE) metrics > ... > In such systems the metric type chosen is a guide to generating > paths and will attempt to minimize the metric subject to the other > constraints. There is little overhead for advertising multiple > metrics for traffic engineering since only the static metrics need > to be propagated. Why only the static metrics? What about available bandwidth that changes dynamically as more LSPs are established? > 4.3 Standardizing resource classes > > It is worthwhile to explore the demand for standardized resource > masks. This will allow requests to propagate seamlessly across > areas since the semantics of the bits will have a universal value. ... > Bits 0-15: Global use > > Bit 0: satellite > Bit 1: terrestrial > Bit 2: highest reliability > Bit 3: high reliability > Bit 4: medium reliability > Bit 5: low reliability > Bits 6-15: reserved > > Bits 16-32: Local use I believe you're talking about the RsCls field in LDP's 0x822 TLV. My opinion is that specific bits should not be assigned to specific colors/characteristics, instead the bit semantics should be starndardized. If the semantics is clear, it doesn't really matter which attribute each bit reflects and the priveledge of meaning assignment should be left to the admin ([s]he may not care about the reliability at all if all links are equally reliable, etc.) Draft "draft-ietf-mpls-cr-ldp-03.txt" does not explicitly specify how the mask should be used. It may be advantegous to introduce sub-TLVs in the ResCls-TLV, each containing a kind of op-code (exact mask match, any bit match, speficied bits cleared, etc.) Best, ------------------------------------------------------------------ Alex D. Zinin, Consultant CCSI #98966 CCIE #4015 From jjl@one.com Tue, 26 Oct 1999 17:24:27 -0400 Date: Tue, 26 Oct 1999 17:24:27 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt At 10:45 AM 10/10/99 -0700, Tony Li wrote: > >Don, > >| > There's no reason that you can't run the traffic engineering TLVs in >| > parallel with the existing TLVs. >| It is an either/or situation though for the new 24 bit metric and the old 6 >| bit metrics, correct? > >Not strictly. You can run both. If you do, you probably want to advertise >the same value in the 24 bit metric as you do in the default 6 bit metric. >You still get to append all of the TE subTLVs that we've specified, you >just lose out on the dynamic range of the metric. Earlier, I pointed out what I though was a problem with the 24-bit metrics, namely, that MAX_PATH_METRIC increased from 1024 to a much larger value. If you are running traffic engineering metrics in parallel with existing TLVs, which value for MAX_PATH_METRIC should be used? Must all routers in the subdomain support the new TLVs before they are used at all, to avoid routing loops that would occur if some paths exceed the smaller MAX_PATH_METRIC? Thanks, Jeff ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From tli@procket.com Tue, 26 Oct 1999 15:51:54 -0700 Date: Tue, 26 Oct 1999 15:51:54 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt | Earlier, I pointed out what I though was a problem with the 24-bit metrics, | namely, that MAX_PATH_METRIC increased from 1024 to a much larger value. | | If you are running traffic engineering metrics in parallel with existing | TLVs, which value for MAX_PATH_METRIC should be used? Must all routers | in the subdomain support the new TLVs before they are used at all, | to avoid routing loops that would occur if some paths exceed the smaller | MAX_PATH_METRIC? Would inconsistent MAX_PATH_METRICs lead to forwarding loops? Or to blackholes? In any case, if you're going to run with both metrics, then in normal operations, the metric would have to be smaller than 1024. If it were to exceed this, presumably due to an outage, then newer systems might find a path while older systems didn't. This would seem like a blackhole. And of course, if everything is a new system, you have a valid path. I'm not sure I see the problem. Tony From jjl@one.com Tue, 26 Oct 1999 19:17:31 -0400 Date: Tue, 26 Oct 1999 19:17:31 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Tony, Right: black holes, not loops. Never mind, Roseanna Roseannadanna At 03:51 PM 10/26/99 -0700, Tony Li wrote: > >| Earlier, I pointed out what I though was a problem with the 24-bit metrics, >| namely, that MAX_PATH_METRIC increased from 1024 to a much larger value. >| >| If you are running traffic engineering metrics in parallel with existing >| TLVs, which value for MAX_PATH_METRIC should be used? Must all routers >| in the subdomain support the new TLVs before they are used at all, >| to avoid routing loops that would occur if some paths exceed the smaller >| MAX_PATH_METRIC? > > >Would inconsistent MAX_PATH_METRICs lead to forwarding loops? Or to >blackholes? > >In any case, if you're going to run with both metrics, then in normal >operations, the metric would have to be smaller than 1024. If it were to >exceed this, presumably due to an outage, then newer systems might find a >path while older systems didn't. This would seem like a blackhole. > >And of course, if everything is a new system, you have a valid path. > >I'm not sure I see the problem. > >Tony > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From dwfedyk@nortelnetworks.com Wed, 27 Oct 1999 09:49:47 -0500 Date: Wed, 27 Oct 1999 09:49:47 -0500 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt This is interesting. It seems to me the current pratice of limiting the metric to a maximum that is less than infinity ie 63 is incompatible with a new metric beyond 63. If metrics beyond 63 were infinity for old systems, this would not happen. Don > -----Original Message----- > From: Tony Przygienda [mailto:prz@siara.com] > Sent: Tuesday, October 26, 1999 8:48 PM > To: Jeff Learman > Cc: Tony Li; Fedyk, Don [BL3:2001-I:EXCH]; > isis-wg@external.juniper.net; > te-wg@UU.NET > Subject: Re: [Isis-wg] draft-ietf-isis-traffic-01.txt > > > Jeff Learman wrote: > > > > Tony, > > > > Right: black holes, not loops. > > It's not exactly because of the MAX_PATH but > loops are possible in a mixed old-TLV, new-TLV > network if e.g. the same prefix is > being advertised twice and if > certain new link metrics are longer >63 and > certain are not (assuming that we'd generate > old-style TLVs for anything <64). In the figure O denotes > old-routers, N new routers and the dashed > lines are links with metrics > > > X/Y > | > 65 > | > [N] > | > 10 > | > [O1] > | > 10 > | > [N1] > | > 63 > | > [O] > | > 63 > | > [O] > | > 63 > | > X/Y > > So new router N1 will see the shortest path to X/Y > as 65+10+10=85 whereas O1 will believe that the > shortest path is 10+63+63+63>85 since it cannot see > any links with metric longer than 64 (new TLVs can > carry it, old ones cannot). Observe that I introduced > X/Y into the network twice to make a simple example, > in reality it's enough O1 cannot compute the route > to X/Y (because it cannot use the links with >64) and > uses aggregated/default forming a loop. > > And yes, trying to make everything >64 to be just 64 > in old TLVs doens't help either. Examples are easily > constructed. > > For a much more thorough (but rather formal so nothing > for the faint-hearted) dealilng > with this (IMHO) interesting topic look @ this year's infocom > 'Hop-by-Hop Routing with Node-Dependent Topology Information' > > > thanks > > -- tony > > > > > > Never mind, > > Roseanna Roseannadanna > > > > At 03:51 PM 10/26/99 -0700, Tony Li wrote: > > > > > >| Earlier, I pointed out what I though was a problem with > the 24-bit > > metrics, > > >| namely, that MAX_PATH_METRIC increased from 1024 to a > much larger value. > > >| > > >| If you are running traffic engineering metrics in > parallel with existing > > >| TLVs, which value for MAX_PATH_METRIC should be used? > Must all routers > > >| in the subdomain support the new TLVs before they are > used at all, > > >| to avoid routing loops that would occur if some paths > exceed the smaller > > >| MAX_PATH_METRIC? > > > > > > > > >Would inconsistent MAX_PATH_METRICs lead to forwarding > loops? Or to > > >blackholes? > > > > > >In any case, if you're going to run with both metrics, > then in normal > > >operations, the metric would have to be smaller than 1024. > If it were to > > >exceed this, presumably due to an outage, then newer > systems might find a > > >path while older systems didn't. This would seem like a blackhole. > > > > > >And of course, if everything is a new system, you have a > valid path. > > > > > >I'm not sure I see the problem. > > > > > >Tony > > > > > > > > ____________________________________________________________________ > > > > Jeff Learman Internet: jjl@one.com > > Engineering Manager Voice: (734)-975-7323 > > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > > 2725 South Industrial Pkwy, Suite 100 > > Ann Arbor, MI 48104 USA > > ____________________________________________________________________ > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > From dwfedyk@nortelnetworks.com Wed, 27 Oct 1999 14:17:53 -0500 Date: Wed, 27 Oct 1999 14:17:53 -0500 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] RE: Ccomments on Draft "Metrics and Resource Classes for TE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF20AF.FB8BBB2C Content-Type: text/plain; charset="iso-8859-1" Alex > -----Original Message----- > From: Alex Zinin [mailto:zinin@amt.ru] > Sent: Tuesday, October 26, 1999 4:48 AM > To: Fedyk, Don [BL3:2001-I:EXCH] > Cc: te-wg@uu.net; isis-wg@external.juniper.net > Subject: Ccomments on Draft "Metrics and Resource Classes for TE" > > > Don, > > My 2c on this (just to make sure it's bitten to death ;) : > > We have: > > >2. Routing Metrics > > > > A metric is a weight that is assigned to links in the network to > > indicate the relative preference of a link during path > computation. > > Usually, metrics are selected so that they allow the > computation of > > paths that meet certain constraints. Metrics for path > selection can > > be classified using the following two criteria: > > I think it would be more correct to say that metric is a > characteristic > of a route or a routing table entry, not a link. Link cost, > BW, delay, > etc. are the attributes that are taken into consideration while > calculating the metric of a path/route, for example, the summary > number of hopes (RIP) or the summary link cost (LS protocols). > So these are the attributes that can be additive/non-additive and > static/dynamic. Thank you. I will consider this for the update of this draft. > > - Additive/non-additive: This refers to whether or not the path > > metric is obtained by adding the metric value for all > links in the > > path. Examples of additive constraints include delay and hop > > count. Bandwidth is an example of a non-additive > constraint. On > > the other hand, it is also possible to look at bandwidth as an > > additive metric by using link costs that are in inverse > proportion > > to available bandwidth; in such cases, the shortest path > > corresponds to the path with the most bandwidth. > > 1. When you treat costs in inverse proportion to the BW as > additive, you effectively minimize the summary serialization > delay (not including the propogation one) of the path, > but you do not maximize the bandwidth, i.e., the semantics > is changed. > > 2. Consequently, there's no reason to calculate the inverse proportion > of the *available* bandwidth when you add the costs > This section will be re-worded. Unfortunately in the haste to get the draft out I was not that very careful with my English. Several people have pointed this out. The point was that there is a desire to seek the shortest path with the largest bandwidth. Available bandwidth used for the metric was again a static. In other words, the actual link capacity or speed. > > >3.1 Multiple traffic engineering (TE) metrics > > > ... > > In such systems the metric type chosen is a guide to generating > > paths and will attempt to minimize the metric subject to the other > > constraints. There is little overhead for advertising multiple > > metrics for traffic engineering since only the static metrics need > > to be propagated. > > Why only the static metrics? What about available bandwidth that > changes dynamically as more LSPs are established? It is true that bandwidth allocation is broadcast in the form of available bandwidth to allocate at a priority, but this is dynamic addition of static numbers. What I am trying to say is it is not related to the dynamic utilization number. I can lay down a path for 2 Meg and only use it 1 day of the week but I want it to be there for me when I use it. Simply we feel there is a need for multiple metrics, if some of these are dynamic in the future that is not precluded. > > > 4.3 Standardizing resource classes > > > > It is worthwhile to explore the demand for standardized resource > > masks. This will allow requests to propagate seamlessly across > > areas since the semantics of the bits will have a universal value. > ... > > > Bits 0-15: Global use > > > > Bit 0: satellite > > Bit 1: terrestrial > > Bit 2: highest reliability > > Bit 3: high reliability > > Bit 4: medium reliability > > Bit 5: low reliability > > Bits 6-15: reserved > > > > Bits 16-32: Local use > > I believe you're talking about the RsCls field in LDP's 0x822 TLV. Yes we should refer to the document, good point. > My opinion is that specific bits should not be assigned to specific > colors/characteristics, instead the bit semantics should be > starndardized. If the semantics is clear, it doesn't really matter > which attribute each bit reflects and the priveledge of meaning > assignment should be left to the admin ([s]he may not care about > the reliability at all if all links are equally reliable, etc.) > Draft "draft-ietf-mpls-cr-ldp-03.txt" does not explicitly specify how > the mask should be used. It may be advantegous to introduce > sub-TLVs in the ResCls-TLV, each containing a kind of op-code > (exact mask match, any bit match, speficied bits cleared, etc.) We agree and that is why we took a stab standardizing it. In general we saw many operations but the simple & and compare operation seemed most workable. If you don't have an agreement on bits, you can have two networks join with different bits meanings and you cannot interwork them. Several of our customers have joined two networks that started out as separate administrative networks. How do you change the bits once set? I like your op-code idea, we just didn't think it was simple enough to standardize. Thanks, Don > > Best, > ------------------------------------------------------------------ > Alex D. Zinin, Consultant > CCSI #98966 > CCIE #4015 > > ------_=_NextPart_001_01BF20AF.FB8BBB2C Content-Type: text/html; charset="iso-8859-1" RE: Ccomments on Draft "Metrics and Resource Classes for TE"

Alex

> -----Original Message-----
> From: Alex Zinin [mailto:zinin@amt.ru]
> Sent: Tuesday, October 26, 1999 4:48 AM
> To: Fedyk, Don [BL3:2001-I:EXCH]
> Cc: te-wg@uu.net; isis-wg@external.juniper.net
> Subject: Ccomments on Draft "Metrics and Resource Classes for TE"
>
>
> Don,
>
> My 2c on this (just to make sure it's bitten to death ;) :
>
> We have:
>
> >2. Routing Metrics
> >
> >   A metric is a weight that is assigned to links in the network to
> >   indicate the relative preference of a link during path
> computation.
> >   Usually, metrics are selected so that they allow the
> computation of
> >   paths that meet certain constraints.  Metrics for path
> selection can
> >   be classified using the following two criteria:
>
> I think it would be more correct to say that metric is a
> characteristic
> of a route or a routing table entry, not a link. Link cost,
> BW, delay,
> etc. are the attributes that are taken into consideration while
> calculating the metric of a path/route, for example, the summary
> number of hopes (RIP) or the summary link cost (LS protocols).
> So these are the attributes that can be additive/non-additive and
> static/dynamic.

Thank you. I will consider this for the update of this draft.


> >   - Additive/non-additive: This refers to whether or not the path
> >     metric is obtained by adding the metric value for all
> links in the
> >     path.  Examples of additive constraints include delay and hop
> >     count.  Bandwidth is an example of a non-additive
> constraint.  On
> >     the other hand, it is also possible to look at bandwidth as an
> >     additive metric by using link costs that are in inverse
> proportion
>  >    to available bandwidth; in such cases, the shortest path
>  >    corresponds to the path with the most bandwidth.
>
> 1. When you treat costs in inverse proportion to the BW as
>     additive, you effectively minimize the summary serialization
>     delay (not including the propogation one) of the path,
>     but you do not maximize the bandwidth, i.e., the semantics
>     is changed.
>
> 2. Consequently, there's no reason to calculate the inverse proportion
>     of the *available* bandwidth when you add the costs
>
This section will be re-worded. Unfortunately in the haste to get the
draft out I was not that very careful with my English. Several people
have pointed this out. The point was that there is a desire to
seek the shortest path with the largest bandwidth.

Available bandwidth used for the metric was again a static.
In other words, the actual link capacity or speed.

>
> >3.1 Multiple traffic engineering (TE) metrics
> >
>  ...
> >   In such systems the metric type chosen is a guide to generating
> >   paths and will attempt to minimize the metric subject to the other
> >   constraints. There is little overhead for advertising multiple
> >   metrics for traffic engineering since only the static metrics need
> >   to be propagated.
>
> Why only the static metrics? What about available bandwidth that
> changes dynamically as more LSPs are established?

It is true that bandwidth allocation is broadcast in the form of
available bandwidth to allocate at a priority, but this is
dynamic addition of static numbers.  What I am trying to say is
it is not related to the dynamic utilization number. I can
lay down a path for 2 Meg and only use it 1 day of the week
but I want it to be there for me when I use it.
 
Simply we feel there is a need for multiple metrics, if some of these
are dynamic in the future that is not precluded.

>
> >   4.3 Standardizing resource classes
> >
> >   It is worthwhile to explore the demand for standardized resource
> >   masks.  This will allow requests to propagate seamlessly across
> >   areas since the semantics of the bits will have a universal value.
> ...
>
> >   Bits 0-15: Global use
> >
> >   Bit 0: satellite
> >   Bit 1: terrestrial
> >   Bit 2: highest reliability
> >   Bit 3: high reliability
> >   Bit 4: medium reliability
> >   Bit 5: low reliability
> >   Bits 6-15: reserved
> >
> >   Bits 16-32: Local use
>
> I believe you're talking about the RsCls field in LDP's 0x822 TLV.
Yes we should refer to the document, good point.

> My opinion is that specific bits should not be assigned to specific
> colors/characteristics, instead the bit semantics should be
> starndardized. If the semantics is clear, it doesn't really matter
> which attribute each bit reflects and the priveledge of meaning
> assignment should be left to the admin ([s]he may not care about
> the reliability at all if all links are equally reliable, etc.)
> Draft "draft-ietf-mpls-cr-ldp-03.txt" does not explicitly specify how
> the mask should be used. It may be advantegous to introduce
> sub-TLVs in the ResCls-TLV, each containing a kind of op-code
> (exact mask match, any bit match, speficied bits cleared, etc.)

We agree and that is why we took a stab standardizing it.
In general we saw many operations but the simple & and compare
operation seemed most workable.
If you don't have an agreement on bits, you can have two networks
join with different bits meanings and you cannot interwork them.
Several of our customers have joined two networks that started out
as separate administrative networks. How do you change the bits
once set?

I like your op-code idea, we just didn't think it was simple
enough to standardize.

Thanks,
Don

>
> Best,
> ------------------------------------------------------------------
> Alex D. Zinin, Consultant
> CCSI #98966
> CCIE #4015
>
>

------_=_NextPart_001_01BF20AF.FB8BBB2C-- From zinin@amt.ru Thu, 28 Oct 1999 21:09:23 +0300 Date: Thu, 28 Oct 1999 21:09:23 +0300 From: Alex Zinin zinin@amt.ru Subject: [Isis-wg] RE: Ccomments on Draft "Metrics and Resource Classes for TE" Don, At 14:17 27.10.99 -0500, Don Fedyk wrote: >Alex > >> >> >3.1 Multiple traffic engineering (TE) metrics >> > >> ... >> > In such systems the metric type chosen is a guide to generating >> > paths and will attempt to minimize the metric subject to the other >> > constraints. There is little overhead for advertising multiple >> > metrics for traffic engineering since only the static metrics need >> > to be propagated. >> >> Why only the static metrics? What about available bandwidth that >> changes dynamically as more LSPs are established? > >It is true that bandwidth allocation is broadcast in the form of >available bandwidth to allocate at a priority, but this is >dynamic addition of static numbers. What I am trying to say is >it is not related to the dynamic utilization number. I can >lay down a path for 2 Meg and only use it 1 day of the week >but I want it to be there for me when I use it. > I may be missing something, but what is the purpose of establishing an LSP along a path with some BW value if this value is not guaranteed to be up to date? Example---you have two alternate paths---one with BW of 1.5M and another with BW of 2Ms. You need to establish say 5 LSPs and the constraint is max BW. If LSPs are established incrementally, you will have all of them traversing the 2M path, because there is no info on how much BW has left unreserved/unprovisioned. On the other side I would understand static Delay attribute calculated in inverse proportion to the BW, but it's not BW itself. Am I really missing something ? >Simply we feel there is a need for multiple metrics, if some of these >are dynamic in the future that is not precluded. > >> >> > 4.3 Standardizing resource classes >> > >> > It is worthwhile to explore the demand for standardized resource >> > masks. This will allow requests to propagate seamlessly across >> > areas since the semantics of the bits will have a universal value. >> ... >> >> > Bits 0-15: Global use >> > >> > Bit 0: satellite >> > Bit 1: terrestrial >> > Bit 2: highest reliability >> > Bit 3: high reliability >> > Bit 4: medium reliability >> > Bit 5: low reliability >> > Bits 6-15: reserved >> > >> > Bits 16-32: Local use >> >> I believe you're talking about the RsCls field in LDP's 0x822 TLV. >Yes we should refer to the document, good point. > >> My opinion is that specific bits should not be assigned to specific >> colors/characteristics, instead the bit semantics should be >> starndardized. If the semantics is clear, it doesn't really matter >> which attribute each bit reflects and the priveledge of meaning >> assignment should be left to the admin ([s]he may not care about >> the reliability at all if all links are equally reliable, etc.) >> Draft "draft-ietf-mpls-cr-ldp-03.txt" does not explicitly specify how >> the mask should be used. It may be advantegous to introduce >> sub-TLVs in the ResCls-TLV, each containing a kind of op-code >> (exact mask match, any bit match, speficied bits cleared, etc.) > >We agree and that is why we took a stab standardizing it. >In general we saw many operations but the simple & and compare >operation seemed most workable. >If you don't have an agreement on bits, you can have two networks >join with different bits meanings and you cannot interwork them. >Several of our customers have joined two networks that started out >as separate administrative networks. How do you change the bits >once set? > >I like your op-code idea, we just didn't think it was simple >enough to standardize. I understand your concern about different bit assignment, but what worries me is that we have only 32bits for the color mask and the document proposes to define a static meaning to some of them. One could foresee problems in the nearest future or in some already installed networks. For example, in a pure ATM-based network utilizing say well-designed SDH links, all bits 0 through 5 lose their purpose. We also do not and cannot know which classes are gonna be needed in the future. Another concern is how these bits are used----e.g. bits 0 and 1 are mutually exclusive, so we basically need only one to indicate the state of Satellite/Terrestrial link attribute. The level of reliability, in turn, can easily be coded in 3 bits instead of 5 (I remember the concerns on checking and standardization). Now imagine that another draft appears trying to assign static meaning to bits 6--15 and then some customers appear that need globally significant bits with absolutely different meaning....What do you do ? You may think of a method of mapping different bit schemes to each other, maybe.... These are just thoughts yet... > >Thanks, >Don > ------------------------------------------------------------------ Alex D. Zinin, Consultant CCSI #98966 CCIE #4015 From dwfedyk@nortelnetworks.com Thu, 28 Oct 1999 19:14:45 -0400 Date: Thu, 28 Oct 1999 19:14:45 -0400 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF219A.3AECE6AC Content-Type: text/plain; charset="iso-8859-1" Tony Przygienda Writes > Don Fedyk wrote: > > > > This is interesting. It seems to me the current pratice > > of limiting the metric to a maximum that is less than > > infinity ie 63 is incompatible with a new metric beyond > > 63. If metrics beyond 63 were infinity for old systems, > > this would not happen. > > if I'm reading you correctly, your conclusion is incorrect. > In the example given, it doesn't matter whether old routers > believe that new links with metric >63 are invisible or > infinity (or de facto, this is the _same_ thing for a link > state protocol). All said below holds. I recommend to familiarize > oneself with the calculus given in the paper before further discussion > on this topic. Things are rather counter-intuitive in > the problem domain that you face in such a network. > > thanks > > -- tony O.K. I see your point. So how do you fix the loop? It seems you must limit the metrics to 63 until you have upgraded all routers. Don > > > > > Don > > > > > -----Original Message----- > > > From: Tony Przygienda [mailto:prz@siara.com] > > > Sent: Tuesday, October 26, 1999 8:48 PM > > > To: Jeff Learman > > > Cc: Tony Li; Fedyk, Don [BL3:2001-I:EXCH]; > > > isis-wg@external.juniper.net; > > > te-wg@UU.NET > > > Subject: Re: [Isis-wg] draft-ietf-isis-traffic-01.txt > > > > > > > > > Jeff Learman wrote: > > > > > > > > Tony, > > > > > > > > Right: black holes, not loops. > > > > > > It's not exactly because of the MAX_PATH but > > > loops are possible in a mixed old-TLV, new-TLV > > > network if e.g. the same prefix is > > > being advertised twice and if > > > certain new link metrics are longer >63 and > > > certain are not (assuming that we'd generate > > > old-style TLVs for anything <64). In the figure O denotes > > > old-routers, N new routers and the dashed > > > lines are links with metrics > > > > > > > > > X/Y > > > | > > > 65 > > > | > > > [N] > > > | > > > 10 > > > | > > > [O1] > > > | > > > 10 > > > | > > > [N1] > > > | > > > 63 > > > | > > > [O] > > > | > > > 63 > > > | > > > [O] > > > | > > > 63 > > > | > > > X/Y > > > > > > So new router N1 will see the shortest path to X/Y > > > as 65+10+10=85 whereas O1 will believe that the > > > shortest path is 10+63+63+63>85 since it cannot see > > > any links with metric longer than 64 (new TLVs can > > > carry it, old ones cannot). Observe that I introduced > > > X/Y into the network twice to make a simple example, > > > in reality it's enough O1 cannot compute the route > > > to X/Y (because it cannot use the links with >64) and > > > uses aggregated/default forming a loop. > > > > > > And yes, trying to make everything >64 to be just 64 > > > in old TLVs doens't help either. Examples are easily > > > constructed. > > > > > > For a much more thorough (but rather formal so nothing > > > for the faint-hearted) dealilng > > > with this (IMHO) interesting topic look @ this year's infocom > > > 'Hop-by-Hop Routing with Node-Dependent Topology Information' > > > > > > > > > thanks > > > > > > -- tony > > > > > > > > > > > > > > Never mind, > > > > Roseanna Roseannadanna > > > > > > > > At 03:51 PM 10/26/99 -0700, Tony Li wrote: > > > > > > > > > >| Earlier, I pointed out what I though was a problem with > > > the 24-bit > > > > metrics, > > > > >| namely, that MAX_PATH_METRIC increased from 1024 to a > > > much larger value. > > > > >| > > > > >| If you are running traffic engineering metrics in > > > parallel with existing > > > > >| TLVs, which value for MAX_PATH_METRIC should be used? > > > Must all routers > > > > >| in the subdomain support the new TLVs before they are > > > used at all, > > > > >| to avoid routing loops that would occur if some paths > > > exceed the smaller > > > > >| MAX_PATH_METRIC? > > > > > > > > > > > > > > >Would inconsistent MAX_PATH_METRICs lead to forwarding > > > loops? Or to > > > > >blackholes? > > > > > > > > > >In any case, if you're going to run with both metrics, > > > then in normal > > > > >operations, the metric would have to be smaller than 1024. > > > If it were to > > > > >exceed this, presumably due to an outage, then newer > > > systems might find a > > > > >path while older systems didn't. This would seem like > a blackhole. > > > > > > > > > >And of course, if everything is a new system, you have a > > > valid path. > > > > > > > > > >I'm not sure I see the problem. > > > > > > > > > >Tony > > > > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > Jeff Learman Internet: > jjl@one.com > > > > Engineering Manager Voice: > (734)-975-7323 > > > > ONE (Open Networks Engineering, Inc) Fax: > (734)-975-6940 > > > > 2725 South Industrial Pkwy, Suite 100 > > > > Ann Arbor, MI 48104 USA > > > > > ____________________________________________________________________ > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > ------_=_NextPart_001_01BF219A.3AECE6AC Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] draft-ietf-isis-traffic-01.txt

Tony Przygienda
Writes

> Don Fedyk wrote:
> >
> > This is interesting. It seems to me the current pratice
> > of limiting the metric to a maximum that is less than
> > infinity ie 63 is incompatible with a new metric beyond
> > 63. If metrics beyond 63 were infinity for old systems,
> > this would not happen.
>
> if I'm reading you correctly, your conclusion is incorrect.
> In the example given, it doesn't matter whether old routers
> believe that new links with metric >63 are invisible or
> infinity (or de facto, this is the _same_ thing for a link
> state protocol). All said below holds. I recommend to familiarize
> oneself with the calculus given in the paper before further discussion
> on this topic. Things are rather counter-intuitive in
> the problem domain that you face in such a network.
>
>               thanks
>
>               -- tony

O.K. I see your point.
So how do you fix the loop?  It seems you must limit the metrics
to 63 until you have upgraded all routers.

Don

>
> >
> > Don
> >
> > > -----Original Message-----
> > > From: Tony Przygienda [mailto:prz@siara.com]
> > > Sent: Tuesday, October 26, 1999 8:48 PM
> > > To: Jeff Learman
> > > Cc: Tony Li; Fedyk, Don [BL3:2001-I:EXCH];
> > > isis-wg@external.juniper.net;
> > > te-wg@UU.NET
> > > Subject: Re: [Isis-wg] draft-ietf-isis-traffic-01.txt
> > >
> > >
> > > Jeff Learman wrote:
> > > >
> > > > Tony,
> > > >
> > > > Right: black holes, not loops.
> > >
> > > It's not exactly because of the MAX_PATH but
> > > loops are possible in a mixed old-TLV, new-TLV
> > > network if e.g. the same prefix is
> > > being advertised twice and if
> > > certain new link metrics are longer >63 and
> > > certain are not (assuming that we'd generate
> > > old-style TLVs for anything <64). In the figure  O denotes
> > > old-routers, N new routers and the dashed
> > > lines are links with metrics
> > >
> > >
> > >       X/Y
> > >       |
> > >       65
> > >       |
> > >        [N]
> > >       |
> > >       10
> > >       |
> > >        [O1]
> > >       |
> > >         10
> > >         |
> > >        [N1]
> > >       |
> > >       63
> > >       |
> > >        [O]
> > >       |
> > >       63
> > >       |
> > >        [O]
> > >       |
> > >       63
> > >       |
> > >       X/Y
> > >
> > > So new router N1 will see the shortest path to X/Y
> > > as 65+10+10=85 whereas O1 will believe that the
> > > shortest path is 10+63+63+63>85 since it cannot see
> > > any links with metric longer than 64 (new TLVs can
> > > carry it, old ones cannot). Observe that I introduced
> > > X/Y into the network twice to make a simple example,
> > > in reality it's enough O1 cannot compute the route
> > > to X/Y (because it cannot use the links with >64) and
> > > uses aggregated/default forming a loop.
> > >
> > > And yes, trying to make everything >64 to be just 64
> > > in old TLVs doens't help either. Examples are easily
> > > constructed.
> > >
> > > For a much more thorough (but rather formal so nothing
> > > for the faint-hearted) dealilng
> > > with this (IMHO) interesting topic look @ this year's infocom
> > > 'Hop-by-Hop Routing with Node-Dependent Topology Information'
> > >
> > >
> > >       thanks
> > >
> > >       -- tony
> > >
> > >
> > > >
> > > > Never mind,
> > > > Roseanna Roseannadanna
> > > >
> > > > At 03:51 PM 10/26/99 -0700, Tony Li wrote:
> > > > >
> > > > >|  Earlier, I pointed out what I though was a problem with
> > > the 24-bit
> > > > metrics,
> > > > >|  namely, that MAX_PATH_METRIC increased from 1024 to a
> > > much larger value.
> > > > >|
> > > > >|  If you are running traffic engineering metrics in
> > > parallel with existing
> > > > >|  TLVs, which value for MAX_PATH_METRIC should be used?
> > > Must all routers
> > > > >|  in the subdomain support the new TLVs before they are
> > > used at all,
> > > > >|  to avoid routing loops that would occur if some paths
> > > exceed the smaller
> > > > >|  MAX_PATH_METRIC?
> > > > >
> > > > >
> > > > >Would inconsistent MAX_PATH_METRICs lead to forwarding
> > > loops?  Or to
> > > > >blackholes?
> > > > >
> > > > >In any case, if you're going to run with both metrics,
> > > then in normal
> > > > >operations, the metric would have to be smaller than 1024.
> > >  If it were to
> > > > >exceed this, presumably due to an outage, then newer
> > > systems might find a
> > > > >path while older systems didn't.  This would seem like
> a blackhole.
> > > > >
> > > > >And of course, if everything is a new system, you have a
> > > valid path.
> > > > >
> > > > >I'm not sure I see the problem.
> > > > >
> > > > >Tony
> > > > >
> > > > >
> > > >
> ____________________________________________________________________
> > > >
> > > >   Jeff Learman                           Internet:    
> jjl@one.com
> > > >   Engineering Manager                    Voice:    
> (734)-975-7323
> > > >   ONE (Open Networks Engineering, Inc)   Fax:      
> (734)-975-6940
> > > >   2725 South Industrial Pkwy, Suite 100
> > > >   Ann Arbor, MI  48104  USA
> > > >
> ____________________________________________________________________
> > > >
> > > > _______________________________________________
> > > > Isis-wg mailing list  -  Isis-wg@external.juniper.net
> > > > http://external.juniper.net/mailman/listinfo/isis-wg
> > >
>

------_=_NextPart_001_01BF219A.3AECE6AC-- From tli@procket.com Thu, 28 Oct 1999 17:22:02 -0700 Date: Thu, 28 Oct 1999 17:22:02 -0700 From: Tony Li tli@procket.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt | So how do you fix the loop? It seems you must limit the metrics | to 63 until you have upgraded all routers. I'd think that it would be somewhat unreasonable to use metrics > 63 in a hybrid environment anyhow. While I appreciate the attention to detail, please recall that the intent of this mechanism is to provide a migration path. Tony From dwfedyk@nortelnetworks.com Fri, 29 Oct 1999 17:12:16 -0500 Date: Fri, 29 Oct 1999 17:12:16 -0500 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] FW: Ccomments on Draft "Metrics and Resource Classes for TE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF225A.ADDA4B4E Content-Type: text/plain; charset="iso-8859-1" Resent to lists. ---- Alex > -----Original Message----- > From: Alex Zinin [mailto:zinin@amt.ru] > Sent: Thursday, October 28, 1999 2:09 PM > To: Fedyk, Don [BL3:2001-I:EXCH] > Cc: te-wg@UU.NET; isis-wg@external.juniper.net > Subject: RE: Ccomments on Draft "Metrics and Resource Classes for TE" > > > Don, > > At 14:17 27.10.99 -0500, Don Fedyk wrote: > >Alex > > > >> > >> >3.1 Multiple traffic engineering (TE) metrics > >> > > >> ... > >> > In such systems the metric type chosen is a guide to generating > >> > paths and will attempt to minimize the metric subject > to the other > >> > constraints. There is little overhead for advertising multiple > >> > metrics for traffic engineering since only the static > metrics need > >> > to be propagated. > >> > >> Why only the static metrics? What about available bandwidth that > >> changes dynamically as more LSPs are established? > > > >It is true that bandwidth allocation is broadcast in the form of > >available bandwidth to allocate at a priority, but this is > >dynamic addition of static numbers. What I am trying to say is > >it is not related to the dynamic utilization number. I can > >lay down a path for 2 Meg and only use it 1 day of the week > >but I want it to be there for me when I use it. > > > > I may be missing something, but what is the purpose of establishing > an LSP along a path with some BW value if this value is not guaranteed > to be up to date? > Example---you have two alternate paths---one with BW of 1.5M > and another with BW of 2Ms. You need to establish say 5 LSPs > and the constraint is max BW. If LSPs are established incrementally, > you will have all of them traversing the 2M path, because there > is no info on how much BW has left unreserved/unprovisioned. > On the other side I would understand static Delay attribute calculated > in inverse proportion to the BW, but it's not BW itself. > Am I really missing something ? > When you have an accurate bandwidth profile or traffic profile it does not add value to maximize bandwidth, as you point out, you really want to minimize something else like delay or perhaps hops or cost. The allocation takes care of the bandwidth part. If you do not have bandwidth profile (or the amount is small) you may want to use another criteria to mimimize or a constraint, that does attempt to satisfy the your criteria. Both scenarios are possible. In some amount of time, the link allocation information is distributed (either by the IGP or by the feedback mechanisms we are proposing.) So if we go to the originating node, the minimized metric has not changed but perhaps now you are laying LSPs on the one path and you have another path that is equal. As the designer of a path selection algorithm you may choose to make it more or less elaborate. The choice is one of load sharing versus leaving bandwidth for large connections. It also depends on how fast you lay down LSPs. Under failure conditions elabortate algorithms may not be accurate. Under long term conditions offline traffic engineering may prove more fruitful. As far as the LSP goes the bandwidth allocation numbers should be accurate in the long run if the traffic class competes for scheduling resources. Best effort LSPs do not (well they are on the lowest runge anyways) . This is no different than ATM where a service class results in a connection admission of a certain BW size. There are several drafts that talk about changing LSP reservation to match the actual or even setting up a new path and hot swapping. All these things make the world more dynamic and accurate. > >Simply we feel there is a need for multiple metrics, if some > of these > >are dynamic in the future that is not precluded. > > > >> > >> > 4.3 Standardizing resource classes > >> > > >> > It is worthwhile to explore the demand for > standardized resource > >> > masks. This will allow requests to propagate seamlessly across > >> > areas since the semantics of the bits will have a > universal value. > >> ... > >> > >> > Bits 0-15: Global use > >> > > >> > Bit 0: satellite > >> > Bit 1: terrestrial > >> > Bit 2: highest reliability > >> > Bit 3: high reliability > >> > Bit 4: medium reliability > >> > Bit 5: low reliability > >> > Bits 6-15: reserved > >> > > >> > Bits 16-32: Local use > >> > >> I believe you're talking about the RsCls field in LDP's 0x822 TLV. > >Yes we should refer to the document, good point. > > > >> My opinion is that specific bits should not be assigned to specific > >> colors/characteristics, instead the bit semantics should be > >> starndardized. If the semantics is clear, it doesn't really matter > >> which attribute each bit reflects and the priveledge of meaning > >> assignment should be left to the admin ([s]he may not care about > >> the reliability at all if all links are equally reliable, etc.) > >> Draft "draft-ietf-mpls-cr-ldp-03.txt" does not explicitly > specify how > >> the mask should be used. It may be advantegous to introduce > >> sub-TLVs in the ResCls-TLV, each containing a kind of op-code > >> (exact mask match, any bit match, speficied bits cleared, etc.) > > > >We agree and that is why we took a stab standardizing it. > >In general we saw many operations but the simple & and compare > >operation seemed most workable. > >If you don't have an agreement on bits, you can have two networks > >join with different bits meanings and you cannot interwork them. > >Several of our customers have joined two networks that started out > >as separate administrative networks. How do you change the bits > >once set? > > > >I like your op-code idea, we just didn't think it was simple > >enough to standardize. > > I understand your concern about different bit assignment, but > what worries me is that we have only 32bits for the color mask and > the document proposes to define a static meaning to some of > them. One could foresee problems in the nearest future or > in some already installed networks. For example, in a pure > ATM-based network utilizing say well-designed SDH links, > all bits 0 through 5 lose their purpose. We also do not and > cannot know which classes are gonna be needed in the future. > > Another concern is how these bits are used----e.g. bits 0 and 1 > are mutually exclusive, so we basically need only one to > indicate the state of Satellite/Terrestrial link attribute. > The level of reliability, in turn, can easily be coded in 3 bits > instead of 5 (I remember the concerns on checking and > standardization). > > Now imagine that another draft appears trying to assign > static meaning to bits 6--15 and then some customers > appear that need globally significant bits with absolutely > different meaning....What do you do ? > You may think of a method of mapping different bit > schemes to each other, maybe.... > > These are just thoughts yet... Points taken. Don > > > > >Thanks, > >Don > > > ------------------------------------------------------------------ > Alex D. Zinin, Consultant > CCSI #98966 > CCIE #4015 > > ------_=_NextPart_001_01BF225A.ADDA4B4E Content-Type: text/html; charset="iso-8859-1" FW: Ccomments on Draft "Metrics and Resource Classes for TE"

Resent to lists.
----
Alex

> -----Original Message-----
> From: Alex Zinin [mailto:zinin@amt.ru]
> Sent: Thursday, October 28, 1999 2:09 PM
> To: Fedyk, Don [BL3:2001-I:EXCH]
> Cc: te-wg@UU.NET; isis-wg@external.juniper.net
> Subject: RE: Ccomments on Draft "Metrics and Resource Classes for TE"
>
>
> Don,
>
> At 14:17 27.10.99 -0500, Don Fedyk wrote:
> >Alex
> >
> >>
> >> >3.1 Multiple traffic engineering (TE) metrics
> >> >
> >>  ...
> >> >   In such systems the metric type chosen is a guide to generating
> >> >   paths and will attempt to minimize the metric subject
> to the other
> >> >   constraints. There is little overhead for advertising multiple
> >> >   metrics for traffic engineering since only the static
> metrics need
> >> >   to be propagated.
> >>
> >> Why only the static metrics? What about available bandwidth that
> >> changes dynamically as more LSPs are established?
> >
> >It is true that bandwidth allocation is broadcast in the form of
> >available bandwidth to allocate at a priority, but this is
> >dynamic addition of static numbers.  What I am trying to say is
> >it is not related to the dynamic utilization number. I can
> >lay down a path for 2 Meg and only use it 1 day of the week
> >but I want it to be there for me when I use it.
> >
>
> I may be missing something, but what is the purpose of establishing
> an LSP along a path with some BW value if this value is not guaranteed
> to be up to date?
> Example---you have two alternate paths---one with BW of 1.5M
> and another with BW of 2Ms. You need to establish say 5 LSPs
> and the constraint is max BW. If LSPs are established incrementally,
> you will have all of them traversing the 2M path, because there
> is no info on how much BW has left unreserved/unprovisioned.
> On the other side I would understand static Delay attribute calculated
> in inverse proportion to the BW, but it's not BW itself.
> Am I really missing something ?
>
When you have an accurate bandwidth profile or traffic profile it does
not add value to maximize bandwidth, as you point out, you really
want to minimize something else like delay or perhaps hops or cost.
The allocation takes care of the bandwidth part. If you do not
have bandwidth profile (or the amount is small) you may want to
use another criteria to mimimize or a constraint, that does
attempt to satisfy the your criteria. Both scenarios are possible.
In some amount of time, the link allocation information
is distributed (either by the IGP or by the feedback mechanisms
we are proposing.)

So if we go to the originating node, the minimized metric has
not changed but perhaps now you are laying LSPs on the one
path and you have another path that is equal. As the designer
of a path selection algorithm you may choose to make it more
or less elaborate. The choice is one of load sharing versus
leaving bandwidth for large connections. It also depends on how
fast you lay down LSPs. Under failure conditions elabortate
algorithms may not be accurate. Under long term conditions
offline traffic engineering may prove more fruitful.

As far as the LSP goes the bandwidth allocation numbers should
be accurate in the long run if the traffic class competes for
scheduling resources.  Best effort LSPs do not (well they are on
the lowest runge anyways) . This is no different than
ATM where a service class results in a connection admission
 of a certain BW size.  There are several drafts that
talk about changing LSP reservation to match the actual
or even setting up a new path and hot swapping. All these
things make the world more dynamic and accurate.

> >Simply we feel there is a need for multiple metrics, if some
> of these
> >are dynamic in the future that is not precluded.
> >
> >>
> >> >   4.3 Standardizing resource classes
> >> >
> >> >   It is worthwhile to explore the demand for
> standardized resource
> >> >   masks.  This will allow requests to propagate seamlessly across
> >> >   areas since the semantics of the bits will have a
> universal value.
> >> ...
> >>
> >> >   Bits 0-15: Global use
> >> >
> >> >   Bit 0: satellite
> >> >   Bit 1: terrestrial
> >> >   Bit 2: highest reliability
> >> >   Bit 3: high reliability
> >> >   Bit 4: medium reliability
> >> >   Bit 5: low reliability
> >> >   Bits 6-15: reserved
> >> >
> >> >   Bits 16-32: Local use
> >>
> >> I believe you're talking about the RsCls field in LDP's 0x822 TLV.
> >Yes we should refer to the document, good point.
> >
> >> My opinion is that specific bits should not be assigned to specific
> >> colors/characteristics, instead the bit semantics should be
> >> starndardized. If the semantics is clear, it doesn't really matter
> >> which attribute each bit reflects and the priveledge of meaning
> >> assignment should be left to the admin ([s]he may not care about
> >> the reliability at all if all links are equally reliable, etc.)
> >> Draft "draft-ietf-mpls-cr-ldp-03.txt" does not explicitly
> specify how
> >> the mask should be used. It may be advantegous to introduce
> >> sub-TLVs in the ResCls-TLV, each containing a kind of op-code
> >> (exact mask match, any bit match, speficied bits cleared, etc.)
> >
> >We agree and that is why we took a stab standardizing it.
> >In general we saw many operations but the simple & and compare
> >operation seemed most workable.
> >If you don't have an agreement on bits, you can have two networks
> >join with different bits meanings and you cannot interwork them.
> >Several of our customers have joined two networks that started out
> >as separate administrative networks. How do you change the bits
> >once set?
> >
> >I like your op-code idea, we just didn't think it was simple
> >enough to standardize.
>
> I understand your concern about different bit assignment, but
> what worries me is that we have only 32bits for the color mask and
> the document proposes to define a static meaning to some of
> them. One could foresee problems in the nearest future or
> in some already installed networks. For example, in a pure
> ATM-based network utilizing say well-designed SDH links,
> all bits 0 through 5 lose their purpose. We also do not and
> cannot know which classes are gonna be needed in the future.
>
> Another concern is how these bits are used----e.g. bits 0 and 1
> are mutually exclusive, so we basically need only one to
> indicate the state of Satellite/Terrestrial link attribute.
> The level of reliability, in turn, can easily be coded in 3 bits
> instead of 5 (I remember the concerns on checking and
> standardization).
>
> Now imagine that another draft appears trying to assign
> static meaning to bits 6--15 and then some customers
> appear that need globally significant bits with absolutely
> different meaning....What do you do ?
> You may think of a method of mapping different bit
> schemes to each other, maybe....
>
> These are just thoughts yet...

Points taken.

Don
>
> >
> >Thanks,
> >Don
> >
> ------------------------------------------------------------------
> Alex D. Zinin, Consultant
> CCSI #98966
> CCIE #4015
>
>

------_=_NextPart_001_01BF225A.ADDA4B4E-- From tli@procket.com Fri, 5 Nov 1999 00:49:59 -0800 Date: Fri, 5 Nov 1999 00:49:59 -0800 From: Tony Li tli@procket.com Subject: [Isis-wg] Proposed agenda This is the proposed agenda for DC: - Agenda bashing - Document review - Update on IS-IS over IP (prz) - Update on IS-IS w/ >255 interfaces (prz) - Keyed MD5 (rja) - Multiple TE metrics (Don Fedyk) From tli@procket.com Fri, 5 Nov 1999 14:25:34 -0800 Date: Fri, 5 Nov 1999 14:25:34 -0800 From: Tony Li tli@procket.com Subject: [Isis-wg] Proposed agenda | > This is the proposed agenda for DC: | > | > - Agenda bashing | > - Document review | > - Update on IS-IS over IP (prz) | > - Update on IS-IS w/ >255 interfaces (prz) | > - Keyed MD5 (rja) | > - Multiple TE metrics (Don Fedyk) | > | | any slot for the new, new version of | L1/L2 draft updated by Henk ? Henk did not request one. If Henk would like to do so, well... he knows the mail address. ;-) Tony From chopps@merit.edu 15 Nov 1999 04:05:45 -0500 Date: 15 Nov 1999 04:05:45 -0500 From: Christian E. Hopps chopps@merit.edu Subject: [Isis-wg] Re: internet-drafts/draft-ietf-isis-wg-255adj-02.txt Radia Perlman - Boston Center for Networking writes: > It is possible to be DIS on more than 255 LANs provided that a 7-byte > pseudonode ID, unique in the area, can be selected. The IS-IS > specification states that the DIS's system ID is the first 6 bytes of > the pseudonode ID. However, the only property of the 7-byte Pnode ID > necessary for correct operation of the routing algorithm is that > the 7-byte ID be unique in the area. A couple small points: There are specific checks against the system ID when processing a received LSP (to determine if its self-originated). So your proposed text should probably point out that these need to be expanded to check against any possible value that might be generated for the 6-byte prefix. It seems to me that there is nothing in the standard that requires System ID's to be MAC addresses. Therefore how can you know that another system's System ID won't be one of your MAC addresses? At least 2 implementations I know of let the user set the system ID to whatever they choose. (And yes, I do think this would be rare in any case). Again these are small points. I like the idea of using MAC addresses. I think the first case can be handled with some additional text. The second case can probably be handled by requiring a run-time configuration variable. That way if, for some bizarre reason, there is a namespace collision at least the user asked for it :) Chris. From Radia.Perlman@east.sun.com Mon, 15 Nov 1999 14:07:28 -0500 (EST) Date: Mon, 15 Nov 1999 14:07:28 -0500 (EST) From: Radia Perlman - Boston Center for Networking Radia.Perlman@east.sun.com Subject: [Isis-wg] Re: internet-drafts/draft-ietf-isis-wg-255adj-02.txt From: chopps@merit.edu (Christian E. Hopps) There are specific checks against the system ID when processing a received LSP (to determine if its self-originated). So your proposed text should probably point out that these need to be expanded to check against any possible value that might be generated for the 6-byte prefix. Agreed. It seems to me that there is nothing in the standard that requires System ID's to be MAC addresses. Therefore how can you know that another system's System ID won't be one of your MAC addresses? At least 2 implementations I know of let the user set the system ID to whatever they choose. (And yes, I do think this would be rare in any case). I hope when they do this that they clear the "global/local" bit in what would be the OUI of the 6-byte quantity. Then, if you use a globally assigned MAC address you're guaranteed not to conflict. It might be nice to require anyone NOT using a MAC address to make it look like a locally assigned MAC address. Radia From jameshe@cabletron.com Wed, 17 Nov 1999 14:41:22 -0500 Date: Wed, 17 Nov 1999 14:41:22 -0500 From: He, James jameshe@cabletron.com Subject: [Isis-wg] integrated is-is question To IS-IS fellows: I was reading the book "CCIE Professional Development: Routing TCP/IP, Volume 1" by Jeff Doyle from ciscopress. In the Integrated IS-IS chapter, there is an example which discusses IS-IS adjacency issues. The following is the illustration from the book: There are six L1/L2 routers in two areas, area1 and area2, and we assume area2 is a level 2 area (IS-IS backbone). The illustration is as follows: Subnet1--------R1---------------Subnet2-------------R2------------Subnet3 | | | | R3 R4 | | |--------------------------------------------------------------------------- | | | R5 | | Subnet4-------------R6------------Subnet5 The top section which consists of R1-R2-R3-R4 is area1 and the lower section which has R5-R6 constitutes area2. All routers are L1/L2 routers (the default configguration in cisco routers). On page 655 of the book, it says that R6 will form level 1 adjacency with R5 as R5 is the only router in area2. However, R6 will form level 2 adjacency with every other router including R1 to R4. Is this statement true? R6 is not physically connected to R1 or R2. How can it form level 2 adjacenct to them. Why can't R6 be level 1 adjacenct to R1 if we adopt the same logic. Many thanks in advance. Please forward answer to jameshe@ctron.com. James He From hsmit@cisco.com Wed, 17 Nov 1999 21:45:19 +0100 (MET) Date: Wed, 17 Nov 1999 21:45:19 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] integrated is-is question > To IS-IS fellows: > > I was reading the book "CCIE Professional Development: Routing TCP/IP, > Volume 1" by Jeff Doyle from ciscopress. Maybe ask the author ? > In the Integrated IS-IS chapter, there is an example which discusses IS-IS > adjacency issues. > The following is the illustration from the book: > > There are six L1/L2 routers in two areas, area1 and area2, and we assume > area2 is a level 2 area (IS-IS backbone). I don't think that sentence is correct. Areas are level-1 thingies. Level-2 is the backbone, and consists of "Level-2 capable routers". All routers have an area-address, and thus all routers are part of a level-1 area. The algorithms (SPF and flooding) that are used in Level-2 are very similar to what is used in Level-1. Therefor we can sometimes talk about "the level-2 backbone area". That would refer to the set of "level-2 capable routers". But you can not say that one R1, R2, R3 and R4 are in one area, and say that R5 and R6 are in another area, and call that area the "level-2 area". Hope I could explain this to you. > The illustration is as follows: > > > > Subnet1--------R1---------------Subnet2-------------R2------------Subnet3 > | | > | | > R3 R4 > | | > > |--------------------------------------------------------------------------- > | > | > | > R5 > | > | > Subnet4-------------R6------------Subnet5 > > > > The top section which consists of R1-R2-R3-R4 is area1 and the lower section > which has R5-R6 constitutes area2. > All routers are L1/L2 routers (the default configguration in cisco routers). In this case, all 6 routers take part in Level-2 routing, and thus the "backbone" or "level-2 area" consists of all 6 routers. > On page 655 of the book, it says that R6 will form level 1 adjacency with > R5 as R5 is the only router in area2. > However, R6 will form level 2 adjacency with every other router including R1 > to R4. > > Is this statement true? No. > R6 is not physically connected to R1 or R2. How can > it form level 2 adjacenct to them. Exactly. Only directly connected routers can form adjacencies. > Why can't R6 be level 1 adjacenct to R1 if we adopt the same logic. Well, R1 and R6 are in different areas. They are configured to be in different areas. So they will never form a level-1 adjacency. Routers are only allowed to form level-1 adjacencies when they have at least one configured area-address in common. So in the above picture, these adjacencies are formed: R1 R2 R3 R4 R5 R6 R1 - L1L2 L1L2 - - - R2 L1L2 - - L1L2 - - R3 L1L2 - - L1L2 L2 - R4 - L1L2 L1L2 - L2 - R5 - - L2 L2 - L1L2 R6 - - - - L1L2 - For a good design, if the above picture would be the full network, it would probably make sense to configure R1, R2 and R6 to be level-1-only routers. Hope this helps, Henk. > Many thanks in advance. Please forward answer to jameshe@ctron.com. > > > James He > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mshand@cisco.com Wed, 17 Nov 1999 20:49:59 +0000 Date: Wed, 17 Nov 1999 20:49:59 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] integrated is-is question Looks wrong to me. Adjacencies must be adjacent! Is there some other context which makes this situation odd? Its not talking about who it shares LSPs with is it? Mike At 14:41 17/11/1999 -0500, He, James wrote: >To IS-IS fellows: > >I was reading the book "CCIE Professional Development: Routing TCP/IP, >Volume 1" by Jeff Doyle from ciscopress. >In the Integrated IS-IS chapter, there is an example which discusses IS-IS >adjacency issues. >The following is the illustration from the book: > >There are six L1/L2 routers in two areas, area1 and area2, and we assume >area2 is a level 2 area (IS-IS backbone). >The illustration is as follows: > > > >Subnet1--------R1---------------Subnet2-------------R2------------Subnet3 > | | > | | > R3 R4 > | | > >|--------------------------------------------------------------------------- >| > | > | > R5 > | > | > Subnet4-------------R6------------Subnet5 > > > >The top section which consists of R1-R2-R3-R4 is area1 and the lower section >which has R5-R6 constitutes area2. >All routers are L1/L2 routers (the default configguration in cisco routers). > >On page 655 of the book, it says that R6 will form level 1 adjacency with >R5 as R5 is the only router in area2. >However, R6 will form level 2 adjacency with every other router including R1 >to R4. > >Is this statement true? R6 is not physically connected to R1 or R2. How can >it form level 2 adjacenct to them. >Why can't R6 be level 1 adjacenct to R1 if we adopt the same logic. > > >Many thanks in advance. Please forward answer to jameshe@ctron.com. > > >James He > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From tli@procket.com Wed, 17 Nov 1999 14:47:44 -0800 Date: Wed, 17 Nov 1999 14:47:44 -0800 From: Tony Li tli@procket.com Subject: [Isis-wg] Re: internet-drafts/draft-ietf-isis-wg-255adj-02.txt | It seems to me that there is nothing in the standard that requires | System ID's to be MAC addresses. Therefore how can you know that | another system's System ID won't be one of your MAC addresses? At least | 2 implementations I know of let the user set the system ID to whatever | they choose. (And yes, I do think this would be rare in any case). The spec requires that the manager insure that the system id is unique within a L1 area for L1 systems and unique within L2 for L2 systems. Frankly, I think that this is overly liberal and the sysadmin should simply insure uniqueness domain-wide. You are correct. Mapping the MAC address is convenient, but is not a requirement. Tony From chopps@merit.edu 17 Nov 1999 22:09:13 -0500 Date: 17 Nov 1999 22:09:13 -0500 From: Christian E. Hopps chopps@merit.edu Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt Henk Smit writes: > If you want to mark an IP prefix as external, we can do it via sub-TLVs. > My collegues Naiming Shen has been working on tagging/coloring IP > prefixes. Similar to OSPF tags or BGP communities. Maybe we can > introduce some "well known" tags, to indicate that some prefixes > were redistributed from outside into ISIS. What about support of incomparable metrics (i.e, ospf's type 2 metric). The idea being you import the metric form the other protocol into the `external' metric and it takes precedence over the IGP metric (which is used to break ties). You can add this as a new sub-TLV in another draft; however, then you run into transition issues. Routing loops are easy to come by if you give the external metric precendence in the SPF and then some router ignores that sub-tlv. By defining this in the main draft you at least eliminate trying to transition twice. Since I don't have a lot of operational experience I'd like to ask: is an incomparable external metric perceived as a gratuitous addition? I was under the impression that it was used just about anytime you wanted to import an EGP (or some aggregates of the EGP) into the IGP. Thanks, Chris. From rsaluja@BayNetworks.COM Thu, 18 Nov 1999 09:29:47 -0500 Date: Thu, 18 Nov 1999 09:29:47 -0500 From: Rajesh Saluja rsaluja@BayNetworks.COM Subject: [Isis-wg] Support of "IP External Reachability Information" TLV in L1 LSP Based on few mails exchanged in the last month ( related to domain-wide prefix distribution draft ), I understand that though RFC 1195 prohibits "IP External Reachability Information" TLV in L1 LSPs but in the REAL WORLD, this TLV is used in L1 LSPs. If there are two vendor implementations in L1 area, one which supports this and one which is strictly RFC 1195 compliant, it may cause routing loops in presence of external routes. In my opinion, this is an interoperability issue ( even if domain wide prefix distribution is not implemented ) and if would be desirable to document this somewhere in the main specification. I will appreciate your comments. Thanks, Rajesh From hsmit@cisco.com Thu, 18 Nov 1999 16:52:43 +0100 (MET) Date: Thu, 18 Nov 1999 16:52:43 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] Support of "IP External Reachability Information" TLV in L1 LSP I tried to document this issue in the new version of draft-ietf-isis-domain-wide-02.txt. 3.2 Definition of external IP prefixes in level 1 LSPs RFC 1195 does not define the "IP External Reachability Information" TLV for L1 LSPs. However, there is no reason why an IS-IS implementation could not allow for redistribution of external routes into L1. Some IS-IS implementations already allow network administrators to do this. This document loosens the restrictions in RFC 1195, and allows for the inclusion of the "IP External Reachability Information" TLV in L1 LSPs. I did not include any explanation that if you mix the two implementations in one L1 area, you can get routing loops. This seems a trivial observation to me. Including all examples of things that can cause routing loops would make any document unreadable, IMHO. I have not submitted the new version of the draft yet, but I did send it to this list just before the IETF in DC. I did not receive any comments, so I assume I can submit the draft as it is ? I do have one issue myself I'd like to discuss. But I'd like to hear other people's comments first before I bring it up. Just for clarity, I have attached the draft again. Thanks, Henk. > Based on few mails exchanged in the last month ( related to domain-wide > prefix distribution draft ), I understand that though RFC 1195 prohibits > > "IP External Reachability Information" TLV in L1 LSPs but in the REAL > WORLD, this TLV is used in L1 LSPs. If there are two vendor > implementations > in L1 area, one which supports this and one which is strictly RFC 1195 > compliant, > it may cause routing loops in presence of external routes. In my > opinion, this is > an interoperability issue ( even if domain wide prefix distribution is > not > implemented ) and if would be desirable to document this somewhere in > the main specification. > I will appreciate your comments. > > Thanks, > Rajesh ---- Network Working Group Tony Li INTERNET DRAFT Procket Networks Tony Przygienda Siara Systems Henk Smit Cisco Systems October 1999 Domain-wide Prefix Distribution with Two-Level IS-IS Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1.0 Abstract This document describes extensions to the IS-IS protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589 [1], with extensions for supporting IPv4 specified in RFC 1195 [2]. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. 2.0 Introduction An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) can be partitioned into multiple level 1 (L1) areas, and a level 2 (L2) connected subset of the topology that interconnects all of the L1 areas. Within each L1 area, all routers exchange link state information. L2 routers also exchange L2 link state information to compute routes between areas. RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that are used to transport IPv4 routing information in IS-IS. RFC 1195 also specifies the semantics and procedures for interactions between levels. Specifically, routers in a L1 area will exchange information within the L1 area. For IP destinations not found in the prefixes in the L1 database, the L1 router should forward packets to the nearest router that is in both L1 and L2 (i.e., an L1L2 router) with the "attached bit" set in its L1 Link State Protocol Data Unit (LSP). Also per RFC 1195, an L1L2 router should be manually configured with a set of prefixes that summarizes the IP prefixes reachable in that L1 area. These summaries are injected into L2. RFC 1195 specifies no further interactions between L1 and L2 for IPv4 prefixes. 2.1 Motivations for domain-wide prefix distribution The mechanisms specified in RFC 1195 are appropriate in many situations, and lead to excellent scalability properties. However, in certain circumstances, the domain administrator may wish to sacrifice some amount of scalability and distribute more specific information than is described by RFC 1195. This section discusses the various reasons why the domain administrator may wish to make such a tradeoff. One major reason for distributing more prefix information is to improve the quality of the resulting routes. A well know property of prefix summarization or any abstraction mechanism is that it necessarily results in a loss of information. This loss of information in turn results in the computation of a route based upon less information, which will frequently result in routes that are not optimal. A simple example can serve to demonstrate this adequately. Suppose that a L1 area has two L1L2 routers that both advertise a single summary of all prefixes within the L1 area. To reach a destination inside the L1 area, any other L2 router is going to compute the shortest path to one of the two L1L2 routers for that area. Suppose, for example, that both of the L1L2 routers are equidistant from the L2 source, and that the L2 source arbitrarily selects one L1L2 router. This router may not be the optimal router when viewed from the L1 topology. In fact, it may be the case that the path from the selected L1L2 router to the destination router may traverse the L1L2 router that was not selected. If more detailed topological information or more detailed metric information was available to the L2 source router, it could make a more optimal route computation. This situation is symmetric in that an L1 router has no information about prefixes in L2 or within a different L1 area. In using the nearest L1L2 router, that L1L2 is effectively injecting a default route without metric information into the L1 area. The route computation that the L1 router performs is similarly suboptimal. Besides the optimality of the routes computed, there are two other significant drivers for the domain wide distribution of prefix information. When a router learns multiple possible paths to external destinations via BGP, it will select only one of those routes to be installed in the forwarding table. One of the factors in the BGP route selection is the IGP cost to the BGP next hop address. Many ISP networks depend on this technique, which is known as "shortest exit routing". If a L1 router does not know the exact IGP metric to all BGP speakers in other L1 areas, it cannot do effective shortest exit routing. The third driver is the current practice of using the IGP (IS-IS) metric as part of the BGP Multi-Exit Discriminator (MED). The value in the MED is advertised to other domains and is used to inform other domains of the optimal entry point into the current domain. Current practice is to take the IS-IS metric and insert it as the MED value. This tends to cause external traffic to enter the domain at the point closest to the exit router. Note that the receiving domain may, based upon policy, choose to ignore the MED that is advertised. However, current practice is to distribute the IGP metric in this way in order to optimize routing wherever possible. This is possible in current networks that only are a single area, but becomes problematic if hierarchy is to be installed into the network. This is again because the loss of end-to-end metric information means that the MED value will not reflect the true distance across the advertising domain. Full distribution of prefix information within the domain would alleviate this problem as it would allow accurate computation of the IS-IS metric across the domain, resulting in an accurate value presented in the MED. 2.2 Scalability The disadvantage to performing the domain-wide prefix distribution described above is that it has an impact to the scalability of IS-IS. Areas within IS-IS help scalability in that LSPs are contained within a single area. This limits the size of the link state database, that in turn limits the complexity of the shortest path computation. Further, the summarization of the prefix information aids scalability in that the abstraction of the prefix information removes the sheer number of data items to be transported and the number of routes to be computed. It should be noted quite strongly that the distribution of prefixes on a domain wide basis impacts the scalability of IS-IS in the second respect. It will increase the number of prefixes throughout the domain. This will result in increased memory consumption, transmission requirements and computation requirements throughout the domain. It must also be noted that the domain-wide distribution of prefixes has no effect whatsoever on the first aspect of scalability, namely the existence of areas and the limitation of the distribution of the link state database. Thus, the net result is that the introduction of domain-wide prefix distribution into a formerly flat, single area network is a clear benefit to the scalability of that network. However, it is a compromise and does not provide the maximum scalability available with IS-IS. Domains that choose to make use of this facility should be aware of the tradeoff that they are making between scalability and optimality and provision and monitor their networks accordingly. Normal provisioning guidelines that would apply to a fully hierarchical deployment of IS-IS will not apply to this type of configuration. 3.0 Proposed syntax and semantics for L2->L1 inter-area routes This document defines the syntax of how to advertise level 2 routes in level 1 LSPs. The encoding is an extension of the encoding in RFC 1195. To some extent, in IS-IS the level 2 backbone can be seen as a separate area itself. RFC 1195 defines that L1L2 routers can advertise IP routes that were learned via L1 routing into L2. These routes can be regarded as inter-area routes. RFC 1195 defines that these L1->L2 inter-area routes must be advertised in L2 LSPs in the "IP Internal Reachability Information" TLV (TLV 128). Intra-area L2 routes are also advertised in L2 LSPs in an "IP Internal Reachability Information" TLV. Therefor L1->L2 inter-area routes are indistinguishable from L2 intra-area routes. RFC 1195 does not define L2->L1 inter-area routes. A simple extension would be to allow a L1L2 router to advertise routes learned via L2 routing in its L1 LSP. However, to prevent routing-loops, L1L2 routers must never advertise L2->L1 inter-area routes that they learn via L1 routing, back into L2. Therefor there must be a way to distinguish L2->L1 inter-area routes from L1 intra-area routes. Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for this purpose. RFC 1195 defines TLVs 128 and 130 to contain IP routes. TVLs 128 and 130 have a metric field that consists of 4 TOS metrics. The first metric, the so-called "default metric", has the high-order bit reserved (bit 8). Routers must set this bit to zero on transmission, and ignore it on receipt. This document redefines this high-order bit in the default metric field in TLVs 128 and 130 to be the up/down bit. L1L2 routers must set this bit to one for prefixes that are derived from L2 routing and are advertised into L1 LSPs. The bit must be set to zero for all other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down bit set that are learned via L1 routing, must never be advertised by L1L2 routers back into L2. 3.1 Clarification of external route-type and external metric-type RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is defined as "IP Internal Reachability Information", and should be used to carry IP prefixes that are directly connected to IS-IS routers. TLV 130 is defined as "IP External Reachability Information", and should be used to carry routes learned from outside the IS-IS domain. RFC 1195 documents TLV type 130 only for level 2 LSPs. RFC 1195 also defines two types of metrics. Metrics of the internal metric-type should be used when the metric is comparable to metrics used to weigh links inside the ISIS domain. Metrics of the external metric-type should be used if the metric of an IP prefix cannot be directly compared to internal metrics. External metric-type can only be used for external IP prefixes. A direct result is that metrics of external metric-type should never be seen in TLV 128. To prevent confusion, this document states again that when a router computes IP routes, it must give the same preference to IP routes advertised in an "IP Internal Reachability Information" TLV and IP routes advertised in an "IP External Reachability Information" TLV. RFC 1195 states this quite clearly in the note in paragraph 3.10.2, item 2c). This document does not alter this rule of preference. NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field), and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation. However, IP routes advertised in "IP External Reachability Information" with external metric-type must be given less preference than the same IP routes advertised with internal-metric type, regardless of the value of the metrics. While IS-IS routers must not give different preference to IP prefixes learned via "IP Internal Reachability Information" and "IP External Reachability Information" when executing the Dijkstra calculation, routers that implement multiple IGPs are free to use this distinction between internal and external routes when comparing routes derived from different IGPs for inclusion in their global RIB. 3.2 Definition of external IP prefixes in level 1 LSPs RFC 1195 does not define the "IP External Reachability Information" TLV for L1 LSPs. However, there is no reason why an IS-IS implementation could not allow for redistribution of external routes into L1. Some IS-IS implementations already allow network administrators to do this. This document loosens the restrictions in RFC 1195, and allows for the inclusion of the "IP External Reachability Information" TLV in L1 LSPs. RFC 1195 defines that IP routes learned via L1 routing must always be advertised in L2 LSPs in a "IP Internal Reachability Information" TLV. Now that this document allows "IP External Reachability Information" TLVs in L1 LSPs, and allows for the advertisement of routes learned via L2 routing into L1, the above rule needs a extensions. When a L1L2 router advertises a L1 route into L2, where that L1 route was learned via a prefix advertised in a "IP External Reachability Information" TLV, that L1L2 router should advertise that prefix in its L2 LSP within an "IP External Reachability Information" TLV. L1 routes learned via an "IP Internal Reachability Information" TLV should still be advertised within a "IP Internal Reachability Information" TLV. These rules should also be applied when advertising IP routes derived from L2 routing into L1. Of course in this case also the up/down bit must be set. RFC 1195 defines that if a router sees the same external prefix advertised by two or more routers with the same external metric, it must select the route that is advertised by the router that is closest to itself. It should be noted that now that external routes can be advertised from L1 into L2, and vice versa, that the router that advertises an external prefix in its LSP might not be the router that originally injected this prefix into the IS-IS domain. Therefor it is less useful to advertise external routes with external metrics into other levels. 4.0 Types of IP routes in IS-IS and their order of preference RFC 1195 and this document defines several ways of advertising IP routes in IS-IS. There are four variables involved. 1) The level of the LSP in which the route is advertised. There are currently two possible values: level 1 and level 2 2) The route-type, which can be derived from the type of TLV in which the prefix is advertised. Internal routes are advertised in IP Internal Reachability Information TLVs (TLV 128), and external routes are advertised in IP External Reachability Information TLVs (TLV 130). 3) The metric-type: Internal or External. The metric-type is derived from the Internal/External metric-type bit in the metric field (bit 7). 4) The fact whether this route is leaked down in the hierarchy, and thus can not be advertised back up. This information can be derived from the newly defined up/down bit in the default metric field. 4.1 Overview of all types of IP prefixes in IS-IS Link State PDUs The combination IP Internal Reachability Information and external metric-type is not allowed. Also the up/down bit is never set in L2 LSPs. This leaves us with 8 different types of IP advertisements in IS-IS. However, there are more than 8 reasons for IP prefixes to be advertised in IS-IS. The following tables describe the types of IP prefixes and how they are encoded. 1) L1 intra-area routes These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router. 2) L1 external routes These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. 3) L2 intra-area routes These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area routes. 4) L2 external routes These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes. 5) L1->L2 inter-area routes These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 128. These prefixes can not be distinguished from L2 intra-area routes. 6) L1->L2 inter-area external routes These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130. These prefixes can not be distinguished from L2 external routes. 7) L2->L1 inter-area routes These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in TLV 128. 8) L2->L1 inter-area external routes These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in L2 LSPs in TLV 130. 9) L1 external routes with external metric These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. 10) L2 external routes with external metric These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes with external metric. 11) L1->L2 inter-area external routes with external metric These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130 with external metrics. These prefixes can not be distinguished from L2 external routes with external metric. 12) L2->L1 inter-area external routes with external metric These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is external metric. These IP prefixes are learned via L2 routing, and were derived during the L1 SPF computation from prefixes advertised in L2 LSPs in TLV 130 with external metrics. 4.2 Order of preference for all types of IP routes in IS-IS Unfortunately IS-IS cannot depend on metrics alone for route selection. Some types of routes must always preferred over others, regardless of the costs that were computed in the Dijkstra calculation. One of the reasons for this is that inter-area routes can only be advertised with a maximum metric of 63. Another reason is that this maximum value of 63 does not mean infinity (e.g. like a hop count of 16 in RIP denotes unreachable). Introducing a value for infinity cost in IS-IS inter-area routes would introduce counting- to-infinity behavior via two or more L1L2 routers, which would have a bad impact on network stability. The order of preference of IP routes in IS-IS is based on a few assumptions. - RFC 1195 defines that routes derived from L1 routing are preferred over routes derived from L2 routing. - The note in RFC 1195 paragraph 3.10.2, item 2c) defines that internal routes with internal metric-type and external prefixes with internal metric-type have the same preference. - RFC 1195 defines that external routes with internal metric-type are preferred over external routes with external metric type. - Routes derived from L2 routing are preferred over L2->L1 routes derived from L1 routing. Based on these assumptions, this document defines the following route preferences. 1) L1 intra-area routes with internal metric L1 external routes with internal metric 2) L2 intra-area routes with internal metric L2 external routes with internal metric L1->L2 inter-area routes with internal metric L1->L2 inter-area external routes with internal metric 3) L2->L1 inter-area routes with internal metric L2->L1 inter-area external routes with internal metric 4) L1 external routes with external metric 5) L2 external routes with external metric L1->L2 inter-area external routes with external metric 6) L2->L1 inter-area external routes with external metric 4.3 Additional notes on what prefixes to accept or advertise Paragraphs 4.1 and 4.2 enumerate all used IP route types in IS-IS. Besides these defined route types, the encoding used would allow for a few more potential combinations. One of them is the combination of "IP Internal Reachability Information" and external metric type. This combination should never be used when building an LSP. Upon receipt of an IP prefix with this combination, routers must ignore this prefix. Another issue would be the usage of the up/down bit in L2 LSPs. Because IS-IS is currently defined with two levels of hierarchy, there should never be a need to set the up/down bit in L2 LSPs. However, if IS-IS would ever be extended with more than two levels of hierarchy, L2-only (or L1L2) routers will need to be able to accept L2 IP routes with the up/down bit set. Therefor it is recommended that implementations ignore the up/down bit in L2 LSPs, and accept the prefixes in L2 LSPs regardless whether the up/down bit is set. This will allow for simpler migration once more than two levels of hierarchy are defined. Another detail that implementors should be aware of is the fact that L1L2 routers should only advertise in their L2 LSP those L1 routes that they use for forwarding themselves. They should not unconditionally advertise into L2 all prefixes from LSPs in the L1 database. Not all prefixes need to be advertised up or down the hierarchy. Implementations might allow for additional manual filtering or summarization to further bring down the number of inter-area prefixes they advertise in their LSPs. It is also recommended that the default configuration of L1L2 routers is to not advertise any L2 routes into L1 (see also paragraph 5.0). 5.0 Inter-operability with older implementations The solution in this document is not fully compatible with RFC 1195. It is an extension to RFC 1195. If routers do not use the new functionality of external L1 routes, nor L2->L1 inter-area routes, older implementations that strictly follow RFC 1195 will be compatible with newer implementations that follow this document. Implementations that do not accept the "IP External Reachability Information" TLV in L1 LSPs will not be able to compute external L1 routes. This could cause routing loops between L1-only routers that do understand external L1 routes for a particular destination, and L1-only routers that use the default route pointing the closest attached L1L2 router for that destination. Implementations that follow RFC 1195 should ignore bit 8 in the default metric field when computing routes. Therefor even older implementations that do not know of the up/down bit should be able to accept the new L2->L1 inter-area routes. These older implementations will install the new L2->L1 inter-area routes as L1 intra-area routes, but that in itself does not cause routing loops among L1-only routers. However, it is vital that the up/down bit is recognized by L1L2 routers. As has been stated before, L1L2 routers must never advertise L2->L1 inter-area routes back into L2. Therefor if L2 routes are advertised down into L1 area, it is required that all L1L2 routers in that area run software that understands the new up/down bit. Older implementations that follow RFC 1195 and do not understand the new up/down bit will threat the L2->L1 inter-area routes as L1 intra-area routes, and they will advertise these routes back into L2. This can cause routing loops, sub-optimal routing or extra routing instability. For this reason it is recommended that implementations by default do not advertise any L2 routes into L1. Implementations should force the network administrator to manually configure L1L2 routers to advertise any L2 routes into L1. 6.0 Comparisons with other proposals In [3], a new TLV is defined to transport IP prefix information. This TLV format also defines an up/down bit to allow for L2->L1 inter-area routes. [3] also defines a new TLV to describe links. Both TLVs have wider metric space, and have the possibility to define sub-TLVs to advertise extra information belonging to the link or prefix. The wider metric space in IP prefix TLVs allows for more granular metric information about inter-area path costs. To make full use of the wider metric space, network administrators must deploy both new TLVs at the same time. Deployment of [3] requires an upgrade of all routers in the network and a transition to the new TLVs. Such a network-wide upgrade and transition might not be an easy task. In this case, the solution defined in this document, which requires only an upgrade of L1L2 routers in selected areas, might be a good alternative to the solution defined in [3]. 5.0 Security Considerations This document raises no new security issues for IS-IS. 6.0 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)" [Also republished as RFC 1142] [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 [3] Smit, H., Li, T. "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-01.txt, work in progress 7.0 Authors' Addresses Tony Li Procket Networks 3910 Freedom Circle, Ste. 102A Santa Clara, CA 95054 Email: tli@procket.net Voice: ??? Tony Przygienda Siara Systems 300 Ferguson Drive, 2nd Floor Mountain View, CA 94043 Email: prz@siara.com Voice: +1 650 237 2173 Fax: +1 650 237 2179 Henk Smit Cisco Systems, Inc. 210 West Tasman Drive San Jose, CA 95134 Email: hsmit@cisco.com Voice: +31 20 342 3736 From jjl@one.com Thu, 18 Nov 1999 11:41:31 -0500 Date: Thu, 18 Nov 1999 11:41:31 -0500 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Support of "IP External Reachability Information" TLV in L1 LSP I find the following statement a little scary: > Including all examples of things that can cause > routing loops would make any document unreadable, IMHO. This seems like the antithesis of interoperability. I strongly recommend that any implementation options that can cause interoperability problems (such as persistent routing loops) be clearly identified, so that a purchaser can know whether or not equipment from different vendors will work together in a network. Are there really a lot of these? Note that there are a number of temporary situations that can cause routing loops. I'm not talking about these, because they're not interoperability problems, they're characteristics of the routing protocol that can be analyzed and discussed without referring to specific implementations. Best Regards, Jeff At 04:52 PM 11/18/99 +0100, Henk Smit wrote: > > I tried to document this issue in the new version of > draft-ietf-isis-domain-wide-02.txt. > > 3.2 Definition of external IP prefixes in level 1 LSPs > > RFC 1195 does not define the "IP External Reachability Information" > TLV for L1 LSPs. However, there is no reason why an IS-IS > implementation could not allow for redistribution of external routes > into L1. Some IS-IS implementations already allow network > administrators to do this. This document loosens the restrictions in > RFC 1195, and allows for the inclusion of the "IP External > Reachability Information" TLV in L1 LSPs. > > I did not include any explanation that if you mix the two implementations > in one L1 area, you can get routing loops. This seems a trivial > observation to me. Including all examples of things that can cause > routing loops would make any document unreadable, IMHO. > > I have not submitted the new version of the draft yet, but I did send > it to this list just before the IETF in DC. I did not receive any > comments, so I assume I can submit the draft as it is ? > > I do have one issue myself I'd like to discuss. But I'd like to hear > other people's comments first before I bring it up. > Just for clarity, I have attached the draft again. > > Thanks, > > Henk. > > >> Based on few mails exchanged in the last month ( related to domain-wide >> prefix distribution draft ), I understand that though RFC 1195 prohibits >> >> "IP External Reachability Information" TLV in L1 LSPs but in the REAL >> WORLD, this TLV is used in L1 LSPs. If there are two vendor >> implementations >> in L1 area, one which supports this and one which is strictly RFC 1195 >> compliant, >> it may cause routing loops in presence of external routes. In my >> opinion, this is >> an interoperability issue ( even if domain wide prefix distribution is >> not >> implemented ) and if would be desirable to document this somewhere in >> the main specification. >> I will appreciate your comments. >> >> Thanks, >> Rajesh > >---- >Network Working Group Tony Li >INTERNET DRAFT Procket Networks > > Tony Przygienda > Siara Systems > > Henk Smit > Cisco Systems > October 1999 > > > Domain-wide Prefix Distribution with Two-Level IS-IS > > > > >Status > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet- Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > >1.0 Abstract > > This document describes extensions to the IS-IS protocol to support > optimal routing within a two-level domain. The IS-IS protocol is > specified in ISO 10589 [1], with extensions for supporting IPv4 > specified in RFC 1195 [2]. > > This document extends the semantics presented in RFC 1195 so that a > routing domain running with both level 1 and level 2 Intermediate > Systems (IS) [routers] can distribute IP prefixes between level 1 and > level 2 and vice versa. This distribution requires certain > restrictions to insure that persistent forwarding loops do not form. > The goal of this domain-wide prefix distribution is to increase the > granularity of the routing information within the domain. > > >2.0 Introduction > > An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) > can be partitioned into multiple level 1 (L1) areas, and a level 2 > (L2) connected subset of the topology that interconnects all of the > L1 areas. Within each L1 area, all routers exchange link state > information. L2 routers also exchange L2 link state information to > compute routes between areas. > > RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that are > used to transport IPv4 routing information in IS-IS. RFC 1195 also > specifies the semantics and procedures for interactions between > levels. Specifically, routers in a L1 area will exchange information > within the L1 area. For IP destinations not found in the prefixes in > the L1 database, the L1 router should forward packets to the nearest > router that is in both L1 and L2 (i.e., an L1L2 router) with the > "attached bit" set in its L1 Link State Protocol Data Unit (LSP). > > Also per RFC 1195, an L1L2 router should be manually configured with > a set of prefixes that summarizes the IP prefixes reachable in that > L1 area. These summaries are injected into L2. RFC 1195 specifies > no further interactions between L1 and L2 for IPv4 prefixes. > > >2.1 Motivations for domain-wide prefix distribution > > The mechanisms specified in RFC 1195 are appropriate in many > situations, and lead to excellent scalability properties. However, > in certain circumstances, the domain administrator may wish to > sacrifice some amount of scalability and distribute more specific > information than is described by RFC 1195. This section discusses > the various reasons why the domain administrator may wish to make > such a tradeoff. > > One major reason for distributing more prefix information is to > improve the quality of the resulting routes. A well know property of > prefix summarization or any abstraction mechanism is that it > necessarily results in a loss of information. This loss of > information in turn results in the computation of a route based upon > less information, which will frequently result in routes that are not > optimal. > > A simple example can serve to demonstrate this adequately. Suppose > that a L1 area has two L1L2 routers that both advertise a single > summary of all prefixes within the L1 area. To reach a destination > inside the L1 area, any other L2 router is going to compute the > shortest path to one of the two L1L2 routers for that area. Suppose, > for example, that both of the L1L2 routers are equidistant from the > L2 source, and that the L2 source arbitrarily selects one L1L2 > router. This router may not be the optimal router when viewed from > the L1 topology. In fact, it may be the case that the path from the > selected L1L2 router to the destination router may traverse the L1L2 > router that was not selected. If more detailed topological > information or more detailed metric information was available to the > L2 source router, it could make a more optimal route computation. > > This situation is symmetric in that an L1 router has no information > about prefixes in L2 or within a different L1 area. In using the > nearest L1L2 router, that L1L2 is effectively injecting a default > route without metric information into the L1 area. The route > computation that the L1 router performs is similarly suboptimal. > > Besides the optimality of the routes computed, there are two other > significant drivers for the domain wide distribution of prefix > information. > > When a router learns multiple possible paths to external destinations > via BGP, it will select only one of those routes to be installed in > the forwarding table. One of the factors in the BGP route selection > is the IGP cost to the BGP next hop address. Many ISP networks > depend on this technique, which is known as "shortest exit routing". > If a L1 router does not know the exact IGP metric to all BGP speakers > in other L1 areas, it cannot do effective shortest exit routing. > > The third driver is the current practice of using the IGP (IS-IS) > metric as part of the BGP Multi-Exit Discriminator (MED). The value > in the MED is advertised to other domains and is used to inform other > domains of the optimal entry point into the current domain. Current > practice is to take the IS-IS metric and insert it as the MED value. > This tends to cause external traffic to enter the domain at the point > closest to the exit router. Note that the receiving domain may, > based upon policy, choose to ignore the MED that is advertised. > However, current practice is to distribute the IGP metric in this way > in order to optimize routing wherever possible. This is possible in > current networks that only are a single area, but becomes problematic > if hierarchy is to be installed into the network. This is again > because the loss of end-to-end metric information means that the MED > value will not reflect the true distance across the advertising > domain. Full distribution of prefix information within the domain > would alleviate this problem as it would allow accurate computation > of the IS-IS metric across the domain, resulting in an accurate value > presented in the MED. > > >2.2 Scalability > > The disadvantage to performing the domain-wide prefix distribution > described above is that it has an impact to the scalability of IS-IS. > Areas within IS-IS help scalability in that LSPs are contained within > a single area. This limits the size of the link state database, that > in turn limits the complexity of the shortest path computation. > > Further, the summarization of the prefix information aids scalability > in that the abstraction of the prefix information removes the sheer > number of data items to be transported and the number of routes to be > computed. > > It should be noted quite strongly that the distribution of prefixes > on a domain wide basis impacts the scalability of IS-IS in the second > respect. It will increase the number of prefixes throughout the > domain. This will result in increased memory consumption, > transmission requirements and computation requirements throughout the > domain. > > It must also be noted that the domain-wide distribution of prefixes > has no effect whatsoever on the first aspect of scalability, namely > the existence of areas and the limitation of the distribution of the > link state database. > > Thus, the net result is that the introduction of domain-wide prefix > distribution into a formerly flat, single area network is a clear > benefit to the scalability of that network. However, it is a > compromise and does not provide the maximum scalability available > with IS-IS. Domains that choose to make use of this facility should > be aware of the tradeoff that they are making between scalability and > optimality and provision and monitor their networks accordingly. > Normal provisioning guidelines that would apply to a fully > hierarchical deployment of IS-IS will not apply to this type of > configuration. > > >3.0 Proposed syntax and semantics for L2->L1 inter-area routes > > This document defines the syntax of how to advertise level 2 routes > in level 1 LSPs. The encoding is an extension of the encoding in RFC > 1195. > > To some extent, in IS-IS the level 2 backbone can be seen as a > separate area itself. RFC 1195 defines that L1L2 routers can > advertise IP routes that were learned via L1 routing into L2. These > routes can be regarded as inter-area routes. RFC 1195 defines that > these L1->L2 inter-area routes must be advertised in L2 LSPs in the > "IP Internal Reachability Information" TLV (TLV 128). Intra-area L2 > routes are also advertised in L2 LSPs in an "IP Internal Reachability > Information" TLV. Therefor L1->L2 inter-area routes are > indistinguishable from L2 intra-area routes. > > RFC 1195 does not define L2->L1 inter-area routes. A simple extension > would be to allow a L1L2 router to advertise routes learned via L2 > routing in its L1 LSP. However, to prevent routing-loops, L1L2 > routers must never advertise L2->L1 inter-area routes that they learn > via L1 routing, back into L2. Therefor there must be a way to > distinguish L2->L1 inter-area routes from L1 intra-area routes. > Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for this > purpose. RFC 1195 defines TLVs 128 and 130 to contain IP routes. > TVLs 128 and 130 have a metric field that consists of 4 TOS metrics. > The first metric, the so-called "default metric", has the high-order > bit reserved (bit 8). Routers must set this bit to zero on > transmission, and ignore it on receipt. > > This document redefines this high-order bit in the default metric > field in TLVs 128 and 130 to be the up/down bit. L1L2 routers must > set this bit to one for prefixes that are derived from L2 routing and > are advertised into L1 LSPs. The bit must be set to zero for all > other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down bit > set that are learned via L1 routing, must never be advertised by L1L2 > routers back into L2. > > >3.1 Clarification of external route-type and external metric-type > > RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is > defined as "IP Internal Reachability Information", and should be used > to carry IP prefixes that are directly connected to IS-IS routers. > TLV 130 is defined as "IP External Reachability Information", and > should be used to carry routes learned from outside the IS-IS domain. > RFC 1195 documents TLV type 130 only for level 2 LSPs. > > RFC 1195 also defines two types of metrics. Metrics of the internal > metric-type should be used when the metric is comparable to metrics > used to weigh links inside the ISIS domain. Metrics of the external > metric-type should be used if the metric of an IP prefix cannot be > directly compared to internal metrics. External metric-type can only > be used for external IP prefixes. A direct result is that metrics of > external metric-type should never be seen in TLV 128. > > To prevent confusion, this document states again that when a router > computes IP routes, it must give the same preference to IP routes > advertised in an "IP Internal Reachability Information" TLV and IP > routes advertised in an "IP External Reachability Information" TLV. > RFC 1195 states this quite clearly in the note in paragraph 3.10.2, > item 2c). This document does not alter this rule of preference. > > NOTE: Internal routes (routes to destinations announced in the > "IP Internal Reachability Information" field), and external > routes using internal metrics (routes to destinations announced > in the "IP External Reachability Information" field, with a > metric of type "internal") are treated identically for the > purpose of the order of preference of routes, and the Dijkstra > calculation. > > However, IP routes advertised in "IP External Reachability > Information" with external metric-type must be given less preference > than the same IP routes advertised with internal-metric type, > regardless of the value of the metrics. > > While IS-IS routers must not give different preference to IP prefixes > learned via "IP Internal Reachability Information" and "IP External > Reachability Information" when executing the Dijkstra calculation, > routers that implement multiple IGPs are free to use this distinction > between internal and external routes when comparing routes derived > from different IGPs for inclusion in their global RIB. > > >3.2 Definition of external IP prefixes in level 1 LSPs > > RFC 1195 does not define the "IP External Reachability Information" > TLV for L1 LSPs. However, there is no reason why an IS-IS > implementation could not allow for redistribution of external routes > into L1. Some IS-IS implementations already allow network > administrators to do this. This document loosens the restrictions in > RFC 1195, and allows for the inclusion of the "IP External > Reachability Information" TLV in L1 LSPs. > > RFC 1195 defines that IP routes learned via L1 routing must always be > advertised in L2 LSPs in a "IP Internal Reachability Information" > TLV. Now that this document allows "IP External Reachability > Information" TLVs in L1 LSPs, and allows for the advertisement of > routes learned via L2 routing into L1, the above rule needs a > extensions. > > When a L1L2 router advertises a L1 route into L2, where that L1 route > was learned via a prefix advertised in a "IP External Reachability > Information" TLV, that L1L2 router should advertise that prefix in > its L2 LSP within an "IP External Reachability Information" TLV. L1 > routes learned via an "IP Internal Reachability Information" TLV > should still be advertised within a "IP Internal Reachability > Information" TLV. These rules should also be applied when advertising > IP routes derived from L2 routing into L1. Of course in this case > also the up/down bit must be set. > > RFC 1195 defines that if a router sees the same external prefix > advertised by two or more routers with the same external metric, it > must select the route that is advertised by the router that is > closest to itself. It should be noted that now that external routes > can be advertised from L1 into L2, and vice versa, that the router > that advertises an external prefix in its LSP might not be the router > that originally injected this prefix into the IS-IS domain. Therefor > it is less useful to advertise external routes with external metrics > into other levels. > > >4.0 Types of IP routes in IS-IS and their order of preference > > RFC 1195 and this document defines several ways of advertising IP > routes in IS-IS. There are four variables involved. > > 1) The level of the LSP in which the route is advertised. > There are currently two possible values: level 1 and level 2 > 2) The route-type, which can be derived from the type of TLV in which > the prefix is advertised. > Internal routes are advertised in IP Internal Reachability Information > TLVs (TLV 128), and external routes are advertised in IP External > Reachability Information TLVs (TLV 130). > 3) The metric-type: Internal or External. The metric-type is derived from > the Internal/External metric-type bit in the metric field (bit 7). > 4) The fact whether this route is leaked down in the hierarchy, and > thus can not be advertised back up. This information can be derived > from the newly defined up/down bit in the default metric field. > > >4.1 Overview of all types of IP prefixes in IS-IS Link State PDUs > > The combination IP Internal Reachability Information and external > metric-type is not allowed. Also the up/down bit is never set in L2 > LSPs. This leaves us with 8 different types of IP advertisements in > IS-IS. However, there are more than 8 reasons for IP prefixes to be > advertised in IS-IS. The following tables describe the types of IP > prefixes and how they are encoded. > > 1) L1 intra-area routes > > These are advertised in L1 LSPs, in TLV 128. > The up/down bit is set to zero, metric-type is internal metric. > These IP prefixes are directly connected to the advertising router. > > 2) L1 external routes > > These are advertised in L1 LSPs, in TLV 130. > The up/down bit is set to zero, metric-type is internal metric. > These IP prefixes are learned from other IGPs, and are usually not > directly connected to the advertising router. > > 3) L2 intra-area routes > > These are advertised in L2 LSPs, in TLV 128. > The up/down bit is set to zero, metric-type is internal metric. > These IP prefixes are directly connected to the advertising router. > These prefixes can not be distinguished from L1->L2 inter-area > routes. > > 4) L2 external routes > > These are advertised in L2 LSPs, in TLV 130. > The up/down bit is set to zero, metric-type is internal metric. > These IP prefixes are learned from other IGPs, and are usually not > directly connected to the advertising router. > These prefixes can not be distinguished from L1->L2 inter-area > external routes. > > 5) L1->L2 inter-area routes > > These are advertised in L2 LSPs, in TLV 128. > The up/down bit is set to zero, metric-type is internal metric. > These IP prefixes are learned via L1 routing, and were derived > during the L1 SPF computation from prefixes advertised in L1 LSPs > in TLV 128. > These prefixes can not be distinguished from L2 intra-area routes. > > 6) L1->L2 inter-area external routes > > These are advertised in L2 LSPs, in TLV 130. > The up/down bit is set to zero, metric-type is internal metric. > These IP prefixes are learned via L1 routing, and were derived > during the L1 SPF computation from prefixes advertised in L1 LSPs > in TLV 130. > These prefixes can not be distinguished from L2 external routes. > > 7) L2->L1 inter-area routes > > These are advertised in L1 LSPs, in TLV 128. > The up/down bit is set to one, metric-type is internal metric. > These IP prefixes are learned via L2 routing, and were derived > during the L2 SPF computation from prefixes advertised in TLV 128. > > 8) L2->L1 inter-area external routes > > These are advertised in L1 LSPs, in TLV 130. > The up/down bit is set to one, metric-type is internal metric. > These IP prefixes are learned via L2 routing, and were derived > during the L2 SPF computation from prefixes advertised in L2 LSPs > in TLV 130. > > 9) L1 external routes with external metric > > These are advertised in L1 LSPs, in TLV 130. > The up/down bit is set to zero, metric-type is external metric. > These IP prefixes are learned from other IGPs, and are usually not > directly connected to the advertising router. > > 10) L2 external routes with external metric > > These are advertised in L2 LSPs, in TLV 130. > The up/down bit is set to zero, metric-type is external metric. > These IP prefixes are learned from other IGPs, and are usually not > directly connected to the advertising router. > These prefixes can not be distinguished from L1->L2 inter-area > external routes with external metric. > > 11) L1->L2 inter-area external routes with external metric > > These are advertised in L2 LSPs, in TLV 130. > The up/down bit is set to zero, metric-type is external metric. > These IP prefixes are learned via L1 routing, and were derived > during the L1 SPF computation from prefixes advertised in L1 LSPs > in TLV 130 with external metrics. > These prefixes can not be distinguished from L2 external routes with > external metric. > > 12) L2->L1 inter-area external routes with external metric > > These are advertised in L1 LSPs, in TLV 130. > The up/down bit is set to one, metric-type is external metric. > These IP prefixes are learned via L2 routing, and were derived > during the L1 SPF computation from prefixes advertised in L2 LSPs > in TLV 130 with external metrics. > > >4.2 Order of preference for all types of IP routes in IS-IS > > Unfortunately IS-IS cannot depend on metrics alone for route > selection. Some types of routes must always preferred over others, > regardless of the costs that were computed in the Dijkstra > calculation. One of the reasons for this is that inter-area routes > can only be advertised with a maximum metric of 63. Another reason is > that this maximum value of 63 does not mean infinity (e.g. like a hop > count of 16 in RIP denotes unreachable). Introducing a value for > infinity cost in IS-IS inter-area routes would introduce counting- > to-infinity behavior via two or more L1L2 routers, which would have a > bad impact on network stability. > > The order of preference of IP routes in IS-IS is based on a few > assumptions. > > - RFC 1195 defines that routes derived from L1 routing are preferred over > routes derived from L2 routing. > - The note in RFC 1195 paragraph 3.10.2, item 2c) defines that internal > routes with internal metric-type and external prefixes with internal > metric-type have the same preference. > - RFC 1195 defines that external routes with internal metric-type are > preferred over external routes with external metric type. > - Routes derived from L2 routing are preferred over L2->L1 routes > derived from L1 routing. > > Based on these assumptions, this document defines the following route > preferences. > > 1) L1 intra-area routes with internal metric > L1 external routes with internal metric > 2) L2 intra-area routes with internal metric > L2 external routes with internal metric > L1->L2 inter-area routes with internal metric > L1->L2 inter-area external routes with internal metric > 3) L2->L1 inter-area routes with internal metric > L2->L1 inter-area external routes with internal metric > 4) L1 external routes with external metric > 5) L2 external routes with external metric > L1->L2 inter-area external routes with external metric > 6) L2->L1 inter-area external routes with external metric > > >4.3 Additional notes on what prefixes to accept or advertise > > Paragraphs 4.1 and 4.2 enumerate all used IP route types in IS-IS. > Besides these defined route types, the encoding used would allow for > a few more potential combinations. One of them is the combination of > "IP Internal Reachability Information" and external metric type. > This combination should never be used when building an LSP. Upon > receipt of an IP prefix with this combination, routers must ignore > this prefix. > > Another issue would be the usage of the up/down bit in L2 LSPs. > Because IS-IS is currently defined with two levels of hierarchy, > there should never be a need to set the up/down bit in L2 LSPs. > However, if IS-IS would ever be extended with more than two levels of > hierarchy, L2-only (or L1L2) routers will need to be able to accept > L2 IP routes with the up/down bit set. Therefor it is recommended > that implementations ignore the up/down bit in L2 LSPs, and accept > the prefixes in L2 LSPs regardless whether the up/down bit is set. > This will allow for simpler migration once more than two levels of > hierarchy are defined. > > Another detail that implementors should be aware of is the fact that > L1L2 routers should only advertise in their L2 LSP those L1 routes > that they use for forwarding themselves. They should not > unconditionally advertise into L2 all prefixes from LSPs in the L1 > database. > > Not all prefixes need to be advertised up or down the hierarchy. > Implementations might allow for additional manual filtering or > summarization to further bring down the number of inter-area prefixes > they advertise in their LSPs. It is also recommended that the > default configuration of L1L2 routers is to not advertise any L2 > routes into L1 (see also paragraph 5.0). > > >5.0 Inter-operability with older implementations > > The solution in this document is not fully compatible with RFC 1195. > It is an extension to RFC 1195. If routers do not use the new > functionality of external L1 routes, nor L2->L1 inter-area routes, > older implementations that strictly follow RFC 1195 will be > compatible with newer implementations that follow this document. > > Implementations that do not accept the "IP External Reachability > Information" TLV in L1 LSPs will not be able to compute external L1 > routes. This could cause routing loops between L1-only routers that > do understand external L1 routes for a particular destination, and > L1-only routers that use the default route pointing the closest > attached L1L2 router for that destination. > > Implementations that follow RFC 1195 should ignore bit 8 in the > default metric field when computing routes. Therefor even older > implementations that do not know of the up/down bit should be able to > accept the new L2->L1 inter-area routes. These older implementations > will install the new L2->L1 inter-area routes as L1 intra-area > routes, but that in itself does not cause routing loops among L1-only > routers. > > However, it is vital that the up/down bit is recognized by L1L2 > routers. As has been stated before, L1L2 routers must never > advertise L2->L1 inter-area routes back into L2. Therefor if L2 > routes are advertised down into L1 area, it is required that all L1L2 > routers in that area run software that understands the new up/down > bit. Older implementations that follow RFC 1195 and do not understand > the new up/down bit will threat the L2->L1 inter-area routes as L1 > intra-area routes, and they will advertise these routes back into L2. > This can cause routing loops, sub-optimal routing or extra routing > instability. For this reason it is recommended that implementations > by default do not advertise any L2 routes into L1. Implementations > should force the network administrator to manually configure L1L2 > routers to advertise any L2 routes into L1. > > >6.0 Comparisons with other proposals > > In [3], a new TLV is defined to transport IP prefix information. > This TLV format also defines an up/down bit to allow for L2->L1 > inter-area routes. [3] also defines a new TLV to describe links. > Both TLVs have wider metric space, and have the possibility to define > sub-TLVs to advertise extra information belonging to the link or > prefix. The wider metric space in IP prefix TLVs allows for more > granular metric information about inter-area path costs. To make > full use of the wider metric space, network administrators must > deploy both new TLVs at the same time. > > Deployment of [3] requires an upgrade of all routers in the network > and a transition to the new TLVs. Such a network-wide upgrade and > transition might not be an easy task. In this case, the solution > defined in this document, which requires only an upgrade of L1L2 > routers in selected areas, might be a good alternative to the > solution defined in [3]. > > >5.0 Security Considerations > > This document raises no new security issues for IS-IS. > >6.0 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)" [Also republished as RFC 1142] > > [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual > environments", R.W. Callon, Dec. 1990 > > [3] Smit, H., Li, T. "IS-IS extensions for Traffic Engineering", > draft-ietf-isis-traffic-01.txt, work in progress > >7.0 Authors' Addresses > > Tony Li > Procket Networks > 3910 Freedom Circle, Ste. 102A > Santa Clara, CA 95054 > Email: tli@procket.net > Voice: ??? > > Tony Przygienda > Siara Systems > 300 Ferguson Drive, 2nd Floor > Mountain View, CA 94043 > Email: prz@siara.com > Voice: +1 650 237 2173 > Fax: +1 650 237 2179 > > Henk Smit > Cisco Systems, Inc. > 210 West Tasman Drive > San Jose, CA 95134 > Email: hsmit@cisco.com > Voice: +31 20 342 3736 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From rsaluja@BayNetworks.COM Thu, 18 Nov 1999 12:23:56 -0500 Date: Thu, 18 Nov 1999 12:23:56 -0500 From: Rajesh Saluja rsaluja@BayNetworks.COM Subject: [Isis-wg] Support of "IP External ReachabilityInformation" TLV in L1 LSP This is a multi-part message in MIME format. --------------C94A52F37C99EEC1385B1C14 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff Learman wrote: > I find the following statement a little scary: > > > Including all examples of things that can cause > > routing loops would make any document unreadable, IMHO. > > This seems like the antithesis of interoperability. > > I strongly recommend that any implementation options > that can cause interoperability problems (such as persistent > routing loops) be clearly identified, so that a purchaser > can know whether or not equipment from different vendors > will work together in a network. Are there really a lot > of these? > > Note that there are a number of temporary situations that > can cause routing loops. I'm not talking about these, > because they're not interoperability problems, they're > characteristics of the routing protocol that can be analyzed > and discussed without referring to specific implementations. > > Best Regards, > Jeff > I agree with Jeff. I do not know of any other persistent loop problems in IISIS. If there are more, they should be documented. The issue I am raising is definitely an interoperability issue and it is because of difference in what spec says and what has been implemented. It would be better to fix this. Thanks, Rajesh --------------C94A52F37C99EEC1385B1C14 Content-Type: text/x-vcard; charset=us-ascii; name="rsaluja.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rajesh Saluja Content-Disposition: attachment; filename="rsaluja.vcf" begin:vcard n:Saluja;Rajesh tel;fax:978 288 4837 tel;work:978 288 7791 x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:rsaluja@baynetworks.com fn:Rajesh Saluja end:vcard --------------C94A52F37C99EEC1385B1C14-- From jameshe@cabletron.com Thu, 18 Nov 1999 15:57:56 -0500 Date: Thu, 18 Nov 1999 15:57:56 -0500 From: He, James jameshe@cabletron.com Subject: [Isis-wg] isis mib question The isis mib states that isisSysTable contains a set of instances of integrated isis on the system. Q1: Does it include all routers in all isis areas or just instances in one area? How is isisSysInstance numbered? it it unique domain-wide? The mib also states that isisCircTable contains one entry for each broadcast or point-to-point interface on the system. Q2: The circuit table contains all interfaces of all the routers in the whole isis domain? Is this table too big??? Thanks. James he (jameshe@ctron.com) From jparker@nexabit.com Thu, 18 Nov 1999 16:05:50 -0500 Date: Thu, 18 Nov 1999 16:05:50 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] isis mib question > The isis mib states that isisSysTable contains a set of instances of > integrated isis on the system. > > Q1: Does it include all routers in all isis areas or just > instances in one > area? How is isisSysInstance > numbered? it it unique domain-wide? Read "System" as "IS" (or "Router"), not as "Network". This is the instances of ISIS you are running on this box. For many folks, there is only one instance. > The mib also states that isisCircTable contains one entry for > each broadcast > or point-to-point interface on the system. > > Q2: The circuit table contains all interfaces of all the > routers in the > whole isis domain? Is this table > too big??? > > James he (jameshe@ctron.com) Again, just the circuits on this box. From chopps@merit.edu 19 Nov 1999 15:42:27 -0500 Date: 19 Nov 1999 15:42:27 -0500 From: Christian E. Hopps chopps@merit.edu Subject: [Isis-wg] ISIS std question. I'm trying to figure out checksum failures in the isis std.. When I receive an LSP with a bad checksum the std in 7.3.14.2 says I should generate an event, overwrite the cksum and lifetime fields with zero and c) treat the link state pdu as though its remaining lifetime had expired (see 7.3.16.4). It seems to me that there are some problems with this. Since 7.3.16.4 has two cases: lifetime on a LSP _in_memory_ becoming zero (i.e., what I would consider `expiring') and receipt of an LSP with a zero lifetime. If it means the former should I just treat my in DB copy of the LSP as if it has expired? If it means the latter it could cause problems. What if the bogus LSP I just received had a really large sequence number (close to `wrapping'). This would seem to allow corrupted pdus to effect the operation of the protocol too greatly. I looked at the proposed new text for the standard and it says to just drop the LSP. Is this what other vendors currently do? It makes a lot of sense to me :) Chris. From dkatz@juniper.net Fri, 19 Nov 1999 12:58:38 -0800 (PST) Date: Fri, 19 Nov 1999 12:58:38 -0800 (PST) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] ISIS std question. The dominant implementations drop the LSP rather than purging it. The reasoning behind purging was that an LSP with a bad checksum probably was due to the LSP being corrupted in memory in some other system (since the link data checksum should protect the LSP while in flight). A few years ago, a certain large ISP was using some L2 equipment that did checksum regeneration had some problems. As a result, one link was reliably corrupting the data while delivering it with good datalink checksums. The net result of this was a continuous purge/reflood cycle for every LSP in the domain (since by definition every LSP must cross every link, mesh groups notwithstanding). It was very exciting, and brought my vacation to an untimely halt. Thus the addition of the "ignore-lsp-errors" configuration in the cisco box. The Juniper box always ignores errored LSPs without configuration. From: chopps@merit.edu (Christian E. Hopps) Date: 19 Nov 1999 15:42:27 -0500 Lines: 27 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I'm trying to figure out checksum failures in the isis std.. When I receive an LSP with a bad checksum the std in 7.3.14.2 says I should generate an event, overwrite the cksum and lifetime fields with zero and c) treat the link state pdu as though its remaining lifetime had expired (see 7.3.16.4). It seems to me that there are some problems with this. Since 7.3.16.4 has two cases: lifetime on a LSP _in_memory_ becoming zero (i.e., what I would consider `expiring') and receipt of an LSP with a zero lifetime. If it means the former should I just treat my in DB copy of the LSP as if it has expired? If it means the latter it could cause problems. What if the bogus LSP I just received had a really large sequence number (close to `wrapping'). This would seem to allow corrupted pdus to effect the operation of the protocol too greatly. I looked at the proposed new text for the standard and it says to just drop the LSP. Is this what other vendors currently do? It makes a lot of sense to me :) Chris. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From lester-ginsberg@vertel.com Sat, 20 Nov 1999 11:14:50 -0800 Date: Sat, 20 Nov 1999 11:14:50 -0800 From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] ISIS std question. Two matters of clarification: 1)The problem related to purging the LSP in this situation rather than dropping it as Dave recommends (and I heartily concur) was actually addressed as a defect by ISO in April of 1993. It is listed in a summary of defects (ISO/IEC JTC1/SC6/WG2 N523). However, I do not believe it was ever published in any of the Technical Corrigenda. 2)The second edition draft of ISO 10589 which I posted some time ago has many problems - most of which have been documented in a contribution I also posted. The draft in its current form should NEVER be used by ANYONE as a means of clarifying or resolving protocol issues. It was provided as a means of getting reviewed by the community. Although further work on this draft has been stalled for some time, there is hope that this work may soon be resumed and a revised second edition may soon be available. Les > > The dominant implementations drop the LSP rather than purging it. > > The reasoning behind purging was that an LSP with a bad checksum > probably was due to the LSP being corrupted in memory in some other > system (since the link data checksum should protect the LSP while > in flight). > > A few years ago, a certain large ISP was using some L2 equipment that > did checksum regeneration had some problems. As a result, one link > was reliably corrupting the data while delivering it with good datalink > checksums. The net result of this was a continuous purge/reflood cycle > for every LSP in the domain (since by definition every LSP must cross > every link, mesh groups notwithstanding). It was very exciting, and > brought my vacation to an untimely halt. Thus the addition of the > "ignore-lsp-errors" configuration in the cisco box. The Juniper box > always ignores errored LSPs without configuration. > > From: chopps@merit.edu (Christian E. Hopps) > Date: 19 Nov 1999 15:42:27 -0500 > Lines: 27 > User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/20.4 (Emerald) > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Sender: isis-wg-admin@external.juniper.net > Errors-To: isis-wg-admin@external.juniper.net > X-Mailman-Version: 1.0rc3 > Precedence: bulk > List-Id: IETF IS-IS working group > X-BeenThere: isis-wg@external.juniper.net > > > I'm trying to figure out checksum failures in the isis std.. > > When I receive an LSP with a bad checksum the std in 7.3.14.2 says I > should generate an event, overwrite the cksum and lifetime fields with > zero and > > c) treat the link state pdu as though its remaining lifetime had > expired (see 7.3.16.4). > > It seems to me that there are some problems with this. Since 7.3.16.4 > has two cases: lifetime on a LSP _in_memory_ becoming zero (i.e., what I > would consider `expiring') and receipt of an LSP with a zero lifetime. > > If it means the former should I just treat my in DB copy of the LSP as > if it has expired? > > If it means the latter it could cause problems. What if the bogus LSP > I just received had a really large sequence number (close to `wrapping'). > This would seem to allow corrupted pdus to effect the operation of the > protocol too greatly. > > I looked at the proposed new text for the standard and it says to just > drop the LSP. Is this what other vendors currently do? It makes a lot > of sense to me :) > > Chris. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.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 chopps@merit.edu 27 Nov 1999 13:31:12 -0500 Date: 27 Nov 1999 13:31:12 -0500 From: Christian E. Hopps chopps@merit.edu Subject: [Isis-wg] New version of draft-ietf-isis-domain-wide-02.txt Henk Smit writes: > Here is the new draft for route-leaking with old-style TLVs. [...] > Based on these assumptions, this document defines the following route > preferences. > > 1) L1 intra-area routes with internal metric > L1 external routes with internal metric > 2) L2 intra-area routes with internal metric > L2 external routes with internal metric > L1->L2 inter-area routes with internal metric > L1->L2 inter-area external routes with internal metric > 3) L2->L1 inter-area routes with internal metric > L2->L1 inter-area external routes with internal metric > 4) L1 external routes with external metric > 5) L2 external routes with external metric > L1->L2 inter-area external routes with external metric > 6) L2->L1 inter-area external routes with external metric I believe that currently the draft doesn't specify how to leak routes derived from both types of reachability. Since the reachability doesn't play a part in route selection this could conceivably happen. This is not described in rfc 1195 because level 1 wasn't defined to have external reachability and level 2 didn't leak into level 1. I think a perfectly reasonable action would be to always choose internal (i.e., TLV 128) if the route was derived in full or in part from a TLV 128 prefix. Does this sound reasonable? Thanks, Chris. From Mounir.Eddabbabi@ensi.rnu.tn Sat, 27 Nov 1999 19:49:11 +0100 Date: Sat, 27 Nov 1999 19:49:11 +0100 From: Mounir Eddabbabi Mounir.Eddabbabi@ensi.rnu.tn Subject: [Isis-wg] Hierarchical Networking Protocols Il s'agit d'un message multivolet au format MIME. --------------5A688AFF4F486A5D9FA32673 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Is there a mailing list for the hierarchicaly network routing protocols or any research groups in this field. Best regards --------------5A688AFF4F486A5D9FA32673 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Carte pour Mounir Eddabbabi Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Mounir Eddabbabi n: Eddabbabi;Mounir org: ENSI adr: BP 290 Publiposte Av Taieb M'Hiri;;;Ariana;;2080;Tunisia email;internet: Mounir.Eddabbabi@ensi.rnu.tn title: Master Student tel;home: 216-4-896142 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------5A688AFF4F486A5D9FA32673-- From hsmit@cisco.com Mon, 29 Nov 1999 17:02:37 +0100 (MET) Date: Mon, 29 Nov 1999 17:02:37 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] New version of draft-ietf-isis-domain-wide-02.txt > Henk Smit writes: > > > Here is the new draft for route-leaking with old-style TLVs. > [...] > > Based on these assumptions, this document defines the following route > > preferences. > > > > 1) L1 intra-area routes with internal metric > > L1 external routes with internal metric > > 2) L2 intra-area routes with internal metric > > L2 external routes with internal metric > > L1->L2 inter-area routes with internal metric > > L1->L2 inter-area external routes with internal metric > > 3) L2->L1 inter-area routes with internal metric > > L2->L1 inter-area external routes with internal metric > > 4) L1 external routes with external metric > > 5) L2 external routes with external metric > > L1->L2 inter-area external routes with external metric > > 6) L2->L1 inter-area external routes with external metric > > I believe that currently the draft doesn't specify how to leak routes > derived from both types of reachability. Since the reachability doesn't > play a part in route selection this could conceivably happen. > > This is not described in rfc 1195 because level 1 wasn't defined to have > external reachability and level 2 didn't leak into level 1. > > I think a perfectly reasonable action would be to always choose internal > (i.e., TLV 128) if the route was derived in full or in part from a TLV > 128 prefix. > > Does this sound reasonable? Yes, this sounds reasonable. I will add some text to describe this. Note, if you see the same prefixes as both internal and external, your network already seems to be experiencing redistribution feedback. Not a good thing to begin with. Henk. > Thanks, > Chris. > From jameshe@cabletron.com Tue, 30 Nov 1999 13:48:30 -0500 Date: Tue, 30 Nov 1999 13:48:30 -0500 From: He, James jameshe@cabletron.com Subject: [Isis-wg] isis mib question The ISIS mib states that the three index objects in the isisISAdjIPAddtTable table are not accessible. The objects are isisISAdjIPAddrSysInstance, isisISAdjIPAddrCircIndex and isisISAdjIPAddrAdjIndex. The MAX-ACCESS value for the three objects are "not-accessible". If these are used as index of the table, why are they not accessible? Thanks. James He From bhazen@xedia.com Tue, 30 Nov 1999 14:38:41 -0500 Date: Tue, 30 Nov 1999 14:38:41 -0500 From: Brad Hazen bhazen@xedia.com Subject: [Isis-wg] ISIS MIB question I'm trying to figure out why it's necessary to use isisCircIndex and isisISAdjIndex as indices for the isisCircTable and the isisISAdjTable. Neither object has any relationship to any protocol value. It seems to me that there are already enough objects available (isisCircIfIndex, isisCircIfSubIndex, and isisISAdjNeighSNPAAddress) to uniquely identify rows in both tables. What is the reason that isisCircIndex and isisISAdjIndex are required? Brad From jparker@nexabit.com Tue, 30 Nov 1999 17:22:13 -0500 Date: Tue, 30 Nov 1999 17:22:13 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] isis mib question > The ISIS mib states that the three index objects in the > isisISAdjIPAddtTable table are not accessible. The objects > are isisISAdjIPAddrSysInstance, isisISAdjIPAddrCircIndex > and isisISAdjIPAddrAdjIndex. The MAX-ACCESS value for the > three objects are "not-accessible". If these are used as > index of the table, why are they not accessible? > > Thanks. > > James He While you would think that "not-accessible" would mean not accessible, it is more complicated than that. Mib indicies are supposed to be marked with this label, which seems to mean "don't mess with this" rather than "you can't see this". - jeff parker - jparker@nexabit.com From jparker@nexabit.com Tue, 30 Nov 1999 17:33:59 -0500 Date: Tue, 30 Nov 1999 17:33:59 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] ISIS MIB question > I'm trying to figure out why it's necessary to use > isisCircIndex and isisISAdjIndex as indices for the > isisCircTable and the isisISAdjTable. > > Neither object has any relationship to any protocol > value. > > It seems to me that there are already enough objects > available (isisCircIfIndex, isisCircIfSubIndex, and > isisISAdjNeighSNPAAddress) to uniquely identify rows > in both tables. > > What is the reason that isisCircIndex and > isisISAdjIndex are required? > > Brad Let's start with the easy one. You might have multiple adjacencies on a LAN interface, such as Ethernet. In this case, you will need to distinguish adjacencies which share the same circuit attributes. The AdjIndex serves to mark such different adjacencies: clearly no circuit index can do that job. While there seem to be too many circuit indicies, they play different roles. The CircIndex may match the IfIndex, but it need not. Your implementation is free to make these the same value: the overhead of supporting the two names is minimal, and allows implementations that make the CircIndex match a physical interface (port 3 on card 2) which the IfIndex is not well suited for. Since most SNMP port management depends on the IfIndex, I found it helpful to include both. We felt that the subInterface was useful to support circuits on interfaces such as ATM and Frame Relay which split one physical interface into multiple portions. This allows you to quickly find the fiber via the IfIndex and then the VCI via the SubInterface. isisCircIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of this circuit, unique within the instance of the protocol. This object follows the index behaviour. This is for SNMP Indexing purposes only and has no relation to any protocol value." ::= { isisCircEntry 2 } isisCircIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of ifIndex for the interface to which this circuit corresponds. This object cannot be modified after creation" ::= { isisCircEntry 3 } isisCircIfSubIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A specifier for the part of the interface ifIndex to which this circuit corresponds, such as a DLCI or VPI/VCI. This object cannot be modified after creation" ::= { isisCircEntry 4 } - jparker@nexabit.com From dwt@cw.net Tue, 30 Nov 1999 17:43:30 -0500 (EST) Date: Tue, 30 Nov 1999 17:43:30 -0500 (EST) From: David Tallerico dwt@cw.net Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt In section 3.0 of the subject draft, regarding the router ID TLV, the following statement appears: Implementations MUST NOT inject a /32 prefix for the router ID into their forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this TLV. Could someone provide further explanation or, better yet, an illustration of the scenario involved? David Tallerico Internet Engineering Cable & Wireless USA From bhazen@xedia.com Tue, 30 Nov 1999 19:54:06 -0500 Date: Tue, 30 Nov 1999 19:54:06 -0500 From: Brad Hazen bhazen@xedia.com Subject: [Isis-wg] ISIS MIB question Jeff, Thanks for the clarification, but a couple of points still aren't clear. >Let's start with the easy one. >You might have multiple adjacencies on a LAN interface, >such as Ethernet. In this case, you will need to >distinguish adjacencies which share the same circuit >attributes. The AdjIndex serves to mark such different >adjacencies: clearly no circuit index can do that job. I understand that you can have multiple adjacencies on a LAN interface. But my question is why do you need to 'assign' an AdjIndex to distinguish adjacencies when there seems to be enough other information to uniquely identify an adjacency without it? Specifically, why can't you use isisISAdjNeighSNPAAddress in combination with the circuit attributes to distinguish an adjacency? Are SNPA addresses not unique? isisISAdjIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value identifying the IS adjacency from all other such adjacencies on this circuit. This value is assigned by the system when the adjacency is created automatically." ::= { isisISAdjEntry 3 } >While there seem to be too many circuit indicies, they >play different roles. The CircIndex may match the >IfIndex, but it need not. Your implementation is >free to make these the same value: the overhead of >supporting the two names is minimal, and allows >implementations that make the CircIndex match a >physical interface (port 3 on card 2) which the >IfIndex is not well suited for. Since most SNMP >port management depends on the IfIndex, I found it >helpful to include both. OK. >We felt that the subInterface was useful to support >circuits on interfaces such as ATM and Frame Relay >which split one physical interface into multiple >portions. This allows you to quickly find the >fiber via the IfIndex and then the VCI via the >SubInterface. OK. Is there a default value for this object when a subinterface index might not apply? On a LAN circuit, for instance. Thanks again, Brad > isisCircIndex OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The identifier of this circuit, unique within the > instance of the protocol. This object follows the index > behaviour. This is for SNMP Indexing purposes only > and has no relation to any protocol value." > ::= { isisCircEntry 2 } > > isisCircIfIndex OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of ifIndex for the interface to which this > circuit corresponds. This object cannot be modified > after creation" > ::= { isisCircEntry 3 } > > isisCircIfSubIndex OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A specifier for the part of the interface ifIndex to which > this circuit corresponds, such as a DLCI or VPI/VCI. > This object cannot be modified after creation" > ::= { isisCircEntry 4 } >> I'm trying to figure out why it's necessary to use >> isisCircIndex and isisISAdjIndex as indices for the >> isisCircTable and the isisISAdjTable. >> >> Neither object has any relationship to any protocol >> value. >> >> It seems to me that there are already enough objects >> available (isisCircIfIndex, isisCircIfSubIndex, and >> isisISAdjNeighSNPAAddress) to uniquely identify rows >> in both tables. >> >> What is the reason that isisCircIndex and >> isisISAdjIndex are required? >> >> Brad From jameshe@cabletron.com Tue, 30 Nov 1999 22:07:04 -0500 Date: Tue, 30 Nov 1999 22:07:04 -0500 From: He, James jameshe@cabletron.com Subject: [Isis-wg] ISIS MIB question >>Let's start with the easy one. >>You might have multiple adjacencies on a LAN interface, >>such as Ethernet. In this case, you will need to >>distinguish adjacencies which share the same circuit >>attributes. The AdjIndex serves to mark such different >>adjacencies: clearly no circuit index can do that job. >I understand that you can have multiple adjacencies on >a LAN interface. But my question is why do you need to >'assign' an AdjIndex to distinguish adjacencies when >there seems to be enough other information to uniquely >identify an adjacency without it? Specifically, why can't >you use isisISAdjNeighSNPAAddress in combination with the >circuit attributes to distinguish an adjacency? Are SNPA >addresses not unique? > isisISAdjIndex OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A unique value identifying the IS adjacency from all > other such adjacencies on this circuit. This value is > assigned by the system when the adjacency is created > automatically." > ::= { isisISAdjEntry 3 } There might be two adjacencies between two systems. Hence isisISAdjNeighSNPAAddress is not enough the identify a particular adjacency. >Is there a default value for this object when a >subinterface index might not apply? On a LAN >circuit, for instance. It might be -1 or 0. James From jameshe@cabletron.com Wed, 1 Dec 1999 08:54:11 -0500 Date: Wed, 1 Dec 1999 08:54:11 -0500 From: He, James jameshe@cabletron.com Subject: [Isis-wg] an ISIS question I am thinking about a scenario like this: three ISIS systems R1, R2, and R3. R1 is a L1/L2 system with area addresses 1 and 2. R2 is a L1-only system with an area address of 1. R3 is also a L1-only system with an area address of 2. All three systems are connected via a LAN. Obviously the systems will establish L1 adjacencies to each other. Q: R1 will have L1 adjacencies to R2 and R3. However, R2 and R3 will not be adjacent to each other as the two systems do not a common area address. Will R1 have two L1 link state databases as we have two L1 areas bridged by R1? Normally different L1 areas are connected via different L1/L2 systems. So we are looking at a degenerated case. Thanks. James From jhalpin@nexabit.com Wed, 1 Dec 1999 09:24:40 -0500 Date: Wed, 1 Dec 1999 09:24:40 -0500 From: Jim Halpin jhalpin@nexabit.com Subject: [Isis-wg] ISIS MIB question > -----Original Message----- > From: bhazen@xedia.com [SMTP:bhazen@xedia.com] > Sent: Tuesday, November 30, 1999 7:54 PM > To: isis-wg@juniper.net > Subject: RE: [Isis-wg] ISIS MIB question > > > I understand that you can have multiple adjacencies on > a LAN interface. But my question is why do you need to > 'assign' an AdjIndex to distinguish adjacencies when > there seems to be enough other information to uniquely > identify an adjacency without it? Specifically, why can't > you use isisISAdjNeighSNPAAddress in combination with the > circuit attributes to distinguish an adjacency? Are SNPA > addresses not unique? [JJH>] From a purely SNMP/MIB-only point of view, you really don't want to use something like a SNPA Address (defined as an OCTET STRING (0..20) I believe) as the index of a table. Because its a variable length string, its length must be encoded into the OID every time you reference an entry in the table. You'll be adding somewhere between 1 to 21 sub-ids to every object reference in this table. Mixing it in with a couple other INDEX objects only makes it worse. Variable length strings are also a pain to deal with when doing GetNext lookups in the MIB at run-time. For ease of implementation, you'll want to avoid complex INDEX clauses. Which is why so many tables have simple, "meaningless" integer index objects like "ifIndex". From mshand@cisco.com Wed, 01 Dec 1999 14:42:26 +0000 Date: Wed, 01 Dec 1999 14:42:26 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] an ISIS question At 08:54 01/12/1999 -0500, He, James wrote: >I am thinking about a scenario like this: three ISIS systems R1, R2, and R3. >R1 is a L1/L2 system with area addresses 1 and 2. R2 is a L1-only system >with >an area address of 1. R3 is also a L1-only system with an area address of 2. >All three systems are connected via a LAN. Obviously the systems will >establish >L1 adjacencies to each other. > >Q: R1 will have L1 adjacencies to R2 and R3. However, R2 and R3 will not >be adjacent to each other as the two systems do not a common area address. >Will R1 have two L1 link state databases as we have two L1 areas bridged >by R1? Normally different L1 areas are connected via different L1/L2 >systems. No. All the systems will reside in the area with area addresses 1 & 2. You are correct that the adjacency between R2 and R3 will not come up and in any sensible implementation it will complain about an area mismatch. >So we are looking at a degenerated case. Yes, this is not a recommended configuration. In general you should always configure all systems on the LAN to have the same set of area addresses. The only exception to this is in the dynamic case where you are trying to add/remove/change an area address. Mike >Thanks. > > >James > > > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From hsmit@cisco.com Wed, 1 Dec 1999 16:00:47 +0100 (MET) Date: Wed, 1 Dec 1999 16:00:47 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt > In section 3.0 of the subject draft, regarding the router ID TLV, the > following statement appears: > > Implementations MUST NOT inject a /32 prefix for the router ID into > their forwarding table, because this can lead to forwarding loops > when interacting with systems that do not support this TLV. > > Could someone provide further explanation or, better yet, an illustration > of the scenario involved? See here a simple example: 22.22.22/24 R1 ----10----- R2 | | 10 4 | | R3 -----4----- R4 Suppose R1 and R2 are connected via a link with prefix 22.22.22/24. Suppose R1 has interface address 22.22.22.1 on that link. Suppose R1 selects 22.22.22.1 as its MPLS TE router ID. Suppose R3 does not inject route 22.22.22.1/32 into the RIB (good). Suppose R4 does inject route 22.22.22.1/32 into the RIB (bad). This will cause a routing loop for traffic to 22.22.22.1: R3 wants to send a packet to 22.22.22.1. The matching route will be 22.22.22/24, cost 18, via R3->R4->R2. R4 wants to send a packet to 22.22.22.1. The matching route will be 22.22.22.1/32, cost 14, via R4->R3->R1. Voila, routing loop. Hope this helps, Henk. From jameshe@cabletron.com Wed, 1 Dec 1999 13:03:28 -0500 Date: Wed, 1 Dec 1999 13:03:28 -0500 From: He, James jameshe@cabletron.com Subject: [Isis-wg] an ISIS MIB question I have the following MIB questions: In isisISAdjTable, isisISAdjNeighborSysType can have the values: 3(intermediate system), 4(L1 system), 5(L2 system). Why do you need the value of 3 when there are already enumerations used for L1 and L2 systems? Also, isisISAdjNeighSysID has a length of 12 octets. a SystemID has up to 8 octets. Why does this ID need some extra octets? I noticed that isisISAdjIPAddrTable does not have as much information as isisISAdjTable. Information such as the type of neighboring systems and the type of the adjacencies are not in the IP table. Is there any way to bridge these two tables? I am wondering if there is an efficient way of obtaining all neighbor system information given an IP of the local system. Which table contains the area address(es) of the local system, isisISAdjAreaAddrTable or isisManAreaAddrTable? The isisISAdjAreaAddrTable is indexed on isisISAdjAreaAddrSysInstance, isisISAdjAreaAddrCircIndex, and isisISAdjAreaAddrAdjIndex. What if there are more than one area addresses for a neighbor? These indices cannot differentiate multiple addresses from the same neighbor sent on the same circuit. Thanks. James From jparker@nexabit.com Thu, 2 Dec 1999 11:46:00 -0500 Date: Thu, 2 Dec 1999 11:46:00 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] an ISIS MIB question > I have the following MIB questions: > > In isisISAdjTable, isisISAdjNeighborSysType > can have the values: 3(intermediate system), 4(L1 system), > 5(L2 system). Why do you need the value of 3 when there > are already enumerations used for L1 and L2 systems? Good question. I'll look at that for the next draft. > Also, isisISAdjNeighSysID has a length of 12 octets. > a SystemID has up to 8 octets. Why does this ID > need some extra octets? The extra octets are to store the extended circuitId as described in DKatz's 3-way handshake draft (see below). While that is still just a draft, I cannot cite it directly. I have placed the systemId first, as that makes more sense for someone walking the table. isisISAdjNeighSysID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..12)) MAX-ACCESS read-only STATUS current DESCRIPTION "The system ID and circuit ID of the neighboring Intermediate System set from the source ID field of the neighbor's IIH PDUs." REFERENCE "{ISIS.aoi neighbourSystemIds (83)}" ::= { isisISAdjEntry 7 } Compare to 3.1 Syntax A new IS-IS Option type, "Point-to-Point Adjacency State", is defined: Type = 0xF0 (decimal 240) Length = 5 to 17 octets Value: Adjacency State (one octet): 0 = Up 1 = Initializing 2 = Down Extended Local Circuit ID (four octets) Neighbor System ID if known (zero to eight octets) Neighbor Extended Local Circuit ID (four octets, if Neighbor System ID is present) > I noticed that isisISAdjIPAddrTable does not have > as much information as isisISAdjTable. Information > such as the type of neighboring systems and > the type of the adjacencies are not in the IP table. > Is there any way to bridge these two tables? I've tried to keep them distinct: there may be systems that run ISIS that do not route IP traffic. > I am wondering if there is an efficient way of obtaining > all neighbor system information given an IP of the > local system. > > Which table contains the area address(es) of the local > system, isisISAdjAreaAddrTable Do you have suggestions for any edits that would make it clearer? "This table contains the set of Area Addresses of neighboring Intermediate Systems as reported in received IIH PDUs." > isisManAreaAddrTable? "The set of manual area addresses configured on this Intermediate System." > The isisISAdjAreaAddrTable is indexed on > isisISAdjAreaAddrSysInstance, isisISAdjAreaAddrCircIndex, > and isisISAdjAreaAddrAdjIndex. What if there are more > than one area addresses for a neighbor? These indices > cannot differentiate multiple addresses from the same > neighbor sent on the same circuit. > > Thanks. > > James Good point. Let me mull that over. - jdp From prkumar@nortelnetworks.com Tue, 07 Dec 1999 17:17:38 -0500 Date: Tue, 07 Dec 1999 17:17:38 -0500 From: Prashant Kumar prkumar@nortelnetworks.com Subject: [Isis-wg] Question on TLV type 135 I have a question on TLV type 135 in "IS-IS extension for Traffic Engineering". under the description it is told that this TLV corrects some problems in existing "IP reachability TLV". But the thing which confuses me is: Is this TLV(type 135) is aimed at replacing the existing IP Internal reachability TLV(type 128) and IP External reachability TLV(type 129). If so section 3.10.2 of RFC1195 "Order of Preference of Routes in the Level 2 routing" does not apply directly anymore because in TLV type 135 there is no bit to indicate "internal" and "external" routes. Also, how are we going to distinguish internal and external reachability. I assume, extended IP reachability TLV deserves more explanation. Regards, -- Prashant Kumar Nortel Networks From hsmit@cisco.com Wed, 8 Dec 1999 03:36:05 +0100 (MET) Date: Wed, 8 Dec 1999 03:36:05 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] Question on TLV type 135 > I have a question on TLV type 135 in "IS-IS extension for Traffic > Engineering". > > under the description it is told that this TLV corrects some > problems in existing "IP reachability TLV". > > But the thing which confuses me is: Is this TLV(type 135) is aimed at > replacing the existing IP Internal reachability TLV(type 128) and IP > External reachability TLV(type 129). Yes. > If so section 3.10.2 of RFC1195 > "Order of Preference of Routes in the Level 2 routing" does not apply > directly anymore because in TLV type 135 there is no bit to indicate > "internal" and "external" routes. Correct. > Also, how are we going to distinguish > internal and external reachability. There is no definition of internal or external routes in the draft. An IP prefix is an IP prefix. If you see the same IP prefix as an internal and an external prefix in your IGP, you already have a big problem (redistribution feedback). Only doing making a distinction between internal/external prefixes during route installation is not going prevent you from problems. If you really want to prevent redistribution feedback, you need to tag the origin of your prefix. If there is a real interest to be able to do that, we have the sub-TLVs in TLV 135 to do things like route coloring/tagging. Henk. > I assume, extended IP reachability TLV deserves more explanation. > > Regards, > -- > Prashant Kumar > Nortel Networks > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From rsaluja@nortelnetworks.com Wed, 08 Dec 1999 09:03:50 -0500 Date: Wed, 08 Dec 1999 09:03:50 -0500 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] Question on TLV type 135 > > > If you really want to prevent redistribution feedback, you > need to tag the origin of your prefix. If there is a real > interest to be able to do that, we have the sub-TLVs in TLV 135 > to do things like route coloring/tagging. > > Henk. Henk, Will you please give pointer to the draft explaining the sub-TLVs for route coloring? Thanks, Rajesh -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From hsmit@cisco.com Wed, 8 Dec 1999 16:26:32 +0100 (MET) Date: Wed, 8 Dec 1999 16:26:32 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] Question on TLV type 135 > > If you really want to prevent redistribution feedback, you > > need to tag the origin of your prefix. If there is a real > > interest to be able to do that, we have the sub-TLVs in TLV 135 > > to do things like route coloring/tagging. > > > > Henk. > > Henk, > Will you please give pointer to the draft explaining the sub-TLVs for > route coloring? draft-ietf-isis-traffic-02.txt only defines the format of the sub-TLVs, in case we want the. There are no sub-TLVs defined for TLV 135 yet. The sub-TLVs for TLV 135 work the same way as the sub-TLVs for TLV 22. If you want to define some sub-TLVs for TLV 135, feel free to build something yourself, write a new draft, and propose it to the WG. Cheers, henk. > Thanks, > Rajesh > > -- > > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- > > > > From hsmit@cisco.com Thu, 9 Dec 1999 17:35:10 +0100 (MET) Date: Thu, 9 Dec 1999 17:35:10 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] Question on TLV type 135 Sorry, that was a typo. ...-01.txt is the latest one. Henk. > Where can I get the draft-ietf-isis-traffic-02.txt draft? I have > draft-ietf-isis-traffic-01.txt but didn't see 02 on the ietf page. > > Thanks. > > Matt > > Henk Smit wrote: > > > > > > If you really want to prevent redistribution feedback, you > > > > need to tag the origin of your prefix. If there is a real > > > > interest to be able to do that, we have the sub-TLVs in TLV 135 > > > > to do things like route coloring/tagging. > > > > > > > > Henk. > > > > > > Henk, > > > Will you please give pointer to the draft explaining the sub-TLVs for > > > route coloring? > > > > draft-ietf-isis-traffic-02.txt only defines the format of the sub-TLVs, > > in case we want the. There are no sub-TLVs defined for TLV 135 yet. > > > > The sub-TLVs for TLV 135 work the same way as the sub-TLVs for TLV 22. > > If you want to define some sub-TLVs for TLV 135, feel free to build > > something yourself, write a new draft, and propose it to the WG. > > > > Cheers, > > > > henk. > > > > > Thanks, > > > Rajesh > > > > > > -- > > > > > > ------------------------------------------------------------- > > > Rajesh Saluja > > > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > > > Ph: (978) 288-7791 Fax: (978) 670-8760 > > > -------------------------------------------------------------- > > > > > > > > > > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > From pst@juniper.net Thu, 9 Dec 1999 16:21:29 -0800 (PST) Date: Thu, 9 Dec 1999 16:21:29 -0800 (PST) From: Paul Traina pst@juniper.net Subject: [Isis-wg] test quick test -- mailing list moved to new hardware Paul From chopps@merit.edu 13 Dec 1999 21:09:09 -0500 Date: 13 Dec 1999 21:09:09 -0500 From: Christian E. Hopps chopps@merit.edu Subject: [Isis-wg] Question on TLV type 135 > > Also, how are we going to distinguish > > internal and external reachability. > > There is no definition of internal or external routes in the draft. > An IP prefix is an IP prefix. If you see the same IP prefix as an > internal and an external prefix in your IGP, you already have > a big problem (redistribution feedback). Only doing making a > distinction between internal/external prefixes during route > installation is not going prevent you from problems. > > If you really want to prevent redistribution feedback, you > need to tag the origin of your prefix. If there is a real > interest to be able to do that, we have the sub-TLVs in TLV 135 > to do things like route coloring/tagging. But this means I have to implement sub-tlv's even though I'm not going to do TE with the TLV. :) Chris. From navaneethk@future.futsoft.com Wed, 22 Dec 1999 18:30:34 -0800 Date: Wed, 22 Dec 1999 18:30:34 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Help on ISIS Hi all, I'm new to the ISIS protocol.I am currentlyin the process of studying and understanding the protocol . In this regard, I would like to have a clear understanding of the various types of PDUs and who sends them and when. I basically would like to know the functionality of the ESH,ISH and IIH PDUs,who sends what and when. Which od these PDUs are associated with ES and which with IS. Also I would like to know,if the associated ISO standards like iso 9542 etc. are available for download from some place on the net.If so can you please pass me the website address. Thanx and Regards Navaneeth. Navaneetha Krishnan.N Senior Software Engineer, HDF, Future Software Pvt Ltd, 480 - 481, Anna Salai, Nandanam, Chennai - 600 035 India. Phone : +91-44-4330550 Ext.412 From rsaluja@nortelnetworks.com Wed, 22 Dec 1999 09:29:49 -0500 Date: Wed, 22 Dec 1999 09:29:49 -0500 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] Help on ISIS navaneeth K wrote: > Hi all, > I'm new to the ISIS protocol.I am currentlyin the process of studying and understanding the protocol . > In this regard, I would like to have a clear understanding of the various types of PDUs and who sends them and when. > I basically would like to know the functionality of the ESH,ISH and IIH PDUs,who sends what and when. > Which od these PDUs are associated with ES and which with IS. > Also I would like to know,if the associated ISO standards like iso 9542 etc. are available for download from some place on the net.If so can you please pass me the website address. > > Thanx and Regards > Navaneeth. > ESH - sent by end system ISH - sent by Intermediate system to end system IIH- sent by Intermediate system to Intermediate system Thanks, Rajesh From jparker@nexabit.com Wed, 22 Dec 1999 09:33:17 -0500 Date: Wed, 22 Dec 1999 09:33:17 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Help on ISIS > Hi all, > I'm new to the ISIS protocol.I am currentlyin the process of > studying and understanding the protocol . > In this regard, I would like to have a clear understanding of > the various types of PDUs and who sends them and when. > I basically would like to know the functionality of the > ESH,ISH and IIH PDUs,who sends what and when. > Which od these PDUs are associated with ES and which with IS. > Also I would like to know,if the associated ISO standards > like iso 9542 etc. are available for download from some place > on the net.If so can you please pass me the website address. > > Thanx and Regards > Navaneeth. > > > Navaneetha Krishnan.N > Senior Software Engineer, > HDF, Future Software Pvt Ltd, > 480 - 481, Anna Salai, Nandanam, > Chennai - 600 035 > India. > Phone : +91-44-4330550 Ext.412 Navaneetha - ISO 10589 is available as RFC 1142. RFC 1195 discusses TLVs for carrying IP. This will start you off. - jdp From navaneethk@future.futsoft.com Thu, 23 Dec 1999 09:59:28 -0800 Date: Thu, 23 Dec 1999 09:59:28 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Help on ISIS Hi all, Thanx to all of you for the immediate reaponse to my question.I'm already in the process of reading RFCs 1142,1195 ans iso10589.But i'm not able to get the clear relation between the ESH,ISH and IIH PDUs.Can anyone explain in detail as to who send ESH,ISH,IIH PDUs and when .What is the relationship between these PDUs,Which is sent in response to which etc.. Thanx for the response.. Looking forward to hear from you Navaneeth. Navaneetha Krishnan.N Senior Software Engineer, HDF, Future Software Pvt Ltd, 480 - 481, Anna Salai, Nandanam, Chennai - 600 035 India. Phone : +91-44-4330550 Ext.412 From amartey@cisco.com Wed, 22 Dec 1999 22:07:58 -0800 Date: Wed, 22 Dec 1999 22:07:58 -0800 From: Abe Martey amartey@cisco.com Subject: [Isis-wg] Help on ISIS Navaneetha, There two protocols that run together to support CLNP for ISO connectionless services. 1. ES-IS 2. IS-IS ES-IS runs between routers (Intermediate Systems) and hosts (End Systems) and it allows ESs and ISs learn about each other and also provides a means for ESs to obtain configuration info from the routers...ie Area info and preferred routers for specific destinations (via redirects). In ES-IS routers send out Intermediate system hellos (ISH) and hosts send out End System Hellos (ESH) The other protocol, IS-IS, is meant for router to router communication. Intermediate System to Intermediate System Hellos (IIH) are used between routers speaking IS-IS...read on IS010589 for further details. All this said...it may be worth mentioning that RFC1195 allows IS-IS to be used for IP routing in a non CLNP environment...and even though ES-IS doesn't have much relevance in this environment, it comes into play in the IS-IS implementation. Neighboring routers in the IP only environment would receive each others ISHs as well as IIHs...but there may not be ISO hosts to send ESHs. IP hosts use a combinition of IP ARP, IP redirects, default gateway, static routes and possibly IP dynamic routing protocols to achieve the ES-IS functionality. Hope this helps. Thanks. - abe On Thu, Dec 23, 1999 at 09:59:28AM -0800, navaneeth K wrote: > Hi all, > > Thanx to all of you for the immediate reaponse to my question.I'm already in the process of reading RFCs 1142,1195 ans iso10589.But i'm not able to get the clear relation between the ESH,ISH and IIH PDUs.Can anyone explain in detail as to who send ESH,ISH,IIH PDUs and when .What is the relationship between these PDUs,Which is sent in response to which etc.. > > Thanx for the response.. > Looking forward to hear from you > Navaneeth. > > > Navaneetha Krishnan.N > Senior Software Engineer, > HDF, Future Software Pvt Ltd, > 480 - 481, Anna Salai, Nandanam, > Chennai - 600 035 > India. > Phone : +91-44-4330550 Ext.412 > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- From navaneethk@future.futsoft.com Thu, 23 Dec 1999 15:37:53 -0800 Date: Thu, 23 Dec 1999 15:37:53 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Help on ISIS PDUs Hi all... Thanx for your reponses.. Can anybody tell me in detail about the interactions or flow of the ESH,ISH and IIH PDUs.. I have read thru the rfcs 1142 & 1195 and also iso10589..all these talk of recieving ISH PDUs at an IS only in Poini-to-Point networks..but not in broadcast networks.Are these PDUs different in these 2 networks.What is applicable where? Can anyone please clarify this? Navaneetha Krishnan.N Senior Software Engineer, HDF, Future Software Pvt Ltd, 480 - 481, Anna Salai, Nandanam, Chennai - 600 035 India. Phone : +91-44-4330550 Ext.412 From hsmit@cisco.com Thu, 23 Dec 1999 18:37:39 +0100 (MET) Date: Thu, 23 Dec 1999 18:37:39 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] New version of draft-ietf-isis-domain-wide-02.txt > Some questions on the lastest draft. Yes, draft-ietf-isis-domain-wide-01.txt is the latest official version of that draft. However, a few weeks ago I posted a newer version, but I have not submitted it yet. I will probably do that in January (but I want to raise one more issue myself about external metrics). Please read this newer version. I hope it is more clear and will answer your questions. If not, please ask again. Thanks, Henk. ---- Network Working Group Tony Li INTERNET DRAFT Procket Networks Tony Przygienda Siara Systems Henk Smit Cisco Systems October 1999 Domain-wide Prefix Distribution with Two-Level IS-IS Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1.0 Abstract This document describes extensions to the IS-IS protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589 [1], with extensions for supporting IPv4 specified in RFC 1195 [2]. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. 2.0 Introduction An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) can be partitioned into multiple level 1 (L1) areas, and a level 2 (L2) connected subset of the topology that interconnects all of the L1 areas. Within each L1 area, all routers exchange link state information. L2 routers also exchange L2 link state information to compute routes between areas. RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that are used to transport IPv4 routing information in IS-IS. RFC 1195 also specifies the semantics and procedures for interactions between levels. Specifically, routers in a L1 area will exchange information within the L1 area. For IP destinations not found in the prefixes in the L1 database, the L1 router should forward packets to the nearest router that is in both L1 and L2 (i.e., an L1L2 router) with the "attached bit" set in its L1 Link State Protocol Data Unit (LSP). Also per RFC 1195, an L1L2 router should be manually configured with a set of prefixes that summarizes the IP prefixes reachable in that L1 area. These summaries are injected into L2. RFC 1195 specifies no further interactions between L1 and L2 for IPv4 prefixes. 2.1 Motivations for domain-wide prefix distribution The mechanisms specified in RFC 1195 are appropriate in many situations, and lead to excellent scalability properties. However, in certain circumstances, the domain administrator may wish to sacrifice some amount of scalability and distribute more specific information than is described by RFC 1195. This section discusses the various reasons why the domain administrator may wish to make such a tradeoff. One major reason for distributing more prefix information is to improve the quality of the resulting routes. A well know property of prefix summarization or any abstraction mechanism is that it necessarily results in a loss of information. This loss of information in turn results in the computation of a route based upon less information, which will frequently result in routes that are not optimal. A simple example can serve to demonstrate this adequately. Suppose that a L1 area has two L1L2 routers that both advertise a single summary of all prefixes within the L1 area. To reach a destination inside the L1 area, any other L2 router is going to compute the shortest path to one of the two L1L2 routers for that area. Suppose, for example, that both of the L1L2 routers are equidistant from the L2 source, and that the L2 source arbitrarily selects one L1L2 router. This router may not be the optimal router when viewed from the L1 topology. In fact, it may be the case that the path from the selected L1L2 router to the destination router may traverse the L1L2 router that was not selected. If more detailed topological information or more detailed metric information was available to the L2 source router, it could make a more optimal route computation. This situation is symmetric in that an L1 router has no information about prefixes in L2 or within a different L1 area. In using the nearest L1L2 router, that L1L2 is effectively injecting a default route without metric information into the L1 area. The route computation that the L1 router performs is similarly suboptimal. Besides the optimality of the routes computed, there are two other significant drivers for the domain wide distribution of prefix information. When a router learns multiple possible paths to external destinations via BGP, it will select only one of those routes to be installed in the forwarding table. One of the factors in the BGP route selection is the IGP cost to the BGP next hop address. Many ISP networks depend on this technique, which is known as "shortest exit routing". If a L1 router does not know the exact IGP metric to all BGP speakers in other L1 areas, it cannot do effective shortest exit routing. The third driver is the current practice of using the IGP (IS-IS) metric as part of the BGP Multi-Exit Discriminator (MED). The value in the MED is advertised to other domains and is used to inform other domains of the optimal entry point into the current domain. Current practice is to take the IS-IS metric and insert it as the MED value. This tends to cause external traffic to enter the domain at the point closest to the exit router. Note that the receiving domain may, based upon policy, choose to ignore the MED that is advertised. However, current practice is to distribute the IGP metric in this way in order to optimize routing wherever possible. This is possible in current networks that only are a single area, but becomes problematic if hierarchy is to be installed into the network. This is again because the loss of end-to-end metric information means that the MED value will not reflect the true distance across the advertising domain. Full distribution of prefix information within the domain would alleviate this problem as it would allow accurate computation of the IS-IS metric across the domain, resulting in an accurate value presented in the MED. 2.2 Scalability The disadvantage to performing the domain-wide prefix distribution described above is that it has an impact to the scalability of IS-IS. Areas within IS-IS help scalability in that LSPs are contained within a single area. This limits the size of the link state database, that in turn limits the complexity of the shortest path computation. Further, the summarization of the prefix information aids scalability in that the abstraction of the prefix information removes the sheer number of data items to be transported and the number of routes to be computed. It should be noted quite strongly that the distribution of prefixes on a domain wide basis impacts the scalability of IS-IS in the second respect. It will increase the number of prefixes throughout the domain. This will result in increased memory consumption, transmission requirements and computation requirements throughout the domain. It must also be noted that the domain-wide distribution of prefixes has no effect whatsoever on the first aspect of scalability, namely the existence of areas and the limitation of the distribution of the link state database. Thus, the net result is that the introduction of domain-wide prefix distribution into a formerly flat, single area network is a clear benefit to the scalability of that network. However, it is a compromise and does not provide the maximum scalability available with IS-IS. Domains that choose to make use of this facility should be aware of the tradeoff that they are making between scalability and optimality and provision and monitor their networks accordingly. Normal provisioning guidelines that would apply to a fully hierarchical deployment of IS-IS will not apply to this type of configuration. 3.0 Proposed syntax and semantics for L2->L1 inter-area routes This document defines the syntax of how to advertise level 2 routes in level 1 LSPs. The encoding is an extension of the encoding in RFC 1195. To some extent, in IS-IS the level 2 backbone can be seen as a separate area itself. RFC 1195 defines that L1L2 routers can advertise IP routes that were learned via L1 routing into L2. These routes can be regarded as inter-area routes. RFC 1195 defines that these L1->L2 inter-area routes must be advertised in L2 LSPs in the "IP Internal Reachability Information" TLV (TLV 128). Intra-area L2 routes are also advertised in L2 LSPs in an "IP Internal Reachability Information" TLV. Therefor L1->L2 inter-area routes are indistinguishable from L2 intra-area routes. RFC 1195 does not define L2->L1 inter-area routes. A simple extension would be to allow a L1L2 router to advertise routes learned via L2 routing in its L1 LSP. However, to prevent routing-loops, L1L2 routers must never advertise L2->L1 inter-area routes that they learn via L1 routing, back into L2. Therefor there must be a way to distinguish L2->L1 inter-area routes from L1 intra-area routes. Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for this purpose. RFC 1195 defines TLVs 128 and 130 to contain IP routes. TVLs 128 and 130 have a metric field that consists of 4 TOS metrics. The first metric, the so-called "default metric", has the high-order bit reserved (bit 8). Routers must set this bit to zero on transmission, and ignore it on receipt. This document redefines this high-order bit in the default metric field in TLVs 128 and 130 to be the up/down bit. L1L2 routers must set this bit to one for prefixes that are derived from L2 routing and are advertised into L1 LSPs. The bit must be set to zero for all other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down bit set that are learned via L1 routing, must never be advertised by L1L2 routers back into L2. 3.1 Clarification of external route-type and external metric-type RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is defined as "IP Internal Reachability Information", and should be used to carry IP prefixes that are directly connected to IS-IS routers. TLV 130 is defined as "IP External Reachability Information", and should be used to carry routes learned from outside the IS-IS domain. RFC 1195 documents TLV type 130 only for level 2 LSPs. RFC 1195 also defines two types of metrics. Metrics of the internal metric-type should be used when the metric is comparable to metrics used to weigh links inside the ISIS domain. Metrics of the external metric-type should be used if the metric of an IP prefix cannot be directly compared to internal metrics. External metric-type can only be used for external IP prefixes. A direct result is that metrics of external metric-type should never be seen in TLV 128. To prevent confusion, this document states again that when a router computes IP routes, it must give the same preference to IP routes advertised in an "IP Internal Reachability Information" TLV and IP routes advertised in an "IP External Reachability Information" TLV. RFC 1195 states this quite clearly in the note in paragraph 3.10.2, item 2c). This document does not alter this rule of preference. NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field), and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation. However, IP routes advertised in "IP External Reachability Information" with external metric-type must be given less preference than the same IP routes advertised with internal-metric type, regardless of the value of the metrics. While IS-IS routers must not give different preference to IP prefixes learned via "IP Internal Reachability Information" and "IP External Reachability Information" when executing the Dijkstra calculation, routers that implement multiple IGPs are free to use this distinction between internal and external routes when comparing routes derived from different IGPs for inclusion in their global RIB. 3.2 Definition of external IP prefixes in level 1 LSPs RFC 1195 does not define the "IP External Reachability Information" TLV for L1 LSPs. However, there is no reason why an IS-IS implementation could not allow for redistribution of external routes into L1. Some IS-IS implementations already allow network administrators to do this. This document loosens the restrictions in RFC 1195, and allows for the inclusion of the "IP External Reachability Information" TLV in L1 LSPs. RFC 1195 defines that IP routes learned via L1 routing must always be advertised in L2 LSPs in a "IP Internal Reachability Information" TLV. Now that this document allows "IP External Reachability Information" TLVs in L1 LSPs, and allows for the advertisement of routes learned via L2 routing into L1, the above rule needs a extensions. When a L1L2 router advertises a L1 route into L2, where that L1 route was learned via a prefix advertised in a "IP External Reachability Information" TLV, that L1L2 router should advertise that prefix in its L2 LSP within an "IP External Reachability Information" TLV. L1 routes learned via an "IP Internal Reachability Information" TLV should still be advertised within a "IP Internal Reachability Information" TLV. These rules should also be applied when advertising IP routes derived from L2 routing into L1. Of course in this case also the up/down bit must be set. RFC 1195 defines that if a router sees the same external prefix advertised by two or more routers with the same external metric, it must select the route that is advertised by the router that is closest to itself. It should be noted that now that external routes can be advertised from L1 into L2, and vice versa, that the router that advertises an external prefix in its LSP might not be the router that originally injected this prefix into the IS-IS domain. Therefor it is less useful to advertise external routes with external metrics into other levels. 4.0 Types of IP routes in IS-IS and their order of preference RFC 1195 and this document defines several ways of advertising IP routes in IS-IS. There are four variables involved. 1) The level of the LSP in which the route is advertised. There are currently two possible values: level 1 and level 2 2) The route-type, which can be derived from the type of TLV in which the prefix is advertised. Internal routes are advertised in IP Internal Reachability Information TLVs (TLV 128), and external routes are advertised in IP External Reachability Information TLVs (TLV 130). 3) The metric-type: Internal or External. The metric-type is derived from the Internal/External metric-type bit in the metric field (bit 7). 4) The fact whether this route is leaked down in the hierarchy, and thus can not be advertised back up. This information can be derived from the newly defined up/down bit in the default metric field. 4.1 Overview of all types of IP prefixes in IS-IS Link State PDUs The combination IP Internal Reachability Information and external metric-type is not allowed. Also the up/down bit is never set in L2 LSPs. This leaves us with 8 different types of IP advertisements in IS-IS. However, there are more than 8 reasons for IP prefixes to be advertised in IS-IS. The following tables describe the types of IP prefixes and how they are encoded. 1) L1 intra-area routes These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router. 2) L1 external routes These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. 3) L2 intra-area routes These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area routes. 4) L2 external routes These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes. 5) L1->L2 inter-area routes These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 128. These prefixes can not be distinguished from L2 intra-area routes. 6) L1->L2 inter-area external routes These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130. These prefixes can not be distinguished from L2 external routes. 7) L2->L1 inter-area routes These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in TLV 128. 8) L2->L1 inter-area external routes These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in L2 LSPs in TLV 130. 9) L1 external routes with external metric These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. 10) L2 external routes with external metric These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes with external metric. 11) L1->L2 inter-area external routes with external metric These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130 with external metrics. These prefixes can not be distinguished from L2 external routes with external metric. 12) L2->L1 inter-area external routes with external metric These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, metric-type is external metric. These IP prefixes are learned via L2 routing, and were derived during the L1 SPF computation from prefixes advertised in L2 LSPs in TLV 130 with external metrics. 4.2 Order of preference for all types of IP routes in IS-IS Unfortunately IS-IS cannot depend on metrics alone for route selection. Some types of routes must always preferred over others, regardless of the costs that were computed in the Dijkstra calculation. One of the reasons for this is that inter-area routes can only be advertised with a maximum metric of 63. Another reason is that this maximum value of 63 does not mean infinity (e.g. like a hop count of 16 in RIP denotes unreachable). Introducing a value for infinity cost in IS-IS inter-area routes would introduce counting- to-infinity behavior via two or more L1L2 routers, which would have a bad impact on network stability. The order of preference of IP routes in IS-IS is based on a few assumptions. - RFC 1195 defines that routes derived from L1 routing are preferred over routes derived from L2 routing. - The note in RFC 1195 paragraph 3.10.2, item 2c) defines that internal routes with internal metric-type and external prefixes with internal metric-type have the same preference. - RFC 1195 defines that external routes with internal metric-type are preferred over external routes with external metric type. - Routes derived from L2 routing are preferred over L2->L1 routes derived from L1 routing. Based on these assumptions, this document defines the following route preferences. 1) L1 intra-area routes with internal metric L1 external routes with internal metric 2) L2 intra-area routes with internal metric L2 external routes with internal metric L1->L2 inter-area routes with internal metric L1->L2 inter-area external routes with internal metric 3) L2->L1 inter-area routes with internal metric L2->L1 inter-area external routes with internal metric 4) L1 external routes with external metric 5) L2 external routes with external metric L1->L2 inter-area external routes with external metric 6) L2->L1 inter-area external routes with external metric 4.3 Additional notes on what prefixes to accept or advertise Paragraphs 4.1 and 4.2 enumerate all used IP route types in IS-IS. Besides these defined route types, the encoding used would allow for a few more potential combinations. One of them is the combination of "IP Internal Reachability Information" and external metric type. This combination should never be used when building an LSP. Upon receipt of an IP prefix with this combination, routers must ignore this prefix. Another issue would be the usage of the up/down bit in L2 LSPs. Because IS-IS is currently defined with two levels of hierarchy, there should never be a need to set the up/down bit in L2 LSPs. However, if IS-IS would ever be extended with more than two levels of hierarchy, L2-only (or L1L2) routers will need to be able to accept L2 IP routes with the up/down bit set. Therefor it is recommended that implementations ignore the up/down bit in L2 LSPs, and accept the prefixes in L2 LSPs regardless whether the up/down bit is set. This will allow for simpler migration once more than two levels of hierarchy are defined. Another detail that implementors should be aware of is the fact that L1L2 routers should only advertise in their L2 LSP those L1 routes that they use for forwarding themselves. They should not unconditionally advertise into L2 all prefixes from LSPs in the L1 database. Not all prefixes need to be advertised up or down the hierarchy. Implementations might allow for additional manual filtering or summarization to further bring down the number of inter-area prefixes they advertise in their LSPs. It is also recommended that the default configuration of L1L2 routers is to not advertise any L2 routes into L1 (see also paragraph 5.0). 5.0 Inter-operability with older implementations The solution in this document is not fully compatible with RFC 1195. It is an extension to RFC 1195. If routers do not use the new functionality of external L1 routes, nor L2->L1 inter-area routes, older implementations that strictly follow RFC 1195 will be compatible with newer implementations that follow this document. Implementations that do not accept the "IP External Reachability Information" TLV in L1 LSPs will not be able to compute external L1 routes. This could cause routing loops between L1-only routers that do understand external L1 routes for a particular destination, and L1-only routers that use the default route pointing the closest attached L1L2 router for that destination. Implementations that follow RFC 1195 should ignore bit 8 in the default metric field when computing routes. Therefor even older implementations that do not know of the up/down bit should be able to accept the new L2->L1 inter-area routes. These older implementations will install the new L2->L1 inter-area routes as L1 intra-area routes, but that in itself does not cause routing loops among L1-only routers. However, it is vital that the up/down bit is recognized by L1L2 routers. As has been stated before, L1L2 routers must never advertise L2->L1 inter-area routes back into L2. Therefor if L2 routes are advertised down into L1 area, it is required that all L1L2 routers in that area run software that understands the new up/down bit. Older implementations that follow RFC 1195 and do not understand the new up/down bit will threat the L2->L1 inter-area routes as L1 intra-area routes, and they will advertise these routes back into L2. This can cause routing loops, sub-optimal routing or extra routing instability. For this reason it is recommended that implementations by default do not advertise any L2 routes into L1. Implementations should force the network administrator to manually configure L1L2 routers to advertise any L2 routes into L1. 6.0 Comparisons with other proposals In [3], a new TLV is defined to transport IP prefix information. This TLV format also defines an up/down bit to allow for L2->L1 inter-area routes. [3] also defines a new TLV to describe links. Both TLVs have wider metric space, and have the possibility to define sub-TLVs to advertise extra information belonging to the link or prefix. The wider metric space in IP prefix TLVs allows for more granular metric information about inter-area path costs. To make full use of the wider metric space, network administrators must deploy both new TLVs at the same time. Deployment of [3] requires an upgrade of all routers in the network and a transition to the new TLVs. Such a network-wide upgrade and transition might not be an easy task. In this case, the solution defined in this document, which requires only an upgrade of L1L2 routers in selected areas, might be a good alternative to the solution defined in [3]. 5.0 Security Considerations This document raises no new security issues for IS-IS. 6.0 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)" [Also republished as RFC 1142] [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 [3] Smit, H., Li, T. "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-01.txt, work in progress 7.0 Authors' Addresses Tony Li Procket Networks 3910 Freedom Circle, Ste. 102A Santa Clara, CA 95054 Email: tli@procket.net Voice: ??? Tony Przygienda Siara Systems 300 Ferguson Drive, 2nd Floor Mountain View, CA 94043 Email: prz@siara.com Voice: +1 650 237 2173 Fax: +1 650 237 2179 Henk Smit Cisco Systems, Inc. 210 West Tasman Drive San Jose, CA 95134 Email: hsmit@cisco.com Voice: +31 20 342 3736 From navaneethk@future.futsoft.com Tue, 28 Dec 1999 10:05:09 -0800 Date: Tue, 28 Dec 1999 10:05:09 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Help on ISIS Hi all... All ISIS standard docs like rfc 1142,1195,iso10589 talk about broadcast abd PPP networks... Can any of you throw some light on how isis over ipv4 an be implemented to support X.25 and Frame relay networks? Thanx & Regards Navaneeth. Navaneetha Krishnan.N Senior Software Engineer, HDF, Future Software Pvt Ltd, 480 - 481, Anna Salai, Nandanam, Chennai - 600 035 India. Phone : +91-44-4330550 Ext.412 From prz@siara.com Wed, 17 Nov 1999 22:33:42 -0500 Date: Wed, 17 Nov 1999 22:33:42 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] draft-ietf-isis-traffic-01.txt "Christian E. Hopps" wrote: > > Henk Smit writes: > > If you want to mark an IP prefix as external, we can do it via sub-TLVs. > > My collegues Naiming Shen has been working on tagging/coloring IP > > prefixes. Similar to OSPF tags or BGP communities. Maybe we can > > introduce some "well known" tags, to indicate that some prefixes > > were redistributed from outside into ISIS. > > What about support of incomparable metrics (i.e, ospf's type 2 metric). > The idea being you import the metric form the other protocol into the > `external' metric and it takes precedence over the IGP metric (which is > used to break ties). > > You can add this as a new sub-TLV in another draft; however, then you > run into transition issues. Routing loops are easy to come by if you > give the external metric precendence in the SPF and then some router > ignores that sub-tlv. By defining this in the main draft you at least > eliminate trying to transition twice. > > Since I don't have a lot of operational experience I'd like to ask: is > an incomparable external metric perceived as a gratuitous addition? I > was under the impression that it was used just about anytime you wanted > to import an EGP (or some aggregates of the EGP) into the IGP. Christian, I thought that adding an external metric into 135 would be a good thing to do since it's such a well-known "color" to borrow Henk's view of the world. However, from the customers of the protocol (those I checked with) I didn't hear any violent uproar telling me that they couldn't live without so my interpretation was taht we can let it pass that way and spend energy otherwise. Actually, thinking deeper, it was just telling me that nobody re-distributes today from/into ISIS heavily and doesn't intend to ;-) but as soon as they do the issue may arise. If you really want an external metric that is worse than any internal metric and interoperate with other people without agreeing on coloring your implementation could set the highest bit in the long-metric field considering If an IP prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see below), this IP prefix should not be considered during the normal SPF computation. This will allow advertisment of an IP prefix for other purposes than building the normal IP routing table. anything with 0x1000000 and above would be external. You'd just assume nobody ever comes with an internal metric > 0x1000000. I know it's a hack and I wouldn't recommend it and as I said I'd rather see the external bit with the appropriate preference in SPF being spelled out but I leave it to the customers to push that one if it's necessary. thanks -- tony