From vleeschh@sh.bel.alcatel.be Wed, 05 Jan 2000 17:58:00 +0100 Date: Wed, 05 Jan 2000 17:58:00 +0100 From: Hans De Vleeschouwer A0 VR233 58223 vleeschh@sh.bel.alcatel.be Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr Hi, I am trying to work my way through the the ISIS MIB defintion. In doing so, I have a question wrt the field isisManAreaAddr in the mib table IsisManAreaAddrEntryTable: Does this field contain only the area address, or does it also include the actual systemid (i.e. the full NET)? >From the description field, I would assume that only the area id is included, however this seems to be contradicted by looking at its type defintion (being OSINSAddress). Any help is kindly appreciated. Kind regards, hans. From jparker@nexabit.com Wed, 5 Jan 2000 13:11:27 -0500 Date: Wed, 5 Jan 2000 13:11:27 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr > Hi, > > I am trying to work my way through the the ISIS MIB defintion. > > In doing so, I have a question wrt the field isisManAreaAddr > in the mib > table IsisManAreaAddrEntryTable: > > Does this field contain only the area address, or does it also include > the actual systemid (i.e. the full NET)? > > From the description field, I would assume that only the area id is > included, however this seems to be contradicted by looking at its type > defintion (being OSINSAddress). > > Any help is kindly appreciated. > > Kind regards, > hans. Hans - It is only the area portion. I could add another type parallel to the OSINSAddress, but this is the orginal form, and it holds exactly what is needed. - jeff parker isisManAreaAddr OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A manually configured area address for this system. This object follows the index behaviour." ::= { isisManAreaAddrEntry 2 } From jparker@nexabit.com Fri, 7 Jan 2000 09:42:15 -0500 Date: Fri, 7 Jan 2000 09:42:15 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr > Hi Jeff, > > Thanks for your reply. > > I am really going through the MIB field by field now. ... > I am not quite sure whether I can contact you with those directly, or > wether I should keep on posting them to the newsgroup? Hans - If you think it isn't of general interest, you might send it only to me. I would rather see traffic to the list, for the selfish reason that I will need at some point to make the case that there has been public comment on the draft. It may also serve to keep me honest. Thus I'm going to copy the list on this reply. > In the mean time I came upon with another question related to the > field isisSysMaxAreaAddresses in the isisSysTable. > > The MIB indicates that the value of this field ranges between > 0 and 254. To be honest, this value is 3. It is 3 in all existing implementations, and it is a show stopper if two implementations don't agree. My ToDo list (see below) has the line isisSysMaxAreaAddresses should be 1..3, not 0..254 You could argue that it should be 3..3 instead. My current ToDo list includes the following items: I do intend to rev the draft this millennium. - jeff parker isisL2SummAddrTable isisL2SummAddrOperState change to AdminState The table name should change to IsisSummAddr instead of IsisL2SummAddr Cisco supports summarization at level-1 also and we have implemented an extended OperState to add this capability Remove isisCircManL2Only - replaced by isisCircLevel CircOperstate should be read-only Only isisCircISISL2HelloMultiplier - should be 2, or one, or none. isisSysMaxAreaAddresses should be 1..3, not 0..254 What is the story with IS(2) vs L1 and L2 below? isisISAdjNeighSysType OBJECT-TYPE SYNTAX INTEGER { unknown(1), intermediateSystem(3), l1IntermediateSystem(4), l2IntermediateSystem(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the neighboring system." REFERENCE "{ISIS.aoi neighbourSystemType (80)}" ::= { isisISAdjEntry 6 } Don't use IP addresses as index - summary table and IP reach table Split off optional parameters Overload bit Compliance - grouping Add boolean to mark L2 to L1 leaking Add Auth Type for MD5 Auth key will need to be a table (Rx values) Clarify UpTime From jparker@nexabit.com Fri, 7 Jan 2000 12:30:23 -0500 Date: Fri, 7 Jan 2000 12:30:23 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr > > To be honest, [isisSysMaxAreaAddresses] is 3. > > It is 3 in all existing implementations, and it is > > a show stopper if two implementations don't agree. > > ... > Just for the record, in IOS, since about a year, you can configure > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement > an ISIS MIB (yet). But I implemented it because of pressure that > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also > note that ADMs usually only implement CLNS routing, not IP routing. > For CLNS routing multiple isisSysMaxAreaAddresses is a little more > usefull. Still bad network design, IMHO. Oh, and I don't think any > of our customers use it. ;-) > > Henk. I think Henk has just demonstrated the importance of keeping such conversations on the list. Thanks, Henk! - jeff From Mkontoff@Kontoff.com Fri, 07 Jan 2000 13:47:26 -0500 Date: Fri, 07 Jan 2000 13:47:26 -0500 From: Matthew Kontoff Mkontoff@Kontoff.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr Jeff Parker wrote: > > > > To be honest, [isisSysMaxAreaAddresses] is 3. > > > It is 3 in all existing implementations, and it is > > > a show stopper if two implementations don't agree. > > > > ... > > Just for the record, in IOS, since about a year, you can configure > > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement > > an ISIS MIB (yet). But I implemented it because of pressure that > > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also > > note that ADMs usually only implement CLNS routing, not IP routing. > > For CLNS routing multiple isisSysMaxAreaAddresses is a little more > > usefull. Still bad network design, IMHO. Oh, and I don't think any > > of our customers use it. ;-) The Avici TSR supports 1..255 area addresses. Matt From rsaluja@nortelnetworks.com Fri, 07 Jan 2000 14:02:09 -0500 Date: Fri, 07 Jan 2000 14:02:09 -0500 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr Why can't this be 0 ? Do you need at least one manual area address for L2-only router also? To me, it seems that isisSysMaxAreaAddresses can be 0..X. Thanks, Rajesh Matthew Kontoff wrote: > Jeff Parker wrote: > > > > > > To be honest, [isisSysMaxAreaAddresses] is 3. > > > > It is 3 in all existing implementations, and it is > > > > a show stopper if two implementations don't agree. > > > > > > ... > > > Just for the record, in IOS, since about a year, you can configure > > > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement > > > an ISIS MIB (yet). But I implemented it because of pressure that > > > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also > > > note that ADMs usually only implement CLNS routing, not IP routing. > > > For CLNS routing multiple isisSysMaxAreaAddresses is a little more > > > usefull. Still bad network design, IMHO. Oh, and I don't think any > > > of our customers use it. ;-) > > The Avici TSR supports 1..255 area addresses. > > Matt > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From jparker@nexabit.com Fri, 7 Jan 2000 15:20:30 -0500 Date: Fri, 7 Jan 2000 15:20:30 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr What is at stake is the maximum -allowed- (isisSysMaxAreaAddresses) not the number of entries in use (the size of isisManAreaAddrTable.) While a size of 0, 1, 2, or 3 are conceivable for this table, I hope we can agree that we wouldn't want a router that didn't allow the user to include 3 Manual Areas, if the user is so foolish as to want that. I did notice the following MIB variable, which suggests I was hasty in calling this a show stopper (see isisSysMaxAreaCheck) The conclusion I will draw from this is that existing practice allows the variable be 3..255. - jeff parker isisSysMaxAreaCheck OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When on, enables checking of maximum area addresses per IS version of ISO10589." DEFVAL { 1 } ::= { isisSysEntry 36 } [Messages edited] > Why can't this be 0 ? Do you need at least one manual area address for > L2-only router also? To me, it seems that > isisSysMaxAreaAddresses can be 0..X. > > Rajesh > > > > > > To be honest, [isisSysMaxAreaAddresses] is 3. > > > > > It is 3 in all existing implementations, and it is > > > > > a show stopper if two implementations don't agree. > > > > > > > > > > Jeff Parker > > > > > > > > Just for the record, in IOS, since about a year, you > > > > can configure isisSysMaxAreaAddresses 3..254. > > > > > > > > Henk Smit > > > > The Avici TSR supports 1..255 area addresses. > > > > Matt Kontoff From Radia.Perlman@East.Sun.COM Fri, 7 Jan 2000 15:42:39 -0500 (EST) Date: Fri, 7 Jan 2000 15:42:39 -0500 (EST) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr > > To be honest, [isisSysMaxAreaAddresses] is 3. > > It is 3 in all existing implementations, and it is > > a show stopper if two implementations don't agree. > > Having this be a parameter is, in my opinion, really silly. It's one of the things that the ISO committee added, along with ID size, that seems like unnecessary flexibility, and as Henk pointed out, everyone in the area has to have the same values or it won't work. The reason for area address, if I recall, is so that you can detect accidentally merging two areas, so they have different names. In CLNP it also told level 1 routers what prefixes should be routed via level 1 (look at the bottom 6 ...er ID_length... bytes) or sent to a level 2 router. The reason it's nice to allow more than one area address is to be able to merge or split up areas while the net's running. To merge A and B, add B as an allowable address to A, and A to B, and then when everyone agrees on both names, then one by one turn off one of the addresses. There's really no reason to need 3 -- 2 suffices but 3 seemed like a good idea at the time, maybe so you could simultaneously merge 3 areas, or perhaps it allowed you to be lazy about removing an area address for awhile, but certainly there's no reason to need 107 area addresses! It would be nice to leave it fixed at 3 and remove it from the MIB, I'd think. Radia From jjl@one.com Fri, 07 Jan 2000 16:39:49 -0500 Date: Fri, 07 Jan 2000 16:39:49 -0500 From: Jeff Learman jjl@one.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr Rajesh, Some implementations may permit it to be provisioned to zero, but only because 0 in the PDU actually means "use the standard default of 3". At least one area address is absolutely required to do any CLNP routing at all, which is what IS-IS was originally designed for. A level 2 router is, according to the IS-IS spec "also a level 1 router in its own area", although there may be some implementations that skirt this issue. Practically speaking, though, there isn't any advantage to setting the value below three -- since it has to be the same for all ISs in the area, it's a bad idea to change it from the default of 3 unless you really need to (or *feel* you need to). Jeff At 02:02 PM 1/7/00 -0500, Rajesh Saluja wrote: >Why can't this be 0 ? Do you need at least one manual area address for >L2-only router also? To me, it seems that >isisSysMaxAreaAddresses can be 0..X. > >Thanks, >Rajesh > > >Matthew Kontoff wrote: > >> Jeff Parker wrote: >> > >> > > > To be honest, [isisSysMaxAreaAddresses] is 3. >> > > > It is 3 in all existing implementations, and it is >> > > > a show stopper if two implementations don't agree. >> > > > >> > ... >> > > Just for the record, in IOS, since about a year, you can configure >> > > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement >> > > an ISIS MIB (yet). But I implemented it because of pressure that >> > > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also >> > > note that ADMs usually only implement CLNS routing, not IP routing. >> > > For CLNS routing multiple isisSysMaxAreaAddresses is a little more >> > > usefull. Still bad network design, IMHO. Oh, and I don't think any >> > > of our customers use it. ;-) >> >> The Avici TSR supports 1..255 area addresses. >> >> Matt >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- > >------------------------------------------------------------- >Rajesh Saluja >Nortel Networks Inc 600 Technology Park Billerica, MA 01821 >Ph: (978) 288-7791 Fax: (978) 670-8760 >-------------------------------------------------------------- > > > > >_______________________________________________ >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 jharper@cisco.com Fri, 07 Jan 2000 21:45:40 +0000 Date: Fri, 07 Jan 2000 21:45:40 +0000 From: John Harper jharper@cisco.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr And in fact, it was more or less deliberate perversity on our part at the time to make it this way. We (those of us who worked on the original design at DEC and subsequently took it into ISO) thought the idea of having this as a parameter was really stupid (as Radia says), and we certainly weren't going to waste any of our neurones figuring out how to make misconfiguration recover gracefully, as we generally tried to do in the parts of the protocol that we cared about. Why anyone would see it as a feature to be able to set this to 8 boggles my mind. "I really like this Ferrari, but Caterpillar make vehicles with 96 wheels." "OK signor, in V550.1 we'll add the 96 wheel feature". John At 15:42 07/01/00 -0500, Radia Perlman - Boston Center for Networking wrote: >> > To be honest, [isisSysMaxAreaAddresses] is 3. >> > It is 3 in all existing implementations, and it is >> > a show stopper if two implementations don't agree. >> > > >Having this be a parameter is, in my opinion, really silly. It's >one of the things that the ISO committee added, along with ID size, >that seems like unnecessary flexibility, and as Henk pointed out, >everyone in the area has to have the same values or it won't work. > >The reason for area address, if I recall, is so that you can detect >accidentally merging two areas, so they have different names. In CLNP >it also told level 1 routers what prefixes should be routed via >level 1 (look at the bottom 6 ...er ID_length... bytes) or sent to >a level 2 router. > >The reason it's nice to allow more than one area address is to be able >to merge or split up areas while the net's running. To merge A and B, >add B as an allowable address to A, and A to B, and then when everyone >agrees on both names, then one by one turn off one of the addresses. >There's really no reason to need 3 -- 2 suffices but 3 seemed >like a good idea at the time, maybe so you could simultaneously merge >3 areas, or perhaps it allowed you to be lazy about removing an area >address for awhile, but certainly there's no reason to >need 107 area addresses! > >It would be nice to leave it fixed at 3 and remove it from the MIB, I'd >think. > >Radia > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > From mshand@cisco.com Sat, 08 Jan 2000 10:41:49 +0000 Date: Sat, 08 Jan 2000 10:41:49 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr At 15:42 07/01/2000 -0500, Radia Perlman - Boston Center for Networking wrote: >The reason it's nice to allow more than one area address is to be able >to merge or split up areas while the net's running. To merge A and B, >add B as an allowable address to A, and A to B, and then when everyone >agrees on both names, then one by one turn off one of the addresses. >There's really no reason to need 3 -- 2 suffices but 3 seemed >like a good idea at the time, maybe so you could simultaneously merge >3 areas, or perhaps it allowed you to be lazy about removing an area >address for awhile, but certainly there's no reason to >need 107 area addresses! It was to do with DECnet Phase IV compatibility Radia. Typically an area would have two area addresses, a Phaseiv compatible one, and a real OSI one. So that makes two. Now if you want to merge/split the OSI area you need another one. I think that was the argument anyway. Mike ps. and yes I think a value other than 3 is silly too. From jparker@nexabit.com Sun, 9 Jan 2000 13:35:52 -0500 Date: Sun, 9 Jan 2000 13:35:52 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr While I don't want to claim I understand exactly what Cisco is trying to do, and while I haven't seen any documentation of what Avici is trying to do, I suspect the issue is supporting multiple L1 domains on a single router, not supporting multiple areas in a single domain. That is, I suspect that each of the L1 domains has a single area address: perhaps 2 when needed, and it may wish to implement upto 3. I don't think anyone is talking about recognizing 254 different Areas in the same domain. I would rather capture this as different SysInstances, each running with a different area address, which can then summarize the collection of routes learned into a common L2. I will try to clarify the language surrounding isisSysMaxAreaAddresses, to make clear that this is the Maximum Area Addresses in one Domain. A name change may help that effort. - jeff parker > At 15:42 07/01/2000 -0500, Radia Perlman - Boston Center for > Networking wrote: > >The reason it's nice to allow more than one area address is > to be able > >to merge or split up areas while the net's running. To merge A and B, > >add B as an allowable address to A, and A to B, and then > when everyone > >agrees on both names, then one by one turn off one of the addresses. > >There's really no reason to need 3 -- 2 suffices but 3 seemed > >like a good idea at the time, maybe so you could simultaneously merge > >3 areas, or perhaps it allowed you to be lazy about removing an area > >address for awhile, but certainly there's no reason to > >need 107 area addresses! > > It was to do with DECnet Phase IV compatibility Radia. > Typically an area > would have two area addresses, a Phaseiv compatible one, and > a real OSI > one. So that makes two. Now if you want to merge/split the > OSI area you > need another one. I think that was the argument anyway. > > Mike > > ps. and yes I think a value other than 3 is silly too. From mshand@cisco.com Mon, 10 Jan 2000 08:28:53 +0000 Date: Mon, 10 Jan 2000 08:28:53 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr At 13:35 09/01/2000 -0500, Jeff Parker wrote: >While I don't want to claim I understand exactly what Cisco is >trying to do, and while I haven't seen any documentation of >what Avici is trying to do, I suspect the issue is supporting >multiple L1 domains on a single router, not supporting multiple >areas in a single domain. The two issues are pretty much orthogonal. The former is useful; the latter is not. Mike From vleeschh@sh.bel.alcatel.be Mon, 10 Jan 2000 12:02:44 +0100 Date: Mon, 10 Jan 2000 12:02:44 +0100 From: Hans De Vleeschouwer A0 VR233 58223 vleeschh@sh.bel.alcatel.be Subject: [Isis-wg] Another question wrt to the isisSysTable hi, I have followed the discussion related to the isisSysTable field isisSysMaxAreaAddresses with great interest. For now, I think I will stick to the solution where: 1. the value can range between 1 and 3 2. the default value = 3 This will imply that a request to change the field isisSysOperState to 'on' will be rejected if no entry exists in the isisManAddrTable for this system instance. Now I have a different question related to the field isisSysAuthAreaType. I already understand from Jeff Parker that this field will be extended to allow also MD5 as authentication method. However, I still have the following questions: 1. The description talks about 'protecting L1 LSPs' . However, If I look at the RFC1195, it seems that authentication can apply to all types of messages, not only to LSP PDU. e.g. authentication can be applied to L1 Hello PDUs. Is there any reason to authenticate only the LSP PDU? 2. The value of the field is set to read-write. Would it make sense to state that this object follows the 'replaceOnlyWhileDisabled behavior' ? Kind regards, Hans De Vleeschouwer (alcatel Belgium). From jparker@nexabit.com Mon, 10 Jan 2000 09:49:55 -0500 Date: Mon, 10 Jan 2000 09:49:55 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Another question wrt to the isisSysTable > I have followed the discussion related to the isisSysTable field > isisSysMaxAreaAddresses with great interest. > > For now, I think I will stick to the solution where: > 1. the value can range between 1 and 3 > 2. the default value = 3 > > This will imply that a request to change the field isisSysOperState to > 'on' will be rejected if no entry exists in the isisManAddrTable for > this system instance. > > Now I have a different question related to the field > isisSysAuthAreaType. > I already understand from Jeff Parker that this field will be extended > to allow also MD5 as authentication method. > > However, I still have the following questions: > 1. The description talks about 'protecting L1 LSPs' . > However, If I look > at the RFC1195, it seems that authentication can apply to all types of > messages, not only to LSP PDU. e.g. authentication can be > applied to L1 Hello PDUs. There are four Authentication types: isisSysAuthAreaType - level 1 pkts isisSysAuthDomainType - level 2 pkts isisCircL1PasswordType- level 1 hellos isisCircL2PasswordType- level 2 hellos > Is there any reason to authenticate only the LSP PDU? The dominant implementation only protects the LSPs with the Area and Dommain values. > 2. The value of the field is set to read-write. Would it > make sense to > state that this object follows the 'replaceOnlyWhileDisabled > behavior' ? I need to review this with my SNMP gurus - I don't want to allow these to be set via SNMP for obvious security reasons. > > Kind regards, > Hans De Vleeschouwer (alcatel Belgium). From zinin@amt.ru Wed, 12 Jan 2000 12:21:25 +0300 Date: Wed, 12 Jan 2000 12:21:25 +0300 From: Alex Zinin zinin@amt.ru Subject: [Isis-wg] New ID: draft-ietf-ospf-refresh-guide-00.txt Hello, all A new I-D that can be interesting for the OSPF and IS-IS WGs has been submitted to the IETF directories : "Guidelines for Efficient LSA Refreshment in OSPF" http://www.ietf.org/internet-drafts/draft-ietf-ospf-refresh-guide-00.txt The abstract section from the I-D follows: OSPF, an IGP widely deployed in IP networks today, requires each LSA to be refreshed by the originating router every 30 minutes. This method increases the protocol's robustness and solves potential problems that may be caused by software bugs, as well as some properties of the protocol itself. Though OSPF expects each LSA to be refreshed independently, ABRs and ASBRs tend to originate Type 3/4/5 LSAs within a short period of time, thus causing periodical network resource exhaustion by LSA refreshments. This document discusses the techniques that can be used to remedy this problem and provide smooth protocol operation. It must be noted that discussed methods can be applied to other link-state routing protocols, such as IS-IS. I would like to encourage everyone to send their comments, corrections and questions. Please use the address of the OSPF WG list (OSPF@DISCUSS.MICROSOFT.COM) for postings. It is ok to send the notes to me directly. ALSO, anyone feeling [s]he can contribute something to the document is welcomed to co-author. Best regards, Alex. From tangcm@future.futsoft.com Wed, 12 Jan 2000 18:37:59 +0530 Date: Wed, 12 Jan 2000 18:37:59 +0530 From: Jorge tangcm@future.futsoft.com Subject: [Isis-wg] ask a question . Hi, everyone I am a new member of IS-IS Group. Now i am engaged in the work of implementation for IS-IS over IPv4. i am a newcomer for IS-IS procotol,My dout is that going through all of IS-IS document,i cann't find the content for how the IS-IS over IPv4 protocol supporting the X.25 ,Frame-Relay ,multi-link access network.who can give me some advice for it, i will very appreciated.you know ,i am eager to get those answer.Thanks in advance. HuaWei Development Facility of CHINA Future Software Private Limited 480-481,Mount Road,Nandanam, Chennai-600 -35.Inida From zinin@amt.ru Wed, 12 Jan 2000 19:15:56 +0300 Date: Wed, 12 Jan 2000 19:15:56 +0300 From: Alex Zinin zinin@amt.ru Subject: [Isis-wg] ask a question . Other people will add some input here if my answer is not complete. One way of dealing with NBMA media is assigning the VCs to logical point-to-point or multipoint interfaces. IS-IS is then enabled on the logical rather then physical interfaces, but transmission of a packet over a logical interface results in sending the packet through the physical one. Sending an IP packet over a p-t-p interface is simple, since the layer-2 details are either not necessary (in case of physical links) or predetermined (in case of logical links). Having split the VCs you basically represent an NBMA cloud as a set of p-t-p links. Another way (also used for multipoint logical interfaces) is treating the NBMA cloud as a broadcast media. This requires providing (manually or dynamically as in the case of FR) the information on which VCs should multicast packets be sent over. So, the router replicates the IP packets and sends the copies over each involved VCs. This, of course, implies that you have your VCs fully meshed. Regards, Alex. Wednesday, January 12, 2000, 4:07:59 PM, Jorge wrote: J> Hi, everyone J> I am a new member of IS-IS Group. Now i am engaged in the work of implementation for IS-IS over IPv4. i am a newcomer for IS-IS procotol,My dout is that going through all of IS-IS J> document,i cann't find the content for how the IS-IS over IPv4 protocol supporting the X.25 ,Frame-Relay ,multi-link access network.who can give me some advice for it, i will very appreciated.you J> know ,i am eager to get those answer.Thanks in advance. J> HuaWei Development Facility of CHINA J> Future Software Private Limited J> 480-481,Mount Road,Nandanam, J> Chennai-600 -35.Inida J> _______________________________________________ J> Isis-wg mailing list - Isis-wg@external.juniper.net J> http://external.juniper.net/mailman/listinfo/isis-wg From jjl@one.com Wed, 12 Jan 2000 11:32:57 -0500 Date: Wed, 12 Jan 2000 11:32:57 -0500 From: Jeff Learman jjl@one.com Subject: [Isis-wg] ask a question . At 07:15 PM 1/12/00 +0300, Alex Zinin wrote: >Other people will add some input here >if my answer is not complete. > >One way of dealing with NBMA media >is assigning the VCs to logical point-to-point >or multipoint interfaces. IS-IS is then >enabled on the logical rather then physical >interfaces, but transmission of a packet >over a logical interface results in sending >the packet through the physical one. >Sending an IP packet over a p-t-p interface >is simple, since the layer-2 details are >either not necessary (in case of physical links) >or predetermined (in case of logical links). >Having split the VCs you basically represent >an NBMA cloud as a set of p-t-p links. > >Another way (also used for multipoint logical >interfaces) is treating the NBMA cloud as a >broadcast media. This requires providing (manually >or dynamically as in the case of FR) the information >on which VCs should multicast packets be sent over. >So, the router replicates the IP packets and >sends the copies over each involved VCs. >This, of course, implies that you have your VCs >fully meshed. This should be done with great care (or not at all). In general, it's important to send routing protocol traffic the same way data would be sent, as much as possible. Otherwise, you run the risk of thinking there is a data connection where there is none, or of incomplete distribution of routing information. In particular, pay careful attention to IS-IS's transitivity requirement for broadcast networks -- that is, if A can hear B and B can hear C, then A must be able to hear C. This rule would be easy to violate in a misprovisioned NBMA network, and would probably lead to serious connectivity problems. Regareds, Jeff >Regards, >Alex. > >Wednesday, January 12, 2000, 4:07:59 PM, Jorge wrote: > >J> Hi, everyone >J> I am a new member of IS-IS Group. Now i am engaged in the work of implementation for IS-IS over IPv4. i am a newcomer for IS-IS procotol,My dout is that going through all of IS-IS >J> document,i cann't find the content for how the IS-IS over IPv4 protocol supporting the X.25 ,Frame-Relay ,multi-link access network.who can give me some advice for it, i will very appreciated.you >J> know ,i am eager to get those answer.Thanks in advance. > >J> HuaWei Development Facility of CHINA >J> Future Software Private Limited >J> 480-481,Mount Road,Nandanam, >J> Chennai-600 -35.Inida > > >J> _______________________________________________ >J> Isis-wg mailing list - Isis-wg@external.juniper.net >J> 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 > > ____________________________________________________________________ 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 navaneethk@future.futsoft.com Thu, 13 Jan 2000 12:00:23 -0800 Date: Thu, 13 Jan 2000 12:00:23 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] ISH PDU.. Hi all.. In the context of ISIS over IP , I have a doubt as to how the ISH PDUs will be handled and by whom... ISO 10589 1992 mentions that as a exception, ISH PDUs will have to be handled on PPP links when they first come up.. ISO 10589 1998 mentions that the ISIS shall cause ES-IS (9542 protocol machine) to send the ISH PDUs on PPP links.. So Who handles ISH PDU? ES-IS or IS-IS. In a pure IP implementation of ISIS we are not to take care of of ES-IS..In this case who sends the ISH PDU... If it is responsibilty of ES-IS, then why the standard talks about IS sendinh ISH in ISIS document.. Please clarify.. 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 Resi: 91 044 4338421 (After 10 P.M , Before 8 A.M) From navaneethk@future.futsoft.com Thu, 13 Jan 2000 12:01:02 -0800 Date: Thu, 13 Jan 2000 12:01:02 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] ISH PDU.. Hi all.. In the context of ISIS over IP , I have a doubt as to how the ISH PDUs will be handled and by whom... ISO 10589 1992 mentions that as a exception, ISH PDUs will have to be handled on PPP links when they first come up.. ISO 10589 1998 mentions that the ISIS shall cause ES-IS (9542 protocol machine) to send the ISH PDUs on PPP links.. So Who handles ISH PDU? ES-IS or IS-IS. In a pure IP implementation of ISIS we are not to take care of of ES-IS..In this case who sends the ISH PDU... If it is responsibilty of ES-IS, then why the standard talks about IS sendinh ISH in ISIS document.. Please clarify.. Navaneeth. From kim@telia.net Thu, 13 Jan 2000 23:26:38 +0100 Date: Thu, 13 Jan 2000 23:26:38 +0100 From: Michael Kim kim@telia.net Subject: [Isis-wg] BCP for building Integrated IS-IS Network Hi! I have som question about design issue of the Integrated IS-IS network. Network is 200-300 nodes. Should this network be buildt with multiple level-1 IS-IS area and 1 level-2 IS-IS area or should this be buildt with just big one level-1-2 IS-IS area. I prefer to build network with the first alternative because in the first alternative will keep the database small on the routers. It will take few ms to recalculate SPF. I got recommendation from some vendor that network with this size it will be the best to build with just one big level-1-2 area. Reason is that there will be just one database so it will take less time to recalculate SPF. In the first case there will be some routers talking both level-1 and level-2 so there will be 2 database on those router and for those routers it will take longer time to recalculate SPF. But I think this is wrong becase in second alternative all the router is talking level-1 and level-2 so all of the router will have one level-1 and one level-2 database with bigger LSDB. It will increase recalculation time. Do I think right? Is there any BCP document other recommendation document for build IS-IS network? Thank You in advances /michael From hsmit@cisco.com Thu, 13 Jan 2000 16:46:24 -0800 (PST) Date: Thu, 13 Jan 2000 16:46:24 -0800 (PST) From: hsmit@cisco.com hsmit@cisco.com Subject: [Isis-wg] BCP for building Integrated IS-IS Network > Hi! > I have som question about design issue of the Integrated IS-IS network. > Network is 200-300 nodes. > > Should this network be buildt with multiple level-1 IS-IS area and 1 > level-2 IS-IS area or should this be buildt with just big one level-1-2 > IS-IS area. This all depends on the strength of the IS-IS implementation of your vendor. And on the type of routers that you are using. I know at least one vendor where you can build areas with a 1000+ routers, if you buy their high end boxes. > I prefer to build network with the first alternative because in the > first alternative will keep the database small on the routers. It will > take few ms to recalculate SPF. Yes, the SPFs will be cheaper. But you run two of them. Also the mathemetical part of the SPF is usually not that expensive. Route installation (and FIB updates) is typically more expensive. Also when you use a lot of inter-area routes (L1->L2), it doesn't matter much if you deal with complexity of inter-area routes, or the complexity of SPF and intra-area routes. All this is just IMHO, and from experience with one implementation. The benefits of using multiple areas are: 1) a little more protection against link flaps 2) ability to extend your network easier. once your network grows so much that you finally really need multipkle areas, you have already layed them out 3) you can do summarization and filtering between area/level boundaries Drawbacks: 1) added configuration and troubleshooting complexity 2) if you do BGP, the fact that L1 areas are stub areas can give you troubles. (Giving MED to customers, doing shortest-exit-routing, etc). BTW, in some implementations L1 areas are more like NSSA. Also you can now do route-leaking with the old TLVs, or with the newer TLVs. See the recent drafts. > I got recommendation from some vendor that network with this size it > will be the best to build with just one big level-1-2 area. Reason is > that there will be just one database so it will take less time to > recalculate SPF. In the first case there will be some routers talking > both level-1 and level-2 so there will be 2 database on those router and > for those routers it will take longer time to recalculate SPF. I would say the main reason to run 200-300 routers in one area is simplicity. Why bother with multiple areas if you can get away with just one. > But I > think this is wrong becase in second alternative all the router is > talking level-1 and level-2 so all of the router will have one level-1 > and one level-2 database with bigger LSDB. It will increase > recalculation time. > > > Do I think right? I think the duration of SPF computation is not really relevant to the design of your network. > Is there any BCP document other recommendation document for build IS-IS > network? Don't think so. > Thank You in advances Hope this helps, Henk. > /michael > > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From danny@qwest.net Thu, 13 Jan 2000 19:33:20 -0700 Date: Thu, 13 Jan 2000 19:33:20 -0700 From: Danny McPherson danny@qwest.net Subject: [Isis-wg] BCP for building Integrated IS-IS Network I agree with Henk's comments. We run a single area L2-only domain with a couple hundred routers, other places I've worked had 350+ in a single domain. The primary reasons for not introducing hierarchy are those Henk mentioned: o Inability to derive accurate BGP MED values o L1 routers defaulting to closest L2 router can result in sub-optimal routing. o Troubleshooting is a bit more complex The ability to route leak does make a multi-level IS-IS network more appealing, though it's certainly not worth the complexity trade-offs at this point, or anywhere in the foreseeable future. I didn't see Henk mention it, but it would perhaps also seem that while a multi-level network is a bit more protected against potential of instabilities introduced by link oscillation, a single level network should converge slightly faster, though the gain is probably negligible. As for the SPF runtimes, they don't seem at all concerning in our network today. We use two different vendor implementations and SPF runtimes seem to be ~200 microseconds per node. We don't have any NBMA stuff or psuedonodes though, so the size of the LSDB is probably pretty small in comparison to other networks. -danny From rja@corp.home.net Fri, 14 Jan 2000 11:08:52 -0500 Date: Fri, 14 Jan 2000 11:08:52 -0500 From: Ran Atkinson rja@corp.home.net Subject: [Isis-wg] BCP for building Integrated IS-IS Network IMHO, the analyses in recent emails (e.g. Henk's) would be useful to document in a short Informational RFC. Ran rja@corp.home.net From emmanuel.dauvergne@cnet.francetelecom.fr Fri, 14 Jan 2000 17:27:42 +0100 Date: Fri, 14 Jan 2000 17:27:42 +0100 From: DAUVERGNE Emmanuel CNET/DAC/ISS emmanuel.dauvergne@cnet.francetelecom.fr Subject: [Isis-wg] BCP for building Integrated IS-IS Network I'm not an MPLS expert, but I'm also thinking about the following drawback (in multi-level) : o Complexity in MPLS environnement : Inability to setup an LSP between two PE located in different L1-areas (stub areas). As Henk mentionned for MED calculation, this issue is solved with route-leaking concept. Manu > ---------- > De : Danny McPherson[SMTP:danny@qwest.net] > Répondre à : danny@ice.ip.qwest.net > Date : vendredi 14 janvier 2000 03:33 > A : hsmit@cisco.com > Cc : kim@telia.net; isis-wg@juniper.net > Objet : Re: [Isis-wg] BCP for building Integrated IS-IS Network > > > I agree with Henk's comments. > > We run a single area L2-only domain with a couple hundred routers, other > places I've worked had 350+ in a single domain. The primary reasons for > not > introducing hierarchy are those Henk mentioned: > > o Inability to derive accurate BGP MED values > o L1 routers defaulting to closest L2 router can result in sub-optimal > routing. > o Troubleshooting is a bit more complex > > The ability to route leak does make a multi-level IS-IS network more > appealing, though it's certainly not worth the complexity trade-offs at > this > point, or anywhere in the foreseeable future. > > I didn't see Henk mention it, but it would perhaps also seem that while a > multi-level network is a bit more protected against potential of > instabilities > introduced by link oscillation, a single level network should converge > slightly faster, though the gain is probably negligible. > > As for the SPF runtimes, they don't seem at all concerning in our network > today. We use two different vendor implementations and SPF runtimes seem > to > be ~200 microseconds per node. We don't have any NBMA stuff or > psuedonodes > though, so the size of the LSDB is probably pretty small in comparison to > other networks. > > -danny > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From tangcm@future.futsoft.com Mon, 17 Jan 2000 10:01:12 +0530 Date: Mon, 17 Jan 2000 10:01:12 +0530 From: Jorge tangcm@future.futsoft.com Subject: [Isis-wg] Problem for Support Frame Relay . This is a multi-part message in MIME format. ------=_NextPart_000_004E_01BF60D1.C8E8E200 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGkgLA0KICAgIE5vdyBpIG1ldCBzb21lIHByb2JsZW0gYWJvdXQgSVMtSVMgb24gSVB2NC5XZSB3 YW50IHRvICBpbXBsZW1lbnQgdGhlIElTLUlTIHRvIHN1cHBvcnQgdGhlIEZyYW1lIFJlbGF5ICxi dXQgaSB3YW50IHRvICBrbm93IGhvdyBpIGNhbiBpbXBsZW1lbnQgaXQgLkp1c3QgYXMgc29tZW9u ZSBzYWlkIGluIHByaW8gbWFpbHMgLHRvIHJlZ2FyZCB0aGUgRnJhbWUgUmVsYXkgYXMgbXVsdGlw bGUgUFBQIGxpbmtzICxpIHRoaW5rICx0aGlzIG1ldGhvZCBjYW4gYmUgZml0YWJsZSBmb3IgUFZD LCBidXQgaG93IHRvIGRlYWwgd2l0aCBTVkMsaSBkb24ndCBrbm93IHdoZXRoZXIgaXMgbWVhbnMg d2UgZG9uJ3QgbmVlZCB0byBjYXJlIGFib3V0IFNWQyAscGxlYXNlICBnaXZlIHNvbWUgYWR2aWNl IGZvciBtZS4gIFRoYW5rcyBhIGxvdCENCg== ------=_NextPart_000_004E_01BF60D1.C8E8E200 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yMDE0LjIxMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj5oaSAsPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNw OyBOb3cgaSBtZXQgc29tZSBwcm9ibGVtIGFib3V0IElTLUlTIA0Kb24gSVB2NC5XZSB3YW50IHRv ICBpbXBsZW1lbnQmbmJzcDt0aGUgSVMtSVMgdG8gc3VwcG9ydCB0aGUgRnJhbWUgUmVsYXkgLGJ1 dCBpIA0Kd2FudCB0byZuYnNwOyBrbm93IGhvdyBpIGNhbiBpbXBsZW1lbnQgaXQgLkp1c3QgYXMg c29tZW9uZSZuYnNwO3NhaWQgaW4gcHJpbyANCm1haWxzICx0byByZWdhcmQgdGhlIEZyYW1lIFJl bGF5IGFzIG11bHRpcGxlIFBQUCBsaW5rcyANCixpJm5ic3A7dGhpbmsmbmJzcDssdGhpcyZuYnNw O21ldGhvZCZuYnNwO2NhbiZuYnNwO2JlIGZpdGFibGUgDQpmb3ImbmJzcDtQVkMsJm5ic3A7YnV0 IGhvdyZuYnNwO3RvIGRlYWwgd2l0aCZuYnNwO1NWQyxpIA0KZG9uJ3QmbmJzcDtrbm93Jm5ic3A7 d2hldGhlciZuYnNwO2lzIG1lYW5zJm5ic3A7d2UgZG9uJ3QgbmVlZCZuYnNwO3RvIGNhcmUgDQph Ym91dCZuYnNwO1NWQyZuYnNwOyxwbGVhc2UmbmJzcDsgZ2l2ZSZuYnNwO3NvbWUmbmJzcDthZHZp Y2UgZm9yIG1lLiZuYnNwOyANClRoYW5rcyBhIGxvdCE8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRN TD4NCg== ------=_NextPart_000_004E_01BF60D1.C8E8E200-- From jjl@one.com Mon, 17 Jan 2000 11:01:03 -0500 Date: Mon, 17 Jan 2000 11:01:03 -0500 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Problem for Support Frame Relay . It's not important whether the links are PVCs or SVCs, it's just important that they're "statically assigned". In other words, they have to be opened at startup time and in general, kept open the whole time. If you need to have the links open and close on an as-needed basis, then you can't use IS-IS to exchange routing information over them. It's OK if you want to shut down a link; just keep in mind that it won't be opened automatically if it is needed for data traffic. If the Frame Relay links are to end systems, then it isn't a problem. I'ts only a problem if the links are between routers, and you need to exchange IS-IS routing information between them. The reason is that IS-IS relies on the fact that all routers in an area (or for level 2, all L2 routers in the domain) must agree on the topology. In order for this to work, they need to be in constant communication. Therefore, "dynamically assigned" links, those that come up and go down on an as-needed basis, aren't appropriate for links between routers (simply because they're always needed.)=20 Regards, Jeff At 10:01 AM 1/17/00 +0530, Jorge wrote:=20 >>>> =CB=CE=CC=E5hi , Now i met some problem about IS-IS on IPv4.We want to implement the IS-IS to support the Frame Relay ,but i want to know how i can implement it .Just as someone said in prio mails ,to regard the Frame Relay as multiple PPP links ,i think ,this method can be fitable for PVC, but how to deal with SVC,i don't know whether is means we don't need to care about SVC ,please give some advice for me. Thanks a lot! <<<<<<<< ____________________________________________________________________ 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 zinin@amt.ru Mon, 17 Jan 2000 19:27:25 +0300 Date: Mon, 17 Jan 2000 19:27:25 +0300 From: Alex Zinin zinin@amt.ru Subject: Re[2]: [Isis-wg] Problem for Support Frame Relay . Hmmm...I wouldn't say so. One can easily run IS-IS (or any other dynamic routing proto) over on-demand circuits provided that the idle timer doesn't close the VC before the next Hello PDU is sent over it. This is, actually, how these things are done in a number of implementations. As for Jorge's question---when SVCs are used, just make sure the SVC is open before sending anything along it. If it is not---generate a request for the circuit manager asking it to open the VC. This is assumed to be done in the IP-to-Layer2 part of the code, not in IS-IS. Just like with PVSs, mapping statements for SVCs are marked to be used for broadcast/multicast propagation. HTH Alex. Monday, January 17, 2000, 7:01:03 PM, Jeff Learman wrote: > It's not important whether the links are PVCs or SVCs, it's > just important that they're "statically assigned". In other > words, they have to be opened at startup time and in general, > kept open the whole time. If you need to have the links open > and close on an as-needed basis, then you can't use IS-IS > to exchange routing information over them. It's OK if you > want to shut down a link; just keep in mind that it won't be > opened automatically if it is needed for data traffic. > If the Frame Relay links are to end systems, then it isn't a > problem. I'ts only a problem if the links are between routers, > and you need to exchange IS-IS routing information between them. > The reason is that IS-IS relies on the fact that all routers > in an area (or for level 2, all L2 routers in the domain) must > agree on the topology. In order for this to work, they need to > be in constant communication. Therefore, "dynamically assigned" > links, those that come up and go down on an as-needed basis, > aren't appropriate for links between routers (simply because > they're always needed.) > Regards, > Jeff > At 10:01 AM 1/17/00 +0530, Jorge wrote: >>>>> > ËÎÌåhi , > Now i met some problem about IS-IS on IPv4.We want to implement the > IS-IS to support the Frame Relay ,but i want to know how i can implement > it .Just as someone said in prio mails ,to regard the Frame Relay as > multiple PPP links ,i think ,this method can be fitable for PVC, but how > to deal with SVC,i don't know whether is means we don't need to care > about SVC ,please give some advice for me. Thanks a lot! > > <<<<<<<< > ____________________________________________________________________ > 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 zinin@amt.ru Mon, 17 Jan 2000 19:54:53 +0300 Date: Mon, 17 Jan 2000 19:54:53 +0300 From: Alex Zinin zinin@amt.ru Subject: Re[2]: [Isis-wg] Problem for Support Frame Relay . Monday, January 17, 2000, 7:43:07 PM, Tony Przygienda wrote: > again, first a problem statement would be nice to make sure > we're all tackling the same problem. Well, I think Jorge's initial messages are quite clear on that---running IS-IS over NBMA media. ...and whichever issues related :) > 2nd, Alex, you're oversimpliofying here ;-) Tony, I'm not. I'm just correcting the statement that on-demand VCs cannot be used with IS-IS. > Just "running" > the protocol that way leads to extensive thrashing of up&downs > of the circuit Quoting myself: "...provided that the idle timer doesn't close the VC before the next Hello PDU is sent over it." Note "doesn't" above. I think you misunderstood me a bit. I'm not proposing to open a VC for every packet and close it afterwards, I'm saying one doesn't need to emulate PVCs using SVCs. > [and therefore billing, if you don't get billed for your > FR or ATM service, you may as well always leave the circuit up ;-)], > a usable solution needs more thought like in OSPF > (don't age bits, smart adjacency stay-up and couple of more details) Agree. Alex. From prz@siara.com Mon, 17 Jan 2000 11:43:07 -0500 Date: Mon, 17 Jan 2000 11:43:07 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Problem for Support Frame Relay . Alex Zinin wrote: > Hmmm...I wouldn't say so. > One can easily run IS-IS (or any other dynamic routing > proto) over on-demand circuits provided that the idle > timer doesn't close the VC before the next Hello PDU > is sent over it. > > This is, actually, how these things are done in a number > of implementations. > > As for Jorge's question---when SVCs are used, just make > sure the SVC is open before sending anything along it. > If it is not---generate a request for the circuit manager > asking it to open the VC. This is assumed to be done > in the IP-to-Layer2 part of the code, not in IS-IS. > Just like with PVSs, mapping statements for SVCs are > marked to be used for broadcast/multicast propagation. again, first a problem statement would be nice to make sure we're all tackling the same problem. 2nd, Alex, you're oversimpliofying here ;-) Just "running" the protocol that way leads to extensive thrashing of up&downs of the circuit [and therefore billing, if you don't get billed for your FR or ATM service, you may as well always leave the circuit up ;-)], a usable solution needs more thought like in OSPF (don't age bits, smart adjacency stay-up and couple of more details) thasnk -tony > HTH > > Alex. > > Monday, January 17, 2000, 7:01:03 PM, Jeff Learman wrote: > > It's not important whether the links are PVCs or SVCs, it's > > just important that they're "statically assigned". In other > > words, they have to be opened at startup time and in general, > > kept open the whole time. If you need to have the links open > > and close on an as-needed basis, then you can't use IS-IS > > to exchange routing information over them. It's OK if you > > want to shut down a link; just keep in mind that it won't be > > opened automatically if it is needed for data traffic. > > > If the Frame Relay links are to end systems, then it isn't a > > problem. I'ts only a problem if the links are between routers, > > and you need to exchange IS-IS routing information between them. > > > The reason is that IS-IS relies on the fact that all routers > > in an area (or for level 2, all L2 routers in the domain) must > > agree on the topology. In order for this to work, they need to > > be in constant communication. Therefore, "dynamically assigned" > > links, those that come up and go down on an as-needed basis, > > aren't appropriate for links between routers (simply because > > they're always needed.) > > > Regards, > > Jeff > > > At 10:01 AM 1/17/00 +0530, Jorge wrote: > > >>>>> > > > ËÎÌåhi , > > > Now i met some problem about IS-IS on IPv4.We want to implement the > > IS-IS to support the Frame Relay ,but i want to know how i can implement > > it .Just as someone said in prio mails ,to regard the Frame Relay as > > multiple PPP links ,i think ,this method can be fitable for PVC, but how > > to deal with SVC,i don't know whether is means we don't need to care > > about SVC ,please give some advice for me. Thanks a lot! From prz@siara.com Fri, 14 Jan 2000 17:07:18 -0500 Date: Fri, 14 Jan 2000 17:07:18 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] BCP for building Integrated IS-IS Network DAUVERGNE Emmanuel CNET/DAC/ISS wrote: 1. Ran's comment on the issues being worth written down is good but I assume I cannot interpret that as equal to volunteering to do it ;-) ?? > I'm not an MPLS expert, but I'm also thinking about the following drawback > (in multi-level) : > > o Complexity in MPLS environnement : Inability to setup an LSP between two > PE located in different L1-areas (stub areas). 2. there is some current thinking by the usual suspects how to solve the problem. I expect some kind of solution to gel. thanks -- tony From prz@siara.com Sun, 16 Jan 2000 23:52:41 -0500 Date: Sun, 16 Jan 2000 23:52:41 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Problem for Support Frame Relay . Jorge wrote: > hi , Now i met some problem about IS-IS on IPv4.We want to implement the IS-IS to support the Frame Relay ,but i want to know how i can implement it .Just as someone said in > prio mails ,to regard the Frame Relay as multiple PPP links ,i think ,this method can be fitable for PVC, but how to deal with SVC,i don't know whether is means we don't need to > care about SVC ,please give some advice for me. Thanks a lot! seems that the issue is being rised of whether we need support for ISIS in terms of P2M as OSPF has (and not of ISIS over IPv4 as the confusing topic and text suggests). It is a non-trivial (and not the most elegant and intuitive) extension to the protocol and probably only worth doing if customer demand exists. I think I pinged once on this list whether the potential customers have interest in P2M for ISIS with 0 answers. So I'd consider the issue not worth tackling for the moment since if there is nobody to deploy it, why put the effort in ? Just run SVCs and FR in P2P mode. However, if someone out there is implementing something proprietary to support P2M, it's probably much better that a draft shows up, rather than struggle with proprietary, incompatible (and probably buggy due to lack of review by knowledgable parties) later. thanks -- tony From prz@siara.com Mon, 17 Jan 2000 11:26:07 -0500 Date: Mon, 17 Jan 2000 11:26:07 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Problem for Support Frame Relay . Jeff Learman wrote: > It's not important whether the links are PVCs or SVCs, it's > just important that they're "statically assigned". In other > words, they have to be opened at startup time and in general, > kept open the whole time. If you need to have the links open > and close on an as-needed basis, then you can't use IS-IS > to exchange routing information over them. It's OK if you > want to shut down a link; just keep in mind that it won't be > opened automatically if it is needed for data traffic. > > If the Frame Relay links are to end systems, then it isn't a > problem. I'ts only a problem if the links are between routers, > and you need to exchange IS-IS routing information between them. > > The reason is that IS-IS relies on the fact that all routers > in an area (or for level 2, all L2 routers in the domain) must > agree on the topology. In order for this to work, they need to > be in constant communication. Therefore, "dynamically assigned" > links, those that come up and go down on an as-needed basis, > aren't appropriate for links between routers (simply because > they're always needed.) I'm not clear which problem this thread is pursuiting. Are we talking about the problem of partial meshes (P2M mode) or are we talking about the problem of dynamic FR circuits (SVCs) coming up ? Both problems have solutions (P2M mode or dial-up link extensions that allow the circuit to be shut down but adjacency maintained) but this whole "ISIS and FR" needs a short problem definition before solutions are being tossed around, I'd say. More important even, is anyone from the customers on this list interested in running ISIS over FR ? htankas -=-tony From nrsoma@pluris.com Mon, 17 Jan 2000 10:49:02 -0800 Date: Mon, 17 Jan 2000 10:49:02 -0800 From: Nageswara Rao Soma nrsoma@pluris.com Subject: [Isis-wg] Passive interface Hi, Somewhere I read that only routing updates are not sent over passive interfaces. However, neighbors' updates are received and processed over passive interfaces without affecting adjacencies. Could someone please explain me little more about this? Advance thanks for any help. Soma. PS: Forgive me if have not sent to correct mailing list address. From dkatz@juniper.net Mon, 17 Jan 2000 11:32:37 -0800 (PST) Date: Mon, 17 Jan 2000 11:32:37 -0800 (PST) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Passive interface Passive interfaces are a figment of implementation, rather than of specmanship. For LS protocols, the implementations with which I'm familiar will advertise passive interfaces as internal routes, but don't attempt to do any protocol handling at all (since it doesn't make a whole lot of sense and wouldn't work anyhow). For periodic DV protocols (i.e., RIP and IGRP), passive usually means that you're receiving the updates (since they're being blindly sent) but not sending anything back. This is the classic RIP-as-a- router-discovery-protocol mode. From: Nageswara Rao Soma Hi, Somewhere I read that only routing updates are not sent over passive interfaces. However, neighbors' updates are received and processed over passive interfaces without affecting adjacencies. From zinin@amt.ru Tue, 18 Jan 2000 14:27:31 +0300 Date: Tue, 18 Jan 2000 14:27:31 +0300 From: Alex Zinin zinin@amt.ru Subject: Re[2]: [Isis-wg] Problem for Support Frame Relay . Tuesday, January 18, 2000, 12:14:54 AM, Tony Przygienda wrote: >> >> Tony, I'm not. I'm just correcting the statement >> that on-demand VCs cannot be used with IS-IS. > this part you don't, right. But after that you're saying it's easy and doesn't > need anything, that's at least slightly oversimplifying. You can run it that > way but you'll stop pretty soon after the montly bills come. If you don't > beleive me, try an ISDN link with OSPF active ;-) Tony, I'm a Russian, not stupid :) Just, please, don't read between the lines. When I say "x != y", I don't mean "(log(x) > sin(z))&&(exp(z) < log10(y))" Similarly, when I say "IS-IS *can* be easily run over SVCs" in contrast to "SVCs cannot be used with IS-IS", it doesn't mean "Guys, come on! Don't care about your money!"... I agree, however, that P2M and on-demand circuits are two different problems. This thread is more about the second issue, I believe. Sorry for BW wastage. Alex. From selvarajr@future.futsoft.com Mon, 24 Jan 2000 21:42:11 +0530 Date: Mon, 24 Jan 2000 21:42:11 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubts in MIB and SNDF Hi, I'm implementing Integrated ISIS protocol which is very new for me . I've the following doubts. 1. In the MIB draft, draft-ietf-isis-wg-mib-02.txt , for Integrated ISIS It has been stated that , isisSystem table contains information specific to a single instance of ISIS protocol running on a router. Does this means more than one Integrated ISIS runs on a single machine ? If yes, what is the purpose of having more than one instance in a single machine and where does it apply. 2. In ISO 10589 1998, in SNDF for PPP , it has been mentioned setting circuit ID Status after receiving IIH PDU ( section 8.2.5.2( c ) ) . What is the significance of this circiut ID status? Also there is no such MIB object. Please , clarify me. Thanx in advance Selva From hsmit@cisco.com Fri, 28 Jan 2000 20:06:51 +0100 (MET) Date: Fri, 28 Jan 2000 20:06:51 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] Concerns about ISIS in IP encapsulation During the IETF ISIS WG meeting in Oslo we had a bit of a discussion about the proposal for ISIS in IP encapsulation. (See draft-ietf-isis-wg-over-ip-01.txt for details). At that meeting, I have voiced my concerns about the proposal. I had prepared an email to send to this list long time ago. But there was never a compeling reason to bring up the subject again. Let me try to recap some of the discussion. Benefits of ISIS in IP encapsulation. A) ISIS-in-IP improves the efficiency of ATM when using ISIS as IP IGP. My opinion: - This true. But had I hope my proposal was a more simple and easier solution for this problem. (See draft-hsmit-isis-ip-aal5mux-00.txt). Last summer I have emailed two of our largest ISIS+ATM customers that I had the code ready, but they didn't seem much interested. Now I wonder how bad ISPs really want to improve the efficiency of the ISIS+ATM combo. B) ISIS-in-IP prevents the need of defining OSI/ISIS encapses every time a new layer2 technology is emerging. - This is true. But it is very likely that native OSI/ISIS encapsulations will be defined for new layer2 technologies anyway. E.g. CLNS itself is not dead yet. CLNS is not relevant in the Internet, and probably not in Enterprise networks. But RBOCs are using CLNS for their management networks for their Sonet/SDH infrastructure. So native OSI/ISIS/CLNS will be around for a while, so there will be new encapsulations for OSI/ISIS/CLNS defined. C) ISIS-in-IP improves portability of gated. - Personally I don't care much about this. While people might not expect this from a cisco employee, I do like open source software. But I think that new technology should not be based on what is easy to implement in one particular operating system (even if it is Unix). Also the fact remains that all current ISIS implementation run native over layer2, so if gated or any other ISIS implementation wants any acceptance in the real world, it still needs to implement ISIS-in-layer2 encapsulation. D) ISIS-in-IP might improve the acceptance of ISIS in circles of IP bigots. - IMHO people who don't like ISIS won't suddenly like it because they can now encapsulate ISIS in IP. Now the drawbacks: 1) Why add a second method of encapsulation ? ISIS-over-IP doesn't solve a real problem. If the efficiency of ISIS+ATM is really an issue for some customers, this could be solved by using the first byte in the IP header as NLPID. Maybe we can get away without a more complex solution. If we solve this problem just for ATM (actually just for "aal5mux ip"), then if ATM becomes less popular in a couple of years (at least in highspeed networks), we can forget about this hack. If we do ISIS-over-IP we will be stuck with it forever. See IPX. 2) It adds more complexity to the protocol. One of the reasons some people like ISIS over OSPF is the fact that ISIS is simpler in some areas. We are now adding all kinds of features and extensions. If we add too many, ISIS will be worse than OSPF in this respect. Personally I would hate to see that happen. 3) It adds more complexity to the configuration. The less configuration choices there are, the easier ISIS will be to deploy. Look at a similar case: IPX. It has four encapsulations. There are no benefits to that, just added confusion. 4) IP fragmentation. I think that people will not move whole networks at the same time. They will run hybrid networks with ISIS-over-layer2 and ISIS-over-IP. That in itself will add complexity. I am sure customers won't configure smaller LSP buffer sizes on all their routers. At least not until their network really breaks. So I am afraid that LSP will be fragmented at the IP layer. Note, if a router has more than 1492 bytes of info to advertise into ISIS, that router must fragment its LSP. It will probably create a first LSP of size 1492, and at least one small LSP. That first LSP of size 1492 will be fragmented at the IP layer on links that have an MTU of 1500 and run ISIS-over-IP. So a router that redistributes more than 100 IP routes or so will have at least one LSP of size 1492. Right now lots of ISIS networks I know run in a single flat area. But if they ever do true L1L2, the L1L2 routers will advertise lots of interarea routes. So most likely the L1L2 routers will all create LSP fragments of size 1492. As you all know, link-state protocols have two areas of concern regarding scalability. One is route computation, and the other is flooding. I think fragmentation at the IP layer will make ISIS flooding less scalable. I was told by one of editors of 10589 that preventing fragmentation during the flooding was the main reason why ISIS fragments only at the originating router. BTW, I am not so much concerned about fragmentation, but more about reassambly. 5) Consistency towards other standards bodies. The ISIS-over-IP draft recommends that routers use an LSPBufferSize of 1480 (or rather 1472) bytes. In the Sonet/SDH/Telco world the Sonet Interoperability Forum (SIF) works on ISIS too. They want to run ISIS over the DCC. The DCC channel is a part of the bandwidth of a Sonet/SDH ring. The Bellcore spec for DCC says that the DCC must use LAPD encaps, and that the *maximum* MTU is 512 bytes. So you can't run ISIS over the DCC, because some routers might send LSPs of size larger than 512 bytes. Those LSPs can not be flooded over the DCC. So the SIF wanted to add some cruft to 10589 that changes the LSPBufferSize from 1492 to 512 bytes. I am heavily opposed to that. But if the ISIS WG in the IETF recommends to lower the LSPBufferSize from 1492 to 1480, why not lower it to 512 ? We will not be able to defend ourselves to changes like the proposal from the SIF. To be honest, I don't know about the latest status on the SIF proposal. It actually might have been withdrawn. 6) Security. ISIS-over-layer2 is actually a feature. ISIS packets are not routable. It makes sure that nobody but your direct physical neighbors can inject routing packets into your IGP. Suppose a network uses ISIS-over-IP. That means I can send ISIS packets from my PC at home to any router in that network. It is easy to fake source IP addresses. So I can inject LSPs into this network, or do other nasty things, like break adjacencies, etc. So now this network needs to use ISIS authentication. Probably strong authentication, like HMAC/MD5 (not cleartext passwords). But still if that is done, I can send a 1000 LSPs/second to those routers. And they need to check the authentication, which might use lots of CPU power. Or I can send IP fragments, which will use buffers. All kinds of nasty denial of service attacks come to mind. I guess these attacks could be applicable to OSPF today, so the OSPF people might already have a solution which we can use. But I would like to point out that ISIS-over-layer2 is a feature. 7) What about IPv6 ? If we ever get around to define TLVs to do IPv6 routing in ISIS, which encapsulation would it use ? A nice thing about ISIS is that ISIS packets are not encapsulated in CLNS, and not in IP. Now if we add ISIS-over-IPv4, we might end up in a situation where we will have to define an ISIS-over-IPv6 encapsulation too. What if routing for other layer3 protocols gets defined ? Will we add an encapsulation for that layer3 too ? 8) Why not encapsulate in CLNS as well ? 10589 defines virtual links for area repair. Those virtual links use CLNS encapsulation to get packets across the L2 backbone. Extra complexity for little gain. (The gain would be that networks with a broken design seem a little less broken). That added complexity was one of the reasons why I have discourge my employer from implementing virtual links and area partition repair. Once we implement virtual links for area partition repair, we probably will have to support area partitioning for IP as well. The result will be that if gated and others want to stay compatible with current features, they might have to implement a full CLNS stack, just to be able to deal with area partition repair. Just ISIS-over-layer2 encapsulation will not be enough anymore. Some comments on my concerns. - Curtis Villamizer said that networks don't run their IGP over 10 Mbps ethernet anymore. ISPs use POS, ATM, FDDI, Fast Ethernet and Gigabit Ethernet. Those layer2 technology all can have MTUs of 1512 or higher. 10 Mbps ethernet is only used at the edges towards the hosts. I guess that is correct. So fragmentation migh occur less often then I fear. After all, the large NBMA meshes are mostly over ATM today, which has a larger MTU. However, enterprise networks might run ISIS over 10 Mbps Ethernet. And some router implementations use standard MTUs of 1500 on their serial (PPP, HDLC, frame-relay) interfaces. To use larger MTUs over FE and Gig-ethernet we need the new encapsulation, which might cause other problems (like on bridges). So I am not fully convinced yet that fragmentation won't be a problem. Thank you for your attention, Henk. From pst@juniper.net Fri, 28 Jan 2000 15:02:33 -0800 Date: Fri, 28 Jan 2000 15:02:33 -0800 From: Paul Traina pst@juniper.net Subject: [Isis-wg] Concerns about ISIS in IP encapsulation Allow me to reiterate my support (and Dave's) from Oslo. I really like Henk's proposal (draft-hsmit-isis-ip-aal5mux-00.txt), and Dave has pointed out that this is well within the expected behavior for OSI protocols. With Henk's proposal as a tool for solving the MUX encaps issues of ATM and similar encapsulations that are incapable of carrying a ptype, I do not see any great need for IS-IS to be reimplemented to use IP as a transport layer. Your IGPs may as well be multi-protocol. The world is already a happy place. Paul From wrath@cs.umbc.edu Fri, 28 Jan 2000 18:15:00 -0500 (EST) Date: Fri, 28 Jan 2000 18:15:00 -0500 (EST) From: Vijay Gill wrath@cs.umbc.edu Subject: [Isis-wg] Concerns about ISIS in IP encapsulation On Fri, 28 Jan 2000, Henk Smit wrote: > Benefits of ISIS in IP encapsulation. > A) ISIS-in-IP improves the efficiency of ATM when using ISIS as IP IGP. > > My opinion: > - This true. But had I hope my proposal was a more simple and easier > solution for this problem. (See draft-hsmit-isis-ip-aal5mux-00.txt). > Last summer I have emailed two of our largest ISIS+ATM customers > that I had the code ready, but they didn't seem much interested. > Now I wonder how bad ISPs really want to improve the efficiency > of the ISIS+ATM combo. I'll speak to this point briefly. As the promising local ISP I work for transitions from IP over ATM to Packet over SONET, the effort to deploy the above proposals doesn't give us a good enough return. Two years ago, yes; today, the benefits are not that glaringly obvious given the transitioning already in place. /vijay From danny@qwest.net Fri, 28 Jan 2000 16:19:44 -0700 Date: Fri, 28 Jan 2000 16:19:44 -0700 From: Danny McPherson danny@qwest.net Subject: [Isis-wg] Concerns about ISIS in IP encapsulation To chime is as "an operator", I agree. I don't see any significant advantages with deploying it in my network, other than the job security that comes along introducing new complexities into a system. Am I missing something? -danny > Allow me to reiterate my support (and Dave's) from Oslo. I really like > Henk's proposal (draft-hsmit-isis-ip-aal5mux-00.txt), and Dave has pointed > out that this is well within the expected behavior for OSI protocols. > > With Henk's proposal as a tool for solving the MUX encaps issues of ATM and > similar encapsulations that are incapable of carrying a ptype, I do not see > any great need for IS-IS to be reimplemented to use IP as a transport layer. > Your IGPs may as well be multi-protocol. The world is already a happy > place. From danny@qwest.net Fri, 28 Jan 2000 16:19:43 -0700 Date: Fri, 28 Jan 2000 16:19:43 -0700 From: Danny McPherson danny@qwest.net Subject: [Isis-wg] Concerns about ISIS in IP encapsulation To chime is as "an operator", I agree. I don't see any significant advantages with deploying it in my network, other than the job security that comes along introducing new complexities into a system. Am I missing something? -danny > Allow me to reiterate my support (and Dave's) from Oslo. I really like > Henk's proposal (draft-hsmit-isis-ip-aal5mux-00.txt), and Dave has pointed > out that this is well within the expected behavior for OSI protocols. > > With Henk's proposal as a tool for solving the MUX encaps issues of ATM and > similar encapsulations that are incapable of carrying a ptype, I do not see > any great need for IS-IS to be reimplemented to use IP as a transport layer. > Your IGPs may as well be multi-protocol. The world is already a happy > place. From chopps@merit.edu 29 Jan 2000 15:04:51 -0500 Date: 29 Jan 2000 15:04:51 -0500 From: Christian E. Hopps chopps@merit.edu Subject: [Isis-wg] Concerns about ISIS in IP encapsulation Henk Smit writes: > C) ISIS-in-IP improves portability of gated. This of course was my fault, and was not the intent of what I was trying to say. People who were at the meeting will recall that I was asked to give an example of system that might not have OSI available. I too quickly fired off, ``well e.g., someone using gated on unix''. I unfortunetly mentioned an implementation and so it seemed like a at least a few people ``latched'' that and didn't actually take the statement in context. GateD has support for OSI/CLNS. So this is not a GateD issue. As you point out: if your going to do an IS-IS, right now, you have to support CLNS encapsulation. > - Personally I don't care much about this. While people might not > expect this from a cisco employee, I do like open source software. > But I think that new technology should not be based on what is > easy to implement in one particular operating system (even if > it is Unix). > Also the fact remains that all current ISIS implementation run > native over layer2, so if gated or any other ISIS implementation > wants any acceptance in the real world, it still needs to implement > ISIS-in-layer2 encapsulation. A huge amount of networking research occurs on Unix systems. To toss Unix out as unimportant to the internet or routing protocols seems unwise to me. Some Unix vendors even have OSI support e.g., NetBSD, BSDI and I think Digital/Compaq. The BSD stacks, at least, are aging, poorly, mostly through lack of use. I think the only point I'd like to make WRT to this discussion is that: CLNS is dead to most of the world. Maybe IS-IS will continue to drag the dead horse along with it, and maybe IS-IS will continue to be a mostly unknown or unpopular routing protocol for most people. I think this would be sad. Why should such a nice protocol be restricted to only the elite in routing? Thanks, Chris. P.S. I found many of Henk's comments worthwhile and well though out, specifically with regards to issues facing us today. Other than what I've said above I choose not to disagree with any of them. From lester-ginsberg@vertel.com Mon, 31 Jan 2000 11:09:34 -0800 Date: Mon, 31 Jan 2000 11:09:34 -0800 From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] Concerns about ISIS in IP encapsulation > > 5) Consistency towards other standards bodies. > The ISIS-over-IP draft recommends that routers use an LSPBufferSize > of 1480 (or rather 1472) bytes. In the Sonet/SDH/Telco world > the Sonet Interoperability Forum (SIF) works on ISIS too. > They want to run ISIS over the DCC. The DCC channel is a part of > the bandwidth of a Sonet/SDH ring. The Bellcore spec for DCC > says that the DCC must use LAPD encaps, and that the *maximum* > MTU is 512 bytes. So you can't run ISIS over the DCC, because > some routers might send LSPs of size larger than 512 bytes. > Those LSPs can not be flooded over the DCC. > So the SIF wanted to add some cruft to 10589 that changes the > LSPBufferSize from 1492 to 512 bytes. I am heavily opposed to > that. But if the ISIS WG in the IETF recommends to lower the > LSPBufferSize from 1492 to 1480, why not lower it to 512 ? > We will not be able to defend ourselves to changes like the > proposal from the SIF. > To be honest, I don't know about the latest status on the SIF > proposal. It actually might have been withdrawn. > To clarify the position presented by SIF - SIF never proposed changing the LSPBufferSize. The current spec allows values of 512-1492, though most folks prefer to use 1492 whenever possible - which, as Henk points out is not possible over the SONET DCC. What SIF did propose is to define TLVs to allow the detection of inconsistent provisioning throughout the area/domain. So at least someone would have a clue when a system generated a 1492 LSP and it couldn't be forwarded over a DCC link. A complete discussion of the SIF proposal can be found on the (renamed) NSIF web site: www.atis.org go to NSIF - then documents - then 1998 - then find SIF-AR-9802-031 (R7) or ftp from ftp.juniper.net:/pub/isis/lspsize.PDF The proposal is still viable - if the work on the 10589 second edition draft ever resumes (there is still hope, I think) - then this proposal will be part of the discussion. Les From tangcm@future.futsoft.com Tue, 1 Feb 2000 15:31:15 +0530 Date: Tue, 1 Feb 2000 15:31:15 +0530 From: Jorge tangcm@future.futsoft.com Subject: [Isis-wg] for a IS-IS conflict . This is a multi-part message in MIME format. ------=_NextPart_000_0061_01BF6CC9.606AC6E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGksDQogICAgIE5vdyBpIGZpbmQgYSBjb25mbGljdCBmb3IgSVMtSVMgUERVIGF1dGhlbnRpY2F0 aW9uIENvZGUgIHZhbHVlIGRlZmluZWQgLkluIElTTyAxMDU4OSAsMTk5OC4gd2hpY2ggaW5pZGNh dGUgdGhpcyBjb2RlIHZhbHVlIHNob3VsZCBiZSAxMCwgYnV0IGluIFJGQyAxMTk1ICx3aGljaCBk ZWZpbmUgdGhpcyB2YWx1ZSB0byBiZSAxMzMgLnNvIHdoYXQgaXMgb24gZWFydGggdGhlIGNvcnJl Y3QgdmFsdWUgID8gb3IgIG1heWJlIG15IHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QgPyBQ bHMgZ2l2ZSBtZSBhZHZpY2UgLg0KICAgICAgIFRoYW5rcyAsYW55d2F5ICENCg== ------=_NextPart_000_0061_01BF6CC9.606AC6E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yMDE0LjIxMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj5oaSw8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE5vdyBpIGZpbmQgDQphJm5ic3A7Y29uZmxpY3QmbmJzcDtmb3IgSVMtSVMmbmJzcDtQ RFUgDQphdXRoZW50aWNhdGlvbiZuYnNwO0NvZGUmbmJzcDsmbmJzcDt2YWx1ZSZuYnNwO2RlZmlu ZWQgLkluIElTTyAxMDU4OSAsMTk5OC4gDQp3aGljaCZuYnNwO2luaWRjYXRlJm5ic3A7dGhpcyZu YnNwO2NvZGUmbmJzcDt2YWx1ZSBzaG91bGQgYmUmbmJzcDsxMCwgYnV0IA0KaW4mbmJzcDtSRkMg MTE5NSZuYnNwOyx3aGljaCZuYnNwO2RlZmluZSB0aGlzIHZhbHVlJm5ic3A7dG8gYmUmbmJzcDsx MzMgLnNvIHdoYXQgDQppcyBvbiBlYXJ0aCB0aGUgY29ycmVjdCB2YWx1ZSZuYnNwOyA/IG9yJm5i c3A7IG1heWJlIG15IHVuZGVyc3RhbmRpbmcgaXMgbm90IA0KY29ycmVjdCA/IFBscyBnaXZlIG1l IGFkdmljZSAuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT0yPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgLGFueXdheSANCiE8L0ZPTlQ+ PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0061_01BF6CC9.606AC6E0-- From mshand@cisco.com Tue, 01 Feb 2000 11:27:39 +0000 Date: Tue, 01 Feb 2000 11:27:39 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] for a IS-IS conflict . At 15:31 01/02/2000 +0530, Jorge wrote: >hi, > Now i find a conflict for IS-IS PDU authentication Code value > defined .In ISO 10589 ,1998. which inidcate this code value should be 10, > but in RFC 1195 ,which define this value to be 133 .so what is on earth > the correct value ? or maybe my understanding is not correct ? Pls give > me advice . > Thanks ,anyway ! I'm pretty sure 10 is the one that is used. RFC 1195 was written when 10589 was only at DIS stage, and there were various technical changes between DIS and IS. One of those was the introduction of the authentication TLV using 10 (i.e. the next unused TLV code point). This was identical in functionality to that which had been put in RFC 1195. So I think the 133 one is now unused. There was a draft (authored by Ross Callon and Chris Gunner) put out some time later (around 1994 I think) which withdrew the 133 value (and incidentally made some improvements to the L1 L2 propagation mechanisms), but by that time the IETF had lost interest in IS-IS and so it never got progressed. Mike From lester-ginsberg@vertel.com Tue, 1 Feb 2000 07:07:17 -0800 (PST) Date: Tue, 1 Feb 2000 07:07:17 -0800 (PST) From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] for a IS-IS conflict . Since several people over the last few weeks - not just Jorge - have referenced the 1998 Second Edition Draft of ISO 10589 as if it were a standard I feel it is time to reiterate the following: The 1998 Second Edition Draft is NOT an approved standard. It is a draft with lots of problems. It was posted to this group as a means of getting reviewed. It should NOT be used as a reference for validating protocol implementations. Hopefully, someday, there will be a new Second Edition Draft which resolves these problems - until then stick with the 1992 edition. Les > At 15:31 01/02/2000 +0530, Jorge wrote: > >hi, > > Now i find a conflict for IS-IS PDU authentication Code value > > defined .In ISO 10589 ,1998. which inidcate this code value should be 10, > > but in RFC 1195 ,which define this value to be 133 .so what is on earth > > the correct value ? or maybe my understanding is not correct ? Pls give > > me advice . > > Thanks ,anyway ! > From mshand@cisco.com Tue, 01 Feb 2000 15:30:17 +0000 Date: Tue, 01 Feb 2000 15:30:17 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] for a IS-IS conflict . At 07:07 01/02/2000 -0800, Lester Ginsberg wrote: >Since several people over the last few weeks - not just Jorge - have >referenced the 1998 Second Edition Draft of ISO 10589 as if it were a >standard I feel it is time to reiterate the following: > >The 1998 Second Edition Draft is NOT an approved standard. It is a >draft with lots of problems. It was posted to this group as a means of >getting reviewed. It should NOT be used as a reference for validating >protocol implementations. Hopefully, someday, there will be a new >Second Edition Draft which resolves these problems - until then stick >with the 1992 edition. Absolutely. The so called second edition is plain WRONG in a number of critical places. However, the authentication code value in question appears equally in the 1992 version. But I guess this raises an interesting question about how one is supposed to decide whether to believe ISO/IEC 10589:1992 or RFC 1195 when they conflict. Mike > Les > > > > > At 15:31 01/02/2000 +0530, Jorge wrote: > > >hi, > > > Now i find a conflict for IS-IS PDU authentication Code value > > > defined .In ISO 10589 ,1998. which inidcate this code value should > be 10, > > > but in RFC 1195 ,which define this value to be 133 .so what is on earth > > > the correct value ? or maybe my understanding is not correct ? Pls > give > > > me advice . > > > Thanks ,anyway ! > > From lester-ginsberg@vertel.com Tue, 1 Feb 2000 07:48:24 -0800 (PST) Date: Tue, 1 Feb 2000 07:48:24 -0800 (PST) From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] for a IS-IS conflict . Mike Shand writes: > > But I guess this raises an interesting question about how one is supposed > to decide whether to believe ISO/IEC 10589:1992 or RFC 1195 when they conflict. > This is an example of the potential benefits of an "Integrated Specification" i.e. a version that combines 10589:1992, defect reports, RFC 1195, traffic engineering extensions into a single document or aligned collection of documents. This notion is part of a proposed agenda within ISO SC6/WG7 and which has received some informal verbal support from both ISO and IETF officialdom. Obviously such an effort requires participation from both communities. I hope in the coming months that this agenda "sees the light of day" and that when contemplating such an agenda that Mike's question/point is considered. Les From rja@corp.home.net Tue, 01 Feb 2000 13:39:40 -0500 Date: Tue, 01 Feb 2000 13:39:40 -0500 From: Ran Atkinson rja@corp.home.net Subject: [Isis-wg] for a IS-IS conflict . My (possibly incorrect) understanding is that IAB/IESG has sent a formal liaison to ISO requesting that ISO ISIS WG be re-activated. I'm less clear on whether ISO sent a formal reply. Ran rja@corp.home.net From tli@miata.procket.com Tue, 1 Feb 2000 15:32:19 -0800 Date: Tue, 1 Feb 2000 15:32:19 -0800 From: Tony Li tli@miata.procket.com Subject: [Isis-wg] for a IS-IS conflict . | My (possibly incorrect) understanding is that IAB/IESG has sent a | formal liaison to ISO requesting that ISO ISIS WG be re-activated. I'm | less clear on whether ISO sent a formal reply. My understanding is that we (IETF) asked for a liaison to TC6, which was granted. However, the lack of interest in the ISO makes the communication rather one-sided. Tony From tli@miata.procket.com Tue, 1 Feb 2000 15:34:19 -0800 Date: Tue, 1 Feb 2000 15:34:19 -0800 From: Tony Li tli@miata.procket.com Subject: [Isis-wg] for a IS-IS conflict . | But I guess this raises an interesting question about how one is supposed | to decide whether to believe ISO/IEC 10589:1992 or RFC 1195 when they conflict. Well, one thing that WE can do is to issue updates that supersede RFC 1195. For example, on the TLV number, we can edict that we use code point 10 now. Tony From navaneethk@future.futsoft.com Wed, 2 Feb 2000 09:35:47 -0800 Date: Wed, 2 Feb 2000 09:35:47 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] CLV encoding for Integrated ISIS... Hi... Keeping aside the conflicting codes for th CLV encoding for authentication in ISO 10589 and RFC 1195, What about the other CLVs? Are the codes given in RFC 1195, being used in implementations? Do we have any documents wihich give us a list of codes to be used for the variable length fields to be encoded using CLV? Any help in this regard is most welcome. -Thanx Navaneeth. From tli@procket.com Wed, 2 Feb 2000 13:35:22 -0800 Date: Wed, 2 Feb 2000 13:35:22 -0800 From: Tony Li tli@procket.com Subject: [Isis-wg] CLV encoding for Integrated ISIS... | Keeping aside the conflicting codes for th CLV encoding for | authentication in ISO 10589 and RFC 1195, What about the other CLVs? Are | the codes given in RFC 1195, being used in implementations? Do we have | any documents wihich give us a list of codes to be used for the variable | length fields to be encoded using CLV? Yes, the other codes specified in RFC 1195 are in use. Note that I don't think any of them has been ratified by ISO, but they've not objected either. ISO 10589 and RFC 1195 are the current definitive sources for TLV code points. Tony From navaneethk@future.futsoft.com Thu, 3 Feb 2000 10:44:42 -0800 Date: Thu, 3 Feb 2000 10:44:42 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification With respect to ISIS MIB Hi, I have few doubts on the MIB for IS-IS. 1. Some tables have got objects, Operstate and ExistState. For Ex, isisSysTable has IsisSysOperState and isisSysExistState. What is the significance of these two objects and how do they differ. Is ExistState equivalent to AdminStatus?, "Setting it off make the Router forget all current states". Does it mean clearing all the databases of IS-IS and making the Protocol down. Please clarify. 2. I am not clear about the correlation between the objects and isisSysNextCircIndex and isisCircIndex. 3. isisCircTable has an object "isisManAdjNeighNSAP" . What is the purpose of this object. Where it is used? 4. Could you explain the object "isisIPRouteForw" in isisIPDestTable. 5. What do the circuit types StaticIn and StaticOut stand for in isisCirctype? 6. What are the MeshGroup entires used for? How do we use this? Thanks Regards -vani ------ Navaneeth. From jparker@nexabit.com Thu, 3 Feb 2000 09:50:15 -0500 Date: Thu, 3 Feb 2000 09:50:15 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] RE: Clarification With respect to ISIS MIB > Hi, > > > I have few doubts on the MIB for IS-IS. > > 1. Some tables have got objects, Operstate and ExistState. > For Ex, isisSysTable has > IsisSysOperState and isisSysExistState. What is the > significance of these two objects > and how do they differ. Is ExistState equivalent to > AdminStatus?, "Setting it off make the > Router forget all current states". Does it mean clearing all > the databases of IS-IS and making the > Protocol down. Please clarify. There are three types of things in mib speak Does this object exist? (Exist state) Do I want this object active? (Admin State) Is this object operating? (Oper State) We are currently using OperState in many spots where we should be using AdminState, but that is another story. ExistState is used to help clarify the steps in creating a new item. If Isis had a SystemAdminState, and you set it to Down, you would hope that configuration, such as system id, would be remembered when SystemAdminState was reset to Up. However, seting isisSysExistState to isisSysExistState_destroy should clear setting such as isisSysID. > 2. I am not clear about the correlation between the > objects and isisSysNextCircIndex and isisCircIndex. I is useful to have a circuit Index that is unique within the instance of Isis. The variable isisSysNextCircIndex is a system wide variable that can be used with an SNMP convention called TestAndIncr to provide the "next" value. It works like the roll of numbers you see at the bakery: you tear off the next number, and you will be the only person in the shop with that number. > 3. isisCircTable has an object "isisManAdjNeighNSAP" . > What is the purpose of this object. > Where it is used? If you wish to have a configured adjacency, rather than one created by the exchange of hello messages, this variable holds the SystemId of the other side which you would otherwise discover in the hello packets. > 4. Could you explain the object "isisIPRouteForw" in > isisIPDestTable. This looks like a "next hop" description. > 5. What do the circuit types StaticIn and StaticOut stand for > in isisCirctype? These look like simplex (one way) circuits. > 6. What are the MeshGroup entires used for? How do we use this? There is a draft describing their use... draft-balay-katz-parker-mesh-00.txt > Thanks > Regards > -vani > > ------ > Navaneeth. From prz@siara.com Thu, 03 Feb 2000 15:33:04 -0500 Date: Thu, 03 Feb 2000 15:33:04 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] comments on Did some more carefull reading and here comments: * please use either "octets" or "bytes" consistently, confusing to have both strawn across the draft (or is there some subtle difference I'm missing ?) * 4 bytes of metric information 1 byte of control information, consisting of 1 bit of up/down information 1 bit indicating the existence of sub-TLVs 6 bits of prefix length you may need to spell out which bits are what, is up/down least or most significant bit ? * sub-TLV format is not given, since all the sub-tlvs have fixed length is the length field contained in sub-tlv format or not, so e.g. for sub-tlv 3 is it byte 1 3 byte 2-5 4 bytes ad-group or byte 1 3 byte 2 4 (length) byte 3-6 4 bytes ad-group ? First is denser, 2nd is extensible (sub-sub-TLVs ?) and consistent with today's TLV encoding. Please spell out which is used in the draft From navaneethk@future.futsoft.com Mon, 7 Feb 2000 10:15:49 -0800 Date: Mon, 7 Feb 2000 10:15:49 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Draft needed... Hi... Can any of you tell me where the draft , < draft-balay-katz-parker-mesh-00.txt> can be found.. Thanx Navaneeth. From balay@torrentnet.com Mon, 07 Feb 2000 10:46:37 -0500 Date: Mon, 07 Feb 2000 10:46:37 -0500 From: Rajesh Balay balay@torrentnet.com Subject: [Isis-wg] Draft needed... Its available at the IETF drafts directory : http://search.ietf.org/internet-drafts/draft-balay-katz-parker-mesh-00.txt -rajesh navaneeth K wrote: > Hi... > Can any of you tell me where the draft , < draft-balay-katz-parker-mesh-00.txt> > can be found.. > Thanx > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From satish@pluris.com Mon, 7 Feb 2000 14:32:52 -0800 Date: Mon, 7 Feb 2000 14:32:52 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] Qn on Pt-Pt IIH Hi, I have a question on pt-pt iih processing: While processing a pt-pt iih does the max area in the packet need to match always? according to [8.2.5.2 (a)] In case of Lan IIH we see if the max area check is enabled or not before discarding the packet. Or is there a error in the version 2 draft here. thanks, satish From lester-ginsberg@vertel.com Mon, 7 Feb 2000 14:57:12 -0800 (PST) Date: Mon, 7 Feb 2000 14:57:12 -0800 (PST) From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] Qn on Pt-Pt IIH The text in 8.2.5.2(a) in 1998 draft appears identical to the text in 8.2.4.2(a) 1992 spec. And both clearly state text which is identical to the LAN IIH case (8.4.2.2(b) - 1992): "...unless the IS only implements a value of three... in which case this check may be omitted." So I am rather confused as to why you think LAN/P2P are different in this regard. And, once again, I repeat to one and all - please do NOT use the 1998 draft as a reference for protocol implementations. It is not an approved standard, it has lots of problems. Until a newer revision is available - 1992 is what to live by. (Sorry for the repetition of this warning - but it seems necessary.) Les Satish Dattatri writes: > Hi, > I have a question on pt-pt iih processing: > > While processing a pt-pt iih does the max area > in the packet need to match always? according to > [8.2.5.2 (a)] > > In case of Lan IIH we see if the max area check > is enabled or not before discarding the packet. > > Or is there a error in the version 2 draft here. > > thanks, > satish > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From nrsoma@pluris.com Mon, 7 Feb 2000 15:11:37 -0800 Date: Mon, 7 Feb 2000 15:11:37 -0800 From: Nageswara Rao Soma nrsoma@pluris.com Subject: [Isis-wg] Qn on Pt-Pt IIH > -----Original Message----- > From: Satish Dattatri [mailto:satish@pluris.com] > Sent: Monday, February 07, 2000 02:33 PM > To: 'isis-wg@external.juniper.net' > Subject: [Isis-wg] Qn on Pt-Pt IIH > > > Hi, > I have a question on pt-pt iih processing: > > While processing a pt-pt iih does the max area > in the packet need to match always? according to > [8.2.5.2 (a)] Value of isisSysMaxAreaCheck may have the same impact on point-to-point IIH processing as it does for LAN IIH. > In case of Lan IIH we see if the max area check > is enabled or not before discarding the packet. I did not find any difference between processing of LAN IIH and PtPt IIH in this context. Correct me, if I am wrong. > Or is there a error in the version 2 draft here. > > thanks, > satish > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From satish@pluris.com Mon, 7 Feb 2000 15:13:33 -0800 Date: Mon, 7 Feb 2000 15:13:33 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] Qn on Pt-Pt IIH That is what I had in mind, both should be processed the same. sorry I overlooked, satish -----Original Message----- From: Lester Ginsberg [mailto:lester-ginsberg@vertel.com] Sent: Monday, February 07, 2000 2:57 PM To: Satish Dattatri Cc: 'isis-wg@external.juniper.net' Subject: [Isis-wg] Qn on Pt-Pt IIH The text in 8.2.5.2(a) in 1998 draft appears identical to the text in 8.2.4.2(a) 1992 spec. And both clearly state text which is identical to the LAN IIH case (8.4.2.2(b) - 1992): "...unless the IS only implements a value of three... in which case this check may be omitted." So I am rather confused as to why you think LAN/P2P are different in this regard. And, once again, I repeat to one and all - please do NOT use the 1998 draft as a reference for protocol implementations. It is not an approved standard, it has lots of problems. Until a newer revision is available - 1992 is what to live by. (Sorry for the repetition of this warning - but it seems necessary.) Les Satish Dattatri writes: > Hi, > I have a question on pt-pt iih processing: > > While processing a pt-pt iih does the max area > in the packet need to match always? according to > [8.2.5.2 (a)] > > In case of Lan IIH we see if the max area check > is enabled or not before discarding the packet. > > Or is there a error in the version 2 draft here. > > thanks, > satish > > _______________________________________________ > 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 navaneethk@future.futsoft.com Tue, 8 Feb 2000 10:58:34 -0800 Date: Tue, 8 Feb 2000 10:58:34 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Draft needed... Hi... Can any of you tell me where the draft , < draft-balay-katz-parker-mesh-00.txt> can be found.. The given link http://search.ietf.org/internet-drafts/draft-balay-katz-parker-mesh-00.txt points to broken link... The draft is not accessible from here.. Any other Links?? Thanx Navaneeth. From navaneethk@future.futsoft.com Tue, 8 Feb 2000 19:26:44 -0800 Date: Tue, 8 Feb 2000 19:26:44 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] (no subject) Hi... Anybody out there knows any router that supports ISIS over NBMA/X.25/FR ?? Thanx Navaneeth.. From satish@pluris.com Tue, 8 Feb 2000 17:15:24 -0800 Date: Tue, 8 Feb 2000 17:15:24 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] MeshGroup in MIB HI, There seems to be a typo in the mib regarding meshgroups. In the object isisCircMeshGroup description: "... If isisCircMeshGroupEnable is false, this value is ignored." ^^^^^^ The fasle should be inactive. thanks, satish From CMartin@mercury.balink.com Tue, 8 Feb 2000 23:43:31 -0500 Date: Tue, 8 Feb 2000 23:43:31 -0500 From: Martin, Christian CMartin@mercury.balink.com Subject: [Isis-wg] Draft needed... Looks as if it has been repaired... Internet Engineering Task Force R.Balay INTERNET DRAFT D.Katz J.Parker Mon Jun 14 1999 IS-IS Mesh Groups 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents <-snip-> /chris > -----Original Message----- > From: navaneeth K [mailto:navaneethk@future.futsoft.com] > Sent: Tuesday, February 08, 2000 1:59 PM > To: 'isis-wg@external.juniper.net' > Subject: [Isis-wg] Draft needed... > > > Hi... > Can any of you tell me where the draft , < > draft-balay-katz-parker-mesh-00.txt> > can be found.. > The given link > http://search.ietf.org/internet-drafts/draft-balay-katz-parker > -mesh-00.txt points to broken link... > The draft is not accessible from here.. Any other Links?? > Thanx > Navaneeth. > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From satish@pluris.com Thu, 10 Feb 2000 11:05:27 -0800 Date: Thu, 10 Feb 2000 11:05:27 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] ISO 10589 : 1992 Edition Hi, Does anyone have a digital copy of 1992 spec? OR do one have to buy a printed version only. Thanks, satish From jparker@nexabit.com Thu, 10 Feb 2000 14:16:02 -0500 Date: Thu, 10 Feb 2000 14:16:02 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] ISO 10589 : 1992 Edition > Hi, > Does anyone have a digital copy of > 1992 spec? OR do one have to buy a > printed version only. > > Thanks, > satish Satish - Check RFC 1142, a reprinting of 10589. There are Text and postscript versions. The text version is a poor imitation. http://www.ietf.org/rfc/rfc1142.txt http://www.ietf.org/rfc/rfc1142.ps - jeff parker From dclemmen@cosinecom.com Thu, 10 Feb 2000 14:52:37 -0500 Date: Thu, 10 Feb 2000 14:52:37 -0500 From: dclemmen dclemmen@cosinecom.com Subject: [Isis-wg] ISO 10589 : 1992 Edition Jeff Parker wrote: > > > Hi, > > Does anyone have a digital copy of > > 1992 spec? OR do one have to buy a > > printed version only. > > > > Thanks, > > satish > > Satish - > Check RFC 1142, a reprinting of 10589. > There are Text and postscript versions. > The text version is a poor imitation. > > http://www.ietf.org/rfc/rfc1142.txt > http://www.ietf.org/rfc/rfc1142.ps > > - jeff parker RFC1142 claims to be the 1990 version of the document, I think. Satish is looking for the 1992 version. From mshand@cisco.com Fri, 11 Feb 2000 08:14:09 +0000 Date: Fri, 11 Feb 2000 08:14:09 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] ISO 10589 : 1992 Edition At 14:52 10/02/2000 -0500, dclemmen wrote: >Jeff Parker wrote: > > > > > Hi, > > > Does anyone have a digital copy of > > > 1992 spec? OR do one have to buy a > > > printed version only. > > > > > > Thanks, > > > satish > > > > Satish - > > Check RFC 1142, a reprinting of 10589. > > There are Text and postscript versions. > > The text version is a poor imitation. > > > > http://www.ietf.org/rfc/rfc1142.txt > > http://www.ietf.org/rfc/rfc1142.ps > > > > - jeff parker > >RFC1142 claims to be the 1990 version of the document, I think. >Satish is looking for the 1992 version. Yes. RFC1142 is a copy of the DP version of 10589. For those unfamiliar with ISO terminology (in those days), there were 3 stages; DP, DIS and IS. DP was the first stage of submission, and numerous changes were made between then and publication of the final standard. I wouldn't try to work off RFC1142 (nor, as has oft been repeated, would I try to work off the so called version 2 of 10589 which is plain WRONG). The best course is to get hold of a copy of the original version 1 (ISO/IEC 10589:1992) AND the various technical corrigenda. These mostly correct trivial errors, but there are some (for example the operation of partition repair; should anyone be foolhardy enough to implement it) which correct very serious bugs. I don't know what the current rules are, but as far as I am aware ISO standards still cannot be made publicly available. >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From lester-ginsberg@vertel.com Fri, 11 Feb 2000 21:04:19 -0800 Date: Fri, 11 Feb 2000 21:04:19 -0800 From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] ISO 10589 : 1992 Edition ISO standards can be purchased from your national organization - in the US that is ANSI (www.ansi.org). Both 1992 spec and the three published Technical Corrigenda should be available. Les > > Yes. RFC1142 is a copy of the DP version of 10589. For those unfamiliar > with ISO terminology (in those days), there were 3 stages; DP, DIS and IS. > DP was the first stage of submission, and numerous changes were made > between then and publication of the final standard. I wouldn't try to work > off RFC1142 (nor, as has oft been repeated, would I try to work off the so > called version 2 of 10589 which is plain WRONG). The best course is to get > hold of a copy of the original version 1 (ISO/IEC 10589:1992) AND the > various technical corrigenda. These mostly correct trivial errors, but > there are some (for example the operation of partition repair; should > anyone be foolhardy enough to implement it) which correct very serious bugs. > > I don't know what the current rules are, but as far as I am aware ISO > standards still cannot be made publicly available. > From vleeschh@sh.bel.alcatel.be Mon, 14 Feb 2000 11:53:11 +0100 Date: Mon, 14 Feb 2000 11:53:11 +0100 From: Hans De Vleeschouwer WX29 58223 vleeschh@sh.bel.alcatel.be Subject: [Isis-wg] Changing the system id while running hi, I was wondering if it is possible to change the ISIS system id while the router is up and running, or whether it is needed to first turn off the protocol. Does anybody have some expierence with this? kind regards, Hans De Vleeschouwer Alcatel Belgium From mshand@cisco.com Mon, 14 Feb 2000 11:32:52 +0000 Date: Mon, 14 Feb 2000 11:32:52 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Changing the system id while running At 11:53 14/02/2000 +0100, Hans De Vleeschouwer WX29 58223 wrote: >hi, > >I was wondering if it is possible to change the ISIS system id while the >router is up and running, or whether it is needed to first turn off the >protocol. Well notionally a router with a different system ID is a different router, so it would be necessary to drop the adjacencies to the old systemID, let the old LSPs die (or purge them) and then form new adjacencies and generate new LSPs. This is equivalent to turning off the protocol. I suppose it is conceivable that one could implement something which did all this in response to changing the system ID, without requiring a separate command to turn the protocol off and back on again, but architecturally it would still be turning off and turning back on the protocol. One could envisage a router having multiple system IDs each with their own set of LSPs, but this starts to get very complicated. Can I ask why you would want to do this? >Does anybody have some expierence with this? > >kind regards, > Hans De Vleeschouwer > Alcatel Belgium > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From dclemmen@cosinecom.com Wed, 16 Feb 2000 17:32:41 -0500 Date: Wed, 16 Feb 2000 17:32:41 -0500 From: dclemmen dclemmen@cosinecom.com Subject: [Isis-wg] Conformance testing tools? Does anyone know of any conformance testing tools or services for IS-IS implementations? From Chris.Flores@broadwing.com Wed, 16 Feb 2000 16:47:35 -0600 Date: Wed, 16 Feb 2000 16:47:35 -0600 From: Chris.Flores@broadwing.com Chris.Flores@broadwing.com Subject: [Isis-wg] Conformance testing tools? The Qosnetics QA Robot- now owned by Agilent technologies. See http://www.qosnetics.com/home.htm I have personally used this test device and would recommend taking a look at the product features. The IS-IS protocol test suite is fairly new. I hope this helps. Thanks. Chris -----Original Message----- From: dclemmen [mailto:dclemmen@cosinecom.com] Sent: Wednesday, February 16, 2000 4:33 PM To: Isis-wg@external.juniper.net Subject: [Isis-wg] Conformance testing tools? Does anyone know of any conformance testing tools or services for IS-IS implementations? _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From dclemmen@cosinecom.com Fri, 18 Feb 2000 15:34:30 -0500 Date: Fri, 18 Feb 2000 15:34:30 -0500 From: dclemmen dclemmen@cosinecom.com Subject: [Isis-wg] e-mail address for Tony Li? I tried to send e-mail to Tony Li, the author of draft-ietf-isis-hmac-00.txt at the address listed in the document. The listed address is: tli@juniper.net It bounced. Tony, are you out there? From wrath@cs.umbc.edu Fri, 18 Feb 2000 15:57:21 -0500 (EST) Date: Fri, 18 Feb 2000 15:57:21 -0500 (EST) From: Vijay Gill wrath@cs.umbc.edu Subject: [Isis-wg] e-mail address for Tony Li? On Fri, 18 Feb 2000, dclemmen wrote: > I tried to send e-mail to Tony Li, the author of > draft-ietf-isis-hmac-00.txt > at the address listed in the document. > The listed address is: > tli@juniper.net > It bounced. > > Tony, are you out there? > I believe the better method is to try tli@procket.com Dr. Li has moved on. /vijay From Chris.Flores@broadwing.com Fri, 18 Feb 2000 16:05:44 -0600 Date: Fri, 18 Feb 2000 16:05:44 -0600 From: Chris.Flores@broadwing.com Chris.Flores@broadwing.com Subject: [Isis-wg] e-mail address for Tony Li? Toni Li is not at Juniper - he has co-founded procket networks. See www.procket.net Thanks. Chris -----Original Message----- From: dclemmen [mailto:dclemmen@cosinecom.com] Sent: Friday, February 18, 2000 2:35 PM To: isis-wg@external.juniper.net Subject: [Isis-wg] e-mail address for Tony Li? I tried to send e-mail to Tony Li, the author of draft-ietf-isis-hmac-00.txt at the address listed in the document. The listed address is: tli@juniper.net It bounced. Tony, are you out there? _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From navaneethk@future.futsoft.com Wed, 23 Feb 2000 09:40:00 -0800 Date: Wed, 23 Feb 2000 09:40:00 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on Terminology... Hi all.. I need to have a clarification on the usage of SystemID, NSAP address and SNPA address and the NET ... What exactly do each of these stand for an how are they related? How are these different when in a OSI environment, IP environment and when in a Dual Environment? It would be better if we could get some examples of each type of address in each of the environments.. Thanx & Regards Navaneeth. From mshand@cisco.com Wed, 08 Mar 2000 09:12:03 +0000 Date: Wed, 08 Mar 2000 09:12:03 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt At 10:32 02/03/2000 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IS-IS for IP Internets Working Group of >the IETF. > > Title : IS-IS Mesh Groups > Author(s) : R. Balay, D. Katz, J. Parker > Filename : draft-ietf-isis-wg-mesh-group-00.txt > Pages : 9 > Date : 01-Mar-00 Just a few comments. In the modified 7.3.15.1. e.1.ii) there is no mention of what to do if the incoming circuit is 'meshblocked'. I assume this is do nothing, since if things are correctly configured you wouldn't receive an LSP over such a circuit, but the spec should be clear on this point. It could do with an example of how one is supposed to deploy it. It might be helpful to say that a very good way of shooting yourself in the foot is to define some links as meshSet and some links as meshBlocked in the same 'mesh'. One could argue that use of CSNPs gets you out of the hole, but maybe that is even worse because although you get the LSPs delivered eventually you introduce a considerable propagation delay. Oh and I think there's a typo. In the sentence leading up to the changes to section 7.3.15.3 clause b) (bottom of page 4) it says "...links with a mesh group meshEnabled or meshBlocked." presumably this should read "... links with a meshEnabled value of meshSet or meshBlocked" Mike From mshand@cisco.com Wed, 08 Mar 2000 09:30:55 +0000 Date: Wed, 08 Mar 2000 09:30:55 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt At 09:12 08/03/2000 +0000, Mike Shand wrote: >In the modified 7.3.15.1. e.1.ii) there is no mention of what to do if the >incoming circuit is 'meshblocked'. I assume this is do nothing, since if >things are correctly configured you wouldn't receive an LSP over such a >circuit, but the spec should be clear on this point. Hmmm. Thinking about this some more, its not so obvious. If you received a CSNP over a meshBlocked circuit, and you had a newer LSP you would send it out over the meshBlocked circuit (since the draft makes no changes to section 7.3.15.2 c). Hence it would be entirely reasonable to receive an LSP over a circuit marked meshBlocked, even in a correctly configured network. So presumably one would want to accept that LSP and treat it as for meshSet? Mike From jparker@nexabit.com Wed, 8 Mar 2000 10:28:20 -0500 Date: Wed, 8 Mar 2000 10:28:20 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt > At 10:32 02/03/2000 -0500, Internet-Drafts@ietf.org wrote: > > > > Title : IS-IS Mesh Groups > > Author(s) : R. Balay, D. Katz, J. Parker > > Filename : draft-ietf-isis-wg-mesh-group-00.txt > > Pages : 9 > > Date : 01-Mar-00 > > Just a few comments. Mike - Thanks for your careful reading. > In the modified 7.3.15.1. e.1.ii) there is no mention of what > to do if the incoming circuit is 'meshblocked'. I assume this > is do nothing, since if things are correctly configured you > wouldn't receive an LSP over such a circuit, but the spec > should be clear on this point. I would imagine that this would be a legal configuration, and that some might find a use for one way links like this. > It could do with an example of how one is supposed to deploy it. I suppose documenting them is one step on the slippery slope to advocating them. Perhaps I can find some weasel words and add an example: maybe a 6-way complete mesh constrained to have a couple of alternative flooding paths between each pair. > It might be helpful to say that a very good way of shooting > yourself in the foot is to define some links as meshSet and > some links as meshBlocked in the same 'mesh'. One could argue > that use of CSNPs gets you out of the hole, but maybe that is > even worse because although you get the LSPs delivered > eventually you introduce a considerable propagation delay. > > Oh and I think there's a typo. In the sentence leading up to > the changes to > section 7.3.15.3 clause b) (bottom of page 4) it says > > "...links with a mesh group meshEnabled or meshBlocked." > > presumably this should read > "... links with a meshEnabled value of meshSet or meshBlocked" > > Mike Thanks - will make that edit. - jeff parker - jdparker@lucent.com From jparker@nexabit.com Wed, 8 Mar 2000 10:57:54 -0500 Date: Wed, 8 Mar 2000 10:57:54 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt > >In the modified 7.3.15.1. e.1.ii) there is no mention of > >what to do if the incoming circuit is 'meshblocked'. > > Hmmm. Thinking about this some more, its not so obvious. If > you received a CSNP over a meshBlocked circuit, and you had > a newer LSP you would send it out over the meshBlocked circuit > (since the draft makes no changes to section 7.3.15.2 c). > Hence it would be entirely reasonable to receive an LSP over > a circuit marked meshBlocked, even in a correctly configured > network. So presumably one would want to accept that LSP and > treat it as for meshSet? > > Mike Sorry, missed this when replying to previous. Is there a reason to discard any valid LSP? We do solicit them when we detect a missing LSP listed in a CSNP. We could check to see if this one arrived "on it's own" or if we asked for it, but this seems excessive. I see Mesh Groups as a way to cut back on transmissions. Once the network has taken the trouble to deliver an LSP, taking the time to check to see if the LSP is new, and keeping it if it is, seems conservative. - jdparker@lucent.com - Lucent INS From selvarajr@future.futsoft.com Sun, 12 Mar 2000 13:02:59 +0530 Date: Sun, 12 Mar 2000 13:02:59 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt regarding DR election ------ =_NextPart_000_01BF8C23.4D49F620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Regarding DR election 10589 : 92 section 8.4.5 (e) states that DR election process can start whenever an IIH PDU is received or transmitted as described in 8.4.4. I find this little bit vague. To my understanding I find it is better to start the DR election whenever 1. A new IIH PDU with higher priority than the existing DR been received. 2. The priority of any existing neighbour been increased higher than the existing DR 3. Initially after waiting for twice the Hello interval when circuit comes UP The third point is mentioned clearly . But the remaining cases are vague if I go through the STD. Will it happen to conduct DR election during transmission of IIH at any time. Some clarification with points of cases will be helpful. Thanx Selva ------ =_NextPart_000_01BF8C23.4D49F620 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgMHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAHAAAAERvdWJ0IHJlZ2FyZGluZyBEUiBlbGVjdGlvbgD6CQEFgAMADgAA ANAHAwAMAA0AAgA7AAAAMAEBIIADAA4AAADQBwMADAAMAB4AKAAAADgBAQmAAQAhAAAARjYzQTAx RTIwNkY4RDMxMUE4NTgwMDIwMzUxRjkyQTAA6AYBA5AGANAKAAAgAAAACwACAAEAAAALACMAAAAA AAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQBgoj4x9Yu/AR4AcAABAAAAHAAAAERvdWJ0IHJl Z2FyZGluZyBEUiBlbGVjdGlvbgACAXEAAQAAABYAAAABv4v1MS3iATsW+AYR06hYACA1H5KgAAAe AB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAAHQAAAHNlbHZhcmFqckBmdXR1cmUuZnV0c29mdC5j b20AAAAAAwAGEMz20FMDAAcQXQIAAB4ACBABAAAAZQAAAEhJLFJFR0FSRElOR0RSRUxFQ1RJT04x MDU4OTo5MlNFQ1RJT044NDUoRSlTVEFURVNUSEFURFJFTEVDVElPTlBST0NFU1NDQU5TVEFSVFdI RU5FVkVSQU5JSUhQRFVJU1JFQ0UAAAAAAgEJEAEAAACuBwAAqgcAADgRAABMWkZ1nCKJTgMACgBy Y3BnMTI1cjIMYGMxAzABBwtgbpEOEDAzMw8WZmUPkk8B9wKkA2MCAGNoCsBzhGV0AtFwcnEyAACS Kgqhbm8SUCAwAdCFAdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQA9T7Ef8TC2IT4RRQE7IY9BTQrwcT AoACkQjmOwlvMBrf+mUOMDUcCh0hHN8d6Rv0/x4SHH8gTyANH48dvxwPEGD8Mjgl2ibxJq8nuRv0 J+K/Jk8qHyndKV8njytUOQ5QHy6kMAEoIzAAAoJzdHlqbAeQaAngdAAAA/BkGGN0bAqxAGBkanVz MXAFEGdoBUIWMgwBY4cJwDJAAzBzbmV4FzAvB7AFsADAAnNzAFBzYpYyFFAxYGET8FxrCeC+cAuQ MjgIYDJwC4BlMaD+djfgAUAy2wwwM6QoADaAmwSgC4BnJ/E0JmJhFxB+ZAIgNOA0hjHQMtA6ESD+ MTEzDlA13zbvN/MAUTh8/wCgM646/zwGMSQPwD0PPh+/N/MOUDhvQM9B3zwzMwKCPRMQYzWgSKEy 0DwwdGmJOBAgRAEQYXVsBUAKUArAYQnAYXBoII5GAiE1ZCVAZmktD5BeOAFAN7BNMzI4Ygsgcs8J UE6SFqBOknc0JUEXAP5wAdBKcjL/R59IpkzQS5AbBRACMC1MMANhOiBUQm9T8FN1YmoFkHRBU/BE YXRlOjVkNv9M/04PTx9QLjHAPCMOIUihbzk2DlBRr1K+UjgBFwEg7kg8EQSQNWQ3Va9Wv1fPv0ih N49ZPw+QZDAI0GIKsPx0OEb6D1RD0Fs/XEZkwPNdUAtQeS9MQFgwCxFdxf5zNWQoAF6/X89g31A/ UU/fZt9n6lQSU7RU6TkyL21FHWRzOW2fbq9z4ERvY/51B4ACMAXQTAAaAxMQYjA/MXABkTGgAAB3 YndUZW0/C1FVAHIwAdAv8FWANDP/AFB3YgCQeMF35WJzagBigm5uFsBp8WKCanu2AhBs/QkAd3vF MXAKwAGQUwB9Nf0KsGMKYHs0C4ABAAIwAeFnYnNVADTAXCcToIBRMO4uAoJ7RHZgYl2BgFE8gf1p gjNEMWIwgoJ8MHdlDMFNgoEggPJ3cW5hB4Agv4Ihd2J5IQ+QeaABwDgwAP13CG9dcTRBFyB3uIa2 hQ/7hmsFoHV/cWoANaAaEHIS730AclBrUQGAblRwAGAJ8P9KoHZAAgE1IFnSiFCMUTGAknAegFx2 CJB3a38x/2YAjcIE8AdAEGEBQA4AayL3PAKPJQIQbwVCFyES8nimoCBDOlxcU0BvS+HebUwwAxAH kJHQTQ3gA2Dkc28BgCBPASAN4IhQWlyThkUAwAMQLkhwdN+CMBcQclA0YWIyeAFAjCG+bjHQGvCV JEs0gzAgEvPzAIAFkGx2P2FEkA5wNSD/l7J9ophCfzQBwZexFuAPcM8AAESQDNABkCAudwSXxv8O UJhiS3AysJjfme+a/w/A30SQBYGcn52vnr9sZgBEkO5snF+hH6IlKZssJUCf/+Ok36IUYiAoApGl /5fz/1WQo6+ob6l/qo+YIF6Qq9L/mK+tP65PmywoAKvfsV+yb/+zf5ggcgCwX7Xvtv+4BAr5DwMw ci9tXzRRe0hpLBsKhV1QZwsRPEJEUiDrYmG90GkCICA8cBQgheA2IFPwMAAglTLBwjguxDQuUyAo ZSnCsH3R/QeRdBbgBUDBShdwdkAHkM8EII6wA6B9kyB3MdA0oEVdcSADkUlJSEuQRPRVIAQAIBrw fqBK4TRg9wWxvpAAcW1KwFUANGBIQP4gAQAE8oGgNGC9YcNCw2D9xzAgaZB/QMRBx8FiMAJAyTGg IGJKwCB2S9AKUMPKwFQQIG15IIpgaNL/AZB/QDxCyuXMIcfBgaB4kf/IkczQxiTEUEsBwVnGhwqF /6IDgCILCjO8y2AW0ABgAEH8ZGLUI2nxdkDUMABAPHD+LgyCvLUDMYJqvaiDLZeEzwrhtNCYIAbg ZHkMQJgR/4qTl7EEoJBgpVKnn39SgoKPoa+E8TWhvkp7QSA0oP8H4MdGA/DEUDvwvrHG4Rdw/8HA BRAxgMRCA6DP0jSwhSLvwRSBoAnwx+cu0W/Sf9OP/dSfMtW/1s/X39jv2f/bD/fcH90v3j1Uz+Hg x5NAxwH/zQDh5zSgvrEG4Ahw4pQLgP8FADwQSFHgRuFfwTHjj+Sf++Wv5r8z59/o7+n/6w/sH+/t L+4/70/ePUkBIErQB0D/Z/DHAIuwxuFoUErBPFGMkf/EQBZwfqDPw13QfOHKMc8Bz8xQl2DGgsXQ aXJ2UMwh84pAFRJVUAqF+wa9r97Ez/ZV8ULLUWhxcG9TYcey/3ZywcHIUYMwPBBrUASQysD+QmIQ z8Ma8JSROgLF0RNwf86w9pATgMxTx7DyIMrgZzfM0OAgkxB180DPw1NUekTKwFeUsJdgzCEW4HD/ jYD1QczQikB/QJiAxIwS8P9TUTxgyLXFsMHC8hHHQsRx3/JCStCEsON29lVTCEENQf/2kBAQkvBU 8NCT4BIMI86wf/IRDxTgABHBgaA78QnwZu9LYON28UDI0HjRVhZ8CS/33kxHAvhANFRAYmDMUIDw CRyGfQAgcAAAAwAQEAAAAAADABEQAAAAAAMAgBD/////QAAHMCDEha3wi78BQAAIMCDEha3wi78B CwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQ hQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADzFQAAAwAHgAggBgAAAAAAwAAAAAAA AEYAAAAAAYUAAAAAAAAeAAiACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAA AAsACYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAA EYUAAAAAAAADAAuACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ADIAIIAYAAAAAAMAAAAAA AABGAAAAADaFAAABAAAAAQAAAAAAAAAeAA2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEA AAAAAAAAHgAOgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAAAQAA AAAAAAADAA00/TcAAP6c ------ =_NextPart_000_01BF8C23.4D49F620-- From mshand@cisco.com Sun, 12 Mar 2000 22:13:48 +0000 Date: Sun, 12 Mar 2000 22:13:48 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Doubt regarding DR election Well, since the standard specifies only externally visible behaviour it makes no difference. If you 'run' the DR election in a case where there is no change it is exactly equivalent to not running it. Whether you actually 'run' it or not is an implementation detail. You could regard some of your cases as actually running the election and then aborting it when you discover that the PDU is not a higher priority. etc. etc. Mike At 13:02 12/03/2000 +0530, SelvarajR wrote: >Hi, >Regarding DR election 10589 : 92 section 8.4.5 (e) states that DR election >process can start whenever an IIH PDU is received or transmitted as >described in 8.4.4. I find this little bit vague. To my understanding I >find it is better to start the DR election whenever >1. A new IIH PDU with higher priority than the existing DR been received. >2. The priority of any existing neighbour been increased higher than the >existing DR >3. Initially after waiting for twice the Hello interval when circuit comes >UP > >The third point is mentioned clearly . But the remaining cases are vague if >I go through the STD. Will it happen to conduct DR election during >transmission of IIH at any time. > >Some clarification with points of cases will be helpful. >Thanx > > >Selva From Henrik.J.Villfor@telia.se Fri, 17 Mar 2000 13:35:27 +0100 Date: Fri, 17 Mar 2000 13:35:27 +0100 From: =?ISO-8859-1?Q?Henrik_Villf=F6r?= Henrik.J.Villfor@telia.se Subject: [Isis-wg] BGP in L1 routers Hi. Reading I am a bit surprised to find the following. " 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. " What confuses me is that I was under the very strong impression that destinations could not be installed from BGP unless a route to the BGP next hop existed in the RIB and FIB and that a default route (as would be what is available in an L1 router for an external route) would not do. I would much appreciate if one of you wise people would spare the time to enlighten me. Thank's in advance, Henrik Villfor Telia Research From danny@tcb.net Fri, 17 Mar 2000 10:43:28 -0700 Date: Fri, 17 Mar 2000 10:43:28 -0700 From: Danny McPherson danny@tcb.net Subject: [Isis-wg] BGP in L1 routers Extracted from RFC 1771, Section 9.1.2: [...] If the NEXT_HOP attribute of a BGP route depicts an address to which the local BGP speaker doesn't have a route in its Loc-RIB, the BGP route SHOULD be excluded from the Phase 2 decision function. [...] The local speaker MUST determine the immediate next hop to the address depicted by the NEXT_HOP attribute of the selected route by performing a lookup in the IGP and selecting one of the possible paths in the IGP. This immediate next hop MUST be used when installing the selected route in the Loc-RIB. I see no reason why "one of the possible paths in the IGP" could not be the "default" route, so long as the immediate next hop address can be determined. -danny > " 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. " > > What confuses me is that I was under the very strong impression that > destinations could not be installed from BGP unless a route to the BGP next > hop existed in the RIB and FIB and that a default route (as would be what is > available in an L1 router for an external route) would not do. From vleeschh@sh.bel.alcatel.be Tue, 21 Mar 2000 11:12:05 +0100 Date: Tue, 21 Mar 2000 11:12:05 +0100 From: Hans De Vleeschouwer WX29 58223 vleeschh@sh.bel.alcatel.be Subject: [Isis-wg] question related to isisSystemTable --------------35B21A56A6ED8AD8BC1FBE0D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a question related to the isisSysTable On one hand we see that the table contains a row-status. This seems to indicate that the operator can create and delete rows. The question we have is: why are the objects not read-create in stead of read-write. Since non of the objects are read-create a row can in fact not be created by the operator (see RFC 2578). In our implementation we would allow only 1 instance of the protocol. Does it still make sense in this case, to allow the operator to create and delete this row, or would it make more sense to have always one row, and use the isisSysOperState to turn on/off the protocol. Any help is kindly appreciated. Kind regards, Hans De Vleeschouwer Alcatel --------------35B21A56A6ED8AD8BC1FBE0D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I have  a question related to the isisSysTable

On one hand we see that the table contains a row-status. This seems to indicate that the operator can create and delete rows.


The question we have is: why are the objects not read-create in stead of read-write. Since non of the objects are read-create a row can in fact not be created by the operator (see RFC 2578).

In our implementation we would allow only 1 instance of the protocol.  Does it still make sense in this case, to allow the operator to create and delete this row,  or would it make more sense to have always one row, and use the isisSysOperState to turn on/off the protocol.
 

Any help is kindly appreciated.
 

Kind regards,
    Hans De Vleeschouwer
    Alcatel --------------35B21A56A6ED8AD8BC1FBE0D-- From navaneethk@future.futsoft.com Tue, 21 Mar 2000 17:58:03 +0530 Date: Tue, 21 Mar 2000 17:58:03 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on ISIS configuration Hi all.. My doubt is with regard to the configuration of Summary Addresses in ISIS . i. Can summary addresses be configured for both Level 1 and Level 2? If so , how do we use the Level 1 summary addresses? In advertising the summary addresses , do we take it from the Level 1 LSPs or from the routes calculated by Level 1 Decision process? ii. In the configuration of the summary address , there are two parts the address mask and the prefix mask. How are these used and what values do these take? Can anyone explain these with an illustration? Any help in this regard is most welcome. Thanks and Regards Navaneeth. From rsaluja@nortelnetworks.com Tue, 21 Mar 2000 08:33:37 -0500 Date: Tue, 21 Mar 2000 08:33:37 -0500 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] Clarification on ISIS configuration Navaneeth K wrote: > > Hi all.. > > My doubt is with regard to the configuration of Summary Addresses in ISIS . > > i. Can summary addresses be configured for both Level 1 and Level 2? Only for Level2 as far as RFC is concerned. Summarization is done while advertising L1 routes into L2 domain. > If so , how do we use the Level 1 summary addresses? In advertising the summary addresses , > do we take it from the Level 1 LSPs or from the routes calculated by Level 1 Decision process? from the routes calculated by Level 1 decision process. > ii. In the configuration of the summary address , there are two parts the address mask and the prefix mask. > How are these used and what values do these take? Can anyone explain these with an illustration? If you have 192.9.3.0/24 and 192.9.2.0/24 networks allocated to your L1 domain, you could configure 192.9.2.0/23 as summary address which will basically aggregate both while advertising to L2 domain. Regards, Rajesh From henk@procket.com Tue, 21 Mar 2000 19:11:57 +0100 (CET) Date: Tue, 21 Mar 2000 19:11:57 +0100 (CET) From: henk@procket.com henk@procket.com Subject: [Isis-wg] Clarification on ISIS configuration Hello Navaneeth, hello all, > My doubt is with regard to the configuration of Summary Addresses in ISIS . > > i. Can summary addresses be configured for both Level 1 and Level 2? Yes, they can now. RFC1195 only specifies L1->L2 leaking, and only specifies redistribution into L2. This has changed with the new draft draft-ietf-isis-domain-wide-02.txt. > If so , how do we use the Level 1 summary addresses? With the new draft about route-leaking, there are now two descriptions of how routes can be summarized into L1. 1) is via L2->L1 route-leaking, and 2) via redistribution from outside the IGP into ISIS. > In advertising the summary addresses , do we take it from the Level > 1 LSPs or from the routes calculated by Level 1 Decision process? From routes calculated. The rule of thumb for routing protocols is that you only advertise routes that you use yourself. So if a prefix is in the LSPDB, but for some reason you didn't install it in the RIB, then you will not advertise it. Nor use it when calculating summary addresses. Hope this helps, Henk. From vanik@future.futsoft.com Wed, 22 Mar 2000 11:50:37 +0530 Date: Wed, 22 Mar 2000 11:50:37 +0530 From: vanisri .k vanik@future.futsoft.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsps Hi, I have doubts regarding the following. Please clarify me. 1. IS-IS allows multiple IP addresses assigned to an physical interface. What is the significant of it and where it is applied? 2. L2 Router advertises in its level 2 LSPs all the IP addresses reachable in their area. Summary address can be configured, otherwise all the level 1 Addresses obtained from the level 1 LSPs has to be advertised. My doubt is can we get the addresses from the "level 1 Forwarding Data base" instead of "level1 LSPs". RFC says (Sec 3.2 of 1195) these are determined from level 1 LSPs. Should the l2 router collects all l1 reachable addresses and the cost to reach them from level 1 LS data base, if summary address is not configured. Thanks -vani From jparker@nexabit.com Wed, 22 Mar 2000 09:34:40 -0500 Date: Wed, 22 Mar 2000 09:34:40 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s > Hi, > > I have doubts regarding the following. Please > clarify me. > > 1. > IS-IS allows multiple IP addresses assigned to > an physical interface. What is the significant of it > and where it is applied? IP allows multiple IP addresses assigned the the same interface. This can be used to allow a router to participate in multiple networks. ISIS just relays the information. > 2. > L2 Router advertises in its level 2 LSPs all the IP addresses > reachable in their area. Summary address can be configured, > otherwise all the level 1 Addresses obtained from the level 1 > LSPs has to be advertised. An optimization lets you reduce the network load by checking to see if the L1 route is comming from an L1/L2 router, which can be trusted to put it into L2 for you. > My doubt is can we get the addresses from the "level 1 > Forwarding Data base" > instead of "level1 LSPs". > RFC says (Sec 3.2 of 1195) these are determined from > level 1 LSPs. Should the l2 router collects all l1 reachable > addresses and the cost to reach them from level 1 LS data base, > if summary address is not configured. > > Thanks > -vani There are a number of issues in your question: I'm not sure which you are asking about. - jeff parker - Lucent INS From rsaluja@nortelnetworks.com Wed, 22 Mar 2000 09:37:43 -0500 Date: Wed, 22 Mar 2000 09:37:43 -0500 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsps "vanisri .k" wrote: > Hi, > > I have doubts regarding the following. Please > clarify me. > > 1. > IS-IS allows multiple IP addresses assigned to > an physical interface. What is the significant of it > and where it is applied? You can support multinetting on one physical interface. > > > 2. > L2 Router advertises in its level 2 LSPs all the IP addresses > reachable in their area. Summary address can be configured, > otherwise all the level 1 Addresses obtained from the level 1 > LSPs has to be advertised. > My doubt is can we get the addresses from the "level 1 Forwarding Data base" > instead of "level1 LSPs". > RFC says (Sec 3.2 of 1195) these are determined from > level 1 LSPs. Should the l2 router collects all l1 reachable > addresses and the cost to reach them from level 1 LS data base, > if summary address is not configured. Spec says "address obtained from level1 LSP". It is an implementation choice whether you want to extract this information from L1 LSPs or forwarding database or some other data structure. Regards, Rajesh From vanik@future.futsoft.com Thu, 23 Mar 2000 11:42:44 +0530 Date: Thu, 23 Mar 2000 11:42:44 +0530 From: vanisri .k vanik@future.futsoft.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Hi Jeff, My comments are inlined. > Hi, > > I have doubts regarding the following. Please > clarify me. > > 1. > IS-IS allows multiple IP addresses assigned to > an physical interface. What is the significant of it > and where it is applied? IP allows multiple IP addresses assigned the same interface. This can be used to allow a router to participate in multiple networks. ISIS just relays the information. [vanisri .k] Then how IS-IS should handle, when advertising reachable information about the nbr,having multiple IP addresses.? There will be multiple IP addresses (Reachable information) to that neighbor .? I am not much clear how IS-IS handles and relays the multiple IP addresses information. Could you please explain. > 2. > L2 Router advertises in its level 2 LSPs all the IP addresses > reachable in their area. Summary address can be configured, > otherwise all the level 1 Addresses obtained from the level 1 > LSPs has to be advertised. An optimization lets you reduce the network load by checking to see if the L1 route is comming from an L1/L2 router, which can be trusted to put it into L2 for you. > RFC says (Sec 3.2 of 1195) these are determined from > level 1 LSPs. Should the l2 router collects all l1 reachable > addresses and the cost to reach them from level 1 LS data base, > if summary address is not configured. > > Thanks > -vani There are a number of issues in your question: I'm not sure which you are asking about. [vanisri .k] My question was clarfied by Rajesh. My actual question was , How do the L1L2 Router collects the level 1 reachablity information, before it advertises in its level2 LSPs to other areas, from its level1 LSPs or Level 1 Forwarding Data base. ? Rajesh says, It is implementaion specific. - jeff parker - Lucent INS Thanks -vani From mshand@cisco.com Thu, 23 Mar 2000 12:00:29 +0000 Date: Thu, 23 Mar 2000 12:00:29 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsps At 09:37 22/03/2000 -0500, Rajesh Saluja wrote: >Spec says "address obtained from level1 LSP". It is an implementation choice >whether you want to extract this information from L1 LSPs or forwarding >database or some other data structure. But its important that what you extract is the REACHABLE addresses, not just any old addresses that happen to be skulking around in some unconnected L1 LSP. So in that sense you should get them from the RIB/FIB not from the raw LSP database. Mike From jparker@nexabit.com Thu, 23 Mar 2000 15:14:08 -0500 Date: Thu, 23 Mar 2000 15:14:08 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s > > 1. > > IS-IS allows multiple IP addresses assigned to > > an physical interface. What is the significant of it > > and where it is applied? > > IP allows multiple IP addresses assigned the same > interface. This can be used to allow a router to > participate in multiple networks. ISIS just relays > the information. > [vanisri .k] Then how IS-IS should handle, when advertising > reachable information about the nbr,having multiple IP addresses.? > There will be multiple IP addresses (Reachable information) > to that neighbor .? > I am not much clear how IS-IS handles and relays the multiple > IP addresses information. > Could you please explain. These IP Addresses could appear in two places: In the hello pkt sent out that port In the LSPs sent by that router If you have multiple IP addresses on a port, you could advertise one, both, or none in your L1 LSP and in your hellos. I think this is an implementation issue: but the principle of least surprise would probably suggest that you include both in Hellos and in LSPs. - jparker From satish@pluris.com Thu, 23 Mar 2000 12:30:43 -0800 Date: Thu, 23 Mar 2000 12:30:43 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Hi Jeff, Take a configuration of R1 and R2 in a area. Let R1 have 2 interfaces R1I1 and R1I2. R1 and R2 are connected via R1I2. Now, if R1I1 has multiple IP addresses, The only way R2 will know is by the LSP of R1 [ assume only isis is running;-) ] Then, where is the option of none of the IP reachability info in L1 LSP holds out? Well, there may be other cases where with a router sending none of the IP info still may have connectivity. But that does not mean protocol can have the option of not sending local reachability. Please let me know if I am missing something here. thanks, satish These IP Addresses could appear in two places: In the hello pkt sent out that port In the LSPs sent by that router If you have multiple IP addresses on a port, you could advertise one, both, or none in your L1 LSP and in your hellos. I think this is an implementation issue: but the principle of least surprise would probably suggest that you include both in Hellos and in LSPs. - jparker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From jparker@nexabit.com Thu, 23 Mar 2000 15:52:14 -0500 Date: Thu, 23 Mar 2000 15:52:14 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Satish - I will not try to defend the option "none", though I admit that I raised it earlier. There is a place for unnumbered interfaces, but that is another discussion. I am just trying to suggest that there is a great deal of leyway for implementations. There may be a reason to have a second IP address, and there may be a reason not to mention that address to the ISIS protocol. R2 will not know about it: that may be what the user wants. We do not want to be in the business of telling you how your users use the protocol. - jeff parker - I'm not sure if these opinions are mine, - much less those of Lucent Technologies. > Hi Jeff, > Take a configuration of R1 and R2 > in a area. Let R1 have 2 interfaces > R1I1 and R1I2. R1 and R2 are connected > via R1I2. > Now, if R1I1 has multiple IP addresses, > The only way R2 will know is by the LSP > of R1 [ assume only isis is running;-) ] > > Then, where is the option of none of the IP > reachability info in L1 LSP holds out? > > Well, there may be other cases where with a > router sending none of the IP info still may > have connectivity. But that does not mean > protocol can have the option of not sending > local reachability. > > Please let me know if I am missing something here. > thanks, > satish > > > These IP Addresses could appear in two places: > In the hello pkt sent out that port > In the LSPs sent by that router > > If you have multiple IP addresses on a port, you could > advertise one, both, or none in your L1 LSP and in your > hellos. I think this is an implementation issue: but > the principle of least surprise would probably suggest > that you include both in Hellos and in LSPs. > > - jparker > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From naiming@siara.com Thu, 23 Mar 2000 13:04:25 -0800 Date: Thu, 23 Mar 2000 13:04:25 -0800 From: Naiming Shen naiming@siara.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s ]Hi Jeff, ]Take a configuration of R1 and R2 ]in a area. Let R1 have 2 interfaces ]R1I1 and R1I2. R1 and R2 are connected ]via R1I2. ]Now, if R1I1 has multiple IP addresses, ]The only way R2 will know is by the LSP ]of R1 [ assume only isis is running;-) ] ] ]Then, where is the option of none of the IP ]reachability info in L1 LSP holds out? ] depends on if there is a need for R2 to know the IP address on R1I1. some IP addresses should be stay local only. so this is an implementation and configuration issue. even if R1I1 has isis configured on the interface, you don't have to stuff all the IP addresses on the LSPs, you have a choice say only put "primary" address there, or put all the addresses there, or even use some kind of filtering to selectively stuff part of the addresses there. An example is if you have a 10/x address on the interface as a secondary IP address, you may choose not to advertise it into your isis LSP. you can also use redistribution to selectively bring in your connected IP addresses using some kind of policy. ]Well, there may be other cases where with a ]router sending none of the IP info still may ]have connectivity. But that does not mean ]protocol can have the option of not sending ]local reachability. ] ]Please let me know if I am missing something here. ]thanks, ]satish ] ] ]These IP Addresses could appear in two places: ] In the hello pkt sent out that port ] In the LSPs sent by that router ] ]If you have multiple IP addresses on a port, you could ]advertise one, both, or none in your L1 LSP and in your ]hellos. I think this is an implementation issue: but ]the principle of least surprise would probably suggest ]that you include both in Hellos and in LSPs. ] ]- jparker ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From mbartell@cisco.com Fri, 24 Mar 2000 00:56:20 -0600 Date: Fri, 24 Mar 2000 00:56:20 -0600 From: Micah Bartell mbartell@cisco.com Subject: [Isis-wg] ISIS TE Draft Do we have a new revision of the draft-ietf-isis-traffic? Revision 02 has expired. This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on March 20, 2000. /mpb -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer, NSA Phone: 972.364.8829 Cisco Systems, Inc Fax: 972.364.8829 -- The Network Works, No Excuses From dwfedyk@nortelnetworks.com Fri, 24 Mar 2000 11:31:51 -0500 Date: Fri, 24 Mar 2000 11:31:51 -0500 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] ISIS TE Draft 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_01BF95AE.76AE75BA Content-Type: text/plain; charset="iso-8859-1" This is a good point. I will mention it at the Routing Area meeting. We are proposing extensions to this draft and OSPF. Neither WG is meeting at Adelaide though. Regards, Don > -----Original Message----- > From: Micah Bartell [mailto:mbartell@cisco.com] > Sent: Friday, March 24, 2000 1:56 AM > To: isis-wg@external.juniper.net > Subject: [Isis-wg] ISIS TE Draft > > > Do we have a new revision of the draft-ietf-isis-traffic? > > Revision 02 has expired. > > This Internet-Draft has expired and is no longer available. > Unrevised documents placed in the Internet-Drafts directories > have a maximum life of six months. After that time, they must > be updated, or they will be deleted. This document was > deleted on March 20, 2000. > > > /mpb > > > -- > Micah Bartell, CCIE #5069 mbartell@cisco.com > Network Consulting Engineer, NSA Phone: 972.364.8829 > Cisco Systems, Inc Fax: 972.364.8829 > -- > The Network Works, No Excuses > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > ------_=_NextPart_001_01BF95AE.76AE75BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] ISIS TE Draft

This is a good point. I will mention it at the = Routing
Area meeting. We are proposing extensions to this = draft and
OSPF. Neither WG is meeting at Adelaide = though.

Regards,
Don

> -----Original Message-----
> From: Micah Bartell [mailto:mbartell@cisco.com]=
> Sent: Friday, March 24, 2000 1:56 AM
> To: isis-wg@external.juniper.net
> Subject: [Isis-wg] ISIS TE Draft
>
>
> Do we have a new revision of the = draft-ietf-isis-traffic?
>
> Revision 02 has expired.
>
> This Internet-Draft has expired and is no = longer available.
> Unrevised documents placed in the = Internet-Drafts directories
> have a maximum life of six months. After that = time, they must
> be updated, or they will be deleted. This = document was
> deleted on March 20, 2000.
>
>
> /mpb
>
>
> --
> Micah Bartell, CCIE = #5069     =         =         mbartell@cisco.com
> Network Consulting Engineer, = NSA      =         Phone: 972.364.8829
> Cisco Systems, Inc    =         =         =         Fax: 972.364.8829
> --
> The Network Works, No Excuses
>
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
>

------_=_NextPart_001_01BF95AE.76AE75BA-- From henk@procket.com Sun, 26 Mar 2000 19:59:50 +0200 (CEST) Date: Sun, 26 Mar 2000 19:59:50 +0200 (CEST) From: Henk Smit henk@procket.com Subject: [Isis-wg] ISIS TE Draft > Do we have a new revision of the draft-ietf-isis-traffic? No. However, I will have a look at it in the near future, and get a new version out. Might take a few weeks, though. If anyone has any comments or remarks, please let me know. Henk. > Revision 02 has expired. > > This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on March 20, 2000. > > > /mpb > > > -- > Micah Bartell, CCIE #5069 mbartell@cisco.com > Network Consulting Engineer, NSA Phone: 972.364.8829 > Cisco Systems, Inc Fax: 972.364.8829 > -- > The Network Works, No Excuses > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From selvarajr@future.futsoft.com Wed, 5 Apr 2000 12:10:39 +0530 Date: Wed, 5 Apr 2000 12:10:39 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt regarding PtPtCircId ------ =_NextPart_000_01BF9EF7.F66220C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Please, could any of you tell the use of PtPtCircId in Integrated ISIS MIB. This object is mentioned in the circuit Table. The standard has mentioned some negotiation process for that. But I find it is no where used in the Protocol. SELVA ------ =_NextPart_000_01BF9EF7.F66220C0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IikGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAGwAAAERvdWJ0IHJlZ2FyZGluZyBQdFB0Q2lyY0lkAKcJAQWAAwAOAAAA 0AcEAAUADAAKACcAAwAgAQEggAMADgAAANAHBAAFAAwAAwAsAAMAHgEBCYABACEAAAAxOTY5OTI3 ODQxMEFENDExQTg1ODAwMjAzNTFGOTJBMADGBgEDkAYAYAQAACAAAAALAAIAAQAAAAsAIwAAAAAA AwAmAAAAAAALACkAAAAAAAMANgAAAAAAQAA5AMCCbNvJnr8BHgBwAAEAAAAbAAAARG91YnQgcmVn YXJkaW5nIFB0UHRDaXJjSWQAAAIBcQABAAAAFgAAAAG/nsnbY3iSaR8KQRHUqFgAIDUfkqAAAB4A HgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAdAAAAc2VsdmFyYWpyQGZ1dHVyZS5mdXRzb2Z0LmNv bQAAAAADAAYQNa9yjgMABxDCAAAAHgAIEAEAAABlAAAASElQTEVBU0UsQ09VTERBTllPRllPVVRF TExUSEVVU0VPRlBUUFRDSVJDSURJTklOVEVHUkFURURJU0lTTUlCVEhJU09CSkVDVElTTUVOVElP TkVESU5USEVDSVJDVUlUVEFCTAAAAAACAQkQAQAAAD8BAAA7AQAAgwEAAExaRnXoe3gMAwAKAHJj cGcxMjUWMgD4C2BuDhAwMzOdAfcgAqQD4wIAY2gKwGBzZXQwIAcTAoB9OQqBdWMAUAsDC7UgSA5p CuMKhAqAUGxlYQkRMCwgBaB1bGQggQBweSBvZiB5CGAQIHRlbAMgdGhlTCB1ETAVQlB0FsBDMGly Y0kU8AuAICBqSQIwZQnAYRXAFPBJBlMYYAXQSUIuIFTmaAQAFUBiagWQBUAZIXsHgAIwaQIgGDEX cRYSY2kXEXVpBUBUAaAUQC6XE3QZABYwcwGQbmQLEXYgEQAZ2nMDcBYwGlBnTm8aIBgQGjEgcANg Y38HkAQgAhAFwBYQGBAY4EJ6dQVASR9wC4AXURmjbnhvIHcWIAlwFkIad1A9A2B0HyAG8BvVE3pT RVhMVkETdBHxACUgAAMAEBAAAAAAAwAREAAAAAADAIAQ/////0AABzDgrjbkyJ6/AUAACDDgrjbk yJ6/AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYA AAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMAB4AIIAYAAAAAAMAA AAAAAABGAAAAAAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4w NAAAAAALAAmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABG AAAAABGFAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAyACCAGAAAAAADA AAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEA AAABAAAAAAAAAB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAA AAEAAAAAAAAAAwANNP03AAC+yw== ------ =_NextPart_000_01BF9EF7.F66220C0-- From mshand@cisco.com Wed, 05 Apr 2000 09:11:21 +0100 Date: Wed, 05 Apr 2000 09:11:21 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Doubt regarding PtPtCircId At 12:10 05/04/2000 +0530, SelvarajR wrote: >Hi > >Please, could any of you tell the use of PtPtCircId in Integrated ISIS >MIB. This object is mentioned in the circuit Table. >The standard has mentioned some negotiation process for that. But I find >it is no where used in the Protocol. 8.2.4.2 sub-clause (d) (if the circuit ID changes drop the adjacency). You are right that this is not ever SENT in the protocol. The local circuit ID is used for that. But the existing value is checked against the newly computed value (based on the value of the other nodes's local circuit ID carried in the protocol. Mike >SELVA From selvarajr@future.futsoft.com Wed, 5 Apr 2000 14:31:02 +0530 Date: Wed, 5 Apr 2000 14:31:02 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt regarding PtPtCircId ------ =_NextPart_000_01BF9F0B.93ECF5A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit But that section is totally left out in the 10589 1998 draft. This I'm mentioning just to consider while taking corrective action in the draft. Thanks SELVA -----Original Message----- From: Mike Shand [SMTP:mshand@cisco.com] Sent: Wednesday, April 05, 2000 1:41 PM To: SelvarajR; 'ISIS-WG' Subject: Re: [Isis-wg] Doubt regarding PtPtCircId At 12:10 05/04/2000 +0530, SelvarajR wrote: >Hi > >Please, could any of you tell the use of PtPtCircId in Integrated ISIS >MIB. This object is mentioned in the circuit Table. >The standard has mentioned some negotiation process for that. But I find >it is no where used in the Protocol. 8.2.4.2 sub-clause (d) (if the circuit ID changes drop the adjacency). You are right that this is not ever SENT in the protocol. The local circuit ID is used for that. But the existing value is checked against the newly computed value (based on the value of the other nodes's local circuit ID carried in the protocol. Mike >SELVA _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------ =_NextPart_000_01BF9F0B.93ECF5A0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgYJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAIAMAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAOQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAE1pa2UgU2hhbmQAU01U UABtc2hhbmRAY2lzY28uY29tAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgADMAEAAAARAAAAbXNo YW5kQGNpc2NvLmNvbQAAAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAANAAAAJ01pa2UgU2hhbmQn AAAAAAIBCzABAAAAFgAAAFNNVFA6TVNIQU5EQENJU0NPLkNPTQAAAAMAADkAAAAACwBAOgAAAAAD AHE6AAAAAB4A9l8BAAAACwAAAE1pa2UgU2hhbmQAAAIB918BAAAAOQAAAAAAAACBKx+kvqMQGZ1u AN0BD1QCAAABAE1pa2UgU2hhbmQAU01UUABtc2hhbmRAY2lzY28uY29tAAAAAAMA/V8BAAAAAwD/ XwAAAAACAfYPAQAAAAQAAAAAAAADEAAAAAMAADAEAAAACwAPDgAAAAACAf8PAQAAAG4AAAAAAAAA tTvCwCx3EBqhvAgAKypWwhUAAAAT3mZrXmHTEahYACA1H5KgZIgAAAAAAACBKx+kvqMQGZ1uAN0B D1QCAAAAAElTSVMtV0cAU01UUABpc2lzLXdnQGV4dGVybmFsLmp1bmlwZXIubmV0AAAAHgACMAEA AAAFAAAAU01UUAAAAAAeAAMwAQAAAB0AAABpc2lzLXdnQGV4dGVybmFsLmp1bmlwZXIubmV0AAAA AAMAFQwCAAAAAwD+DwYAAAAeAAEwAQAAAAoAAAAnSVNJUy1XRycAAAACAQswAQAAACIAAABTTVRQ OklTSVMtV0dARVhURVJOQUwuSlVOSVBFUi5ORVQAAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEAAAAI AAAASVNJUy1XRwACAfdfAQAAACwAAAC/AAAAtTvCwCx3EBqhvAgAKypWwhUAAAAT3mZrXmHTEahY ACA1H5KgZIgAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAEQZcBBIABACkAAABSRTog W0lzaXMtd2ddIERvdWJ0IHJlZ2FyZGluZyBQdFB0Q2lyY0lkABMOAQWAAwAOAAAA0AcEAAUADgAf AAIAAwASAQEggAMADgAAANAHBAAFAA4AGAAfAAMAKAEBCYABACEAAAAyNjY5OTI3ODQxMEFENDEx QTg1ODAwMjAzNTFGOTJBMADEBgEDkAYAtAcAACIAAAALAAIAAQAAAAsAIwAAAAAAAwAmAAAAAAAL ACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAgPwTeN2evwEeAHAAAQAAACkAAABSRTogW0lzaXMt d2ddIERvdWJ0IHJlZ2FyZGluZyBQdFB0Q2lyY0lkAAAAAAIBcQABAAAAFgAAAAG/nt132niSaSgK QRHUqFgAIDUfkqAAAB4AHgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAdAAAAc2VsdmFyYWpyQGZ1 dHVyZS5mdXRzb2Z0LmNvbQAAAAADAAYQrBTkowMABxBhAwAAHgAIEAEAAABlAAAAQlVUVEhBVFNF Q1RJT05JU1RPVEFMTFlMRUZUT1VUSU5USEUxMDU4OTE5OThEUkFGVFRISVNJTU1FTlRJT05JTkdK VVNUVE9DT05TSURFUldISUxFVEFLSU5HQ09SUkVDVElWRQAAAAACAQkQAQAAADsEAAA3BAAAgwYA AExaRnW9CosOAwAKAHJjcGcxMjV2MgD0AfcgAqQD4wIAY4JoCsBzZXQwIAcThwKDAFAPtnBycTIQ tmZ9CoAIyCA7CW8OMDWzAoAKgXVjAFALA2MAQUULYG4OEDAzMwumIHRCdQVAdBBABUAQcGO0dGkC ICAEABdQbwGQoGxseSBsAXEgCGAnBUALgBdRZSAWUDU4AjkZ0Dk5OCBkckJhAYAuIFRoGDFJeCdt IAeAAjAX8QuAZ5AganVzF0FvIAWgcwCBBIEgdxsQGOAXUGHeaxwCBaEJcBfRdhnAAND/F+QZhBqU CqIKhAqAGwAAcAZrBCEgKVNFTFZBwyAaCvRsaTM2AUAV0B8BQBIAGHAXwRFEMTYg6i0lEk8FEGcL gAdABdDhB5BzYWdlJRMgFiQkByPxCxMkJmktMTQ04wFAI3AxODABQAzQKLOoYiBGA2E6DINiEKAo TWlrGcBTIOFkIABbU01UUDptc1krMkBjBAAFoC4FoG2+XSAVKeAGYAIwKkdXCYDCbgeQZGF5LBCw EgA/AxEZ8C7gAdApQBnQOjSQMSBQTSz3VG8qRwkGYGx2CsBhalI7ECAnSVMyYC1XR2InLPh1YmoX wSpHUhRlOitwSQCQcy130GddIEQIYGIFQAlwJmcLERwCUHQ2UENp+HJjSQsxJt8n6CN0C7ZtICNB BUAOIDoWUC9RLygwNC8voysZ8DMwPy7gMacdQCQiKkAgIz5I1wCgPLQ8pVAY4GEQcC7gOQWgdWwr YABwGMBvZvwgeQhgF1AxsAMgGaIcUP8ZwD8xNlgZYhtAAjA1wBqgDyRAK2AyYiE1Pk1JQv0a5W8z kxgiG5VCERl1LFDpNrB1aQVAVAGgGOAgBb4+GwAZwBxgK0ELESAQQN1EKnMDcBnALoBnGHAHMOsX 4yQRYyYBIAIQBcAXYvsa4BciSUnQC4ArYDylRaF9GDFuHKAdUASQQBNEx1APJCFJgAbwIAs4LjIu zjROsBegM4AtYwtgQDI4KGQpT8AGkEULSUSfHLAg4SZABCAakG9wGZMYYWRqANAJ8GN5Kb0gC1k/ cQrAGcAlcWgXRe8XYBgxS9MFQGUeoAXAIgD8TlQZZiQSTZMa8RnACQD+YyXBRVYgFFERGDFMk0ns +RmiZXgEABfgHBEx0ApB/xgiEDAFkCrwPtE10AuAHGK7GbEugHcYsSAULLFwFzDzQhFbRChiPkEr YBgBGaJ/W0Q/MRmiGHBMQUvxAQBz/icEIFesURFdZgrACIFEx/9WxyJeCoBBcGV1KtJkXyBl9j4i DyAUX2lPal9rKliF/zTUG4ALcCNwHBEjcBxhJQB7QXE01EBasCRABKAHQC7rHEADAHAEkC4ugCRw ICQPFdI+sEdgAkBwOi8v226vb7EvbRIDgS9tkguA/QIQLwQANOMjwz6wOYUSwQIAdSAAAwAQEAAA AAADABEQAAAAAB4AQhABAAAALwAAADw0LjIuMi4yMDAwMDQwNTA5MDgxNC4wMGFhZTYxMEBqYXdz LmNpc2NvLmNvbT4AAAMAgBD/////QAAHMGCYBI/cnr8BQAAIMGCYBI/cnr8BCwAAgAggBgAAAAAA wAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAI IAYAAAAAAMAAAAAAAABGAAAAAFKFAADzFQAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAA AAAeAAiACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAAAAsACYAIIAYAAAAA AMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAAuA CCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAAB AAAAAQAAAAAAAAAeAA2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAOgAgg BgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAABQAAAFJFOiAAAAAAAwAN NP03AABe0g== ------ =_NextPart_000_01BF9F0B.93ECF5A0-- From mshand@cisco.com Wed, 05 Apr 2000 10:15:51 +0100 Date: Wed, 05 Apr 2000 10:15:51 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Doubt regarding PtPtCircId At 14:31 05/04/2000 +0530, SelvarajR wrote: >But that section is totally left out in the 10589 1998 draft. This I'm >mentioning just to consider while taking corrective action in the draft. Which just goes to show that you should not believe ANYTHING you read in the so called 1998 draft. I think the strategy being adopted is to ignore the 1998 draft, but start with the original 1992 standard, and apply all the defect reports etc. to that. Mike From rvaradar@fore.com Thu, 6 Apr 2000 17:39:06 -0400 (EDT) Date: Thu, 6 Apr 2000 17:39:06 -0400 (EDT) From: Rajesh Varadarajan rvaradar@fore.com Subject: [Isis-wg] Doubt regarding PtPtCircId This misunderstanding of using one draft vs the other has happened *multiple* times in the mailing list. It would be useful to have a pointer to the ISO document that is to be used for reference at the IETF web site or at a place which is *freely* accessible. This will for hopefully avoid this type of misunderstanding so that people know what version of the standard to implement to. For ISO liasons or WG chairs - Would ISO would make it available for use for the IETF community for *free* :) along with the defect reports that are relevant for ISIS. thanks, rajesh On Wed, 5 Apr 2000, Mike Shand wrote: > At 14:31 05/04/2000 +0530, SelvarajR wrote: > >But that section is totally left out in the 10589 1998 draft. This I'm > >mentioning just to consider while taking corrective action in the draft. > > Which just goes to show that you should not believe ANYTHING you read in > the so called 1998 draft. > > I think the strategy being adopted is to ignore the 1998 draft, but start > with the original 1992 standard, and apply all the defect reports etc. to > that. > > > Mike > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From selvarajr@future.futsoft.com Fri, 7 Apr 2000 18:00:11 +0530 Date: Fri, 7 Apr 2000 18:00:11 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt reg system type usage in Integ. ISIS ------ =_NextPart_000_01BFA0BB.21070560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi The Integ,ISIS MIB draft has specified three values for system type( L1(1) or L2(2) or L1AndL2 (3) ) in the system table But the Hello PDU transmission is based on whether system Type is L1 (1) ,or L2 (3) and manualCircL2Only( TRUE/FALSE) Here, if the system type is L1AndL2 ( 3 ) then no Hello be sent. The system type object in the MIB shall be defined to take only two values, L1 (1) or L2 (2). No L1AndL2 ( 3 ). I hope the MIB Draft is still Valid.. How can we handle this anomaly? SELVA ------ =_NextPart_000_01BFA0BB.21070560 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhAMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAKwAAAERvdWJ0IHJlZyBzeXN0ZW0gdHlwZSB1c2FnZSBpbiBJbnRlZy4g SVNJUwDMDgEFgAMADgAAANAHBAAHABIAAAALAAUABAEBIIADAA4AAADQBwQABwARACwAJQAFAEkB AQmAAQAhAAAARUJGMzRBOUQ3QzBDRDQxMUE4NTgwMDIwMzUxRjkyQTAAHAcBA5AGACAFAAAgAAAA CwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQDAC30EjaC/AR4AcAAB AAAAKwAAAERvdWJ0IHJlZyBzeXN0ZW0gdHlwZSB1c2FnZSBpbiBJbnRlZy4gSVNJUwAAAgFxAAEA AAAWAAAAAb+gjQR1nUrz7Qx8EdSoWAAgNR+SoAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAA AB0AAABzZWx2YXJhanJAZnV0dXJlLmZ1dHNvZnQuY29tAAAAAAMABhC3lZrsAwAHEIgBAAAeAAgQ AQAAAGUAAABISVRIRUlOVEVHLElTSVNNSUJEUkFGVEhBU1NQRUNJRklFRFRIUkVFVkFMVUVTRk9S U1lTVEVNVFlQRShMMSgxKU9STDIoMilPUkwxQU5ETDIoMykpSU5USEVTWVNURU1UQUJMAAAAAAIB CRABAAAA7QEAAOkBAAC8AgAATFpGdWkT1GIDAAoAcmNwZzEyNRYyAPgLYG4OEDAzM50B9yACpAPj AgBjaArAYHNldDAgBxMCgH05CoF1YwBQCwMLtSBIDwCgCrEKhAqAVGhlIIJJAjBlZyxJUxTAgQXQ SUIgZHJhAYDmIBEABCBzcAWQBpAIkJBkIHRoCdEgdgdAjwpQBCACEAXAc3lzFIAKbRaAeRYAKCBM MRAoMSkgBbFMMihCMhi0MUFuZBkAIPwoMxiwGLALgBaBFEAXpskBoGxlE2RCdQVAGqIISGVsCQAg UERV1xaAFWAAgG0EAWkCIBpg3QQgYhXAFmEdwXcUMBqh/ReHVBghHeITZBhwGgAYoX4sBbAgJRn0 AHAWcAOBdSEHQENpcmMZAE9uBGx5GFBUUlVFL8BGQUxTRSkTahyAdQlwLBpgZhqbH7UZlyDOMxpB GqEDoCBuHMAchGZiGsEJ8HQuE24lmm+8YmoFkAVAGnUVEnMRAH8coChCAQELgBZiHMABkGv3KnEj ARaAdxzAFvQlACCF9xjTGgAZMC4HsBzAJosoy9pJFaBvH8ErNkQVYx3xFxfAAxADIFYHQGlkLqko y0hvB+BjA5F3FED/EQAZwBuAFoEd8QBwA3EjEI4/E2oTaiPQTFZBE2QFEfEAOLAAAAADABAQAAAA AAMAERAAAAAAAwCAEP////9AAAcwQDud14qgvwFAAAgwQDud14qgvwELAACACCAGAAAAAADAAAAA AAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAA AAAAwAAAAAAAAEYAAAAAUoUAAPMVAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAB4A CIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAAADguMDQAAAAACwAJgAggBgAAAAAAwAAA AAAAAEYAAAAADoUAAAAAAAADAAqACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAC4AIIAYA AAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAMgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAAB AAAAAAAAAB4ADYAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAA6ACCAGAAAA AADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAHgA9AAEAAAABAAAAAAAAAAMADTT9NwAASgs= ------ =_NextPart_000_01BFA0BB.21070560-- From jparker@nexabit.com Fri, 7 Apr 2000 10:01:42 -0400 Date: Fri, 7 Apr 2000 10:01:42 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] RE: Doubt reg system type usage in Integ. ISIS > Hi > > The Integ,ISIS MIB draft has specified three values for > system type( L1(1) or L2(2) or L1AndL2 (3) ) in the system table > But the Hello PDU transmission is based on whether system Type is > L1 (1) ,or > L2 (3) and manualCircL2Only( TRUE/FALSE) > > Here, if the system type is L1AndL2 ( 3 ) then no Hello be sent. > > The system type object in the MIB shall be defined to take > only two values, L1 (1) or L2 (2). No L1AndL2 ( 3 ). > > I hope the MIB Draft is still Valid.. > > How can we handle this anomaly? > > SELVA Selva - As you know, L2 in line 7 above means L1AndL2. The current MIB work reflects many changes that have been deployed since the original version of 10589 was written. This is one place where existing practice and the document conflict. When implementing a system, you may decide if you wish to implement the a system that supports system type of L2 only. If not, you need not vary your implementation of the Hello Transmission. If you would like to support L2 only systemType, you will need to change the algorithm in the Hello PDU transmission in the obvious fashion. - jeff parker From selvarajr@future.futsoft.com Fri, 7 Apr 2000 20:38:14 +0530 Date: Fri, 7 Apr 2000 20:38:14 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] RE: Doubt reg system type usage in Integ. ISIS ------ =_NextPart_000_01BFA0D1.34EFC100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jeff, Thank U Thers is one mistake in my last mail. The line number 7 should have been "L2 (2) and manualCircL2Only( TRUE/FALSE)" I'm sorry. That what I like to convey is, setting 3 to system type object in system table will case problem during Hello transmission. OK , anyhow I accept ur suggestion that the implementation should decide over the algorithm. SELVA -----Original Message----- From: Jeff Parker [SMTP:jparker@nexabit.com] Sent: Friday, April 07, 2000 7:32 PM To: selvarajr@kailash.future.futsoft.com; 'ISIS-WG' Subject: RE: Doubt reg system type usage in Integ. ISIS > Hi > > The Integ,ISIS MIB draft has specified three values for > system type( L1(1) or L2(2) or L1AndL2 (3) ) in the system table > But the Hello PDU transmission is based on whether system Type is > L1 (1) ,or > L2 (3) and manualCircL2Only( TRUE/FALSE) > > Here, if the system type is L1AndL2 ( 3 ) then no Hello be sent. > > The system type object in the MIB shall be defined to take > only two values, L1 (1) or L2 (2). No L1AndL2 ( 3 ). > > I hope the MIB Draft is still Valid.. > > How can we handle this anomaly? > > SELVA Selva - As you know, L2 in line 7 above means L1AndL2. The current MIB work reflects many changes that have been deployed since the original version of 10589 was written. This is one place where existing practice and the document conflict. When implementing a system, you may decide if you wish to implement the a system that supports system type of L2 only. If not, you need not vary your implementation of the Hello Transmission. If you would like to support L2 only systemType, you will need to change the algorithm in the Hello PDU transmission in the obvious fashion. - jeff parker ------ =_NextPart_000_01BFA0D1.34EFC100 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhIPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYALAMAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAEplZmYgUGFya2VyAFNN VFAAanBhcmtlckBuZXhhYml0LmNvbQAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAFAAA AGpwYXJrZXJAbmV4YWJpdC5jb20AAwAVDAEAAAADAP4PBgAAAB4AATABAAAADgAAACdKZWZmIFBh cmtlcicAAAACAQswAQAAABkAAABTTVRQOkpQQVJLRVJATkVYQUJJVC5DT00AAAAAAwAAOQAAAAAL AEA6AAAAAAMAcToAAAAAHgD2XwEAAAAMAAAASmVmZiBQYXJrZXIAAgH3XwEAAAA9AAAAAAAAAIEr H6S+oxAZnW4A3QEPVAIAAAEASmVmZiBQYXJrZXIAU01UUABqcGFya2VyQG5leGFiaXQuY29tAAAA AAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAADEAAAAAMAADAEAAAACwAPDgAAAAACAf8P AQAAAG4AAAAAAAAAtTvCwCx3EBqhvAgAKypWwhUAAAAT3mZrXmHTEahYACA1H5KgZIgAAAAAAACB Kx+kvqMQGZ1uAN0BD1QCAAAAAElTSVMtV0cAU01UUABpc2lzLXdnQGV4dGVybmFsLmp1bmlwZXIu bmV0AAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAAB0AAABpc2lzLXdnQGV4dGVybmFsLmp1 bmlwZXIubmV0AAAAAAMAFQwCAAAAAwD+DwYAAAAeAAEwAQAAAAoAAAAnSVNJUy1XRycAAAACAQsw AQAAACIAAABTTVRQOklTSVMtV0dARVhURVJOQUwuSlVOSVBFUi5ORVQAAAADAAA5AAAAAAsAQDoB AAAAHgD2XwEAAAAIAAAASVNJUy1XRwACAfdfAQAAACwAAAC/AAAAtTvCwCx3EBqhvAgAKypWwhUA AAAT3mZrXmHTEahYACA1H5KgZIgAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAE2Z0B BIABAC8AAABSRTogRG91YnQgcmVnIHN5c3RlbSB0eXBlIHVzYWdlIGluIEludGVnLiBJU0lTAL0P AQWAAwAOAAAA0AcEAAcAFAAmAA4ABQAvAQEggAMADgAAANAHBAAHABQACQAbAAUAHwEBCYABACEA AABGMEYzNEE5RDdDMENENDExQTg1ODAwMjAzNTFGOTJBMAALBwEDkAYAOAkAACIAAAALAAIAAQAA AAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAYKTTGKOgvwEeAHAA AQAAAC8AAABSRTogRG91YnQgcmVnIHN5c3RlbSB0eXBlIHVzYWdlIGluIEludGVnLiBJU0lTAAAC AXEAAQAAABYAAAABv6CjGKqdSvP0DHwR1KhYACA1H5KgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4A HwwBAAAAHQAAAHNlbHZhcmFqckBmdXR1cmUuZnV0c29mdC5jb20AAAAAAwAGEFIcAf0DAAcQRQUA AB4ACBABAAAAZQAAAEhJSkVGRixUSEFOS1VUSEVSU0lTT05FTUlTVEFLRUlOTVlMQVNUTUFJTFRI RUxJTkVOVU1CRVI3U0hPVUxESEFWRUJFRU4iTDIoMilBTkRNQU5VQUxDSVJDTDJPTkxZKFRSVUUA AAAAAgEJEAEAAACqBQAApgUAADUJAABMWkZ1gZfW2gMACgByY3BnMTI1djIA9AH3IAKkA+MCAGOC aArAc2V0MCAHE4cCgwBQD7ZwcnEyELZmfQqACMggOwlvDjA1swKACoF1YwBQCwNjAEFFC2BuDhAw MzMLpiDQSGkgSgERLAqiCoSFCoBUEEBuayBVF6wXBJAEIAQAIAIgZSBtOwQAAZBrGkALgBpQeSCP C2AagBpQC3BsLiAZkc4gGzALgBpAbnUG0ASQJCA3HCBzaAhgbGT6IBBAdhpAHMAJ8ArjCoAWIhXB EKBMEjAoMikuIABwHYADgXUHQENpBHJjHwBPbmx5KAEb4FJVRS9GQUwYU0UpHqAXs0knbVMdIAWw cnkb0mEFQHeNIrJJHDEasXRvIAWgbm4dwBsgBAAsHSAQgHSRC4BnIDMjonN5GoAiZSIQdHlwGkBv Yr5qBZAFQBrhJWYBoGwaQPUD8GwDIGMbUBpAEgAmIJsnYCIQZAhxJOFIZSeweSPAdHIAcRphAJAC IC6xF6pPSyAkcABweR1A5wfgI0AA0GNlBTEIcB0g+HVnZweQJMACICOgIrL7LUAawW0LUCWgCfAB kCzz+x01BYFpAQAaEB3ABcAtktUHQGcFsGktQG0qSzE/4gohUExWQTGfCpAV0ucXtwswHEAzNgFA HsEKoA8DYCWQJmARRDE2IC31NsJPBRBnC4AHQAXQB5D8c2EswDbDF6Y11DWhCxPBNdZpLTE0NAFA HEA4MTgwAUAM0DpjYiBqRgNhOgyDYhCgF1IgDlAKwBqwBcBbU01UWFA6agqxPQFAGjB4ywGgMIAu BaBtXRelO5CfBmACMDv3O7AvYGF5JHDmQRIAAxEwNyRwAdA68Ekc8DozEjBQTT7nVCZvO/cQcGx2 CsBhag0+AGsboRtQaC5mdXp0CHBlRHIiMAGAPpI7ECAnSVNF0C1XRxonPuh1JjM791JFOvQgRAhg YgVACXAk8CVq9nU30hrSSQIwSJAb0EXS3zhvOXo1JAu2F7M+FxFNZjdNZhvyShMsRdIF0ElC3yig KZABgB2RBCBzJfAvUO86MAmALTEJ0SBDkApBBCAfAhAK1E2iJWkgsEwxKD4xH1AFsR8AHzJUMjFB +x+AHwIzH1AfUBrhLZImyh1NZkJEkC2DKSRQRFX7KXsZ4mIn8R2ALREi8BCA+xmhJVZUJeIZ8U1m U9AfIP1UASwFsFunVVQffyCOTg7/KSAJcCRwBpBV+1s1VPclAf9dkC2RA6AcgCPAKSQcwCSB/wIw KkVObCVvJnMtkk/yHTD/B0ADIGRRAQEcUVFRKWEaou9NZgIgIJAjoHcjwFHUJHDvXCVUMx8iG9BO I8Bii2TP7yNAHUAl8Wd2RFBDGfEs4a0nsVYHQC9gLm0/SCuh7yfgWhEaQBhxZCdhLUAZ8fcAcANx IJA/ZN4yvwZgQ4FfNrAXpQGRELAEIHkIYCD6a2PAd2rxEjAa4RxDHQD3AaAvoRpQZQYiVPUb0B41 +3YJG/JjCHAJcAIwT+NqYPs88EhxZidgJmAEIAOBGyD/EDEWMAeRLUMdohekHfMBANkLUG95UUEA kG4sEC2DXzBhN0QvsVkjRTAgFlA17Dg5IuBQoXcwcWZAKjD/eZYYYBnxGfULUX9xWjEJcP4gPjAa cSTSEgAA0CTAf3HzXbItkmRvewAuIhekI+HvfDAN4D6AHCBXY3It1yTS/3XQZhQkcHbiAMAbIC81 YSH3F6R24gPxaCOiLdcv5GYH8yKyLJBwcAkRULFmIxek3yXUPLAfAWoCeYFJPLBjwP50iRQaMFFB j9FRwSJgdtLfBcAt3BekgPFXyFQpmo+D/4qzHVMjZo01F6SPBWYFWyL/iRQnk5BjI7J9Ay/sF6RV 1e9YD1kVVeQmIHYqEEmAUjDnREGUNBeqLSAmQDyhPbQLF6QSwQCgQAAAAwAQEAAAAAADABEQAAAA AB4AQhABAAAAPQAAADxCQUM5Q0NGMDRGRUVEMzExQkQxRDAwMDYyOTUwQUJCMTIxOEQwMEBiYW5k aXRvLm5leGFiaXQuY29tPgAAAAADAIAQ/////0AABzAgwBUTn6C/AUAACDAgwBUTn6C/AQsAAIAI IAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAA AAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAA AAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4wNAAAAAALAAmA CCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAA AAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAyACCAGAAAAAADAAAAAAAAARgAA AAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAA AB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTog AAAAAAMADTT9NwAABHA= ------ =_NextPart_000_01BFA0D1.34EFC100-- From navaneethk@future.futsoft.com Thu, 20 Apr 2000 13:14:49 +0530 Date: Thu, 20 Apr 2000 13:14:49 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification.. Hi.. In the case of processing of the LSPs in integrated ISIS , used for IP forwarding, How are the interface addresses (4 octet Values without mask) in the TLVs used in route tabel calculation. Can any of you help out on how these i/f addresses are used? Thanx Navaneeth. From prkumar@nortelnetworks.com Thu, 20 Apr 2000 09:08:03 -0400 Date: Thu, 20 Apr 2000 09:08:03 -0400 From: Prashant Kumar prkumar@nortelnetworks.com Subject: [Isis-wg] Clarification.. Hello Navaneeth, For route calculation IP Internal reachability, IP external reachability and IS reachability TLVs are used. Please refer the SPF calculation section(Dijkstra) C.1 in RFC1195. Hope this helps you. Regards, Prashant. Navaneeth K wrote: > > Hi.. > > In the case of processing of the LSPs in integrated ISIS , used for IP forwarding, > How are the interface addresses (4 octet Values without mask) in the TLVs used in route tabel calculation. > Can any of you help out on how these i/f addresses are used? > > Thanx > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- Prashant Kumar Nortel Networks Telephone : 978-288-7947(o) Billerica, MA 01821 ESN : 288-7947 From navaneethk@future.futsoft.com Thu, 20 Apr 2000 20:56:46 +0530 Date: Thu, 20 Apr 2000 20:56:46 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm Hi, This doubt is regarding the SPF algorithm mentioned in RFC 1195 The section 8 under STEP 0: Says: " Now add systems to which the local router does not have adjacencies, but which are mentioned in neighbouring pseudonode LSPs.The adjacency for such systems is set to that of the Designated router" What does it exactly mean? When is possible that a router does not have adjacency to a system mentioned in a neighbour's pseudonode LSP? Please clarify. Thanx and regards Navaneeth. From henk@Procket.com Thu, 20 Apr 2000 10:21:25 -0700 (PDT) Date: Thu, 20 Apr 2000 10:21:25 -0700 (PDT) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification.. > In the case of processing of the LSPs in integrated ISIS , used for > IP forwarding, How are the interface addresses (4 octet Values > without mask) in the TLVs used in route tabel calculation. Can any > of you help out on how these i/f addresses are used? They are not used for calculating the topology. The interface IP addresses are only used to determine the IP address of the first next-hop on the path to each destination. When you build a routing table, most implementations have entries there that look like: destination IP prefix, mask, outgoing interface, next-hop IP address For p2p interfaces you don't really need the next-hop IP address, the interface should be enough info. But for LANs it is much more convenient (though in theory the MAC address of the next-hop should be enough). Hope this helps, Henk. From henk@Procket.com Thu, 20 Apr 2000 10:24:50 -0700 (PDT) Date: Thu, 20 Apr 2000 10:24:50 -0700 (PDT) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm Under buggy conditions on a LAN. Should never happen though. Another example might be when you configure your routers to model a Frame-relay, ATM or X25 cloud as a LAN. On those NBMA WAN technologies it is more likely that when some links fail, the resulting topology might be a partial mesh. Note that even if you do the trick that you quote, routing is still broken. IMHO on NBMA networks you need to configure all VCs as p2p links. Hope this helps, Henk. > Hi, > > This doubt is regarding the SPF algorithm mentioned in RFC 1195 > > The section 8 under STEP 0: > > Says: > > " Now add systems to which the local router does not have adjacencies, but > which are mentioned in neighbouring pseudonode LSPs.The adjacency for such > systems is set to that of the Designated router" > > What does it exactly mean? When is possible that a router does not have > adjacency to a system mentioned in a neighbour's pseudonode LSP? > > Please clarify. > > Thanx and regards > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From henk@Procket.com Thu, 20 Apr 2000 10:37:50 -0700 (PDT) Date: Thu, 20 Apr 2000 10:37:50 -0700 (PDT) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification.. > Thanks for the reponse. > I still have one doubt.. Can we use these addresses advetised in LSP TLV's > for next hop addresses.Since these addresses have no specific mapping to > the IP reachability information. > Please correct me if I'm wrong. Ai, sorry, I was to quick in my reply. The IP interface address TLV (TLV #132) I was talking about are the IP interface address TLVs used in *hellos*. Not in LSPs. In LSPs there is the same TLV (TLV #132). But those have no practical use. And you are not supposed to use them in your routing calculations. The easiest thing is to just ignore them during your SPF computation. Sorry about the confusion, Henk. > Thanx > Navaneeth > > -----Original Message----- > From: Henk Smit [SMTP:henk@procket.com] > Sent: Thursday, April 20, 2000 10:51 PM > To: navaneethk@kailash.future.futsoft.com > Cc: 'isis-wg@external.juniper.net' > Subject: Re: [Isis-wg] Clarification.. > > > > In the case of processing of the LSPs in integrated ISIS , used for > > IP forwarding, How are the interface addresses (4 octet Values > > without mask) in the TLVs used in route tabel calculation. Can any > > of you help out on how these i/f addresses are used? > > They are not used for calculating the topology. > The interface IP addresses are only used to determine the IP address > of the first next-hop on the path to each destination. When you > build a routing table, most implementations have entries there that > look like: > destination IP prefix, mask, outgoing interface, next-hop IP address > > For p2p interfaces you don't really need the next-hop IP address, the > interface should be enough info. But for LANs it is much more convenient > (though in theory the MAC address of the next-hop should be enough). > > Hope this helps, > > Henk. > From navaneethk@future.futsoft.com Fri, 21 Apr 2000 14:50:53 +0530 Date: Fri, 21 Apr 2000 14:50:53 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm Hi Henk, Thanks for your reply. I just want to confirm this. LAN nbrs will be loaded to TENT from Adjacency table as well as from the pseudonode LSP. In the second loading, since the Nbr is already present it wont be loaded (normal LAN scenario) Eventhough this is done as a pre-caution, it is unnecessary operation most of the time. Thanks Navaneeth Under buggy conditions on a LAN. Should never happen though. Another example might be when you configure your routers to model a Frame-relay, ATM or X25 cloud as a LAN. On those NBMA WAN technologies it is more likely that when some links fail, the resulting topology might be a partial mesh. Note that even if you do the trick that you quote, routing is still broken. IMHO on NBMA networks you need to configure all VCs as p2p links. Hope this helps, Henk. > Hi, > > This doubt is regarding the SPF algorithm mentioned in RFC 1195 > > The section 8 under STEP 0: > > Says: > > " Now add systems to which the local router does not have adjacencies, but > which are mentioned in neighbouring pseudonode LSPs.The adjacency for such > systems is set to that of the Designated router" > > What does it exactly mean? When is possible that a router does not have > adjacency to a system mentioned in a neighbour's pseudonode LSP? > > Please clarify. > > Thanx and regards > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From henk@Procket.com Fri, 21 Apr 2000 10:45:32 -0700 (PDT) Date: Fri, 21 Apr 2000 10:45:32 -0700 (PDT) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm That is an implementation decision. The one implementation I am familiar with only looks at the content of the LSPs during SPF, and tries to find the relevant adjacencies in the adjacency database later. Henk. > I just want to confirm this. > LAN nbrs will be loaded to TENT from Adjacency table as well > as from the pseudonode LSP. In the second loading, since the Nbr is > already present it wont be loaded (normal LAN scenario) > Eventhough this is done as a pre-caution, it is unnecessary > operation most of the time. > > Thanks > Navaneeth From mshand@cisco.com Tue, 25 Apr 2000 08:18:32 +0100 Date: Tue, 25 Apr 2000 08:18:32 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm At 10:24 20/04/2000 -0700, Henk Smit wrote: > Under buggy conditions on a LAN. Should never happen though. Strictly its not just buggy conditions, but it can happen for some period of time when a new router comes up etc. It might well acquire the adjacency to the DR and hence discover that certain other nodes are reachable via its pseudonode, before it has acquired the adjacencies to the nodes themselves. All this is doing is saying that if the pseudonode claims reachability, but you don't have an adjacency(yet), then you can always get packets to the node in question by forwarding them to the DR (since that MUST have an adjacency to the node, otherwise it wouldn't appear in its pseudonode LSP. This was more of an issue with OSI, where the endsystem adjacencies could take a few minutes to be acquired in some cases (typically you run with quite long ESH timers to keep the traffic down from potentially thousands of Endsystems, and the soliciting mechanisms don't work for all implementations.) So, bottom line is that it doesn't happen very often, and even if it does it doesn't happen for very long, but it does avoid the problem of not having an adjacency, and gets things working a little bit quicker. Mike From emmanuel.dauvergne@rd.francetelecom.fr Wed, 26 Apr 2000 08:54:55 +0200 Date: Wed, 26 Apr 2000 08:54:55 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] ID status ? Hi, Just a refresh regarding 2 IDs : Is the ISIS WG still concerned with OMP works? (The last ID I read was draft-ietf-isis-omp-01, and it disapeared from the IETF server) Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved to the TEWG? Regardless of subTLV specifications, what is the status of the "wider metric" concept which was introduced in that ID? Thanks Manu (by the way, I sent this email last week, but I guess it got lost because my address changed. I fixed it, but sorry if you received it twice) From henk@procket.com Wed, 26 Apr 2000 09:51:47 +0200 (CEST) Date: Wed, 26 Apr 2000 09:51:47 +0200 (CEST) From: Henk Smit henk@procket.com Subject: [Isis-wg] ID status ? > Just a refresh regarding 2 IDs : > > Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved > to the TEWG? I am one of the two authors. There have been no significant changes to the document, so basically we could just re-submit the draft with little work. But because I changed jobs I have little time to work on the draft. > Regardless of subTLV specifications, what is the status of the "wider > metric" concept which was introduced in that ID? What do you mean by "status of the wider metric concept" ? draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links and IP prefixes, and those new TLVs have more bits for metrics. I know of at least two inter-operable implementations that are use in ISP backbones today. Hope this helps, Henk. From emmanuel.dauvergne@rd.francetelecom.fr Wed, 26 Apr 2000 12:05:06 +0200 Date: Wed, 26 Apr 2000 12:05:06 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] ID status ? Thanks for your replies. My comments below... -----Message d'origine----- De: Henk Smit [mailto:henk@procket.com] Date: mercredi 26 avril 2000 09:52 À: emmanuel.dauvergne@rd.francetelecom.fr Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] ID status ? > Just a refresh regarding 2 IDs : > > Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved > to the TEWG? I am one of the two authors. There have been no significant changes to the document, so basically we could just re-submit the draft with little work. But because I changed jobs I have little time to work on the draft. I'm not trying to urge you, it was just a question ;-) > Regardless of subTLV specifications, what is the status of the "wider > metric" concept which was introduced in that ID? What do you mean by "status of the wider metric concept" ? My question was not clear, sorry for that, let me detail (and correct me if I'm wrong)... Actually, I was first concerned with the up/down bit encoding : - in draft-ietf-domain-wide-02, it is suggested to encode it in the classical TLVs (128 and 130) on the high-order bit reserved of the default metric. (And the 4-byte metrics field remain a structured field). rather than, - in draft-ietf-isis-traffic-01, it is suggested to encode it in the extended TLVs, where it is encoded in the control information field. (And the 4-byte metric is a flat field) I was confused about this difference : why not using the same high-order bit in the 4-byte metric? (which would leave 31-bit for the metric value) I was also confused about the extended IS reachibility TLV which default-metric is "only" 3-byte long (and not 4-byte long). Thanks for your time Manu draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links and IP prefixes, and those new TLVs have more bits for metrics. I know of at least two inter-operable implementations that are use in ISP backbones today. Hope this helps, Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From henk@procket.com Wed, 26 Apr 2000 13:24:00 +0200 (CEST) Date: Wed, 26 Apr 2000 13:24:00 +0200 (CEST) From: Henk Smit henk@procket.com Subject: [Isis-wg] ID status ? > Actually, I was first concerned with the up/down bit encoding : - in > draft-ietf-domain-wide-02, it is suggested to encode it in the > classical TLVs (128 and 130) on the high-order bit reserved of the > default metric. (And the 4-byte metrics field remain a structured > field). The reason for this is that some customers wanted to have L2->L1 route-leaking in the older TLVs, and preferably in a way where you only need to upgrade the L1L2 routers. With this hack of using the reserved bit in existing TLVs 128 and 130, older implementations will just ignore the up/down bit. > rather than, - in draft-ietf-isis-traffic-01, it is suggested to > encode it in the extended TLVs, where it is encoded in the control > information field. (And the 4-byte metric is a flat field) This is a cleaner way. The up/down bit has nothing to do with the metrics. So why make it part of it. We have two unused bits in the prefix-lenght field, so we could save a byte for each IP prefix by using one of these two unused bits as the up/down bit. For the other bit we found another use: indicator whether there are sub-TLVs present. > I was confused about this difference : why not using the same > high-order bit in the 4-byte metric? (which would leave 31-bit for > the metric value) Because metric and up/down bit have nothing to do with each other. And why make the metric wider, and then start nibbling bits off of it again. Yes, we could have done it that way, but we didn't. Also note that draft-ietf-isis-traffic-01.txt is older than draft-ietf-domain-wide-02.txt. And draft-ietf-isis-traffic-01.txt is in use in the Internet today, while I don't know of any ISPs (or enterprise networks) that use draft-ietf-domain-wide-02.txt today. > I was also confused about the extended IS reachibility TLV which > default-metric is "only" 3-byte long (and not 4-byte long). That was my idea. One of the problems with the TLVs in 10589 and rfc1195 is that the metrics between areas (or rather between L1 and L2) are not very useful. Link metrics are 1-63, which creates some limitations for people designing networks. But the overall result is a little less bad, as the path inside an area or inside the L2 backbone can be up to 1023. However, if your L1 path has a cost over 63, that cost can not be advertised, it has to be rounded down to 63. The problem is the fact that the added cost of the links can be way bigger than what you can advertise in a TLV 128 or 130. We wanted to prevent that from happening. So the link cost can be 2^24 at most, while the advertised total path cost can be 2^32. That way you can have 256 links with the worst cost in your network, and still maintain the path cost when advertising between L1 and L2. And the risk of overflowing a ulong of 4 bytes in your implementation is reduced as well. Hope this helps, henk. > Thanks for your time > Manu > > > > draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links > and IP prefixes, and those new TLVs have more bits for metrics. I know > of at least two inter-operable implementations that are use in ISP > backbones today. > > Hope this helps, > > 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 emmanuel.dauvergne@rd.francetelecom.fr Wed, 26 Apr 2000 18:51:44 +0200 Date: Wed, 26 Apr 2000 18:51:44 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] ID status ? Ok, thanks a lot for this explanation. Fine for me! Manu -----Message d'origine----- De: Henk Smit [mailto:henk@procket.com] Date: mercredi 26 avril 2000 13:24 À: emmanuel.dauvergne@rd.francetelecom.fr Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] ID status ? > Actually, I was first concerned with the up/down bit encoding : - in > draft-ietf-domain-wide-02, it is suggested to encode it in the > classical TLVs (128 and 130) on the high-order bit reserved of the > default metric. (And the 4-byte metrics field remain a structured > field). The reason for this is that some customers wanted to have L2->L1 route-leaking in the older TLVs, and preferably in a way where you only need to upgrade the L1L2 routers. With this hack of using the reserved bit in existing TLVs 128 and 130, older implementations will just ignore the up/down bit. > rather than, - in draft-ietf-isis-traffic-01, it is suggested to > encode it in the extended TLVs, where it is encoded in the control > information field. (And the 4-byte metric is a flat field) This is a cleaner way. The up/down bit has nothing to do with the metrics. So why make it part of it. We have two unused bits in the prefix-lenght field, so we could save a byte for each IP prefix by using one of these two unused bits as the up/down bit. For the other bit we found another use: indicator whether there are sub-TLVs present. > I was confused about this difference : why not using the same > high-order bit in the 4-byte metric? (which would leave 31-bit for > the metric value) Because metric and up/down bit have nothing to do with each other. And why make the metric wider, and then start nibbling bits off of it again. Yes, we could have done it that way, but we didn't. Also note that draft-ietf-isis-traffic-01.txt is older than draft-ietf-domain-wide-02.txt. And draft-ietf-isis-traffic-01.txt is in use in the Internet today, while I don't know of any ISPs (or enterprise networks) that use draft-ietf-domain-wide-02.txt today. > I was also confused about the extended IS reachibility TLV which > default-metric is "only" 3-byte long (and not 4-byte long). That was my idea. One of the problems with the TLVs in 10589 and rfc1195 is that the metrics between areas (or rather between L1 and L2) are not very useful. Link metrics are 1-63, which creates some limitations for people designing networks. But the overall result is a little less bad, as the path inside an area or inside the L2 backbone can be up to 1023. However, if your L1 path has a cost over 63, that cost can not be advertised, it has to be rounded down to 63. The problem is the fact that the added cost of the links can be way bigger than what you can advertise in a TLV 128 or 130. We wanted to prevent that from happening. So the link cost can be 2^24 at most, while the advertised total path cost can be 2^32. That way you can have 256 links with the worst cost in your network, and still maintain the path cost when advertising between L1 and L2. And the risk of overflowing a ulong of 4 bytes in your implementation is reduced as well. Hope this helps, henk. > Thanks for your time > Manu > > > > draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links > and IP prefixes, and those new TLVs have more bits for metrics. I know > of at least two inter-operable implementations that are use in ISP > backbones today. > > Hope this helps, > > 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 vanik@future.futsoft.com Wed, 3 May 2000 10:53:51 +0530 Date: Wed, 3 May 2000 10:53:51 +0530 From: Vani Sree K vanik@future.futsoft.com Subject: [Isis-wg] Incremental SPF Hi, Is there any document or guide that explains about incremental SPF. Can anyone provide the pointer to it, if any. Thanks Regards -vani From shenjun@ns.chinanet.cn.net Tue, 9 May 2000 10:12:17 +0800 Date: Tue, 9 May 2000 10:12:17 +0800 From: shenjun shenjun@ns.chinanet.cn.net Subject: [Isis-wg] undescribe undescribe From shenjun@ns.chinanet.cn.net Tue, 9 May 2000 10:23:06 +0800 Date: Tue, 9 May 2000 10:23:06 +0800 From: shenjun shenjun@ns.chinanet.cn.net Subject: [Isis-wg] (no subject) undescribe From shenjun@ns.chinanet.cn.net Tue, 9 May 2000 10:29:38 +0800 Date: Tue, 9 May 2000 10:29:38 +0800 From: shenjun shenjun@ns.chinanet.cn.net Subject: [Isis-wg] (no subject) unsubscribe> From dwm@caida.org Sun, 14 May 2000 04:06:39 -0400 Date: Sun, 14 May 2000 04:06:39 -0400 From: Daniel McRobb dwm@caida.org Subject: [Isis-wg] draft-ietf-isis-wg-mib-02 I'm new to the list, so please forgive me if this issue has come up before (I dind't find it in a cursory search of the archives)... Is there any interest in making isisISAdjUpTime semantics similar to bgpPeerFsmEstablishedTime from BGP4-MIB, making it the number of seconds the adjacency has been 'up' if the current state is 'up', and seconds passed since the adjacency was last 'up' if the current state is not 'up'? I personally prefer these semantics (even if we define notifications for adjacency changes). Daniel ~~~~~~ From navaneethk@future.futsoft.com Thu, 18 May 2000 17:12:18 +0530 Date: Thu, 18 May 2000 17:12:18 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on Dual ISIS Hi, The doubt is regarding a Dual environment where integrated ISIS is deployed. In this scenario, i. Is it possible for a system reachable through a circuit to have both IP and OSI addresses simultaneously? ii. In Dual routers, normally are both the IP and OSI addresses valid at the same time? According to RFC 1195, A dual router must be capable of routing both IP and OSI packets. Are there Any address considerations in this regard? Thanx Navaneeth. From henk@Procket.com Thu, 18 May 2000 14:14:41 +0200 (MEST) Date: Thu, 18 May 2000 14:14:41 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification on Dual ISIS > Hi, > The doubt is regarding a Dual environment where integrated ISIS is > deployed. > In this scenario, > i. Is it possible for a system reachable through a circuit to have both > IP and OSI addresses simultaneously? Yes. Note, IP addresses are interface specific. E.g. each interface typically has one IP address. OSI addresses (NSAPs) are box specific. E.g. typically each router or each hosts has a single OSI address. > ii. In Dual routers, normally are both the IP and OSI addresses valid at > the same time? That is the definition of a Dual router. An ISIS-CLNS router has and OSI address (an NSAP), forwards CLNS packets, and does not forward IP packets. An ISIS-IP router has an IP addresses, forwards IP packets, and does not forward CLNS packets. Typically an ISIS-IP router still has an NSAP configured, because it needs a systemID and an area-address. A Dual router has all of that combined. IP addresses, an NSAP, and it does forward IP and CLNS packets. > According to RFC 1195, A dual router must be capable of routing both IP > and OSI packets. Are there Any address considerations in this regard? Not that I can think of. IP and OSI address space are independant. But don't forget that typically the NSAP is used to derive the systemID and the area-address. Hope this helps, Henk. From jparker@nexabit.com Thu, 18 May 2000 09:49:14 -0400 Date: Thu, 18 May 2000 09:49:14 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Clarification on Dual ISIS > Note, IP addresses are interface specific. E.g. each > interface typically has one IP address. OSI addresses and the new TLV for Router ID that provides a unique IP address for a box. - jeff parker - Nexabit From ben.abarbanel@ipoptical.com Thu, 18 May 2000 09:35:50 -0700 Date: Thu, 18 May 2000 09:35:50 -0700 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] Clarification on Dual ISIS Does anybody know where I can purchase a reliable implementation of ISIS with dual mode. Thanks, Ben ----- Original Message ----- From: Henk Smit To: Cc: Sent: Thursday, May 18, 2000 5:14 AM Subject: Re: [Isis-wg] Clarification on Dual ISIS > > > Hi, > > The doubt is regarding a Dual environment where integrated ISIS is > > deployed. > > In this scenario, > > i. Is it possible for a system reachable through a circuit to have both > > IP and OSI addresses simultaneously? > > Yes. > Note, IP addresses are interface specific. E.g. each interface typically > has one IP address. OSI addresses (NSAPs) are box specific. E.g. typically > each router or each hosts has a single OSI address. > > > ii. In Dual routers, normally are both the IP and OSI addresses valid at > > the same time? > > That is the definition of a Dual router. > An ISIS-CLNS router has and OSI address (an NSAP), forwards CLNS packets, > and does not forward IP packets. > An ISIS-IP router has an IP addresses, forwards IP packets, and does not > forward CLNS packets. Typically an ISIS-IP router still has an NSAP > configured, because it needs a systemID and an area-address. > > A Dual router has all of that combined. IP addresses, an NSAP, and it > does forward IP and CLNS packets. > > > According to RFC 1195, A dual router must be capable of routing both IP > > and OSI packets. Are there Any address considerations in this regard? > > Not that I can think of. IP and OSI address space are independant. > But don't forget that typically the NSAP is used to derive the systemID > and the area-address. > > Hope this helps, > > Henk. > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From jparker@nexabit.com Thu, 18 May 2000 11:56:53 -0400 Date: Thu, 18 May 2000 11:56:53 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Clarification on Dual ISIS > -----Original Message----- > From: ben abarbanel [mailto:ben.abarbanel@ipoptical.com] > Sent: Thursday, May 18, 2000 12:36 PM > To: Henk Smit; navaneethk@future.futsoft.com > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] Clarification on Dual ISIS > > > Does anybody know where I can purchase a reliable > implementation of ISIS > with dual mode. > > Thanks, > Ben Ben - Are you looking to route both OSI and IP, or are you asking for dual mode because you want to route IP? - jeff parker - Nexabit Networks - Lucent Technologies From emmanuel.dauvergne@rd.francetelecom.fr Thu, 18 May 2000 19:09:02 +0200 Date: Thu, 18 May 2000 19:09:02 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] Behavior upon new adjacency Hello, A few questions regarding the Update Process and the Decision Process upon new adjacency event. 1. Update Process : Upon an LSP generation (either a periodic regeneration or an event driven generation), ISO10589 indicates that the LSP(s) shall be sent on every circuit with an IS adjacency of the appropriate level, by setting the SRMFlag on each circuits. In the case of an new adjacency (event driven generation), is there any restriction regarding the circuit corresponding to this new adjacency which has triggered the generation of the LSP? According to the spec, the LSP shall be sent on that circuit as well, but is it recommended to wait for a certain time before sending routing information through that new adjacency? In that same case what chronological order should be respected between the sending of LSP and CSNP (p2p link)? 2. Decision Process : ISO10589 indicates that any topological change (notified by the update process) can trigger an SPF calculation. Is a new adjacency considered as a topological change? Shouldn't the local router wait for the LSP of the new adjacent router before triggering the SPF calculation? Thanks for your time Manu From prz@net4u.ch Thu, 18 May 2000 19:31:14 +0200 (MEST) Date: Thu, 18 May 2000 19:31:14 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] last calls ... After simmering for a while and enough experience following drafts are going last call: 1. draft-ietf-isis-wg-255adj-02.txt 2. draft-ietf-isis-domain-wide-02.txt 3. draft-ietf-isis-wg-mesh-group-00.txt 4. draft-kaplan-isis-ext-eth-01.txt Authors of 4. pls comment whether you want to pursuit informational, experimental or standards track. 1-3 are informational. Last call ends June 3rd thanks -- tony From ben.abarbanel@ipoptical.com Thu, 18 May 2000 13:15:55 -0700 Date: Thu, 18 May 2000 13:15:55 -0700 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] Clarification on Dual ISIS Looking for dual mode to route IP. Regards, Ben ----- Original Message ----- From: Jeff Parker To: ben abarbanel Cc: Sent: Thursday, May 18, 2000 8:56 AM Subject: RE: [Isis-wg] Clarification on Dual ISIS > > -----Original Message----- > > From: ben abarbanel [mailto:ben.abarbanel@ipoptical.com] > > Sent: Thursday, May 18, 2000 12:36 PM > > To: Henk Smit; navaneethk@future.futsoft.com > > Cc: isis-wg@juniper.net > > Subject: Re: [Isis-wg] Clarification on Dual ISIS > > > > > > Does anybody know where I can purchase a reliable > > implementation of ISIS > > with dual mode. > > > > Thanks, > > Ben > > Ben - > Are you looking to route both OSI and IP, > or are you asking for dual mode because you > want to route IP? > > - jeff parker > - Nexabit Networks > - Lucent Technologies > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From jparker@nexabit.com Thu, 18 May 2000 14:24:10 -0400 Date: Thu, 18 May 2000 14:24:10 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Clarification on Dual ISIS > > > Does anybody know where I can purchase a reliable > > > implementation of ISIS > > > with dual mode. > > > > > > Thanks, > > > Ben Ben - If you intend to route IP, then the usual suspects (ourselves included) ship a version of ISIS. I'm not sure that this is the venue to discuss reliability of implementations rather than protocols. I'm not sure how much recent work there has been on routing both OSI and IP using IS-IS. - jeff parker - Nexabit Networks - Lucent Technologies From prz@siara.com Mon, 17 Jan 2000 16:14:54 -0500 Date: Mon, 17 Jan 2000 16:14:54 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Problem for Support Frame Relay . Alex Zinin wrote: > Monday, January 17, 2000, 7:43:07 PM, Tony Przygienda wrote: > > again, first a problem statement would be nice to make sure > > we're all tackling the same problem. > > Well, I think Jorge's initial messages are quite > clear on that---running IS-IS over NBMA media. > ...and whichever issues related :) again, it may be the partial mesh problem (the protocol needs to understand the topology correctly) or the "running over dial-up links" problem. > > 2nd, Alex, you're oversimpliofying here ;-) > > Tony, I'm not. I'm just correcting the statement > that on-demand VCs cannot be used with IS-IS. this part you don't, right. But after that you're saying it's easy and doesn't need anything, that's at least slightly oversimplifying. You can run it that way but you'll stop pretty soon after the montly bills come. If you don't beleive me, try an ISDN link with OSPF active ;-) > > Just "running" > > the protocol that way leads to extensive thrashing of up&downs > > of the circuit > > Quoting myself: > > "...provided that the idle timer doesn't close > the VC before the next Hello PDU is sent over it." then de-facto you _never_ close the circuit wyhen the protocol is running and if you're paying usage, that's expensive stuff, either charged per data unit or per time unit (2nd is worse normally). If that's the soluiton people are happy with (but weren't in OSPF) then de facto, no work needs tio be done in layer 3 and Alex's right. From tli@Procket.com Thu, 18 May 2000 11:25:20 -0700 Date: Thu, 18 May 2000 11:25:20 -0700 From: Tony Li tli@Procket.com Subject: [Isis-wg] Clarification on Dual ISIS | Looking for dual mode to route IP. There is at least one implementation in the world that routes IP but not CLNP. This can't strictly be called dual mode. Tony From Internet-Drafts@ietf.org Wed, 12 Apr 2000 07:11:20 -0400 Date: Wed, 12 Apr 2000 07:11:20 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-01.txt Pages : 11 Date : 11-Apr-00 This document specifies an algorithm-independent cryptographic authentication mechanism for use with the IS-IS routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-hmac-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-hmac-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000411095848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000411095848.I-D@ietf.org> --OtherAccess-- --NextPart-- From prz@redback.com Wed, 17 May 2000 15:16:16 -0700 (PDT) Date: Wed, 17 May 2000 15:16:16 -0700 (PDT) From: prz@redback.com prz@redback.com Subject: [Isis-wg] (no subject) going last call for informational: 1. draft-ietf-isis-wg-255adj-02.txt 2. draft-ietf-isis-domain-wide-02.txt 3. draft-ietf-isis-wg-mesh-group-00.txt Last calls end June 2nd thanks -- tony From root@prz-laptop.redback.com Wed, 17 May 2000 16:12:48 -0700 (PDT) Date: Wed, 17 May 2000 16:12:48 -0700 (PDT) From: Charlie Root root@prz-laptop.redback.com Subject: [Isis-wg] Last call started for 3 drafts going last call for informational: 1. draft-ietf-isis-wg-255adj-02.txt 2. draft-ietf-isis-domain-wide-02.txt 3. draft-ietf-isis-wg-mesh-group-00.txt Last calls end June 2nd thanks -- tony From ethkkg@etxb.ericsson.se Thu, 18 May 2000 10:20:20 +0200 Date: Thu, 18 May 2000 10:20:20 +0200 From: Gabor Korossy (ETH) ethkkg@etxb.ericsson.se Subject: [Isis-wg] RE: MPLS and IS-IS Hi, if I may repeat, could anyone help me please, find the draft "IS-IS extensions for Traffic Engineering," draft-ietf-isis-traffic-01.txt If so many ISPs run IS-IS with MPLS TE extensions shouldn't it become an IETF standard? Maybe one of the MPLS, TE and IS-IS working groups doesn´t feel ashamed to adopt this child? regards - Gabor >> -----Original Message----- >> From: Chris.Flores@broadwing.com [mailto:Chris.Flores@broadwing.com] >> Sent: Wednesday, May 17, 2000 8:48 PM >> To: mpls@UU.NET >> Subject: FW: MPLS and IS-IS >> >> >> >> David - >> >> Most large ISPs in the US use ISIS: >> >> UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. >> >> It also seems like more and more european ISPs are starting >> to use ISIS: >> EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. >> >> Chris >> >> -----Original Message----- >> From: David Wang [mailto:david.wang@metro-optix.com] >> Sent: Wednesday, May 17, 2000 12:36 PM >> To: 'HANSEN CHAN'; mpls@UU.NET >> Subject: RE: MPLS and IS-IS >> >> >> Hi all, >> >> IS-IS is defined to work with CLNP not for IP originally. >> Until today a lot >> of SONET and telecommunication equipment vendors still use >> IS-IS to route >> CLNP packets through the SONET Data communication >> channel(DCC) to carry >> management information and there is a great pressure to >> change this to OSPF >> and IP. I also know that UUNET runs IS-IS on their network. >> I never heard >> any other networks run IS-IS. Seems I am wrong. My questions are. >> >> 1. You guys are talking about using IS-IS in a IP networks >> not in CLNP >> networks. The IS-IS has been modified according to RFC 1195 >> (Use of OSI >> IS-IS for Routing in TCP/IP and Dual Environments) or some >> other standard. >> Is this correct? >> >> 2. Besides UUNET, which ISPs run IS-IS protocol? Can you >> name a few? or >> what percentage of networks run IS-IS instead of OSPF? >> >> Thanks >> David >> >> >> -----Original Message----- >> From: HANSEN CHAN [mailto:hchan@newbridge.com] >> Sent: Tuesday, May 16, 2000 7:22 AM >> To: mpls@UU.NET >> Subject: MPLS and IS-IS >> >> >> Hi all, >> >> I have been hearing IS-IS is a better protocol to be used >> than OSPF in a >> MPLS >> network for TE application. Is that a fair statement? What >> are the technical >> reasons? >> >> Appreciate if someone can shed some light on this subject. >> >> Thanks, >> Hansen >> >> From emmanuel.dauvergne@rd.francetelecom.fr Fri, 21 Apr 2000 11:45:42 +0200 Date: Fri, 21 Apr 2000 11:45:42 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] ID status ? Hi, Just a refresh regarding 2 IDs : Is the ISIS WG still concerned with OMP works? (The last ID I read was draft-ietf-isis-omp-01) Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved to the TEWG? Regardless of subTLV specifications, what is the status of the "wider metric" concept which was introduced in that ID? Thanks Manu From navaneethk@future.futsoft.com Wed, 3 May 2000 15:08:35 +0530 Date: Wed, 3 May 2000 15:08:35 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on ISIS MIB Hi... My doubt is with regard to the ISIS MIB.. In the IpRA table, There is a field for the IpRASNPA address.. This is mentioned as to be used as the NextHop for reaching the Reachable address.. But in case of IP , How can the NExtHop address be got.. Since the SNPA address is equivalent to the MAC address, what address can be considered as the nexthop address? Please Clarify. Thanx Navaneeth. From prz@siara.com Wed, 26 Apr 2000 01:22:10 -0700 Date: Wed, 26 Apr 2000 01:22:10 -0700 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] ID status ? DAUVERGNE Emmanuel FTRD/DAC/ISS wrote: > Hi, > > Just a refresh regarding 2 IDs : > > Is the ISIS WG still concerned with OMP works? (The last ID I read was > draft-ietf-isis-omp-01, and it disapeared from the IETF server) expired a while ago. > Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved > to the TEWG? > Regardless of subTLV specifications, what is the status of the "wider > metric" concept which was introduced in that ID? Henk promised a new version in 2--3 weeks (and it was 2--3 weeks ago ;-) thanks -- tony > > > Thanks > Manu > From Internet-Drafts@ietf.org Thu, 11 May 2000 06:57:18 -0400 Date: Thu, 11 May 2000 06:57:18 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-kaplan-isis-ext-eth-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Extended Ethernet Frame Size Support Author(s) : M. O'Dell, J. Kaplan, J. Hayes, T. Schroeder, P. Singh, D. Morrell, J. Hsu Filename : draft-kaplan-isis-ext-eth-01.txt Pages : 4 Date : 10-May-00 This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kaplan-isis-ext-eth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaplan-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> --OtherAccess-- --NextPart-- From jkaplan@UU.NET Wed, 10 May 2000 09:13:35 -0400 (EDT) Date: Wed, 10 May 2000 09:13:35 -0400 (EDT) From: Jed Kaplan jkaplan@UU.NET Subject: [Isis-wg] Extended Ethernet Frame Size Support This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-684387517-957964415=:12311 Content-Type: TEXT/PLAIN; charset=US-ASCII A revised ISIS draft (draft-kaplan-isis-ext-eth-01.txt) by O'Dell, Kaplan, Hayes, Schroeder, Singh, and Hsu entitled: "Extended Ethernet Frame Size Support" has been submitted to the IETF. The is a resubmission of the draft, draft-kaplan-isis-ext-eth-00.txt, that expired in November, 1999. The sole change to the draft was an update of authorship. The draft abstract is: This document presents an extension to the current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. Jed kaplan jkaplan@uu.net ---559023410-684387517-957964415=:12311 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-kaplan-isis-ext-eth-01.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-kaplan-isis-ext-eth-01.txt" TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBNaWtlIE8nRGVsbA0KSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKZWQgS2FwbGFu DQpFeHBpcmF0aW9uIERhdGU6IE5vdmVtYmVyIDE5OTkJCQkJVVVORVQgVGVj aG5vbG9naWVzLCBJbmMuDQoNCgkJCQkJCQlKb2huIEhheWVzDQoJCQkJCQkJ VGVkIFNjaHJvZWRlcg0KCQkJCQkJCUFsdGVvbiBXZWJTeXN0ZW1zLCBJbmMu DQoJCQkJCQkJDQoJCQkJCQkJUC5KLiBTaW5naA0KCQkJCQkJCVBhY2tldCBF bmdpbmVzLCBJbmMuDQoNCgkJCQkJCQlEYWVtb24gTW9ycmVsbA0KCQkJCQkJ CUp1bmlwZXIgTmV0d29ya3MsIEluYy4NCg0KCQkJCQkJCUplbm5pZmVyIEhz dQ0KCQkJCQkJDQoNCg0KCSAgICAgICAgICBFeHRlbmRlZCBFdGhlcm5ldCBG cmFtZSBTaXplIFN1cHBvcnQgDQoNCgkJICAgIGRyYWZ0LWthcGxhbi1pc2lz LWV4dC1ldGgtMDAudHh0DQoNCg0KMS4gU3RhdHVzIG9mIHRoaXMgTWVtbw0K DQoJVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMg aW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIA0KCWFsbCBwcm92aXNpb25zIG9m IFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KCUludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nDQoJVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3 b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0DQoJb3RoZXIgZ3JvdXBzIG1heSBh bHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt DQoJRHJhZnRzLg0KDQoJSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIA0KCWFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv dGhlciBkb2N1bWVudHMgYXQgYW55DQoJdGltZS4gSXQgaXMgaW5hcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KCW1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGlu IHByb2dyZXNzLiINCg0KCVRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt RHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCglodHRwOi8vd3d3LmlldGYu b3JnL2lldGYvbGlkLWFic3RyYWN0cy50eHQNCg0KCVRoZSBsaXN0IG9mIElu dGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNz ZWQgYXQNCglodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQoNCg0K Mi4gQWJzdHJhY3QNCg0KCVRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYW4gZXh0 ZW5zaW9uIHRvIGN1cnJlbnQgRXRoZXJuZXQgRnJhbWUgDQoJc3RhbmRhcmRz IHRvIHN1cHBvcnQgcGF5bG9hZHMgZ3JlYXRlciB0aGFuIDE1MDAgQnl0ZXMg Zm9yIEV0aGVybmV0X0lJDQoJYW5kIDgwMi4zIGZyYW1lcy4gVGhpcyBpcyB1 c2VmdWwgZm9yIEdpZ2FiaXQgRXRoZXJuZXQgdGVjaG5vbG9neSwgDQogICAg ICAgIHByb3ZpZGluZyBhIG1lYW5zIHRvIGNhcnJ5IGxhcmdlIE1UVSBwYWNr ZXRzIHdpdGhvdXQgZnJhZ21lbnRhdGlvbiANCiAgICAgICAgb3ZlciBhIGhp Z2gtc3BlZWQgYnJvYWRjYXN0IG5ldHdvcmsuDQoNCjMuIE92ZXJ2aWV3DQoN CglUaGVyZSBhcmUgdHdvIGZ1bmRhbWVudGFsIGZyYW1lIHR5cGVzIGRlZmlu ZWQgZm9yIEV0aGVybmV0Og0KCUV0aGVybmV0IElJIFtFVEhdIFtSRkM4OTRd IGFuZCA4MDIuMyBbSUVFRTgwMi4zXS4gODAyLjMgaGVhZGVycw0KCW1heSBi ZSBmb2xsb3dlZCBieSBhIExvZ2ljYWwgTGluayBDb250cm9sIGhlYWRlciwN Cgk4MDIuMiBbSUVFRTgwMi4yXS4gQm90aCB0eXBlcyBvZiBlbmNhcHN1bGF0 aW9ucyBjYW4gY28tZXhpc3Qgb24NCgl0aGUgc2FtZSBtZWRpYSBhdCB0aGUg c2FtZSB0aW1lLiBFbmNvZGluZ3MgZm9yIEV0aGVybmV0IElJIGFuZCA4MDIu Mw0KCWZyYW1lcyBldm9sdmVkIHN1Y2ggdGhhdCwgYXMgbG9uZyBhcyBwYXls b2FkcyB3ZXJlIGxlc3MgdGhhbiAxNTAwDQoJYnl0ZXMsIEV0aGVybmV0IElJ IGZyYW1lcyBjb3VsZCBhbHdheXMgYmUgZGlzdGluZ3Vpc2hlZCBmcm9tDQoJ SUVFRSA4MDIuMyBmcmFtZXMuDQoNCglIb3dldmVyLCB3aGVuIHRoZSBwYXls b2FkIGlzIGdyZWF0ZXIgdGhhbiAxNTAwIGJ5dGVzIGZyYW1lcyBtYXkgDQog ICAgICAgIG5vdCBiZSB1bmlxdWVseSBkaXN0aW5ndWlzaGFibGUgYXMgY29u Zm9ybWluZyB0byBFdGhlcm5ldCBJSSBvciANCiAgICAgICAgODAyLjMgZm9y bWF0cy4gVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBFdGhlcm5ldCBmcmFt ZSBmb3JtYXQgDQoJdG8gYWxsb3cgRXRoZXJuZXRfSUkgb3IgODAyLjMgZnJh bWUgcGF5bG9hZHMgbGFyZ2VyIHRoYW4gMTUwMCBieXRlcyANCiAgICAgICAg dG8gYmUgdW5pcXVlbHkgZGlzdGluZ3Vpc2hlZC4NCg0KNC4gRXRoZXJuZXQg RnJhbWUgRm9ybWF0cw0KDQoJQS4gRXRoZXJuZXQgSUkNCgkJDQoJCSstLS0t Ky0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLSsNCgkJfCBEQSB8IFNBIHwgVHlw ZSB8IERhdGEgfCBGQ1MgfA0KCQkrLS0tLSstLS0tKy0tLS0tLSstLS0tLS0r LS0tLS0rDQoJICANCgkJREEgICAgICBEZXN0aW5hdGlvbiBNQUMgQWRkcmVz cyAoNiBieXRlcykNCgkJU0EgICAgICBTb3VyY2UgTUFDIEFkZHJlc3MgICAg ICAoNiBieXRlcykNCgkJVHlwZSAgICBQcm90b2NvbCBUeXBlICAgICAgICAg ICAoMiBieXRlcykNCgkJRGF0YSAgICBQcm90b2NvbCBEYXRhICAgICAgICAg ICAoNDYgLSAxNTAwIGJ5dGVzKQ0KCQlGQ1MgICAgIEZyYW1lIENoZWNrc3Vt ICAgICAgICAgICg0IGJ5dGVzKQ0KDQoJQi4gSUVFRSA4MDIuMyBhbmQgZGVy aXZhdGl2ZXMNCg0KCQkrLS0tLSstLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0r DQoJCXwgREEgfCBTQSB8IExlbiAgfCBEYXRhIHwgRkNTIHwNCgkJKy0tLS0r LS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tKw0KDQoJCURBICAgICAgRGVzdGlu YXRpb24gTUFDIEFkZHJlc3MgKDYgYnl0ZXMpDQoJCVNBICAgICAgU291cmNl IE1BQyBBZGRyZXNzICAgICAgKDYgYnl0ZXMpDQoJCUxlbiAgICAgTGVuZ3Ro IG9mIERhdGEgZmllbGQgICAgKDIgYnl0ZXMpDQoJCURhdGEgICAgUHJvdG9j b2wgRGF0YSAgICAgICAgICAgKDQ2IC0gMTUwMCBieXRlcykNCgkJRkNTICAg ICBGcmFtZSBDaGVja3N1bSAgICAgICAgICAoNCBieXRlcykNCgkgIA0KCVRo ZSBkZXJpdmF0aXZlcyBpbmNsdWRlIExMQyAoODAyLjIpIGFuZCBTTkFQIHdo aWNoIHByZWZpeCB0aGUNCglkYXRhIGZpZWxkIHdpdGggYW4gTExDIGhlYWRl ci4gIEluIHRoZXNlIGluc3RhbmNlcyB0aGUgTGVuIGZpZWxkDQoJdGhlbiBj b3JyZXNwb25kcyB0byB0aGUgY29tYmluZWQgc2l6ZSBvZiBib3RoIHRoZSBk YXRhIHBvcnRpb24NCglvZiB0aGUgZnJhbWUgYW5kIHRoZSBMTEMgaGVhZGVy Lg0KCQ0KCU9uIHJlY2VwdGlvbiwgdGhlIHR3byBmb3JtYXRzIGFyZSBkaWZm ZXJlbnRpYXRlZCBiYXNlZCBvbiB0aGUNCgltYWduaXR1ZGUgb2YgdGhlIFR5 cGUvTGVuZ3RoIGZpZWxkLCBhcyBmb2xsb3dzOg0KDQoJPiAxNTAwIGJ5dGVz OiAgIHZhbHVlIGNvcnJlc3BvbmRzIHRvIGEgdHlwZSBmaWVsZC4gIFRoZSBm cmFtZSBpcyBhbg0KCQkJRXRoZXJuZXQgSUkgZnJhbWUsIHdpdGggdHlwZSB2 YWx1ZXMgc3RhcnRpbmcNCgkJCWF0IDE1MzYgKDYwMCBoZXgpLg0KDQoJPD0g MTUwMCBieXRlczogIHZhbHVlIGNvcnJlc3BvbmRzIHRvIGEgbGVuZ3RoIGZp ZWxkLiAgVGhlIGZyYW1lIGlzDQoJCQlhbiBJRUVFIDgwMi4zIGZvcm1hdCAo b3IgZGVyaXZhdGl2ZSkgd2l0aCBhIG1heGltdW0NCgkJCWRhdGEgbGVuZ3Ro IG9mIDE1MDAgYnl0ZXMuDQoNCjUuIFByb2JsZW0gd2l0aCBMYXJnZSA4MDIu MyBGcmFtZXMgaW4gdGhlIHByZXNlbmNlIG9mIEV0aGVybmV0X0lJIEZyYW1l cw0KDQoJU29tZSBwcm90b2NvbHMgY29tbW9ubHkgdXNlZCBpbiB0aGUgSW50 ZXJuZXQsIHN1Y2ggYXMgRVNJUw0KCWFuZCBJU0lTIHdoaWNoIGFyZSBjYXJy aWVkIGFzIENMTlMgcGFja2V0cywgaGF2ZSBubyByZXNlcnZlZA0KICAgICAg ICBFdGhlcnR5cGUuICBTdWNoIHBhY2tldHMgY2FuIG9ubHkgdXNlIHRoZSBJ RUVFIDgwMi4zLzgwMi4yIGVuY29kaW5nLCANCiAgICAgICAgYW5kIHNvIGFy ZSBsaW1pdGVkIGluIGxlbmd0aCB0byAxNTAwIGJ5dGVzLg0KDQogCUV0aGVy bmV0X0lJIGZyYW1lcyBoYXZlIG5vIGxlbmd0aCBmaWVsZC4gUHJvdG9jb2xz IGVuY2Fwc3VsYXRlZCBpbiANCglFdGhlcm5ldCBJSSBmcmFtZXMsIHN1Y2gg YXMgSVAsIGFyZSBub3QgbGltaXRlZCBpbiBsZW5ndGggdG8gMTUwMCANCiAg ICAgICAgYnl0ZXMgYnkgZnJhbWluZy4NCg0KNi4gUHJvcG9zZWQgRXRoZXJu ZXQgRnJhbWUgRXh0ZW5zaW9uDQoNCglMYXJnZSA4MDIuMyBhbmQgRXRoZXJu ZXRfSUkgZnJhbWVzIGNhbiBiZSBzdXBwb3J0ZWQgYnkgdGhlIGZvbGxvd2lu ZzoNCgkNCgkrICBEZWZpbmUgYW4gRXRoZXJ0eXBlIGZvciA4MDIuMywgMHg4 ODcwLCBhbmQgZW5jb2RlIGxhcmdlIGZyYW1lcw0KCSAgICh3aGVyZSB0aGUg ZGF0YSBmaWVsZCBpcyBncmVhdGVyIHRoYW4gMTUwMCBieXRlcyksDQoJICAg ZXhjbHVzaXZlIG9mIHRoZSBEZXN0aW5hdGlvbiBNQUMgYWRkcmVzcywgU291 cmNlIE1BQyBhZGRyZXNzLA0KICAgICAgICAgICBhbmQgRGF0YSBsZW5ndGgg ZmllbGRzLCB3aXRoaW4gRXRoZXJuZXQgSUkuDQoNCgkgICBMYXJnZSA4MDIu My84MDIuMiBmcmFtZXMgd291bGQgaGF2ZSB0aGUgZm9sbG93aW5nIGZpZWxk czoNCiANCgkJKy0tLS0rLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0t LS0rLS0tLS0tKy0tLS0tKw0KCQl8IERBIHwgU0EgfCBUeXBlIHwgRFNBUCB8 IFNTQVAgfCBDdHJsIHwgRGF0YSB8IEZDUyB8DQoJCSstLS0tKy0tLS0rLS0t LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLSsNCgkJCQkg ID09PSA4MDIuMiBIZWFkZXIgPT09DQoNCgkJREEgICAgICBEZXN0aW5hdGlv biBNQUMgQWRkcmVzcyAgICAgICAgICAgICAgICAgKDYgYnl0ZXMpDQoJCVNB ICAgICAgU291cmNlIE1BQyBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAg ICg2IGJ5dGVzKQ0KCQlUeXBlICAgIDB4ODg3MCAoRXRoZXJ0eXBlKSAgICAg ICAgICAgICAgICAgICAgICAoMiBieXRlcykNCgkJRFNBUCAgICA4MDIuMiBE ZXN0aW5hdGlvbiBTZXJ2aWNlIEFjY2VzcyBQb2ludCAgKDEgYnl0ZSkNCgkJ U1NBUCAgICA4MDIuMiBTb3VyY2UgU2VydmljZSBBY2Nlc3MgUG9pbnQgICAg ICAgKDEgYnl0ZSkNCgkJQ3RybCAgICA4MDIuMiBDb250cm9sIEZpZWxkICAg ICAgICAgICAgICAgICAgICAgKDEgYnl0ZSkNCgkJRGF0YSAgICBQcm90b2Nv bCBEYXRhICAgICAgICAgICAgICAgICAgICAgICAgICAgKCA+IDQ2IGJ5dGVz KQ0KCQlGQ1MgICAgIEZyYW1lIENoZWNrc3VtICAgICAgICAgICAgICAgICAg ICAgICAgICAoNCBieXRlcykNCgkgIA0KCSsgIEFsbG93IEV0aGVybmV0IElJ IGZyYW1lcyB0byBoYXZlIHBheWxvYWRzIGdyZWF0ZXIgdGhhbiAxNTAwIGJ5 dGVzLg0KDQoJVGhlcmUgaXMgbm8gbG9zcyBvZiBpbmZvcm1hdGlvbiBmcm9t IDgwMi4zLzgwMi4yIGZyYW1lcy4gQWx0aG91Z2ggDQogICAgICAgIHRoZSA4 MDIuMyBsZW5ndGggZmllbGQgaXMgbWlzc2luZywgdGhlIGZyYW1lIGxlbmd0 aCBpcyBrbm93biBieSANCiAgICAgICAgdmlydHVlIG9mIHRoZSBmcmFtZSBi ZWluZyBhY2NlcHRlZCBieSB0aGUgbmV0d29yayBpbnRlcmZhY2UuDQoNCglJ biB0aGlzIG1hbm5lciwgYWxsIEV0aGVybmV0IElJIGZyYW1lcywgaW5jbHVk aW5nIGxhcmdlIDgwMi4zIA0KIAlwYWNrZXRzLCBjYW4gYmUgbG9uZ2VyIHRo YW4gMTUwMCBieXRlcywgeWV0IGFyZSB1bmlxdWVseSBpZGVudGlmaWVkLg0K DQoNCjcuIFJlZmVyZW5jZXMNCg0KW0VUSF0gIlRoZSBFdGhlcm5ldCAtIEEg TG9jYWwgQXJlYSBOZXR3b3JrIiwgdmVyc2lvbiAxLjAsIERpZ2l0YWwNCkVx dWlwbWVudCBDb3Jwb3JhdGlvbiwgU2VwdGVtYmVyIDE5ODAsIGFuZCAiVGhl IEV0aGVybmV0LCBBIExvY2FsDQpBcmVhIE5ldHdvcmsiIERhdGEgTGluayBM YXllciBhbmQgUGh5c2ljYWwgTGF5ZXIgU3BlY2lmaWNhdGlvbnMiLA0KRGln aXRhbCwgSW50ZWwsIGFuZCBYZXJveCwgTm92ZW1iZXIsIDE5ODIuDQoNCltS RkM4OTRdIElFVEYgUkZDIDg5NA0KDQpbSUVFRTgwMi4zXSBJRUVFIFN0ZCA4 MDIuMw0KDQpbSUVFRTgwMl0gSUVFRSBTdGQgODAyDQoNCltJRUVFODAyLjNa XSBJRUVFIFN0ZCA4MDIuM3oNCg0KW0VYVC5GUkFNRV0gIlVzZSBvZiBFeHRl bmRlZCBGcmFtZSBTaXplcyBpbiBFdGhlcm5ldCBOZXR3b3JrcyIsIGRyYWZ0 DQoyLjEsIEFsdGVvbiBOZXR3b3JrcywgSW5jLg0KDQoNCjguIEF1dGhvcidz IEFkZHJlc3Nlcw0KDQpNaWtlIE8nRGVsbA0KVVVORVQgYW4gTUNJIFdvcmxk Q29tIENvbXBhbnkNCjMwNjAgV0lsbGFpbXMgRHJpdmUNCkZhaXJmYXgsIFZh LiAyMjAzMS00NjQ4DQo3MDMtMjA2LTU4OTANCmVtYWlsOiBtb0B1dS5uZXQN Cg0KSmVkIEthcGxhbg0KVVVORVQgYW4gTUNJIFdvcmxkQ29tIENvbXBhbnkN CjMwNjAgV0lsbGFpbXMgRHJpdmUNCkZhaXJmYXgsIFZhLiAyMjAzMS00NjQ4 DQo5MTQtNzAxLTUzMDkNCmVtYWlsOiBqa2FwbGFuQHV1Lm5ldA0KDQpKb2hu IEhheWVzDQpBbHRlb24gV2ViU3lzdGVtcywgSW5jLg0KNTAgR3JlYXQgT2Fr cyBCbHZkLg0KU2FuIEpvc2UsIENBIDk1MTE5DQo0MDgtMzYwLTU1MDcNCmVt YWlsOiBoYXllc0BhbHRlb24uY29tDQoNClRlZCBTY2hyb2VkZXINCkFsdGVv biBXZWJTeXN0ZW1zLCBJbmMuDQo1MCBHcmVhdCBPYWtzIEJsdmQuDQpTYW4g Sm9zZSwgQ0EgOTUxMTkNCjQwOC0zNjAtNTUwMA0KZW1haWw6IHRlZEBhbHRl b24uY29tDQoNClAuSi4gU2luZ2gNClBhY2tldCBFbmdpbmVzLCBJbmMuDQox MTcwNyBFYXN0IFNwcmFndWUgIzEwMQ0KU3Bva2FuZSBXQSAgOTkyMDYNCjUw OS03NzctNzAwMA0KZW1haWw6IHBqc2luZ2hAcGFja2V0ZW5naW5lcy5jb20N Cg0KRGFlbW9uIE1vcnJlbGwNCkp1bmlwZXIgTmV0d29ya3MsIEluYy4NCjEy MzQzLUQgU3VucmlzZSBWYWxsZXkgRHJpdmUNClJlc3RvbiwgVkEgMjAxOTEN CmVtYWlsOiBkbW9ycmVsbEBqdW5pcGVyLm5ldA0KDQpKZW5uaWZlciBIc3UN Cmpoc3VAbXVyLmNvbQ0K ---559023410-684387517-957964415=:12311-- From Internet-Drafts@ietf.org Wed, 19 Apr 2000 06:43:40 -0400 Date: Wed, 19 Apr 2000 06:43:40 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-snp-checksum-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Optional Checksums in ISIS Author(s) : A. Przygienda Filename : draft-ietf-isis-wg-snp-checksum-01.txt Pages : 3 Date : 18-Apr-00 This draft describes an optional extension to IS-IS [ISO90, Cal90a, Cal90b], used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. IS-IS originally doesn't provide CSNP adn PSNP checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional TLV providing checksums. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-snp-checksum-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-snp-checksum-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-snp-checksum-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000418080618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-snp-checksum-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-snp-checksum-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000418080618.I-D@ietf.org> --OtherAccess-- --NextPart-- From prz@redback.com Thu, 20 Apr 2000 13:51:32 -0700 Date: Thu, 20 Apr 2000 13:51:32 -0700 From: Tony Przygienda prz@redback.com Subject: [Isis-wg] Clarification.. Henk Smit wrote: > > Thanks for the reponse. > > I still have one doubt.. Can we use these addresses advetised in LSP TLV's > > for next hop addresses.Since these addresses have no specific mapping to > > the IP reachability information. > > Please correct me if I'm wrong. > > Ai, sorry, I was to quick in my reply. > The IP interface address TLV (TLV #132) I was talking about are the IP > interface address TLVs used in *hellos*. Not in LSPs. > > In LSPs there is the same TLV (TLV #132). But those have no practical use. > And you are not supposed to use them in your routing calculations. > The easiest thing is to just ignore them during your SPF computation. You are not supposed to use them in the routing calculations, so far Henk's correct, but some people use them as the management address of the router so basically if they need to connect to the box to manage it, they use this specific address. That way you can advertise a stable loopback independent from the fact whether certain router interfaces are up or not ... One can solve the problem in different ways as well but that's one way ... just my 2c -- tony From Internet-Drafts@ietf.org Thu, 11 May 2000 06:57:18 -0400 Date: Thu, 11 May 2000 06:57:18 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-kaplan-isis-ext-eth-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Extended Ethernet Frame Size Support Author(s) : M. O'Dell, J. Kaplan, J. Hayes, T. Schroeder, P. Singh, D. Morrell, J. Hsu Filename : draft-kaplan-isis-ext-eth-01.txt Pages : 4 Date : 10-May-00 This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kaplan-isis-ext-eth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaplan-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> --OtherAccess-- --NextPart-- From Daniel.Proch@marconi.com Thu, 18 May 2000 16:17:08 -0400 Date: Thu, 18 May 2000 16:17:08 -0400 From: Proch, Daniel Daniel.Proch@marconi.com Subject: [Isis-wg] RE: MPLS and IS-IS Gabor, http://202.38.127.18/res/www.ietf.org/internet-drafts/draft-ietf-isis-traffi c-01.txt If that link is broke, I will send it to you. ======================== Daniel Proch Marconi Communications ======================== -----Original Message----- From: Gabor Korossy (ETH) [mailto:ethkkg@etxb.ericsson.se] Sent: Thursday, May 18, 2000 4:20 AM To: mpls@UU.NET; 'isis-wg@juniper.net'; 'te-wg@uu.net' Subject: [Isis-wg] RE: MPLS and IS-IS Hi, if I may repeat, could anyone help me please, find the draft "IS-IS extensions for Traffic Engineering," draft-ietf-isis-traffic-01.txt If so many ISPs run IS-IS with MPLS TE extensions shouldn't it become an IETF standard? Maybe one of the MPLS, TE and IS-IS working groups doesn´t feel ashamed to adopt this child? regards - Gabor >> -----Original Message----- >> From: Chris.Flores@broadwing.com [mailto:Chris.Flores@broadwing.com] >> Sent: Wednesday, May 17, 2000 8:48 PM >> To: mpls@UU.NET >> Subject: FW: MPLS and IS-IS >> >> >> >> David - >> >> Most large ISPs in the US use ISIS: >> >> UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. >> >> It also seems like more and more european ISPs are starting >> to use ISIS: >> EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. >> >> Chris >> >> -----Original Message----- >> From: David Wang [mailto:david.wang@metro-optix.com] >> Sent: Wednesday, May 17, 2000 12:36 PM >> To: 'HANSEN CHAN'; mpls@UU.NET >> Subject: RE: MPLS and IS-IS >> >> >> Hi all, >> >> IS-IS is defined to work with CLNP not for IP originally. >> Until today a lot >> of SONET and telecommunication equipment vendors still use >> IS-IS to route >> CLNP packets through the SONET Data communication >> channel(DCC) to carry >> management information and there is a great pressure to >> change this to OSPF >> and IP. I also know that UUNET runs IS-IS on their network. >> I never heard >> any other networks run IS-IS. Seems I am wrong. My questions are. >> >> 1. You guys are talking about using IS-IS in a IP networks >> not in CLNP >> networks. The IS-IS has been modified according to RFC 1195 >> (Use of OSI >> IS-IS for Routing in TCP/IP and Dual Environments) or some >> other standard. >> Is this correct? >> >> 2. Besides UUNET, which ISPs run IS-IS protocol? Can you >> name a few? or >> what percentage of networks run IS-IS instead of OSPF? >> >> Thanks >> David >> >> >> -----Original Message----- >> From: HANSEN CHAN [mailto:hchan@newbridge.com] >> Sent: Tuesday, May 16, 2000 7:22 AM >> To: mpls@UU.NET >> Subject: MPLS and IS-IS >> >> >> Hi all, >> >> I have been hearing IS-IS is a better protocol to be used >> than OSPF in a >> MPLS >> network for TE application. Is that a fair statement? What >> are the technical >> reasons? >> >> Appreciate if someone can shed some light on this subject. >> >> Thanks, >> Hansen >> >> _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From Thomas.M.Holland@usa.alcatel.com Thu, 18 May 2000 17:19:22 -0400 Date: Thu, 18 May 2000 17:19:22 -0400 From: Thomas M Holland Thomas.M.Holland@usa.alcatel.com Subject: [Isis-wg] IS-IS mixed domains I have a question about mixing Dual and OSI-only routers in an OSI-only area. Here is the configuration: Dual-1 --- OSI-1 --- OSI-2 --- Dual-2 | | Dual-3 --- Dual-4 --- Dual-5 --- Dual-6 (note: there are supposed to be vertical connections from Dual-1 to Dual-3 and from Dual-2 to Dual-6, in case my artwork gets mangled) Each of these NEs support Integrated ISIS and are all in the same area. By definition, this must be an OSI-only area since two of the NEs are OSI-only. Assume Dual-1 wants to send an IP packet to IP3 which is attached to Dual-2. Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP reachability entries list. Dual-1 should now have 2 paths to IP3, one through OSI-1 and one through Dual-3. The one through OSI-1 looks like the shorter path, but won't work, because it includes OSI only routers. The standard states that you cannot route IP packets in an OSI-only area. But it doesn't indicate any checks that you must do to prevent doing this. Are you required to check the 'protocol supported' field in each LSP and keep track of what type of area you are in? It seems if the node was required to look at the 'protocol supported' field of each link to determine if the area was OSI-only, that would fix the problem. Either the node would drop the packet itself with an appropriate ICMP error, or perhaps the SPF algorithm would take into account which nodes support IP and which do not. However, the way the standard reads to me (especially sec 1.4 and 3.10), it implies that you just send it out and the packet will get dropped. Is my reading correct? It seems that if you have even one OSI only router in an area, there's not much use in having Dual routers in that area, since IP packets can't be routed. Is there any kind of mechanism for easing the transition from OSI to IP (or vice-versa)? Do you know if anyone is using RFC1195 to route both CLNP and IP? Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms for forwarding packets through incompatible routers (which might help ease the transition); do you know of any work along these lines? Thanks, Tom Holland Alcatel From henk@Procket.com Fri, 19 May 2000 00:02:40 +0200 (MEST) Date: Fri, 19 May 2000 00:02:40 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] IS-IS mixed domains > > I have a question about mixing Dual and OSI-only routers in an OSI-only area. > > Here is the configuration: > > Dual-1 --- OSI-1 --- OSI-2 --- Dual-2 > | | > Dual-3 --- Dual-4 --- Dual-5 --- Dual-6 > > (note: there are supposed to be vertical connections > from Dual-1 to Dual-3 and from Dual-2 to Dual-6, in > case my artwork gets mangled) The picture is crisp clear. > Each of these NEs support Integrated ISIS and are all in the same area. > By definition, this must be an OSI-only area since two of the NEs are > OSI-only. Don't know where you found that definition. This is what rfc1195 has to say. See paragraph 1.4: Support of Mixed Routing Domains. In a dual routing domain, IP-only, OSI-only, and dual routers may be mixed on a per-area basis. Specifically, each area may itself be defined to be pure IP, pure OSI, or dual. In a dual area within a dual routing domain only dual routers may be used. Both IP and OSI traffic can be routed within a dual area. When I read this, I understand that it states that you may not mix Dual routers and OSI-only routers *inside* one area. In the design you presented in your example, you do mix them. That is forbidden. Your network design will not work. > Assume Dual-1 wants to send an IP packet to IP3 which is attached to Dual-2. > Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP > reachability entries list. Dual-1 should now have 2 paths to IP3, > one through OSI-1 and one through Dual-3. The one through OSI-1 > looks like the shorter path, but won't work, because it includes OSI > only routers. Correct. > The standard states that you cannot route IP packets in an OSI-only > area. But it doesn't indicate any checks that you must do to > prevent doing this. Are you required to check the 'protocol > supported' field in each LSP and keep track of what type of area you > are in? I would assume it is the responsability of the network adminstrator who install and configures the routers. Note: the protocol supported TLV is inside hello packets. So routers could check that to accept or reject adjacencies with other routers that are differently configured. Note also that this would make migration between modes more difficult. > It seems if the node was required to look at the 'protocol > supported' field of each link Which field ? The description of a link inside an LSP only tells you between which routers the link is, and what the cost is. It does not tell you which protocols are supported over that link. This is TLV #2. If you use the newer TLV #22, then you might want to add a new sub-TLV to describe the protocols supported. Then each router can run an SPF per protocol. IMHO this is not worth the trouble. > to determine if the area was OSI-only, > that would fix the problem. Either the node would drop the packet > itself with an appropriate ICMP error, or perhaps the SPF algorithm > would take into account which nodes support IP and which do > not. You'll need a separate SPF for IP and one for OSI. > However, the way the standard reads to me (especially sec 1.4 > and 3.10), it implies that you just send it out and the packet will > get dropped. Is my reading correct? My reading is that your setup is illegal. Behaviour of routers in illegal configurations in not (always) defined. > It seems that if you have even one OSI only router in an area, there's not > much use in having Dual routers in that area, since IP packets can't > be routed. Correct. That is probably why the requirement is there to make all routers inside an area in the same mode. > Is there any kind of mechanism for easing the transition > from OSI to IP (or vice-versa)? I am not sure what you mean by that question. > Do you know if anyone is using RFC1195 to route both CLNP and IP? Of course. > Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms > for forwarding packets through incompatible routers (which might help ease > the transition); do you know of any work along these lines? Nothing that I know of. Tunnels are a pain. Hope this helps, Henk. From jjl@one.com Fri, 19 May 2000 15:32:09 -0400 Date: Fri, 19 May 2000 15:32:09 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] IS-IS mixed domains >> I have a question about mixing Dual and OSI-only routers in an OSI-only area. You can mix OSI-only and dual routers in an area, but only OSI routing will be supported in the area. While the dual routers support IP routing capability, you won't get meaningful IP routing in the area. RFC1195 says: In a pure-OSI area within a dual domain, OSI-only and dual routers may be freely mixed. Only OSI traffic can be routed by level 1 routing within a pure OSI area. The protocol does not enforce the requirement. But if you try to break the rules, it just won't work. IP-capable routers may attempt to forward IP packets to OSI-only routers, which will drop them (if it's robust, but NE implementations aren't always as robust as one might wish ;-). As Henk says, the protocol doesn't distinguish between CLNP links and IP links. It just describes links, and a link is assumed to be capable of any protocol supported by the router that's running SPF. The strange upshot of this is that there are some mixed networks (some dual, some CLNP-only) where IP actually works, but only because all best paths between dual routers are via dual routers. I would strongly recommend against building a network like this on purpose, except in very special cases. Note that the fault tolerance assesment is much more complicated. For example, in your picture: >> >> Here is the configuration: >> >> Dual-1 --- OSI-1 --- OSI-2 --- Dual-2 >> | | >> Dual-3 --- Dual-4 --- Dual-5 --- Dual-6 >> If Dual-1 is trying to send IP traffic to Dual 2, it will forward it via OSI-1, which will just drop it. Assuming all link costs are equal, Dual-3 will be able to exchange IP traffic with Dual-6, but only if none of the links between them are down. >> Each of these NEs support Integrated ISIS and are all in the same area. >> By definition, this must be an OSI-only area since two of the NEs are >> OSI-only. Correct. >> Assume Dual-1 wants to send an IP packet to IP3 which is attached to Dual-2. >> Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP >> reachability entries list. Dual-1 should now have 2 paths to IP3, >> one through OSI-1 and one through Dual-3. The one through OSI-1 >> looks like the shorter path, but won't work, because it includes OSI >> only routers. > > Correct. > >> The standard states that you cannot route IP packets in an OSI-only >> area. But it doesn't indicate any checks that you must do to >> prevent doing this. Are you required to check the 'protocol >> supported' field in each LSP and keep track of what type of area you >> are in? > > I would assume it is the responsability of the network adminstrator > who install and configures the routers. > Note: the protocol supported TLV is inside hello packets. So routers could > check that to accept or reject adjacencies with other routers that > are differently configured. Note also that this would make migration > between modes more difficult. > >> It seems if the node was required to look at the 'protocol >> supported' field of each link to determine if the area was OSI-only, >> that would fix the problem. Either the node would drop the packet >> itself with an appropriate ICMP error, or perhaps the SPF algorithm >> would take into account which nodes support IP and which do >> not. As Henk says, there is no information for each link. There is, however, a Protocols Supported TLV in each LSP, identifying the protocols supported by the router, according to RFC 1195: The "Protocols Supported" field identifies the protocols which are supported by each router. This field must be included in all IS-IS Hello packets and all LSPs with LSP number 0 transmitted by IP- capable routers. But this information is not consulted when running SPF (or at any other time, so some implementations might even omit them from LSPs, and there would be no side effects except when trying to debug routing problems by looking in a router's LSDB). >> However, the way the standard reads to me (especially sec 1.4 >> and 3.10), it implies that you just send it out and the packet will >> get dropped. Is my reading correct? > > My reading is that your setup is illegal. Behaviour of routers in > illegal configurations in not (always) defined. I disagree that the setup is illegal (using dual routers in an OSI-only area). I do agree that trying to route IP traffic in this area is illegal. This is only a semantic nit I am picking ;-) and I agree with Henk's assessment that the behavior is a "don't care case" in the spec. >> It seems that if you have even one OSI only router in an area, there's not >> much use in having Dual routers in that area, since IP packets can't >> be routed. The only reason would be for transition purposes. >> Is there any kind of mechanism for easing the transition >> from OSI to IP (or vice-versa)? Introduce dual routers, but use only CLNP, until all routers are dual- capable. Then it is a dual area, and you can start using IP. >> Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms >> for forwarding packets through incompatible routers (which might help ease >> the transition); do you know of any work along these lines? Unfortunately, RFC 1195 makes this difficult if not impossible to do, because of ignoring the Protocols Supported TLV when running SPF. This makes tunneling impossible without creating some new special kind of link that would need to be understood by all dual routers in the area as being an IP-only link. This need to upgrade all dual routers in the area makes such an enhancement impractical. Regards, 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 prz@net4u.ch Sat, 20 May 2000 22:47:39 +0200 (MEST) Date: Sat, 20 May 2000 22:47:39 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] Last call for draft-kaplan-isis-ext-eth-01.txt Last call for draft-kaplan-isis-ext-eth-01.txt to go informational. Last call ends June 5th thanks -- tony From Thomas.M.Holland@usa.alcatel.com Wed, 24 May 2000 08:56:07 -0400 Date: Wed, 24 May 2000 08:56:07 -0400 From: Thomas M Holland Thomas.M.Holland@usa.alcatel.com Subject: [Isis-wg] IDRPI field Does anyone know if the Inter-Domain Routing Protocol Information field (TLV 131) is used very much out in the field? Are there other values for the Inter-Domain Information Type than (0, 1, and 2) in use? I did not see any reference to them in IANA. For Type 1 (i.e., local) are there standard or common formats in use? Thanks, Tom Holland Alcatel From henk@Procket.com Wed, 24 May 2000 15:53:46 +0200 (MEST) Date: Wed, 24 May 2000 15:53:46 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] IDRPI field I have never seen it in any LSPs. I don't know of any vendor that has implemented this. In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-) Henk. > Does anyone know if the Inter-Domain Routing > Protocol Information field (TLV 131) is used > very much out in the field? > > Are there other values for the Inter-Domain > Information Type than (0, 1, and 2) in use? > I did not see any reference to them in IANA. > > For Type 1 (i.e., local) are there standard > or common formats in use? > > Thanks, > > Tom Holland > Alcatel > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Internet-Drafts@ietf.org Wed, 24 May 2000 06:35:13 -0400 Date: Wed, 24 May 2000 06:35:13 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-02.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Three-Way Handshake for IS-IS Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-3way-02.txt Pages : 7 Date : 23-May-00 The IS-IS routing protocol (ISO 10589) does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-3way-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-3way-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000523121610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-3way-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-3way-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000523121610.I-D@ietf.org> --OtherAccess-- --NextPart-- From NZvaig@adtech-inc.com Wed, 24 May 2000 10:09:33 -1000 Date: Wed, 24 May 2000 10:09:33 -1000 From: Nava.Zvaig NZvaig@adtech-inc.com Subject: [Isis-wg] Packet encapsulations 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_01BFC5BB.FA81D192 Content-Type: text/plain; charset="iso-8859-1" I'm looking for the latest encapsulations of IS-IS packets. It seemed that the format detailed in RFC 1195 and RFC 1142 has changed. For example, by searching the web, I found out that the common header doesn't include the ECO and USER ECO fields and has the Maximum Area Addresses field. Is there another source that describes the encapsulations of the Hello, LSP, and SNPs (for IS-IS over IP)? TIA, Nava ------_=_NextPart_001_01BFC5BB.FA81D192 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Packet encapsulations

I'm looking for the latest encapsulations of IS-IS = packets.  It seemed that the format detailed in RFC 1195 and RFC = 1142 has changed.  For example, by searching the web, I found out = that the common header doesn't include the ECO and USER ECO fields and = has the Maximum Area Addresses field.  Is there another source = that describes the encapsulations of the Hello, LSP, and SNPs (for = IS-IS over IP)?

TIA,
Nava

------_=_NextPart_001_01BFC5BB.FA81D192-- From jjl@one.com Wed, 24 May 2000 16:25:54 -0400 Date: Wed, 24 May 2000 16:25:54 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions The procedures in draft-ietf-isis-3way-02 look great. I have a suggestion: It should be stated that this mechanism is unnecessary when using a reliable link layer service, and that implementing this mechanism relaxes certain requirements stated in ISO 10589 for the operation of IS-IS over point-to-point links. These requirements are: "a) Provision that both source and destination systems complete startup before PDU exchange can occur; b) Detection of remote start-up; c) Provision that no old PDUs be received after start-up is complete; d) Provision that no PDUs transmitted after a particular startup is complete are delivered out of sequence; e) Provision that failure to deliver a specific subnetwork SDU will result in the timely disconnexion of the subnetwork connection in both directions and that this failure will be reported to both systems; and f) Reporting of other subnetwork failures and degrade subnetwork conditions. g) The following events are "very low probability", ..." Clearly, the draft relieves the subnetwork of requirements a, b, e, and f. I don't know whether the mechanism has any impact on requirements c and d. Regards, 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 mbartell@cisco.com Wed, 24 May 2000 17:37:59 -0500 Date: Wed, 24 May 2000 17:37:59 -0500 From: Micah Bartell mbartell@cisco.com Subject: [Isis-wg] Packet encapsulations With regards to the encapsulations of IS-IS packets, they are encapsulated within the Data Link. They do not run over CLNS or over IP. Does this answer you question? I would also not recommend the use of RFC 1142 as it is not the final draft of ISO 10589. I would instead recommend the obtaining an actual copy of ISO 10589 with the related updates which are packaged together by ANSI. Yes, work is in progress to produce a new edition of ISO 10589 which contains the defect reports integrated into the standard. /mpb At 10:09 AM 5/24/2000 -1000, Nava.Zvaig wrote: >I'm looking for the latest encapsulations of IS-IS packets. It seemed that the format detailed in RFC 1195 and RFC 1142 has changed. For example, by searching the web, I found out that the common header doesn't include the ECO and USER ECO fields and has the Maximum Area Addresses field. Is there another source that describes the encapsulations of the Hello, LSP, and SNPs (for IS-IS over IP)? > >TIA, >Nava -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer, NSA Phone: 972.364.8829 Cisco Systems, Inc Fax: 972.364.8829 -- The Network Works, No Excuses From rsaluja@nortelnetworks.com Thu, 25 May 2000 09:36:27 -0400 Date: Thu, 25 May 2000 09:36:27 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions Jeff, It is a valid point. Thanks for your suggestion. Regards, Rajesh Jeff Learman wrote: > The procedures in draft-ietf-isis-3way-02 look great. I have a suggestion: > > It should be stated that this mechanism is unnecessary when using a > reliable link layer service, and that implementing this mechanism relaxes > certain requirements stated in ISO 10589 for the operation of IS-IS over > point-to-point links. These requirements are: > > "a) Provision that both source and destination systems complete startup > before PDU exchange can occur; > b) Detection of remote start-up; > c) Provision that no old PDUs be received after start-up is complete; > d) Provision that no PDUs transmitted after a particular startup is > complete are delivered out of sequence; > e) Provision that failure to deliver a specific subnetwork SDU will > result in the timely disconnexion of the subnetwork connection in > both directions and that this failure will be reported to both systems; > and > f) Reporting of other subnetwork failures and degrade subnetwork conditions. > g) The following events are "very low probability", ..." > > Clearly, the draft relieves the subnetwork of requirements a, b, e, and f. > I don't know whether the mechanism has any impact on requirements c and d. > > Regards, > 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 > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From CMartin@mercury.balink.com Thu, 25 May 2000 17:10:29 -0400 Date: Thu, 25 May 2000 17:10:29 -0400 From: Martin, Christian CMartin@mercury.balink.com Subject: [Isis-wg] IDRPI field Henk, I posed a question regarding this a while back. As you know, RFC1195 indicates that the IDRPI field could be used for adminstrative tagging, a la OSPF admin tags when the type is set to 1, or an External AS LSA (LSA 6) for a type 2. From an operational perspective, this would be useful additional information that could aid in things like redistribution filtering. Given all the TE work being done to extend the protocol, it should be a relatively painless addition to the next rev. Regards, Chris -----Original Message----- From: Henk Smit [mailto:henk@Procket.com] Sent: Wednesday, May 24, 2000 9:54 AM To: Thomas.M.Holland@usa.alcatel.com Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] IDRPI field I have never seen it in any LSPs. I don't know of any vendor that has implemented this. In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-) Henk. > Does anyone know if the Inter-Domain Routing > Protocol Information field (TLV 131) is used > very much out in the field? > > Are there other values for the Inter-Domain > Information Type than (0, 1, and 2) in use? > I did not see any reference to them in IANA. > > For Type 1 (i.e., local) are there standard > or common formats in use? > > Thanks, > > Tom Holland > Alcatel > > _______________________________________________ > 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 vanik@future.futsoft.com Fri, 26 May 2000 10:27:07 +0530 Date: Fri, 26 May 2000 10:27:07 +0530 From: Vani Sree K vanik@future.futsoft.com Subject: [Isis-wg] Doubt on IS-IS Hi, In the Intermediate system Neighbors option of LAN Hello, the code value carries the 6 Octet Mac Address. (10589, 1992) My doubt is whether it is the Mac Address of the interface from which the Hello is sent or System Id of the Intermediate system. (Assuming one of the Mac address is system Id). (In one of the Cisco document of IS-IS, it has been stated that the "SystemID is usually the MAC identifier of an interface on the device. The IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has been heard within the last Hold time..") While creating new adjacencies, the NeigbourSNPA Address is set to the MAC source address of the PDU. It means, the source MAC address is got from the Ethernet header.? Please correct me. Thanks -vani From rsaluja@nortelnetworks.com Fri, 26 May 2000 09:16:30 -0400 Date: Fri, 26 May 2000 09:16:30 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] Doubt on IS-IS LAN Hello carries the system ID. -Rajesh Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From jjl@one.com Fri, 26 May 2000 11:37:44 -0400 Date: Fri, 26 May 2000 11:37:44 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Doubt on IS-IS Vani, While it is true that a LAN IIH carries a system ID, the Intermediate System Neighbors option in a LAN IIH carries the MAC address of the neighbor, not the system ID. The MAC address of the neighbor is obtained from the Ethernet header of the IIH received from the neighbor. See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, on page 50. Regards, Jeff Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > 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 emmanuel.dauvergne@rd.francetelecom.fr Fri, 26 May 2000 18:11:33 +0200 Date: Fri, 26 May 2000 18:11:33 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] Doubt on IS-IS ...and this MAC address (SNPA) is used in the DIS election : (if no priority imposed) choose the highest one. Regards, Manu -----Message d'origine----- De: Jeff Learman [mailto:jjl@one.com] Date: vendredi 26 mai 2000 17:38 À: Vani Sree K Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] Doubt on IS-IS Vani, While it is true that a LAN IIH carries a system ID, the Intermediate System Neighbors option in a LAN IIH carries the MAC address of the neighbor, not the system ID. The MAC address of the neighbor is obtained from the Ethernet header of the IIH received from the neighbor. See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, on page 50. Regards, Jeff Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > 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 ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From selvarajr@future.futsoft.com Sat, 27 May 2000 10:52:52 +0530 Date: Sat, 27 May 2000 10:52:52 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt on IS-IS ------ =_NextPart_000_01BFC7C9.B68FE220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Except resolving tie does the SNPA is useful for any other purpose that can't be done using System ID. Also for breaking Tie, if there are two string(or value) that can be compared then that's enough. But those string(or value) necessarily not be the SNPA. In case of Integrated ISIS while the protocol runs over IP , I feel it is little bit inefficient to get the MAC address from the Ethernet header. Pls clarify if wrong. SELVA -----Original Message----- From: DAUVERGNE Emmanuel FTRD/DAC/ISS [SMTP:emmanuel.dauvergne@rd.francetelecom.fr] Sent: Friday, May 26, 2000 9:42 PM To: Vani Sree K Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] Doubt on IS-IS ...and this MAC address (SNPA) is used in the DIS election : (if no priority imposed) choose the highest one. Regards, Manu -----Message d'origine----- De: Jeff Learman [mailto:jjl@one.com] Date: vendredi 26 mai 2000 17:38 A: Vani Sree K Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] Doubt on IS-IS Vani, While it is true that a LAN IIH carries a system ID, the Intermediate System Neighbors option in a LAN IIH carries the MAC address of the neighbor, not the system ID. The MAC address of the neighbor is obtained from the Ethernet header of the IIH received from the neighbor. See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, on page 50. Regards, Jeff Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > 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 ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------ =_NextPart_000_01BFC7C9.B68FE220 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjcFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAwAMAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAZAAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAERBVVZFUkdORSBFbW1h bnVlbCBGVFJEL0RBQy9JU1MAU01UUABlbW1hbnVlbC5kYXV2ZXJnbmVAcmQuZnJhbmNldGVsZWNv bS5mcgAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAJwAAAGVtbWFudWVsLmRhdXZlcmduZUBy ZC5mcmFuY2V0ZWxlY29tLmZyAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAiAAAAJ0RBVVZFUkdO RSBFbW1hbnVlbCBGVFJEL0RBQy9JU1MnAAAAAgELMAEAAAAsAAAAU01UUDpFTU1BTlVFTC5EQVVW RVJHTkVAUkQuRlJBTkNFVEVMRUNPTS5GUgADAAA5AAAAAAsAQDoAAAAAAwBxOgAAAAAeAPZfAQAA ACAAAABEQVVWRVJHTkUgRW1tYW51ZWwgRlRSRC9EQUMvSVNTAAIB918BAAAAZAAAAAAAAACBKx+k vqMQGZ1uAN0BD1QCAAABAERBVVZFUkdORSBFbW1hbnVlbCBGVFJEL0RBQy9JU1MAU01UUABlbW1h bnVlbC5kYXV2ZXJnbmVAcmQuZnJhbmNldGVsZWNvbS5mcgADAP1fAQAAAAMA/18AAAAAAgH2DwEA AAAEAAAAAAAAAxAAAAADAAAwBAAAAAsADw4AAAAAAgH/DwEAAABuAAAAAAAAALU7wsAsdxAaobwI ACsqVsIVAAAAE95ma15h0xGoWAAgNR+SoGSIAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABJU0lT LVdHAFNNVFAAaXNpcy13Z0BleHRlcm5hbC5qdW5pcGVyLm5ldAAAAB4AAjABAAAABQAAAFNNVFAA AAAAHgADMAEAAAAdAAAAaXNpcy13Z0BleHRlcm5hbC5qdW5pcGVyLm5ldAAAAAADABUMAgAAAAMA /g8GAAAAHgABMAEAAAAKAAAAJ0lTSVMtV0cnAAAAAgELMAEAAAAiAAAAU01UUDpJU0lTLVdHQEVY VEVSTkFMLkpVTklQRVIuTkVUAAAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAACAAAAElTSVMtV0cA AgH3XwEAAAAsAAAAvwAAALU7wsAsdxAaobwIACsqVsIVAAAAE95ma15h0xGoWAAgNR+SoGSIAAAD AP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAABDXPAQSAAQAdAAAAUkU6IFtJc2lzLXdnXSBE b3VidCBvbiBJUy1JUwDsCAEFgAMADgAAANAHBQAbAAoANAA0AAYAbwEBIIADAA4AAADQBwUAGwAK ACUAAAAGACwBAQmAAQAhAAAAMkFCMEE1QkRCMDMzRDQxMUE4NTgwMDIwMzUxRjkyQTAA9gYBA5AG AGgLAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAAAAAA QAA5AECeG5ubx78BHgBwAAEAAAAdAAAAUkU6IFtJc2lzLXdnXSBEb3VidCBvbiBJUy1JUwAAAAAC AXEAAQAAABYAAAABv8ebmwq9pbAsM7AR1KhYACA1H5KgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4A HwwBAAAAHQAAAHNlbHZhcmFqckBmdXR1cmUuZnV0c29mdC5jb20AAAAAAwAGEP8jp7cDAAcQfwgA AB4ACBABAAAAZQAAAEVYQ0VQVFJFU09MVklOR1RJRURPRVNUSEVTTlBBSVNVU0VGVUxGT1JBTllP VEhFUlBVUlBPU0VUSEFUQ0FOVEJFRE9ORVVTSU5HU1lTVEVNSURBTFNPRk9SQlJFQUtJTkdUSUUA AAAAAgEJEAEAAADsBwAA6AcAAJwPAABMWkZ19+scXXcACgEDAfcgAqQD4wIAY4JoCsBzZXQwIAcT DwKDAFADVA9ZQm9vaxEDgk9sZAYAdHlsGmUCgzIC4w9ZVGFoCwNxAoMzDudwcnEyTQ/2fQqACMgg OwlvMsw1NQKACoF1YwBQCwMGYwBBC2BuZzEwM4MU8QvEIEV4Y2UFMRUJcHMG8HYLgGcgdJEIkCBk bweRdGgb4CBTTlBBIAQAIHV5D7BmdQMgAhAFwABweSwgbxxRBcBwCHBwb6sPsBxBYQVAYwBwJwVA emIb4m4b4B0QG4IGsHOAdGVtIElELgqiWQqAQWwbQB1zYglwYUZrG4IHYGUsIBzQZs8cQglwHbAj UXR3IaAgkGsFEBnAKAWxdgdAClAp9x7XH4IFoG0KsQmAHEIDoB0e4icEIAnwCGBnaC7zCuMKgEJ1 BUAcUB6iJA//H+Aa0AQQCsADEB3gJzAfc3ccViEFIRRJA6AfMB6xbz8jACwwIKAJwB8AJjFJU/Et kCB3aAMQKsQVkB4Alm8I4RsQdQYxb3YeMehJUCAiwEkdcAngAyBWaQVAHOFsMHB0LhFi5zByH+AB IGljCJACMBuwjSGgZw/AHENNQUMdsLxkZBshBCADUhxDRR4Sfx/gBUAcYDMwBJArayEUUL8hgB8g C2AGgR3gIvF3A2B/GcA1PxlCAUAAoABABgBFOExWQQxAAtETMXMxnjY4GhThOCkw0DM2AUBXLoIF kAVALTziTwUQZ/8LgAdABdAp4jJwPOMrdjx0DzxBCxM8dAIAaS0xNMY0AUAw0DE4MAFADNBRQINi IEYDYToMg2IBD+BEQVVWRVJHdE5FGqBtA4EKUAMgRpBUUkQvQqBDLy2QgQXwW1NNVFA6ILChQ2Qu ZGF1L3FnH+D6QAsgLgNQAHAa0CCgEsD7JdFGUV0rdUGwBmACMEIXVUHQaUWQeSLATUkQIBwyNiLA AdBBECA5OpI0FcBQTUd3VG9CF5pWAHBpBgAJ0SBLR3ccQ2NCFwQABAAtd2c4QGV4IKAEoAdALmof LyAFIDURNJFHeHViaqM8oUIXUkU6RJBJTdR2XUKQCGBiBUACIC2BLb8tkD6PP5o8BAu2ISMuVdDv AHAmQhzhMvooHJIk8Bzk9xJwC4AcQ0QtsUbSG8BSUf1RMCgi8ScwLnFZQAUQEqD3IRQHcB6SZCTw D3AR4B6zXxvgLfAnYAeQUjJlK2tS8y0QCxFzLCEUSVBDgCt6dzzjPcUb8CdaQT1hPipESmVRMEoB ESBMIiByfQOCWxlTHVEAwAMQLrA68GpqbEBcsiXROMMdUPsP4EdlRC1BUTAvcFYQCXEPTABJkGMy ScQxNzoz4jgrdSdjMFEwS99NEfNNv07PCk9QMUgwB/Bhsb9RX1JtNW5oIl4lIRRXLfMvMHQkEApQ HtRhYiBBTukg0ElIHyFyCIEEIHGw/nMghl4lHFIs4mJgZhEtQf8gZgfAXEEG4A+gHfAFMFlC/1hB cbchFHJWMr4ssRxSH+D/dZQiwCpyHFJy9CvVIPAi0O5UeD95SxzSb20QC3EmMX8DUnOYNE15FnIS CXAa0Gk/L3B+ZHlLIQUGYHQRU08RZwAwNThKIDE5OccVwAZgWSQ5LjUv4XRPP3VXCHBeFlJRCrBg MTUw/1zvXfhh4m6OTBU3QmWBK3roPiBIb3Y+jEYsMXP/73L1dX8ssXHSSDBACQAiwX8cUgWgAQAk lIxGd6pmYE93PLAygUlQYw/wM0QngCjXg6MiwIQCKYxGTR3gHAD/bQIc4S3gD8AeInC1MsKUSPd5 FguAahFmANAb4DOzLeH/D3AcQoxHkSIc0g+wMhEFsb8gdhJwgGaOb0cgV0BBBBD8dW0bgh/SLLBz l5XXlEG3MzabwpyGKSEFjKAoLDG7n3QcQ0MEAAWgG/FjnxD/nAMswVKSIsAwcQ+ABCAfkJ8mgSCQ LUMe45q5ICIgdPsg4BzUdQdAKkEytkjwMgH/BpAIkSyiA5GZaFJRHFIBAL8bcBrQIQV7wY1nBfBO IgD9BCBDOYAwwSCQHDSh13yj/6jBeYczlS3gM9FxsJtkpbH/jEal8zTRCyAt0DBwLfBYVHsLYFyB SAbwJkEHcVXQIv+VxoxGcFQFACIgG8AbkR/g+wfgMzBqmcFGkHKRIsAcUv+PkoayHJOYdpvDMiMy tYxGjxtACHCZ0XxNUERVonf+SQVAB4AAcZFlurUy+hzh7mcqgTO/NMY/jP02YCIg/x6xJcFycDyi tEGM/XvAAHC6a7GXLSSgAwCM/V/GP//HT8gajWdphGMzG4Kt8iLQfi0i0GxVae9PSIygYsZoYQJA cDovL8u/NJEvu2NCA4EvrfILgAIQL2l1/2RmK3rIH9N/1I/Vnyt6ItD/YevYX9j3hSM0kWwg2PJj uv3XJUUZwDGBBnEbkV6RPgFnBcDdTyLQVm+r4dqEKAA3MzQpLTk3NVot30AyOzUi0E9DESjeT08Q A6AHwCPBcsRQ3AqNhQJjJPAi0EZheNqEWd8aNjlAodclMgHANe8GAAhgHFAs0WQdECQRPZH4UGt3 SSFQEDBwG+AZ4Lnkh0FuA6AHEHnjTTAAKCA0OBngNCLQVVP/OaDSL+qP65/sr9Zv7Q/v3//tTywR yb/Kz86PT3bNj/Rv/8+v0L/uL/sv/D/xX/Jv839/9I/1n/av97/4z/nYGJEAAQawAwAQEAAAAAAD ABEQAAAAAB4AQhABAAAAPwAAADw5ODM4OEMwNUQ0NjREMTExQjYxODAwODA1RjE1MDQxNjAxNDhC NDc4QHAtaWJpcy5pc3N5LmNuZXQuZnI+AAADAIAQ/////0AABzDgF9Jjmce/AUAACDDgF9Jjmce/ AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAA EIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMAB4AIIAYAAAAAAMAAAAAA AABGAAAAAAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4wNAAA AAALAAmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABGAAAA ABGFAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAyACCAGAAAAAADAAAAA AAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAAB AAAAAAAAAB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUA AABSRTogAAAAAAMADTT9NwAARWY= ------ =_NextPart_000_01BFC7C9.B68FE220-- From tangcm@future.futsoft.com Sat, 27 May 2000 11:34:05 +0530 Date: Sat, 27 May 2000 11:34:05 +0530 From: Jorge tangcm@future.futsoft.com Subject: [Isis-wg] Doubt on IS-IS I also agree with most of what Mr/Miss SELVA say . for actually now integrated Is-Is communication with IP layer only through Raw socket API , can somebody tell me how i can get the Ethernet header from raw socket with the condition that i won't encapsulate Is-Is packet with Ethernet header myself ( And also i can't make assumption that another implementation for integrated is-is will encapsulate Is-Is packet with Ethernet header in raw socket ) . ----- Original Message ----- From: SelvarajR To: 'DAUVERGNE Emmanuel FTRD/DAC/ISS' Cc: 'ISIS-WG' Sent: Saturday, May 27, 2000 10:52 AM Subject: RE: [Isis-wg] Doubt on IS-IS > Except resolving tie does the SNPA is useful for any other purpose that > can't be done using System ID. > Also for breaking Tie, if there are two string(or value) that can be > compared then that's enough. > But those string(or value) necessarily not be the SNPA. > > In case of Integrated ISIS while the protocol runs over IP , I feel it is > little bit inefficient to get the MAC address from the Ethernet header. > > > Pls clarify if wrong. > > SELVA > > -----Original Message----- > From: DAUVERGNE Emmanuel FTRD/DAC/ISS > [SMTP:emmanuel.dauvergne@rd.francetelecom.fr] > Sent: Friday, May 26, 2000 9:42 PM > To: Vani Sree K > Cc: isis-wg@external.juniper.net > Subject: RE: [Isis-wg] Doubt on IS-IS > > ...and this MAC address (SNPA) is used in the DIS election : (if no > priority > imposed) choose the highest one. > > Regards, > Manu > > -----Message d'origine----- > De: Jeff Learman [mailto:jjl@one.com] > Date: vendredi 26 mai 2000 17:38 > A: Vani Sree K > Cc: isis-wg@external.juniper.net > Objet: Re: [Isis-wg] Doubt on IS-IS > > > > Vani, > > While it is true that a LAN IIH carries a system ID, > the Intermediate System Neighbors option in a LAN IIH > carries the MAC address of the neighbor, not the system > ID. The MAC address of the neighbor is obtained from > the Ethernet header of the IIH received from the neighbor. > See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, > on page 50. > > Regards, > Jeff > > Vani Sree K wrote: > > > Hi, > > > > In the Intermediate system Neighbors option of LAN Hello, the code value > > carries the 6 Octet Mac Address. (10589, 1992) > > My doubt is whether it is the Mac Address of the interface from which the > > Hello is sent or System Id of the Intermediate system. (Assuming one of > the > > Mac address is system Id). > > (In one of the Cisco document of IS-IS, it has been stated that the > > "SystemID is usually the MAC identifier of an interface on the device. > The > > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > > been heard within the last Hold time..") > > > > While creating new adjacencies, the NeigbourSNPA Address is set to the > MAC > > source address of the PDU. > > It means, the source MAC address is got from the Ethernet header.? > > > > Please correct me. > > > > Thanks > > -vani > > > > _______________________________________________ > > 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 > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From henk@Procket.com Sat, 27 May 2000 12:21:03 +0200 (MEST) Date: Sat, 27 May 2000 12:21:03 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Doubt on IS-IS > In case of Integrated ISIS while the protocol runs over IP , I feel it is > little bit inefficient to get the MAC address from the Ethernet header. > > Pls clarify if wrong. Yes, this is wrong. There is a relatively new draft proposal to define an IP encapsulation for IS-IS. But integrated ISIS, as defined in rfc1195, uses the same encapsulation as ISIS defined in ISO/IEC DIS 10589. IS-IS packets are encapsulated directly in the data-link layer. No IP headers anywhere ...... Henk. From henk@Procket.com Sat, 27 May 2000 12:23:23 +0200 (MEST) Date: Sat, 27 May 2000 12:23:23 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Doubt on IS-IS > I also agree with most of what Mr/Miss SELVA say . for actually now > integrated Is-Is communication with IP layer only through Raw socket > API , can somebody tell me how i can get the Ethernet header from raw > socket with the condition that i won't encapsulate Is-Is packet with > Ethernet header myself ( And also i can't make assumption that another > implementation for integrated is-is will encapsulate Is-Is packet with > Ethernet header in raw socket ) . These are all clearly *implementation* questions. The answers depend on the OS you use. Henk. From prz@net4u.ch Sat, 27 May 2000 21:29:56 +0200 (MEST) Date: Sat, 27 May 2000 21:29:56 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] Doubt on IS-IS > > I also agree with most of what Mr/Miss SELVA say . for actually now > > integrated Is-Is communication with IP layer only through Raw socket > > API , can somebody tell me how i can get the Ethernet header from raw > > socket with the condition that i won't encapsulate Is-Is packet with > > Ethernet header myself ( And also i can't make assumption that another > > implementation for integrated is-is will encapsulate Is-Is packet with > > Ethernet header in raw socket ) . > > These are all clearly *implementation* questions. > The answers depend on the OS you use. > > Henk. Correct, however nothings' wrong with posting implementation qeustions on this list ;-) Henk was right in the other mail as well, there is the IPv4 encaps draft and one of the reasons for it was the difficulty to get mac header in many environments. Observe however that today's deployment occurs without IPv4 encaps pretty much. If you primarily want to play with ISIS without the realities of the market-place and only care to have it talk to e.g. gated, IPv4 encaps is nice since it let's you forget most of those ethernet header problems which are not easily taken care of on any Unix platform and in fact imply writing your own encaps and lots of toying around wiht things like SOCK_PACKET stuff. -- tony From Internet-Drafts@ietf.org Tue, 30 May 2000 06:34:25 -0400 Date: Tue, 30 May 2000 06:34:25 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-kaplan-isis-ext-eth-02.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Extended Ethernet Frame Size Support Author(s) : M. O'Dell, J. Kaplan, J. Hayes, T. Schroeder, P. Singh, D. Morrell, J. Hsu Filename : draft-kaplan-isis-ext-eth-02.txt Pages : 4 Date : 26-May-00 This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kaplan-isis-ext-eth-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kaplan-isis-ext-eth-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000526105527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaplan-isis-ext-eth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaplan-isis-ext-eth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000526105527.I-D@ietf.org> --OtherAccess-- --NextPart-- From jjl@one.com Tue, 30 May 2000 14:16:43 -0400 Date: Tue, 30 May 2000 14:16:43 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions Rajesh, Does the 3-way handshake resolve the problem of a loss of the initial CSNP? I see how the probability is reduced by handling the restart case. But over Frame Relay, for example, the first CSNP could be dropped without a restart. Is this covered by the procedure? If not, a timer could be added forcing a circuit restart if the CSNP is not received within a reasonable time. Also, if the first CSNP is lost, I would expect it to take up to 20 minutes for all systems to regenerate their LSPs, causing them to be flooded throughout the area and correcting the problem (not 18 hours). How did you come up with 18 hours? 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 jjl@one.com Tue, 30 May 2000 14:16:46 -0400 Date: Tue, 30 May 2000 14:16:46 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Doubt on IS-IS In addition to resolving the tie for Designated IS, the SNPA address in the LAN IIH is used to govern the adjacency transition from "initializing" to "up". You don't transition the adjacency for a neigboring IS to "up" until you see your MAC address in the neighbor's IIH (in the Intermediate System Neighbors option). Note that if your IS has multiple LAN interfaces on the same LAN, you will have multiple adjacencies for each neighbor IS, and each adjacency's state is independently controlled by the presence of its MAC address in the neighbor's IIH. Concerning implementation issues, most UNIX systems, including Solaris and AIX, support DLPI (Data Link Provider Interface), a STREAMS-based interface to the data link layer. This interface provides all necessary link and MAC layer addressing information. At 10:52 AM 5/27/00 +0530, SelvarajR wrote: >Except resolving tie does the SNPA is useful for any other purpose that >can't be done using System ID. >Also for breaking Tie, if there are two string(or value) that can be >compared then that's enough. >But those string(or value) necessarily not be the SNPA. > >In case of Integrated ISIS while the protocol runs over IP , I feel it is >little bit inefficient to get the MAC address from the Ethernet header. > > >Pls clarify if wrong. > >SELVA > >-----Original Message----- >From: DAUVERGNE Emmanuel FTRD/DAC/ISS >[SMTP:emmanuel.dauvergne@rd.francetelecom.fr] >Sent: Friday, May 26, 2000 9:42 PM >To: Vani Sree K >Cc: isis-wg@external.juniper.net >Subject: RE: [Isis-wg] Doubt on IS-IS > >...and this MAC address (SNPA) is used in the DIS election : (if no >priority >imposed) choose the highest one. > >Regards, >Manu > >-----Message d'origine----- >De: Jeff Learman [mailto:jjl@one.com] >Date: vendredi 26 mai 2000 17:38 >A: Vani Sree K >Cc: isis-wg@external.juniper.net >Objet: Re: [Isis-wg] Doubt on IS-IS > > > >Vani, > >While it is true that a LAN IIH carries a system ID, >the Intermediate System Neighbors option in a LAN IIH >carries the MAC address of the neighbor, not the system >ID. The MAC address of the neighbor is obtained from >the Ethernet header of the IIH received from the neighbor. >See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, >on page 50. > >Regards, >Jeff > >Vani Sree K wrote: > >> Hi, >> >> In the Intermediate system Neighbors option of LAN Hello, the code value >> carries the 6 Octet Mac Address. (10589, 1992) >> My doubt is whether it is the Mac Address of the interface from which the >> Hello is sent or System Id of the Intermediate system. (Assuming one of >the >> Mac address is system Id). >> (In one of the Cisco document of IS-IS, it has been stated that the >> "SystemID is usually the MAC identifier of an interface on the device. >The >> IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has >> been heard within the last Hold time..") >> >> While creating new adjacencies, the NeigbourSNPA Address is set to the >MAC >> source address of the PDU. >> It means, the source MAC address is got from the Ethernet header.? >> >> Please correct me. >> >> Thanks >> -vani >> >> _______________________________________________ >> 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 >____________________________________________________________________ > >_______________________________________________ >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 >Attachment Converted: "c:\eudora\attach\RE [Isis-wg] Doubt on IS-IS" > ____________________________________________________________________ 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 henk@Procket.com Tue, 30 May 2000 20:36:06 +0200 (MEST) Date: Tue, 30 May 2000 20:36:06 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions > Also, if the first CSNP is lost, I would expect it to take up to It should be noted that in addition to sending a CSNP, you must also set the SRM bit for this interface on all LSPs. If the CSNP from your neighbor does arrive, you can probably unset the SRM bits for lots of LSPs. If the CSNP from your neighbor is dropped, you end up sending all LSPs to your neighbor. That is gonna take more resources than strictly needed, but at least you are sure that the LSPDBs are synced quickly. > 20 minutes for all systems to regenerate their LSPs, causing them > to be flooded throughout the area and correcting the problem > (not 18 hours). How did you come up with 18 hours? The Remaininglifetime in the LSPs is 2 bytes. So in theory you could set the Remaininglifetime of a new LSP to 65535 seconds. If you adhere strictly to 10589, such an LSP should be considered to be corrupted. However, IMHO there is no need to be so restrictive. Some implementations will work fine with Remaininglifetimes larger than 20 minutes. Some implementations will even allow you to configure the router to set the Remaininglifetime higher than 20 minutes on new LSPs. This helps to bring down the "background flooding noise". 65535 seconds is 18.7 hours. Voila .... Henk. From prz@net4u.ch Wed, 31 May 2000 06:03:18 +0200 (MEST) Date: Wed, 31 May 2000 06:03:18 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] Agenda for Pittsburgh ... it's time to start to gather the agenda (beside the last calls and new draft versions) for Pittsburgh. Requests for slots pls to me or Tony Li -- tony From henk@Procket.com Fri, 26 May 2000 18:46:27 +0200 (MEST) Date: Fri, 26 May 2000 18:46:27 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] IDRPI field > Henk, > > I posed a question regarding this a while back. As you know, RFC1195 > indicates that the IDRPI field could be used for adminstrative tagging, a la > OSPF admin tags when the type is set to 1, or an External AS LSA (LSA 6) for > a type 2. Because TLV 131 is not well documented, different people can use it for different things. And if their technology gets deployed, the customers run into interoperability problems. > From an operational perspective, this would be useful additional > information that could aid in things like redistribution filtering. I agree it can be useful to have that kind of information available in the protocol. I'm not sure TLV 131 is the right place to do that. E.g. as far as I can see, TLV 131 stands on itself inside an LSP, and is not associated with any IP prefixes. How would you want to associate TLV 131 with particular IP prefixes ? By looking at the ordering of the TLVs inside an LSP ? For the obvious reasons, that doesn't seem a good idea to me. Can you let us know if you have a better idea about how to do that ? BTW, I tried to answer the question whether TLV 131 was deployed in the real world. I did not want to touch the subject of what it could be used for. That is another discussion. > Given all the TE work being done to extend the protocol, it should > be a relatively painless addition to the next rev. Agreed. However, if you look at the traffic-eng draft, you see there is new TLV for IP prefixes, TLV 135. Besides having wider metrics, this new TLV also has the capability to store sub-TLVs associated with an IP prefix. We designed to have these sub-TLVs to store TE info. But also other useful info can be stored there, like redistribution information. Feel free to implement a solution and write a draft about it. Yeah, yeah, yeah, I know I'm supposed to submit the next version of draft-draft-ietf-isis-traffic-0x.txt. :-) RSN ........ Henk. From bboulton@nexabit.com Wed, 31 May 2000 10:22:39 -0400 Date: Wed, 31 May 2000 10:22:39 -0400 From: Bryan Boulton bboulton@nexabit.com Subject: [Isis-wg] IDRPI field > Agreed. > However, if you look at the traffic-eng draft, you see there is new > TLV for IP prefixes, TLV 135. Besides having wider metrics, this > new TLV also has the capability to store sub-TLVs associated with an > IP prefix. We designed to have these sub-TLVs to store TE info. > But also other useful info can be stored there, like redistribution > information. Feel free to implement a solution and write a draft > about it. > Are these sub-TLVs defined anywhere? I notice the traffic-eng draft describes some for the extended IS reachability TLV (22) but not TLV 135. Thanks, -Bryan Boulton -Lucent Technologies From chopps@djinesys.com Fri, 26 May 2000 14:25:01 -0400 Date: Fri, 26 May 2000 14:25:01 -0400 From: Christian E. Hopps chopps@djinesys.com Subject: [Isis-wg] IDRPI field On Wed, May 24, 2000 at 03:53:46PM +0200, Henk Smit wrote: > > I have never seen it in any LSPs. > I don't know of any vendor that has implemented this. > In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-) I'm not sure but I suspect this is somehow related to RC1745. However, RFC1745 uses other bits in the 32 bit ospf tag field that aren't available with the TLV131 type 2 description. If people want to implement RFC1745 I would think the new TE TLV (using a sub-TLV) would be a better way to do it. Chris. From chopps@djinesys.com Fri, 26 May 2000 14:36:29 -0400 Date: Fri, 26 May 2000 14:36:29 -0400 From: Christian E. Hopps chopps@djinesys.com Subject: [Isis-wg] draft-ietf-isis-traffic Is this draft (draft-ietf-isis-traffic) going to be reissued? It appears to have expired. Thanks, Chris. From prz@siara.com Fri, 26 May 2000 23:17:30 -0700 Date: Fri, 26 May 2000 23:17:30 -0700 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Doubt on IS-IS Jorge wrote: > I also agree with most of what Mr/Miss SELVA say . for actually now integrated Is-Is communication with IP layer only through Raw socket API , can somebody tell me how i can get the Ethernet header from raw socket with the condition that i won't encapsulate Is-Is packet with Ethernet header myself ( And also i can't make assumption that another implementation for integrated is-is will encapsulate Is-Is packet with Ethernet header in raw socket ) . look @ the ISIS over IPv4 draft ... thanks -- tony From henk@Procket.com Wed, 31 May 2000 17:52:26 +0200 (MEST) Date: Wed, 31 May 2000 17:52:26 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] IDRPI field > > However, if you look at the traffic-eng draft, you see there is new > > TLV for IP prefixes, TLV 135. Besides having wider metrics, this > > new TLV also has the capability to store sub-TLVs associated with an > > IP prefix. We designed to have these sub-TLVs to store TE info. > > But also other useful info can be stored there, like redistribution > > information. Feel free to implement a solution and write a draft > > about it. > > > Are these sub-TLVs defined anywhere? I notice the traffic-eng draft > describes some for the extended IS reachability TLV (22) but not > TLV 135. No, none have been described yet. Henk. From rhan@ibnets.com Wed, 31 May 2000 16:14:02 +0000 Date: Wed, 31 May 2000 16:14:02 +0000 From: Rick Han rhan@ibnets.com Subject: [Isis-wg] question on MTU Hi, iso10589 (8.2.3 (c)) says that IIH should be padded (at least for the first one) to the maxsize-1. This is to make sure that allISs in the domain use the same MTU. Does this mean that MTU check is part of HELLO checking before further processing the PDU? My understanding is that there will be no adjacency established if an IS uses different MTU as other ISs are configured. Is this correct? It seems Cisco allows adjacency setup even the two routers configured different MTU, why is that? Thanks Rick -- Rick Han Iron Bridge Networks, Inc. rhan@ibnets.com (781)372-8180 From jjl@one.com Wed, 31 May 2000 16:56:26 -0400 Date: Wed, 31 May 2000 16:56:26 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] question on MTU Remember that ISO 10598 requires point-to-point links to be reliable, so that failure to deliver an IS-IS PDU would cause the link to go down. Note that 8.2.2 does not require the IS to check the size of the received IIH. I think the idea was to make sure that whatever your idea of the MTU size is, that you can transmit a packet of that size without worrying about it being dropped by the link layer. If you're transmitting IIHs that are too large to be received at the other end, your data-link connection will go down and the adjacency will never come up. But this only works if the link is reliable (that is, if the link goes down if it can't deliver a packet). Since Integrated IS-IS is usually used over unreliable links (ones where failure to deliver doesn't cause anything special), the guarantee that you can actually deliver a packet of what you think is the maximum size doesn't work any more. On the other hand, isn't MTU size negotiation handled by LCP/NCP? If IS-IS is run over PPP with MTU size negotiation, this IS-IS guarantee may no longer be important. Regards, Jeff At 04:14 PM 5/31/00 +0000, Rick Han wrote: >Hi, iso10589 (8.2.3 (c)) says that IIH should be padded (at least for the >first one) to the maxsize-1. This is to make sure that allISs in the domain >use the same MTU. Does this mean that MTU check is part of HELLO checking >before further processing the PDU? My understanding is that there will be >no adjacency established if an IS uses different MTU as other ISs are >configured. Is this correct? It seems Cisco allows adjacency setup even the >two routers configured different MTU, why is that? > >Thanks > >Rick >-- >Rick Han >Iron Bridge Networks, Inc. >rhan@ibnets.com >(781)372-8180 > > >_______________________________________________ >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 jparker@nexabit.com Wed, 31 May 2000 17:10:54 -0400 Date: Wed, 31 May 2000 17:10:54 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] question on MTU > I think the idea was to make sure that whatever your idea of > the MTU size is, that you can transmit a packet of that size > without worrying about it being dropped by the link layer. > If you're transmitting IIHs that are too large to be received > at the other end, your data-link connection will go down and > the adjacency will never come up. But this only works if the > link is reliable (that is, if the link goes down if it can't > deliver a packet). > > Jeff Learman Internet: jjl@one.com You could send padded packets on pt2pt until the adjacency comes up. This makes no assumptions about the reliability of the link layer. - jeff parker - Lucent Technology From jjl@one.com Wed, 31 May 2000 17:29:42 -0400 Date: Wed, 31 May 2000 17:29:42 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] question on MTU Jeff Good point -- that would solve the problem. This could be added to the 3-way handshake RFC. It might be unnecessary, though, when operating over links where the MTU is negotiated end-to-end and IS-IS is using the result of that negotiation. Unfortunately, it wouldn't guarantee that you can receive big packets from the other end, which might not implement the new requirement. To do that, you'd have to check the size of the neighbor's IIH and only accept it if it looks like it's padded to a maximum size, during initialization phase. (But how would you do that? Presence of any padding option over some given size?) As you probably know, the check is important to make sure that any LSP you send over the link will actually make it. It is not necessary that the MTU size be equal in both directions, so it wouldn't necessarily be a good idea to require the received IIH to match your own MTU size. While I suppose it's uncommon to have asymmetrical MTU sizes, it might be useful in certain situations, like ADSL. To add such a check would be to add a new restriction on the use of IS-IS. Regards, Jeff At 05:10 PM 5/31/00 -0400, you wrote: >> I think the idea was to make sure that whatever your idea of >> the MTU size is, that you can transmit a packet of that size >> without worrying about it being dropped by the link layer. >> If you're transmitting IIHs that are too large to be received >> at the other end, your data-link connection will go down and >> the adjacency will never come up. But this only works if the >> link is reliable (that is, if the link goes down if it can't >> deliver a packet). >> >> Jeff Learman Internet: jjl@one.com > >You could send padded packets on pt2pt until the adjacency comes up. >This makes no assumptions about the reliability of the link layer. > >- jeff parker >- Lucent Technology ____________________________________________________________________ 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 jjl@one.com Wed, 31 May 2000 17:54:24 -0400 Date: Wed, 31 May 2000 17:54:24 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] question on MTU This is a big, bad, nasty problem. This case is NOT handled by the protocol -- you aren't told what to do, and no matter what you do, it's not good. It was discussed in detail at the SONET Interoperability Forum, where we have the unlucky situation that the SONET management channel (normally unused by you IP folks) is specified to use an MTU size of 512 bytes, but the rest of the natural world uses a size of 1500. Fortunately, there is a solution, which can be found in ftp://ftp.atis.org/pub/sif/arch/ar820317.doc I believe that this was submitted to ISO as a defect report or technical corrigendum, but I don't know the current status. Perhaps Les Guinsberg or Tom Rutt could fill us in, if they are listening. Regards, Jeff At 09:52 PM 5/31/00 +0000, Rick Han wrote: >Suppose we have following setup: > router1 (R1) --- router2 (R2)----- router3 (R3) > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and R3 is 2k. If R1 >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the >following LSPs from R1, if they are in 4k packets? How does R2 propagate >them to R3? I guess that's why the adjacency between R1 and R2 is supposed >to be droped at the first place. But if we accept the neighbor, then what >if R1 sends two LSPs, one in 1.5k and another in 3k? The smaller LSP can go >through to R3 but the bigger one get droped at the link. Now we have >un-synchronized database over the domain. > >Rick > >Jeff Learman wrote: >> >> Jeff >> >> Good point -- that would solve the problem. This could be added >> to the 3-way handshake RFC. It might be unnecessary, though, when >> operating over links where the MTU is negotiated end-to-end >> and IS-IS is using the result of that negotiation. >> >> Unfortunately, it wouldn't guarantee that you can receive big >> packets from the other end, which might not implement the new >> requirement. To do that, you'd have to check the size of the >> neighbor's IIH and only accept it if it looks like it's padded >> to a maximum size, during initialization phase. (But how would >> you do that? Presence of any padding option over some given >> size?) >> >> As you probably know, the check is important to make sure that >> any LSP you send over the link will actually make it. It is not >> necessary that the MTU size be equal in both directions, so >> it wouldn't necessarily be a good idea to require the received >> IIH to match your own MTU size. While I suppose it's uncommon >> to have asymmetrical MTU sizes, it might be useful in certain >> situations, like ADSL. To add such a check would be to add a >> new restriction on the use of IS-IS. >> >> Regards, >> Jeff >> >> At 05:10 PM 5/31/00 -0400, you wrote: >> >> I think the idea was to make sure that whatever your idea of >> >> the MTU size is, that you can transmit a packet of that size >> >> without worrying about it being dropped by the link layer. >> >> If you're transmitting IIHs that are too large to be received >> >> at the other end, your data-link connection will go down and >> >> the adjacency will never come up. But this only works if the >> >> link is reliable (that is, if the link goes down if it can't >> >> deliver a packet). >> >> >> >> Jeff Learman Internet: jjl@one.com >> > >> >You could send padded packets on pt2pt until the adjacency comes up. >> >This makes no assumptions about the reliability of the link layer. >> > >> >- jeff parker >> >- Lucent Technology >> >> ____________________________________________________________________ >> >> 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 > >-- >Rick Han >Iron Bridge Networks, Inc. >rhan@ibnets.com >(781)372-8180 > > ____________________________________________________________________ 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 jparker@nexabit.com Wed, 31 May 2000 18:01:39 -0400 Date: Wed, 31 May 2000 18:01:39 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] question on MTU I think section 8.2.3 of ISO 10589 specifies that you use the appropriate L1 or L2 BufferSize, rather than the interface MTU. - jeff parker - Lucent Technology > > This is a big, bad, nasty problem. This case is NOT handled by > the protocol -- you aren't told what to do, and no matter what you > do, it's not good. It was discussed in detail at the SONET > Interoperability Forum, where we have the unlucky situation that > the SONET management channel (normally unused by you IP folks) > is specified to use an MTU size of 512 bytes, but the rest of > the natural world uses a size of 1500. > > Fortunately, there is a solution, which can be found in > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > I believe that this was submitted to ISO as a defect report or > technical corrigendum, but I don't know the current status. > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > are listening. > > Regards, > Jeff > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > >Suppose we have following setup: > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > R3 is 2k. If R1 > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > >following LSPs from R1, if they are in 4k packets? How does > R2 propagate > >them to R3? I guess that's why the adjacency between R1 and > R2 is supposed > >to be droped at the first place. But if we accept the > neighbor, then what > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > smaller LSP can go > >through to R3 but the bigger one get droped at the link. Now we have > >un-synchronized database over the domain. > > > >Rick > > > >Jeff Learman wrote: > >> > >> Jeff > >> > >> Good point -- that would solve the problem. This could be added > >> to the 3-way handshake RFC. It might be unnecessary, though, when > >> operating over links where the MTU is negotiated end-to-end > >> and IS-IS is using the result of that negotiation. > >> > >> Unfortunately, it wouldn't guarantee that you can receive big > >> packets from the other end, which might not implement the new > >> requirement. To do that, you'd have to check the size of the > >> neighbor's IIH and only accept it if it looks like it's padded > >> to a maximum size, during initialization phase. (But how would > >> you do that? Presence of any padding option over some given > >> size?) > >> > >> As you probably know, the check is important to make sure that > >> any LSP you send over the link will actually make it. It is not > >> necessary that the MTU size be equal in both directions, so > >> it wouldn't necessarily be a good idea to require the received > >> IIH to match your own MTU size. While I suppose it's uncommon > >> to have asymmetrical MTU sizes, it might be useful in certain > >> situations, like ADSL. To add such a check would be to add a > >> new restriction on the use of IS-IS. > >> > >> Regards, > >> Jeff > >> > >> At 05:10 PM 5/31/00 -0400, you wrote: > >> >> I think the idea was to make sure that whatever your idea of > >> >> the MTU size is, that you can transmit a packet of that size > >> >> without worrying about it being dropped by the link layer. > >> >> If you're transmitting IIHs that are too large to be received > >> >> at the other end, your data-link connection will go down and > >> >> the adjacency will never come up. But this only works if the > >> >> link is reliable (that is, if the link goes down if it can't > >> >> deliver a packet). > >> >> > >> >> Jeff Learman Internet: > jjl@one.com > >> > > >> >You could send padded packets on pt2pt until the > adjacency comes up. > >> >This makes no assumptions about the reliability of the link layer. > >> > > >> >- jeff parker > >> >- Lucent Technology > >> > >> > ____________________________________________________________________ > >> > >> 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 > > > >-- > >Rick Han > >Iron Bridge Networks, Inc. > >rhan@ibnets.com > >(781)372-8180 > > > > > ____________________________________________________________________ > > 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 mbartell@cisco.com Wed, 31 May 2000 17:25:35 -0500 Date: Wed, 31 May 2000 17:25:35 -0500 From: Micah Bartell mbartell@cisco.com Subject: [Isis-wg] question on MTU Actually the IIH should be at least maxsize-1 octets. maxsize is the maximum of the three following values: 1. dataLinkBlocksize 2. originatingL1LSPBufferSize 3. originatingL2LSPBufferSize The reason for using maxsize-1 is any padding added needs to be at least 2 octets. So if the PDU length is maxsize-1 you can't add 2 octets, requiring that to be a valid size also. /mpb At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote: >I think section 8.2.3 of ISO 10589 specifies that you use the appropriate >L1 or L2 BufferSize, rather than the interface MTU. > >- jeff parker >- Lucent Technology > > > > This is a big, bad, nasty problem. This case is NOT handled by > > the protocol -- you aren't told what to do, and no matter what you > > do, it's not good. It was discussed in detail at the SONET > > Interoperability Forum, where we have the unlucky situation that > > the SONET management channel (normally unused by you IP folks) > > is specified to use an MTU size of 512 bytes, but the rest of > > the natural world uses a size of 1500. > > > > Fortunately, there is a solution, which can be found in > > > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > > > I believe that this was submitted to ISO as a defect report or > > technical corrigendum, but I don't know the current status. > > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > > are listening. > > > > Regards, > > Jeff > > > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > > >Suppose we have following setup: > > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > > R3 is 2k. If R1 > > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > > >following LSPs from R1, if they are in 4k packets? How does > > R2 propagate > > >them to R3? I guess that's why the adjacency between R1 and > > R2 is supposed > > >to be droped at the first place. But if we accept the > > neighbor, then what > > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > > smaller LSP can go > > >through to R3 but the bigger one get droped at the link. Now we have > > >un-synchronized database over the domain. > > > > > >Rick > > > > > >Jeff Learman wrote: > > >> > > >> Jeff > > >> > > >> Good point -- that would solve the problem. This could be added > > >> to the 3-way handshake RFC. It might be unnecessary, though, when > > >> operating over links where the MTU is negotiated end-to-end > > >> and IS-IS is using the result of that negotiation. > > >> > > >> Unfortunately, it wouldn't guarantee that you can receive big > > >> packets from the other end, which might not implement the new > > >> requirement. To do that, you'd have to check the size of the > > >> neighbor's IIH and only accept it if it looks like it's padded > > >> to a maximum size, during initialization phase. (But how would > > >> you do that? Presence of any padding option over some given > > >> size?) > > >> > > >> As you probably know, the check is important to make sure that > > >> any LSP you send over the link will actually make it. It is not > > >> necessary that the MTU size be equal in both directions, so > > >> it wouldn't necessarily be a good idea to require the received > > >> IIH to match your own MTU size. While I suppose it's uncommon > > >> to have asymmetrical MTU sizes, it might be useful in certain > > >> situations, like ADSL. To add such a check would be to add a > > >> new restriction on the use of IS-IS. > > >> > > >> Regards, > > >> Jeff > > >> > > >> At 05:10 PM 5/31/00 -0400, you wrote: > > >> >> I think the idea was to make sure that whatever your idea of > > >> >> the MTU size is, that you can transmit a packet of that size > > >> >> without worrying about it being dropped by the link layer. > > >> >> If you're transmitting IIHs that are too large to be received > > >> >> at the other end, your data-link connection will go down and > > >> >> the adjacency will never come up. But this only works if the > > >> >> link is reliable (that is, if the link goes down if it can't > > >> >> deliver a packet). > > >> >> > > >> >> Jeff Learman Internet: > > jjl@one.com > > >> > > > >> >You could send padded packets on pt2pt until the > > adjacency comes up. > > >> >This makes no assumptions about the reliability of the link layer. > > >> > > > >> >- jeff parker > > >> >- Lucent Technology > > >> > > >> > > ____________________________________________________________________ > > >> > > >> 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 > > > > > >-- > > >Rick Han > > >Iron Bridge Networks, Inc. > > >rhan@ibnets.com > > >(781)372-8180 > > > > > > > > ____________________________________________________________________ > > > > 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 > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer, NSA Phone: 972.364.8829 Cisco Systems, Inc Fax: 972.364.8829 -- The Network Works, No Excuses From ginsberg@pluris.com Wed, 31 May 2000 16:04:23 -0700 Date: Wed, 31 May 2000 16:04:23 -0700 From: Les Ginsberg ginsberg@pluris.com Subject: [Isis-wg] question on MTU The problem that Rick refers to is not quite as bad as his example suggests. "originatingLxBufferSize" is limited to values between 512-1492. So long as the MTU of any link over which IS-IS operates is >= 1492 there should never be a problem propagating LSPs due to PDU size issues. This issue, as Jeff remembers all too well, actually occurs only when some of the links used for IS-IS have an MTU smaller than 1492 - as is the case with SONET DCC. The solution referred to below does not eliminate the problem, but it provides the protocol with the tools to detect and report the problem, hopefully before it ever occurs. The proposal is part of the revised agenda the US has submitted to ISO for producing a new draft revision of ISO 10589:1992. Inclusion of this proposal is of course subject to review by the international community - as of this date the revised draft is not yet available and the international review process has not yet begun. Les > -----Original Message----- > From: Jeff Learman [mailto:jjl@one.com] > Sent: Wednesday, May 31, 2000 2:54 PM > To: rhan@ibnets.com > Cc: Jeff Parker; isis-wg@external.juniper.net > Subject: Re: [Isis-wg] question on MTU > > > > This is a big, bad, nasty problem. This case is NOT handled by > the protocol -- you aren't told what to do, and no matter what you > do, it's not good. It was discussed in detail at the SONET > Interoperability Forum, where we have the unlucky situation that > the SONET management channel (normally unused by you IP folks) > is specified to use an MTU size of 512 bytes, but the rest of > the natural world uses a size of 1500. > > Fortunately, there is a solution, which can be found in > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > I believe that this was submitted to ISO as a defect report or > technical corrigendum, but I don't know the current status. > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > are listening. > > Regards, > Jeff > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > >Suppose we have following setup: > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > R3 is 2k. If R1 > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > >following LSPs from R1, if they are in 4k packets? How does > R2 propagate > >them to R3? I guess that's why the adjacency between R1 and > R2 is supposed > >to be droped at the first place. But if we accept the > neighbor, then what > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > smaller LSP can go > >through to R3 but the bigger one get droped at the link. Now we have > >un-synchronized database over the domain. > > > >Rick > > > >Jeff Learman wrote: > >> > >> Jeff > >> > >> Good point -- that would solve the problem. This could be added > >> to the 3-way handshake RFC. It might be unnecessary, though, when > >> operating over links where the MTU is negotiated end-to-end > >> and IS-IS is using the result of that negotiation. > >> > >> Unfortunately, it wouldn't guarantee that you can receive big > >> packets from the other end, which might not implement the new > >> requirement. To do that, you'd have to check the size of the > >> neighbor's IIH and only accept it if it looks like it's padded > >> to a maximum size, during initialization phase. (But how would > >> you do that? Presence of any padding option over some given > >> size?) > >> > >> As you probably know, the check is important to make sure that > >> any LSP you send over the link will actually make it. It is not > >> necessary that the MTU size be equal in both directions, so > >> it wouldn't necessarily be a good idea to require the received > >> IIH to match your own MTU size. While I suppose it's uncommon > >> to have asymmetrical MTU sizes, it might be useful in certain > >> situations, like ADSL. To add such a check would be to add a > >> new restriction on the use of IS-IS. > >> > >> Regards, > >> Jeff > >> > >> At 05:10 PM 5/31/00 -0400, you wrote: > >> >> I think the idea was to make sure that whatever your idea of > >> >> the MTU size is, that you can transmit a packet of that size > >> >> without worrying about it being dropped by the link layer. > >> >> If you're transmitting IIHs that are too large to be received > >> >> at the other end, your data-link connection will go down and > >> >> the adjacency will never come up. But this only works if the > >> >> link is reliable (that is, if the link goes down if it can't > >> >> deliver a packet). > >> >> > >> >> Jeff Learman Internet: > jjl@one.com > >> > > >> >You could send padded packets on pt2pt until the > adjacency comes up. > >> >This makes no assumptions about the reliability of the link layer. > >> > > >> >- jeff parker > >> >- Lucent Technology > >> > >> > ____________________________________________________________________ > >> > >> 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 > > > >-- > >Rick Han > >Iron Bridge Networks, Inc. > >rhan@ibnets.com > >(781)372-8180 > > > > > ____________________________________________________________________ > > 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 dkatz@juniper.net Wed, 31 May 2000 16:21:45 -0700 (PDT) Date: Wed, 31 May 2000 16:21:45 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] question on MTU LSPs have an architecturally-defined maximum size (1492 if memory serves) because, unlike in OSPF, they are not regenerated hop-by-hop so they must be small enough so that they are guaranteed to be able to cross *any* media in the network. Trying to use variable sizes gets very interesting. NLSP was operationally problematic due to this (try setting the MTU to 1500 and then accidentally using SNAP encapsulation on some links--whee!) The "big, bad, nasty problem" is due to the media of choice in the SONET application having an unfortunately small MTU, and the problem is confined entirely to such media (I think ARCnet is about the only other one; see earlier comment about NLSP). It in particular is *not* any sort of problem when dealing with links having MTUs *larger* than 1492. Even if the link MTU were negotiated, it would *not* have any use in the protocol per se (other than complaining if it were too small). OSPF has a hook added after the original spec came out which won't allow neighbors to become adjacent unless their MTUs agree--this is more important because LSUpdates are built hop-by-hop and so can become MTU-sized if the implementor so desires, but it also leads to regular customer service calls asking "why are my neighbors stuck in EXSTART state." IIH padding was intended to catch badly misconfigured boxes, and to a lesser extent size-dependent errors (though the padded ones were only supposed to be sent on point-to-point links only briefly, and these are the only links that usually ever show any size dependency). IIH padding has, in practice, been largely deprecated because it is essentially useless and creates lots of unnecessary customer service calls to vendors ("Why is my adjacency stuck in Init state?"). Incoming padding should be ignored, period. --Dave X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 31 May 2000 17:54:24 -0400 From: Jeff Learman Cc: Jeff Parker , isis-wg@external.juniper.net References: <3.0.1.32.20000531172942.0131f370@mail.one.com> 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 This is a big, bad, nasty problem. This case is NOT handled by the protocol -- you aren't told what to do, and no matter what you do, it's not good. It was discussed in detail at the SONET Interoperability Forum, where we have the unlucky situation that the SONET management channel (normally unused by you IP folks) is specified to use an MTU size of 512 bytes, but the rest of the natural world uses a size of 1500. Fortunately, there is a solution, which can be found in ftp://ftp.atis.org/pub/sif/arch/ar820317.doc I believe that this was submitted to ISO as a defect report or technical corrigendum, but I don't know the current status. Perhaps Les Guinsberg or Tom Rutt could fill us in, if they are listening. Regards, Jeff At 09:52 PM 5/31/00 +0000, Rick Han wrote: >Suppose we have following setup: > router1 (R1) --- router2 (R2)----- router3 (R3) > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and R3 is 2k. If R1 >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the >following LSPs from R1, if they are in 4k packets? How does R2 propagate >them to R3? I guess that's why the adjacency between R1 and R2 is supposed >to be droped at the first place. But if we accept the neighbor, then what >if R1 sends two LSPs, one in 1.5k and another in 3k? The smaller LSP can go >through to R3 but the bigger one get droped at the link. Now we have >un-synchronized database over the domain. > >Rick > >Jeff Learman wrote: >> >> Jeff >> >> Good point -- that would solve the problem. This could be added >> to the 3-way handshake RFC. It might be unnecessary, though, when >> operating over links where the MTU is negotiated end-to-end >> and IS-IS is using the result of that negotiation. >> >> Unfortunately, it wouldn't guarantee that you can receive big >> packets from the other end, which might not implement the new >> requirement. To do that, you'd have to check the size of the >> neighbor's IIH and only accept it if it looks like it's padded >> to a maximum size, during initialization phase. (But how would >> you do that? Presence of any padding option over some given >> size?) >> >> As you probably know, the check is important to make sure that >> any LSP you send over the link will actually make it. It is not >> necessary that the MTU size be equal in both directions, so >> it wouldn't necessarily be a good idea to require the received >> IIH to match your own MTU size. While I suppose it's uncommon >> to have asymmetrical MTU sizes, it might be useful in certain >> situations, like ADSL. To add such a check would be to add a >> new restriction on the use of IS-IS. >> >> Regards, >> Jeff >> >> At 05:10 PM 5/31/00 -0400, you wrote: >> >> I think the idea was to make sure that whatever your idea of >> >> the MTU size is, that you can transmit a packet of that size >> >> without worrying about it being dropped by the link layer. >> >> If you're transmitting IIHs that are too large to be received >> >> at the other end, your data-link connection will go down and >> >> the adjacency will never come up. But this only works if the >> >> link is reliable (that is, if the link goes down if it can't >> >> deliver a packet). >> >> >> >> Jeff Learman Internet: jjl@one.com >> > >> >You could send padded packets on pt2pt until the adjacency comes up. >> >This makes no assumptions about the reliability of the link layer. >> > >> >- jeff parker >> >- Lucent Technology >> >> ____________________________________________________________________ >> >> 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 > >-- >Rick Han >Iron Bridge Networks, Inc. >rhan@ibnets.com >(781)372-8180 > > ____________________________________________________________________ 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 rsaluja@nortelnetworks.com Wed, 31 May 2000 18:58:16 -0400 Date: Wed, 31 May 2000 18:58:16 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] question on MTU IIH maximum size and LSP maximum size are two different things. IIH size should be at least equal to the maximum(dataLinkBlocksize (MTU),LSPBuffersize) -1 according to the spec. The LSP packet maximum size has really a global significance in an ISIS area and it should be set consistently by system management. LSP packets have to travel throughout the area. Also note that dataLinkBlocksize should always be greater than or equal to the maximum of the LSPBufferSize. So IMHO IIH size is nothing but dataLinkBlocksize - 1. Regards, Rajesh Micah Bartell wrote: > > Actually the IIH should be at least maxsize-1 octets. maxsize is the maximum of the three following values: > > 1. dataLinkBlocksize > 2. originatingL1LSPBufferSize > 3. originatingL2LSPBufferSize > > The reason for using maxsize-1 is any padding added needs to be at least 2 octets. So if the PDU length is maxsize-1 you can't add 2 octets, requiring that to be a valid size also. > > /mpb > > At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote: > >I think section 8.2.3 of ISO 10589 specifies that you use the appropriate > >L1 or L2 BufferSize, rather than the interface MTU. > > > >- jeff parker > >- Lucent Technology > > > > > > This is a big, bad, nasty problem. This case is NOT handled by > > > the protocol -- you aren't told what to do, and no matter what you > > > do, it's not good. It was discussed in detail at the SONET > > > Interoperability Forum, where we have the unlucky situation that > > > the SONET management channel (normally unused by you IP folks) > > > is specified to use an MTU size of 512 bytes, but the rest of > > > the natural world uses a size of 1500. > > > > > > Fortunately, there is a solution, which can be found in > > > > > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > > > > > I believe that this was submitted to ISO as a defect report or > > > technical corrigendum, but I don't know the current status. > > > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > > > are listening. > > > > > > Regards, > > > Jeff > > > > > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > > > >Suppose we have following setup: > > > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > > > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > > > R3 is 2k. If R1 > > > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > > > >following LSPs from R1, if they are in 4k packets? How does > > > R2 propagate > > > >them to R3? I guess that's why the adjacency between R1 and > > > R2 is supposed > > > >to be droped at the first place. But if we accept the > > > neighbor, then what > > > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > > > smaller LSP can go > > > >through to R3 but the bigger one get droped at the link. Now we have > > > >un-synchronized database over the domain. > > > > > > > >Rick > > > > > > > >Jeff Learman wrote: > > > >> > > > >> Jeff > > > >> > > > >> Good point -- that would solve the problem. This could be added > > > >> to the 3-way handshake RFC. It might be unnecessary, though, when > > > >> operating over links where the MTU is negotiated end-to-end > > > >> and IS-IS is using the result of that negotiation. > > > >> > > > >> Unfortunately, it wouldn't guarantee that you can receive big > > > >> packets from the other end, which might not implement the new > > > >> requirement. To do that, you'd have to check the size of the > > > >> neighbor's IIH and only accept it if it looks like it's padded > > > >> to a maximum size, during initialization phase. (But how would > > > >> you do that? Presence of any padding option over some given > > > >> size?) > > > >> > > > >> As you probably know, the check is important to make sure that > > > >> any LSP you send over the link will actually make it. It is not > > > >> necessary that the MTU size be equal in both directions, so > > > >> it wouldn't necessarily be a good idea to require the received > > > >> IIH to match your own MTU size. While I suppose it's uncommon > > > >> to have asymmetrical MTU sizes, it might be useful in certain > > > >> situations, like ADSL. To add such a check would be to add a > > > >> new restriction on the use of IS-IS. > > > >> > > > >> Regards, > > > >> Jeff > > > >> > > > >> At 05:10 PM 5/31/00 -0400, you wrote: > > > >> >> I think the idea was to make sure that whatever your idea of > > > >> >> the MTU size is, that you can transmit a packet of that size > > > >> >> without worrying about it being dropped by the link layer. > > > >> >> If you're transmitting IIHs that are too large to be received > > > >> >> at the other end, your data-link connection will go down and > > > >> >> the adjacency will never come up. But this only works if the > > > >> >> link is reliable (that is, if the link goes down if it can't > > > >> >> deliver a packet). > > > >> >> > > > >> >> Jeff Learman Internet: > > > jjl@one.com > > > >> > > > > >> >You could send padded packets on pt2pt until the > > > adjacency comes up. > > > >> >This makes no assumptions about the reliability of the link layer. > > > >> > > > > >> >- jeff parker > > > >> >- Lucent Technology > > > >> > > > >> > > > ____________________________________________________________________ > > > >> > > > >> 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 > > > > > > > >-- > > > >Rick Han > > > >Iron Bridge Networks, Inc. > > > >rhan@ibnets.com > > > >(781)372-8180 > > > > > > > > > > > ____________________________________________________________________ > > > > > > 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 > > > > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > -- > Micah Bartell, CCIE #5069 mbartell@cisco.com > Network Consulting Engineer, NSA Phone: 972.364.8829 > Cisco Systems, Inc Fax: 972.364.8829 > -- > The Network Works, No Excuses > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From ginsberg@pluris.com Wed, 31 May 2000 17:14:14 -0700 Date: Wed, 31 May 2000 17:14:14 -0700 From: Les Ginsberg ginsberg@pluris.com Subject: [Isis-wg] question on MTU (At the risk of belaboring a point...) dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of sending a padded IIH which is the maximum of the bunch is precisely to detect those misconfigurations where this is not the case. So if dataLinkBlockSize is NOT large enough, the adjacency presumably will never come up. Therefore stating that "So IMHO IIH size is nothing but dataLinkBlocksize - 1." is denying the possibility of a misconfiguration. I believe the original text in ISO 10589 8.2.3c is better, even if it rarely comes into play. Of course, given the global significance of originatingLxLSPBufferSize, this still does not guarantee consistency throughout the area/domain - hence the problem that occurs in SONET environments. Les > -----Original Message----- > From: Rajesh Saluja [mailto:rsaluja@nortelnetworks.com] > Sent: Wednesday, May 31, 2000 3:58 PM > To: Micah Bartell > Cc: Jeff Parker; Jeff Learman; rhan@ibnets.com; > isis-wg@external.juniper.net > Subject: Re: [Isis-wg] question on MTU > > > IIH maximum size and LSP maximum size are two different > things. IIH size > should be at least equal to the maximum(dataLinkBlocksize > (MTU),LSPBuffersize) -1 according to the spec. > The LSP packet maximum size has really a global significance > in an ISIS > area and it should be set consistently by system management. > LSP packets > have to travel throughout the area. > > Also note that dataLinkBlocksize should always be greater > than or equal > to the maximum of the LSPBufferSize. So IMHO IIH size is nothing but > dataLinkBlocksize - 1. > > Regards, > Rajesh > > Micah Bartell wrote: > > > > Actually the IIH should be at least maxsize-1 octets. > maxsize is the maximum of the three following values: > > > > 1. dataLinkBlocksize > > 2. originatingL1LSPBufferSize > > 3. originatingL2LSPBufferSize > > > > The reason for using maxsize-1 is any padding added needs > to be at least 2 octets. So if the PDU length is maxsize-1 > you can't add 2 octets, requiring that to be a valid size also. > > > > /mpb > > > > At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote: > > >I think section 8.2.3 of ISO 10589 specifies that you use > the appropriate > > >L1 or L2 BufferSize, rather than the interface MTU. > > > > > >- jeff parker > > >- Lucent Technology > > > > > > > > This is a big, bad, nasty problem. This case is NOT handled by > > > > the protocol -- you aren't told what to do, and no > matter what you > > > > do, it's not good. It was discussed in detail at the SONET > > > > Interoperability Forum, where we have the unlucky situation that > > > > the SONET management channel (normally unused by you IP folks) > > > > is specified to use an MTU size of 512 bytes, but the rest of > > > > the natural world uses a size of 1500. > > > > > > > > Fortunately, there is a solution, which can be found in > > > > > > > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > > > > > > > I believe that this was submitted to ISO as a defect report or > > > > technical corrigendum, but I don't know the current status. > > > > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > > > > are listening. > > > > > > > > Regards, > > > > Jeff > > > > > > > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > > > > >Suppose we have following setup: > > > > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > > > > > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > > > > R3 is 2k. If R1 > > > > >sends a HELLO padded to 4k and R2 accepts it. What > does R2 do to the > > > > >following LSPs from R1, if they are in 4k packets? How does > > > > R2 propagate > > > > >them to R3? I guess that's why the adjacency between R1 and > > > > R2 is supposed > > > > >to be droped at the first place. But if we accept the > > > > neighbor, then what > > > > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > > > > smaller LSP can go > > > > >through to R3 but the bigger one get droped at the > link. Now we have > > > > >un-synchronized database over the domain. > > > > > > > > > >Rick > > > > > > > > > >Jeff Learman wrote: > > > > >> > > > > >> Jeff > > > > >> > > > > >> Good point -- that would solve the problem. This > could be added > > > > >> to the 3-way handshake RFC. It might be > unnecessary, though, when > > > > >> operating over links where the MTU is negotiated end-to-end > > > > >> and IS-IS is using the result of that negotiation. > > > > >> > > > > >> Unfortunately, it wouldn't guarantee that you can receive big > > > > >> packets from the other end, which might not implement the new > > > > >> requirement. To do that, you'd have to check the size of the > > > > >> neighbor's IIH and only accept it if it looks like > it's padded > > > > >> to a maximum size, during initialization phase. > (But how would > > > > >> you do that? Presence of any padding option over some given > > > > >> size?) > > > > >> > > > > >> As you probably know, the check is important to make > sure that > > > > >> any LSP you send over the link will actually make > it. It is not > > > > >> necessary that the MTU size be equal in both directions, so > > > > >> it wouldn't necessarily be a good idea to require > the received > > > > >> IIH to match your own MTU size. While I suppose > it's uncommon > > > > >> to have asymmetrical MTU sizes, it might be useful in certain > > > > >> situations, like ADSL. To add such a check would be to add a > > > > >> new restriction on the use of IS-IS. > > > > >> > > > > >> Regards, > > > > >> Jeff > > > > >> > > > > >> At 05:10 PM 5/31/00 -0400, you wrote: > > > > >> >> I think the idea was to make sure that whatever > your idea of > > > > >> >> the MTU size is, that you can transmit a packet > of that size > > > > >> >> without worrying about it being dropped by the link layer. > > > > >> >> If you're transmitting IIHs that are too large to > be received > > > > >> >> at the other end, your data-link connection will > go down and > > > > >> >> the adjacency will never come up. But this only > works if the > > > > >> >> link is reliable (that is, if the link goes down > if it can't > > > > >> >> deliver a packet). > > > > >> >> > > > > >> >> Jeff Learman Internet: > > > > jjl@one.com > > > > >> > > > > > >> >You could send padded packets on pt2pt until the > > > > adjacency comes up. > > > > >> >This makes no assumptions about the reliability of > the link layer. > > > > >> > > > > > >> >- jeff parker > > > > >> >- Lucent Technology > > > > >> > > > > >> > > > > > ____________________________________________________________________ > > > > >> > > > > >> 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 > > > > > > > > > >-- > > > > >Rick Han > > > > >Iron Bridge Networks, Inc. > > > > >rhan@ibnets.com > > > > >(781)372-8180 > > > > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > 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 > > > > > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > -- > > Micah Bartell, CCIE #5069 mbartell@cisco.com > > Network Consulting Engineer, NSA Phone: 972.364.8829 > > Cisco Systems, Inc Fax: 972.364.8829 > > -- > > The Network Works, No Excuses > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From ginsberg@pluris.com Wed, 31 May 2000 20:39:27 -0700 Date: Wed, 31 May 2000 20:39:27 -0700 From: Les Ginsberg ginsberg@pluris.com Subject: [Isis-wg] question on MTU I agree - I think it would be a useful addition to the three way handshake RFC - send padded IIHs until the adjacency is in the UP state. I also agree that the receiving side should not check the size of the received IIH. In addition to solving the issue in cases where the "first" IIH was lost, it would eliminate wording in 10589 that has always been a bit confusing. The use of the term "first" IIH PDU was never unambiguous. It really meant the IIH sent as a result of receiving an ISH PDU and if for some strange reason multiple ISH PDUs were received then one was left to wonder how to resolve the designation of an IIH sent in response to receipt of an ISH which was not the "first". Much less ambiguous to say "an IIH should be padded if the adjacency is not in the UP state". Les > -----Original Message----- > From: Jeff Learman [mailto:jjl@one.com] > Sent: Wednesday, May 31, 2000 2:30 PM > To: Jeff Parker > Cc: isis-wg@external.juniper.net > Subject: RE: [Isis-wg] question on MTU > > > > Jeff > > Good point -- that would solve the problem. This could be added > to the 3-way handshake RFC. It might be unnecessary, though, when > operating over links where the MTU is negotiated end-to-end > and IS-IS is using the result of that negotiation. > > Unfortunately, it wouldn't guarantee that you can receive big > packets from the other end, which might not implement the new > requirement. To do that, you'd have to check the size of the > neighbor's IIH and only accept it if it looks like it's padded > to a maximum size, during initialization phase. (But how would > you do that? Presence of any padding option over some given > size?) > > As you probably know, the check is important to make sure that > any LSP you send over the link will actually make it. It is not > necessary that the MTU size be equal in both directions, so > it wouldn't necessarily be a good idea to require the received > IIH to match your own MTU size. While I suppose it's uncommon > to have asymmetrical MTU sizes, it might be useful in certain > situations, like ADSL. To add such a check would be to add a > new restriction on the use of IS-IS. > > Regards, > Jeff > > At 05:10 PM 5/31/00 -0400, you wrote: > >> I think the idea was to make sure that whatever your idea of > >> the MTU size is, that you can transmit a packet of that size > >> without worrying about it being dropped by the link layer. > >> If you're transmitting IIHs that are too large to be received > >> at the other end, your data-link connection will go down and > >> the adjacency will never come up. But this only works if the > >> link is reliable (that is, if the link goes down if it can't > >> deliver a packet). > >> > >> Jeff Learman Internet: jjl@one.com > > > >You could send padded packets on pt2pt until the adjacency > comes up. > >This makes no assumptions about the reliability of the link layer. > > > >- jeff parker > >- Lucent Technology > > ____________________________________________________________________ > > 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 rsaluja@nortelnetworks.com Wed, 31 May 2000 23:49:38 -0400 Date: Wed, 31 May 2000 23:49:38 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] question on MTU Les Ginsberg wrote: > > (At the risk of belaboring a point...) > > dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of > sending a padded IIH which is the maximum of the bunch is precisely to > detect those misconfigurations where this is not the case. So if > dataLinkBlockSize is NOT large enough, the adjacency presumably will never > come up. Therefore stating that > > "So IMHO IIH size is nothing but dataLinkBlocksize - 1." > > is denying the possibility of a misconfiguration. Yes, I should say that if you impose the requirement ( dataLinkBlocksize >= Buffersize ), then IIH size = dataLinkBlocksize - 1. The reason why it is not possible to enforce this requirement in explained in ISO 10589 section 8.2.3c. But I was wondering if this mechanism on P2P link could result in one way adjacency if you do not implement three way handshake mechanism. Consider IS A and IS B connected by P2P link. Suppose P2P link MTU size = X A - Buffersize = Y B - Buffersize = Z ( misconfiguration ) where Y < X < Z A will send padded Hello with size max(X,Y) i.e. X - 1. When B receives, it is going to accept this packet. Right? ( I do not see any check on the padded hello size at the receive end ). So B will make adjacency A UP ( if you do not implement three way handshake ) B will send padded Hello with size max(X,Z) i.e. Z-1 but it can not be delivered becuase DataLinkBlockSize is less. A will never receive Hello packet from B. So you end up with one-way adjacency. ( an example of link failing in one direction ? ) Please correct me if I am missing anything. Thanks, Rajesh From jjl@one.com Thu, 01 Jun 2000 10:10:05 -0400 Date: Thu, 01 Jun 2000 10:10:05 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] question on MTU Rajesh, You are correct -- you can get a persistent one-way adjacency. At the risk of sounding like a broken record, let me note that this wouldn't happen when operating IS-IS as it was designed to operate, over reliable p2p links. Fortunately, thanks to the "robustness check" for two-way connectivity, this isn't a problem unless there are multiple links between systems. In this case, if you were so unlucky as to have the same problem in different directions on two links, you would have a black hole. Of course, the 3-way handshake solves the problem. Thanks to Les, Jeff, and Dave for detecting my mistake about a 4K link not causing the "inconsistent LSP buffer size" problem. I also agree with Micah Bartell -- the IIH should be AT LEAST maxsize - 1. It's better to make it maxsize unless you simply can't because of the size of your IIH ending at maxsize - 1. (That's assuming you think the check is worthwhile at all.) Concerning what Dave Katz says about the unfortunate choice of SONET using a 512-byte MTU size, I completely agree that this was a particularly bad choice by Bellcore. Actually, this is not a media limitation, simply a poor choice of the default for a LAPD parameter. However, the IS-IS spec does not prohibit the use of smaller MTU sizes; it is certainly possible to use a consistently small LSP buffer size in a subdomain. IS-IS is flawed in that it does not properly address what should be done when the LSP buffer size is inconsistent. The good news is that, as Dave and Les point out, it isn't a problem unless you use an MTU size smaller than 1492. And Rajesh is correct that a link-by-link check is not sufficient to guarantee the end-to-end requirement for passing LSPs. The fact that maxsize is limited by LSP buffer size indicates that it's a check for passing LSPs and not a true MTU size check (which is better to do using LCP's MRU configuration option, and has nothing to do with routes anyway). This means that the IIH padding doesn't really serve any purpose, as Dave points out. I still agree with Les and Jeff that, if you're going to send padded IIHs, it's best to continue doing it until the adjacency goes into the UP state. But sending padded IIHs could be made optional if the MTU size is negotiated. And I take back my suggestion about checking the size on received IIHs! Bad idea! Regards, Jeff At 11:49 PM 5/31/00 -0400, Rajesh Saluja wrote: > > >Les Ginsberg wrote: >> >> (At the risk of belaboring a point...) >> >> dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of >> sending a padded IIH which is the maximum of the bunch is precisely to >> detect those misconfigurations where this is not the case. So if >> dataLinkBlockSize is NOT large enough, the adjacency presumably will never >> come up. Therefore stating that >> >> "So IMHO IIH size is nothing but dataLinkBlocksize - 1." >> >> is denying the possibility of a misconfiguration. > >Yes, I should say that if you impose the requirement ( dataLinkBlocksize >>= Buffersize ), then IIH size = dataLinkBlocksize - 1. >The reason why it is not possible to enforce this requirement in >explained in ISO 10589 section 8.2.3c. > >But I was wondering if this mechanism on P2P link could result in one >way adjacency if you do not implement three way handshake mechanism. > >Consider IS A and IS B connected by P2P link. >Suppose P2P link MTU size = X >A - Buffersize = Y >B - Buffersize = Z ( misconfiguration ) >where Y < X < Z > >A will send padded Hello with size max(X,Y) i.e. X - 1. >When B receives, it is going to accept this packet. Right? ( I do not >see any check on the padded hello size at the receive end ). >So B will make adjacency A UP ( if you do not implement three way >handshake ) > >B will send padded Hello with size max(X,Z) i.e. Z-1 but it can not be >delivered becuase DataLinkBlockSize is less. A will never receive Hello >packet from B. >So you end up with one-way adjacency. ( an example of link failing in >one direction ? ) > >Please correct me if I am missing anything. > >Thanks, >Rajesh > > ____________________________________________________________________ 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 selvarajr@future.futsoft.com Fri, 2 Jun 2000 08:00:32 +0530 Date: Fri, 2 Jun 2000 08:00:32 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt regarding LSP IP Address TLV ------ =_NextPart_000_01BFCC68.A123B440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit LSP includes one or more IP Addresses of the interfaces. (for encapsulation or transmission of n/w Mgmt pkts). I suppose it need not include all the IP addresses of the interfaces. How these IP Address(s) chosen? What may be selection criteria ? SELVA ------ =_NextPart_000_01BFCC68.A123B440 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiICAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAJAAAAERvdWJ0IHJlZ2FyZGluZyBMU1AgSVAgQWRkcmVzcyBUTFYgALUL AQWAAwAOAAAA0AcGAAIACAAAACAABQAMAQEggAMADgAAANAHBgACAAcANwA3AAUAWQEBCYABACEA AABERThCMjJFNzVBMzhENDExQTg1ODAwMjAzNTFGOTJBMAABBwEDkAYAsAQAACAAAAALAAIAAQAA AAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMANgAAAAAAQAA5AGCLZoY6zL8BHgBwAAEAAAAkAAAA RG91YnQgcmVnYXJkaW5nIExTUCBJUCBBZGRyZXNzIFRMViAAAgFxAAEAAAAWAAAAAb/MOoZV5yKL 4zhaEdSoWAAgNR+SoAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAAB0AAABzZWx2YXJhanJA ZnV0dXJlLmZ1dHNvZnQuY29tAAAAAAMABhDMh61rAwAHEM4AAAAeAAgQAQAAAGUAAABMU1BJTkNM VURFU09ORU9STU9SRUlQQUREUkVTU0VTT0ZUSEVJTlRFUkZBQ0VTKEZPUkVOQ0FQU1VMQVRJT05P UlRSQU5TTUlTU0lPTk9GTi9XTUdNVFBLVFMpSVNVUFBPU0VJAAAAAAIBCRABAAAAhwEAAIMBAABJ AgAATFpGdSlvLukDAAoAcmNwZzEyNRYyAPgLYG4OEDAzM50B9yACpAPjAgBjaArA4HNldDAgBxMC gwBQ8RB2cHJxDlAQ7wHxEvFDA2MTCUJvb2sDgk+EbGQGAHR5bGUCg8YzAuMTCVRhaANxAoDyfQqB dWMAUAsDC7YKsTMKhAswbGkBwRIBIEzoU1AgC4BjCkABAAQgPQIgZRvABcAEYAlwIElxGyBBZGQJ cAQQG6JmWCB0aBvwC4B0BJBm4wDQB5AuICgCEAXACfAgY2Fwc3ULYHRp0wIgHAJ0cgBxbQQBH4MS Zhm0bi8H4E1nbUEFQHBrdHMpHnBJ4iAfMHBwbxEwGzAFQLcb4AmAIwBvBUAbRSAHQPcDIB2SHJFh HN8d6Bm4GfbiZhqCIEhvB+AdkSKxNRyYKCIAIBMgIqFuPxwgVxMwBUAAwHkgYvcb8BEwFnBjH3MF AR3xBzD8ID8ZuicKGasAoBRABgBwRUxWQQxAAtEW4XNcMTYszRl4GHEAMYAAAwAQEAAAAAADABEQ AAAAAAMAgBD/////QAAHMMCnK+E5zL8BQAAIMMCnK+E5zL8BCwAAgAggBgAAAAAAwAAAAAAAAEYA AAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAIIAYAAAAAAMAA AAAAAABGAAAAAFKFAADzFQAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAAeAAiACCAG AAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAAAAsACYAIIAYAAAAAAMAAAAAAAABG AAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAAuACCAGAAAAAADA AAAAAAAARgAAAAAYhQAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAA AAAeAA2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAOgAggBgAAAAAAwAAA AAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAAAQAAAAAAAAADAA00/TcAAGrs ------ =_NextPart_000_01BFCC68.A123B440-- From chopps@djinesys.com Mon, 5 Jun 2000 01:56:50 -0400 Date: Mon, 5 Jun 2000 01:56:50 -0400 From: Christian E. Hopps chopps@djinesys.com Subject: [Isis-wg] attached bit I was looking at ``Technical Corrigendum 1'' to 10589.. and I noticed that it changes when an IS should consider itself attached. It adds the condition that if the IS has at least one active reachable address prefix it should consider itself attached. What is the intention of the change to 10589? My initial thought is since the reachability won't be advertised into level 1 the level 1-2 router sets ATT to attract traffic to itself. I suspect I may be missing something though since this change would seem to blackhole things. In any case what is the analogous situation in IP? Would it be: if the IS is announcing any external IP reachability. ? If so thats easy enough but things get more interesting in light of the domain wide draft. For example, domainwide mentions how people have allowed external reachability to be announced into level 1, in which case I think that you would not set the ATT bit. Also, if you are leaking level 2 reachability into level 1 there too I don't think setting ATT would be appropriate. I would appreciate any clarification people can offer. Thanks, Chris. From henk@Procket.com Mon, 5 Jun 2000 15:34:05 +0200 (MEST) Date: Mon, 5 Jun 2000 15:34:05 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] attached bit Hi Chris, > I was looking at ``Technical Corrigendum 1'' to 10589.. and I noticed > that it changes when an IS should consider itself attached. > > It adds the condition that if the IS has at least one active > reachable address prefix it should consider itself attached. > > What is the intention of the change to 10589? My initial thought > is since the reachability won't be advertised into level 1 > the level 1-2 router sets ATT to attract traffic to itself. As usual, attracting traffic is the reason to set the ATT bit. > I suspect I may be missing something though since this change > would seem to blackhole things. The paragraph in the corrigendum seems to explain it. The old rule was: set ATT if you see other areas in your domain. The problem is, what do you do if your area is the only area in your domain ? If there is only one area in the domain, the routers in that area will never see other areas, and thus were never allowed to set the ATT bit. If your domain is connected to other domains, at least one L1L2 router should forward traffic from L1-only routers to the other domain. With the old spec that wouldn't happen, because the L1L2 router wasn't allowed to set the ATT bit. The corrigendum adds explanation that a L1L2 router is allowed to set ATT if it sees either: 1) other areas in its own domain, or 2) sees other domains. > In any case what is the analogous situation in IP? > Would it be: > > if the IS is announcing any external IP reachability. > > ? I think the rule is the same: set ATT if you are connected to either 1) other areas, or 2) other domains. How to determine if you are connected to another area or domain is kinda implementation specific, I am afraid. Esp for IP, as IP addressing is not strictly hierarchical. > If so thats easy enough but things get more interesting in light of > the domain wide draft. For example, domainwide mentions how people > have allowed external reachability to be announced into level 1, > in which case I think that you would not set the ATT bit. Agreed. If you leak specific prefixes into L1, you attact traffic for for those destinations. IMHO there is no need to also set the ATT bit. Unless you leak only a few external prefixes, and don't leak all external prefixes. > Also, if > you are leaking level 2 reachability into level 1 there too I don't > think setting ATT would be appropriate. Agreed again. > I would appreciate any clarification people can offer. I think a L1L2 router should set the ATT bit if it can forward traffic to destinations outside of the L1 area, and those destinations are not explicitely known by L1-only routers. Hope this helps, Henk. From cwk@verio.net Mon, 5 Jun 2000 15:23:04 -0500 Date: Mon, 5 Jun 2000 15:23:04 -0500 From: Carl W. Kalbfleisch cwk@verio.net Subject: [Isis-wg] Agenda for Pittsburgh ... Will there be any discussion of the MIB for ISIS? Carl > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Tony Przygienda > Sent: Tuesday, May 30, 2000 11:03 PM > To: isis-wg@external.juniper.net > Subject: [Isis-wg] Agenda for Pittsburgh ... > > > it's time to start to gather the agenda (beside the last calls > and new draft versions) for Pittsburgh. Requests for slots pls > to me or Tony Li > > -- tony > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From chopps@djinesys.com Sun, 11 Jun 2000 11:51:03 -0400 Date: Sun, 11 Jun 2000 11:51:03 -0400 From: Christian E. Hopps chopps@djinesys.com Subject: [Isis-wg] too many segments I'm curious what the standard way to deal with overflowing 255 LSP segments for an IS is. At first I was tempted to use the overload state, but this doesn't strike me as fitting well in its definition. (e.g., how do you report which LSP caused the overload when there is no LSP). Also overflowing 255 segments is a gross misconfiguration error which the overload state doesn't appear to be directly intended for (given that it waits some time and then switches back to normal). Its pretty easy to overflow the LSP by redistributing e.g., BGP into ISIS. Even if it doesn't overflow the IS LSPs itself you can then get into trouble at the level 1/level 2 boundary when summarization occurs. I'm curious what other implementations do in this situation. Thanks for any help, Chris. From tli@Procket.com Sun, 11 Jun 2000 10:24:12 -0700 (PDT) Date: Sun, 11 Jun 2000 10:24:12 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] too many segments | I'm curious what the standard way to deal with overflowing 255 LSP | segments for an IS is. At first I was tempted to use the overload | state, but this doesn't strike me as fitting well in its definition. | (e.g., how do you report which LSP caused the overload when there | is no LSP). Also overflowing 255 segments is a gross misconfiguration | error which the overload state doesn't appear to be directly intended | for (given that it waits some time and then switches back to normal). | | Its pretty easy to overflow the LSP by redistributing e.g., BGP | into ISIS. Even if it doesn't overflow the IS LSPs itself you can | then get into trouble at the level 1/level 2 boundary when summarization | occurs. | | I'm curious what other implementations do in this situation. Chris, There is no "standard" way of dealing with this problem. The most commonly suggested local hack for dealing with this, if one intentionally wants to generate more segments, is to have the administrator manually allocate another system ID. You then establish a zero cost adjacency between your primary system ID and your secondary. We discussed this at length back when we were discussing more than 255 adjacencies, tho the driver there was the ability to have more pseudo-node numbers. The same mechanism gives you more space to play in as well... As to the accidental overflow, the simplest mechanism is: don't. ;-) Tony From Radia.Perlman@East.Sun.COM Sun, 11 Jun 2000 21:35:54 -0400 (EDT) Date: Sun, 11 Jun 2000 21:35:54 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] too many segments The 1 byte fragment number is a field that in retrospect should have been larger. As Toni Li pointed out, it should be possible to get around it with the hack of pretending to be two (or more) nodes with zero cost between them, and have part of the information reported by each one. Do people actually do this? Do all implementations calculate correctly when they see this? Does the Dijkstra calculation do anything weird with 0-cost adjacencies? (It should work, but I wouldn't be surprised if some implementations got very confused.) Certainly it has nothing to do with overflow state if a router has more information to report than fits into 255 fragments. If this really is a big problem, it would probably be possible to change the size of the field, but it's tricky to do it in a way without flag days, or in a way that would work if someone accidentally plugs in a router that doesn't know about it. Radia From tli@Procket.com Sun, 11 Jun 2000 22:11:14 -0700 (PDT) Date: Sun, 11 Jun 2000 22:11:14 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] too many segments | The 1 byte fragment number is a field that in retrospect should have | been larger. As Toni Li pointed out, it should be possible to get around | it with the hack of pretending to be two (or more) nodes with zero cost | between them, and have part of the information reported by each one. | Do people actually do this? Do all implementations calculate correctly | when they see this? Does the Dijkstra calculation do anything weird | with 0-cost adjacencies? (It should work, but I wouldn't be surprised | if some implementations got very confused.) As a pseudo-node adjacency is already at zero cost, there's a fairly high chance that this will work in all implementations. And given that the predominant implementations have a fairly restricted set of authors, who are reasonably general, there's an excellent chance that it Just Works. Tony From mshand@cisco.com Mon, 12 Jun 2000 11:10:32 +0100 Date: Mon, 12 Jun 2000 11:10:32 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] too many segments At 22:11 11/06/2000 -0700, Tony Li wrote: >As a pseudo-node adjacency is already at zero cost, there's a fairly high >chance that this will work in all implementations. And given that the >predominant implementations have a fairly restricted set of authors, who >are reasonably general, there's an excellent chance that it Just Works. Yes, the thing about the pseudonode is that it is carefully crafted such that the zero cost is only in one direction. Dijkstra's algorithm can get upset if the set of LSPs contains a loop who's cost sum is zero. This is avoided in the pseudonode case, but here we would want to have zero cost in BOTH directions (not least, to satisfy the two way check). Its not clear that all implementations would necessarily take kindly to that. The other thing about the zero cost links in pseudonodes, is that you are supposed to give priority to selecting pseudonode LSPs from TENT where there are non-pseudonode LSPs present at equal cost. If we didn't do this and there were equal cost paths one of which was a direct link and the other through the pseudonode, we could fail to detect the path through the pseudonode, because the destination node would already have been added to PATHs and we can't (don't) increment the adjacency set of node already on PATHS. At least I think that was the rationale. So if we have zero cost links which aren't in pseudonodes we might upset an implementation which was doing this (as it is supposed to) on the basis of the LSP being a pseudonode rather than the more general property that it carried zero cost links. Mike Mike From Radia.Perlman@East.Sun.COM Mon, 12 Jun 2000 11:22:49 -0400 (EDT) Date: Mon, 12 Jun 2000 11:22:49 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] too many segments Mike, I didn't quite understand your paragraph >>>we could fail to detect the path through the >>>pseudonode, because the destination node would already have been added to >>>PATHs and we can't (don't) increment the adjacency set of node already on >>>PATHS. But as for your worry about having zero cost loops, I'd think you wouldn't need to have the cost be zero in both directions. For instance, suppose the node that has too much LSP information to fit into 255 fragments is named "A". So A invents new nodes A', A'', A'''. A adds neighbors A', A'', and A''' to its LSP as neighbors with zero cost. A also creates LSPs from A', A'', and A''' with the excess LSP info that didn't fit into the LSP for A, and also each with neighbor A with reasonably large, but finite cost. Would that work, and then eliminate any possible implementation confusion with zero cost loops? Radya ;-) From mshand@cisco.com Mon, 12 Jun 2000 16:38:21 +0100 Date: Mon, 12 Jun 2000 16:38:21 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] too many segments At 11:22 12/06/2000 -0400, Radia Perlman - Boston Center for Networking wrote: >But as for your worry about having zero cost loops, I'd think you wouldn't >need to have the cost be zero in both directions. For instance, suppose >the node that has too much LSP information to fit into 255 >fragments is named "A". So A invents new nodes A', >A'', A'''. A adds neighbors A', A'', and A''' to its LSP as neighbors with >zero cost. A also creates LSPs from A', A'', and A''' with the excess LSP >info that didn't fit into the LSP for A, and also each with neighbor A with >reasonably large, but finite cost. > >Would that work, and then eliminate any possible implementation confusion >with zero cost loops? I don't think that works in all cases. If the information in A', A'' etc's LSPs are just leaf information, then its fine, but if you had lots of genuine router adjacencies, then I think the two way connectivity check gets you. A' has links to B,C etc. These are real costs. But if we have links from B to A', C to A', then you end up needing to use the A' to A link to compute a route through A. You can't do the obvious thing of making B link directly to A, since then the two way check would get you since there was no link from A to B. Am I making any sense? I admit that the most likely reason for LSP size explosion is lots of imported routes, for which your solution would work fine. Mike From Radia.Perlman@East.Sun.COM Mon, 12 Jun 2000 12:10:42 -0400 (EDT) Date: Mon, 12 Jun 2000 12:10:42 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] too many segments Mike, Your point about the genuine router links is correct...but as you also point out, there is no problem with the assymetric costs (nonzero cost when fake nodes point to the real node) when it's for lots of imported routes. So the rule should be explicit about what information is allowed to hang off fake nodes (only leaf information). Would anyone ever need more than 255 fragments' worth of router neighbor information? (for instance, a really humongous "LAN" with thousands of attached routers). Radia From m1lu@yahoo.com Mon, 12 Jun 2000 09:23:07 -0700 (PDT) Date: Mon, 12 Jun 2000 09:23:07 -0700 (PDT) From: newbie m1lu@yahoo.com Subject: [Isis-wg] RFC 1195 post script version Hi: Could anyone here tell me where I acn find the post script version of RFC 1195? TIA _ming __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com From tli@Procket.com Mon, 12 Jun 2000 10:15:01 -0700 (PDT) Date: Mon, 12 Jun 2000 10:15:01 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] too many segments | Would anyone ever need more than 255 fragments' worth of router neighbor | information? (for instance, a really humongous "LAN" with thousands of | attached routers). Possibly. But the aforementioned solution for creation of additional sysids would apply. The question then degenerates into: do you ever need more than 255 fragments to describe the adjacencies for a single interface? At current technology levels, I bet one can't support the IIH traffic necessary to do this. Tony From m1lu@yahoo.com Mon, 12 Jun 2000 13:59:50 -0700 (PDT) Date: Mon, 12 Jun 2000 13:59:50 -0700 (PDT) From: newbie m1lu@yahoo.com Subject: [Isis-wg] router ID for IS-IS Hi: What does IS-IS use for router ID? NSAP's systme ID? most of vendor uses MAC address for NSAP system ID, but what about there is no ethernet card in the router? what is the role of loopback address in the IS-IS? thanks __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com From rsaluja@nortelnetworks.com Mon, 12 Jun 2000 17:45:25 -0400 Date: Mon, 12 Jun 2000 17:45:25 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] router ID for IS-IS newbie wrote: > > Hi: > > What does IS-IS use for router ID? NSAP's systme ID? > most of vendor uses MAC address for NSAP system ID, > but what about there is no ethernet card in the > router? what is the role of loopback address in the > IS-IS? It need not be MAC address. It is basically 1 to 8 octets long value ( almost all implementations use 6 octets ) which should be unique in a routing domain. People use loopback address so as to have reachability to a router till there is at least one physical interface to reach the router. ( eg : in BGP next hop ). IS-IS treats loopback address as just another reachability information. Hope it helps. Regards, Rajesh From jparker@nexabit.com Mon, 12 Jun 2000 18:34:38 -0400 Date: Mon, 12 Jun 2000 18:34:38 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] router ID for IS-IS > What does IS-IS use for router ID? If you use the same router ID that BGP and OSPF use, then you may be able to share some information between the protocols. This doesn't really answer your question, but does suggest that you define some answer common to all protocols you support. - jeff parker - Lucent From rsaluja@nortelnetworks.com Mon, 12 Jun 2000 21:41:27 -0400 Date: Mon, 12 Jun 2000 21:41:27 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] router ID for IS-IS Jeff Parker wrote: > If you use the same router ID that BGP and OSPF > use, then you may be able to share some information > between the protocols. > > This doesn't really answer your question, but > does suggest that you define some answer > common to all protocols you support. Jeff, I was wondering if anybody uses ISIS router ID ( which is 1 to 8 bytes long ) same as BGP router ID ( which is 4 bytes long )? The same router ID for BGP and OSPF is very helpful when you import routes from BGP into OSPF routing domain. I am not sure if anybody distributes BGP routes into IISIS domain in the field? Regards, Rajesh From tli@Procket.com Mon, 12 Jun 2000 19:21:46 -0700 (PDT) Date: Mon, 12 Jun 2000 19:21:46 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] router ID for IS-IS | I was wondering if anybody uses ISIS router ID ( which is 1 to 8 bytes | long ) same as BGP router ID ( which is 4 bytes long )? The same router | ID for BGP and OSPF is very helpful when you import routes from BGP into | OSPF routing domain. Many people do this, but not in the obvious way. They take the IP router ID and convert it into Binary Coded Decimal, concatenate it and then use those resulting 6 bytes as the system id. For example: router id 1.2.3.4 => 001.002.003.004 | V 0x001002003004 | V 0x00 0x10 0x02 0x00 0x30 0x04 Ugly, eh? | I am not sure if anybody distributes BGP routes into IISIS domain in the | field? This turns out to be a very bad idea, in so very many ways. Tony From danny@tcb.net Mon, 12 Jun 2000 20:39:42 -0600 Date: Mon, 12 Jun 2000 20:39:42 -0600 From: Danny McPherson danny@tcb.net Subject: [Isis-wg] router ID for IS-IS > I was wondering if anybody uses ISIS router ID ( which is 1 to 8 bytes > long ) same as BGP router ID ( which is 4 bytes long )? While it could be 1-8 octets in length, nobody ever uses anything other than 6 octets for sysid. > The same router > ID for BGP and OSPF is very helpful when you import routes from BGP into > OSPF routing domain. I am not sure if anybody distributes BGP routes > into IISIS domain in the field? Usually not intentionally, and even if unintentionally, not for very long ;-) A common practice is for service providers to map the loopback IP address of the router to the sysid (4 octets -> 6 octets, padded), this eases management overhead, especially when using automated tools. For example, a router with a IP loopback address of 192.168.56.1 would have a sysid value of 1921.6805.6001. Though this is a bit more intuitive, it's little more. -danny From jparker@nexabit.com Tue, 13 Jun 2000 09:20:04 -0400 Date: Tue, 13 Jun 2000 09:20:04 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] router ID for IS-IS > I was wondering if anybody uses ISIS router ID ( which is > 1 to 8 bytes long ) same as BGP router ID ( which is 4 bytes > long )? Sorry that I continued this confussion. There are two IDs at issue here: the 6 byte System ID, and the 4 byte Router ID used, for example, in Traffic Engineering. I think mostt of the posts on this thread were really about the System ID: I confused things by talking reading the words, rather than the intent of the posting. - jeff parker - Lucent Technology From Radia.Perlman@East.Sun.COM Tue, 13 Jun 2000 11:00:46 -0400 (EDT) Date: Tue, 13 Jun 2000 11:00:46 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] router ID for IS-IS I never thought the variable length system ID was a good idea. Just one of these design by committee things added trying to be fancy, at the expense of ugliness and little or no functionality. Especially since it's the kind of thing that can cause serious problems if anyone really did try to make routers use different sizes. It might be nice someday to rewrite the spec and take out things like that. Radia From m1lu@yahoo.com Tue, 13 Jun 2000 08:55:10 -0700 (PDT) Date: Tue, 13 Jun 2000 08:55:10 -0700 (PDT) From: newbie m1lu@yahoo.com Subject: [Isis-wg] router ID for IS-IS The role of IS-IS is the same as OSPF. If someone wants to redistribute BGP routes into OSPF, then there will be some cases one wants to redistribute BGP into IS-IS. -newbie --- Rajesh Saluja wrote: > > Jeff Parker wrote: > > > If you use the same router ID that BGP and OSPF > > use, then you may be able to share some > information > > between the protocols. > > > > This doesn't really answer your question, but > > does suggest that you define some answer > > common to all protocols you support. > > Jeff, > I was wondering if anybody uses ISIS router ID ( > which is 1 to 8 bytes > long ) same as BGP router ID ( which is 4 bytes long > )? The same router > ID for BGP and OSPF is very helpful when you import > routes from BGP into > OSPF routing domain. I am not sure if anybody > distributes BGP routes > into IISIS domain in the field? > > Regards, > Rajesh > > _______________________________________________ > Isis-wg mailing list - > Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com From mcr@solidum.com Wed, 14 Jun 2000 15:02:50 -0400 Date: Wed, 14 Jun 2000 15:02:50 -0400 From: Michael Richardson mcr@solidum.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: >> It's never been the point of any of this discussion to deprecate the >> notion that authentication is useful -- the issue is whether it makes >> sense to retain AH when ESP does the job with significantly less >> hassle. Michael> What keeps nagging at me is the overhead of both AH and ESP, not Michael> to mention the added complexity. If two routers need privacy and authenticity, they can use end-to-end ESP, as they can get strong origin authentication by virtue of the integrity check succeeding in the ESP. Don't trust the source IP, rather take the appropriate source IP from the SA to look up the appropriate PCB for the TCP/UDP session you are protecting. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From pkoning@xedia.com Wed, 14 Jun 2000 09:33:05 -0400 (EDT) Date: Wed, 14 Jun 2000 09:33:05 -0400 (EDT) From: Paul Koning pkoning@xedia.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Waters," == Waters, Stephen writes: Waters,> There has been some discussion recently on the possible Waters,> deprecation of the Authentication Header defined for Waters,> 'whole-packet' authentication. Waters,> I 'think' the decision was to leave it alone, and allow AH Waters,> to wait for its day. >> From reading the various, associated methods of securing ISIS, >> OSPF and Waters,> RIPV2 messages, it seems to me that AH is perfect for the Waters,> protection of these protocols. Waters,> The current HMAC-MD5 options have the following exposures Waters,> that are solved with AH: Waters,> 1) no source address authentication (IP header Waters,> authentication in general) 2) poor/no replay protection 3) Waters,> manual keys - which restricts key length and complexity to Waters,> human-manageable keys, and makes for difficult key change Waters,> procedures. Waters,> IPSEC+AH would seem to be a good choice for all control Waters,> traffic exchange between routers. If this exchange is Waters,> confidential, the ESP could be used as well. Yes, but if it's not confidential (which is the likely case) then ESP in authentication only mode will serve just as well. It's never been the point of any of this discussion to deprecate the notion that authentication is useful -- the issue is whether it makes sense to retain AH when ESP does the job with significantly less hassle. paul From mcr@solidum.com Wed, 14 Jun 2000 16:22:37 -0400 Date: Wed, 14 Jun 2000 16:22:37 -0400 From: Michael Richardson mcr@solidum.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Michael" == Michael Thomas writes: Michael> Maybe you're misunderstanding me: if ESP had a bit which said Michael> "I'm protecting the outside headers too", it could be either Michael> signaled or potentially even done on an as-needed basis by the Michael> IPsec stack for IP headers which would otherwise require AH. I'm Michael> all for not protecting things that don't need protection Michael> otherwise. The point that Steve Bellovin keeps making, and which he has written about, is that AH does not provide much more in the way of authentication that ESP does not (at least for IPv4). The outer headers are all either irrelevant, or can be derived from the SPD, so you don't have to trust them. I believe that there are other things that AH provides (like the guarantee that the contents are not encrypted and therefore can be audited), and things that will be defined in IPv6-extension land that will make AH a useful thing to keep in the spec, just not MUST it. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From pkoning@xedia.com Wed, 14 Jun 2000 14:19:19 -0400 (EDT) Date: Wed, 14 Jun 2000 14:19:19 -0400 (EDT) From: Paul Koning pkoning@xedia.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Ben" == Ben McCann writes: Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? Ben> Aren't your goals met by using ESP _tunnel_ mode? Just tunnel Ben> the OSPF, RIP, etc, packet from one box to the other. The Ben> tunneled packet has an inner IP header is completely secured by Ben> ESP. This is the header seen by OSPF, RIP, etc, once ESP Ben> completes the authentication of the packet. That certainly does the job. The trouble appears if someone wants to use transport mode (perhaps to save a few bytes) and then decides that for some reason there are IP headers worthy of protection. That's where the messy hybrid (AH) appears. paul From bmccann@indusriver.com Wed, 14 Jun 2000 14:07:16 -0400 Date: Wed, 14 Jun 2000 14:07:16 -0400 From: Ben McCann bmccann@indusriver.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit > Michael> This might be water well under the bridge, but has the > Michael> thought of having a mode to ESP which protects the outer > Michael> headers? Aren't your goals met by using ESP _tunnel_ mode? Just tunnel the OSPF, RIP, etc, packet from one box to the other. The tunneled packet has an inner IP header is completely secured by ESP. This is the header seen by OSPF, RIP, etc, once ESP completes the authentication of the packet. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From mat@cisco.com Wed, 14 Jun 2000 10:20:06 -0700 (PDT) Date: Wed, 14 Jun 2000 10:20:06 -0700 (PDT) From: Michael Thomas mat@cisco.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Paul Koning writes: > Michael> What keeps nagging at me is the overhead of both AH and ESP, > Michael> not to mention the added complexity. > > Michael> This might be water well under the bridge, but has the > Michael> thought of having a mode to ESP which protects the outer > Michael> headers? > > That's no help, because that is exactly the difference that makes AH > so much harder than ESP. (Well, there's details like having the MAC > in the header rather than the trailer. Then again, ESP puts the > NextHeader value in the wrong place, so they're even...) > > The reason I like ESP authentication is precisely the fact that it > doesn't contain all the hair needed to protect a subset of IP header > fields. Maybe you're misunderstanding me: if ESP had a bit which said "I'm protecting the outside headers too", it could be either signaled or potentially even done on an as-needed basis by the IPsec stack for IP headers which would otherwise require AH. I'm all for not protecting things that don't need protection otherwise. Mike From mat@cisco.com Wed, 14 Jun 2000 08:29:41 -0700 (PDT) Date: Wed, 14 Jun 2000 08:29:41 -0700 (PDT) From: Michael Thomas mat@cisco.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Paul Koning writes: > It's never been the point of any of this discussion to deprecate the > notion that authentication is useful -- the issue is whether it makes > sense to retain AH when ESP does the job with significantly less > hassle. What keeps nagging at me is the overhead of both AH and ESP, not to mention the added complexity. This might be water well under the bridge, but has the thought of having a mode to ESP which protects the outer headers? I know that's contrary to the "encapsulating" part, but if we want to converge on one crypto header, it seems to me that placing an artificial restriction that outside headers can never be protected is pretty arbitrary and wrongheaded (even though I'm persuaded by Steve Bellovin's arguments about v4 headers). Mike From pkoning@xedia.com Wed, 14 Jun 2000 13:03:43 -0400 (EDT) Date: Wed, 14 Jun 2000 13:03:43 -0400 (EDT) From: Paul Koning pkoning@xedia.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: >> It's never been the point of any of this discussion to deprecate >> the notion that authentication is useful -- the issue is whether >> it makes sense to retain AH when ESP does the job with >> significantly less hassle. Michael> What keeps nagging at me is the overhead of both AH and ESP, Michael> not to mention the added complexity. Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? That's no help, because that is exactly the difference that makes AH so much harder than ESP. (Well, there's details like having the MAC in the header rather than the trailer. Then again, ESP puts the NextHeader value in the wrong place, so they're even...) The reason I like ESP authentication is precisely the fact that it doesn't contain all the hair needed to protect a subset of IP header fields. paul From pkoning@xedia.com Wed, 14 Jun 2000 13:25:08 -0400 (EDT) Date: Wed, 14 Jun 2000 13:25:08 -0400 (EDT) From: Paul Koning pkoning@xedia.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: What keeps nagging at me is the overhead Michael> of both AH and ESP, not to mention the added complexity. >> Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? >> That's no help, because that is exactly the difference that makes >> AH so much harder than ESP. (Well, there's details like having >> the MAC in the header rather than the trailer. Then again, ESP >> puts the NextHeader value in the wrong place, so they're even...) >> >> The reason I like ESP authentication is precisely the fact that it >> doesn't contain all the hair needed to protect a subset of IP >> header fields. Michael> Maybe you're misunderstanding me: if ESP had a bit which Michael> said "I'm protecting the outside headers too", it could be Michael> either signaled or potentially even done on an as-needed Michael> basis by the IPsec stack for IP headers which would Michael> otherwise require AH. I'm all for not protecting things that Michael> don't need protection otherwise. I think I understood. The issue is that the bit you're describing is actually the only essential difference between AH and ESP. In other words, you can think of it as the "do AH" bit. You can't just "protect the outside headers too". You have to be selective about it, protecting only immutable ones, skipping fields and headers that change in transit, mumble mumble mumble. That's the "hair" of AH I'm referring to. It doesn't matter what you call it or how you encode it. The hypothetical "ESP with the bit" you describe has to do the same thing so it has to contain the same amount of hair. paul From Stephen.Waters@cabletron.com Wed, 14 Jun 2000 10:38:55 +0100 Date: Wed, 14 Jun 2000 10:38:55 +0100 From: Waters, Stephen Stephen.Waters@cabletron.com Subject: [Isis-wg] Deprecation of AH header from the IPSEC tool kit There has been some discussion recently on the possible deprecation of the Authentication Header defined for 'whole-packet' authentication. I 'think' the decision was to leave it alone, and allow AH to wait for its day. >From reading the various, associated methods of securing ISIS, OSPF and RIPV2 messages, it seems to me that AH is perfect for the protection of these protocols. The current HMAC-MD5 options have the following exposures that are solved with AH: 1) no source address authentication (IP header authentication in general) 2) poor/no replay protection 3) manual keys - which restricts key length and complexity to human-manageable keys, and makes for difficult key change procedures. IPSEC+AH would seem to be a good choice for all control traffic exchange between routers. If this exchange is confidential, the ESP could be used as well. Regards, Steve. From mat@cisco.com Wed, 14 Jun 2000 11:54:05 -0700 (PDT) Date: Wed, 14 Jun 2000 11:54:05 -0700 (PDT) From: Michael Thomas mat@cisco.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Ben McCann writes: > > Michael> This might be water well under the bridge, but has the > > Michael> thought of having a mode to ESP which protects the outer > > Michael> headers? > > Aren't your goals met by using ESP _tunnel_ mode? Just tunnel the OSPF, > RIP, etc, packet from one box to the other. The tunneled packet has an > inner IP header is completely secured by ESP. This is the header seen > by OSPF, RIP, etc, once ESP completes the authentication of the packet. > See my previous post. Throwing bytes at the problem is certainly one way to solve it, but it may not be practical in many, many cases. Mike From mat@cisco.com Wed, 14 Jun 2000 11:48:19 -0700 (PDT) Date: Wed, 14 Jun 2000 11:48:19 -0700 (PDT) From: Michael Thomas mat@cisco.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Paul Koning writes: > The issue is that the bit you're describing is actually the only > essential difference between AH and ESP. In other words, you can > think of it as the "do AH" bit. > > You can't just "protect the outside headers too". You have to be > selective about it, protecting only immutable ones, skipping fields > and headers that change in transit, mumble mumble mumble. That's the > "hair" of AH I'm referring to. It doesn't matter what you call it or > how you encode it. The hypothetical "ESP with the bit" you describe > has to do the same thing so it has to contain the same amount of hair. Sure. Doing AH-like functionality is a pain; if you have to do it, you have to do it -- that's just a given. What I don't like is having a completely separate header with its associated complexity and (especially) overhead. Right now though, if I had a flow which for some reason need privacy and outer header protection (ie, AH functionality), you'd have to put on an AH and ESP header. This means that the SPI and the Sequence are completely redundant, as well as having to burn another longword for the redundant header, thus I'm having to add yet another 12 bytes per packet. If we're talking about something like RTP audio, that's probably significant. Then of course there's the issue of, say, CRTP. I don't think that a profile for crypto for CRTP has been done to compress the predictable parts of the crypto headers, (ie, SPI, SEQ, next header), but having to contend with *both* AH and ESP would make crypto-aware CRTP an even uglier proposition. The same, incidentally, goes for normal header compression, and the coming IP enabled cellular stuff is going to absolutely demand both compression as well as security. Whether it is wise to open up this debate yet again is questionable, but life is only going to get more complicated if AH stays around. Pick your poison. Mike From ben.abarbanel@ipoptical.com Thu, 15 Jun 2000 09:58:48 -0700 Date: Thu, 15 Jun 2000 09:58:48 -0700 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] Maximum number of adjacencies This is a multi-part message in MIME format. ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the absolute maximum number of adjacencies per router various = vendors have defined in their software? I know we have a circuit ID maximum of 255, but assuming we can solve = that with IS-IS 3 way handshake. Thanks in advance for your input. Ben ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the absolute maximum number of = adjacencies=20 per router various vendors have defined in their software?
I know we have a circuit ID maximum of = 255, but=20 assuming we can solve that with IS-IS 3 way handshake.
 
Thanks in advance for your = input.
 
Ben
 
 
------=_NextPart_000_0015_01BFD6B0.4CCDB100-- From Radia.Perlman@East.Sun.COM Thu, 15 Jun 2000 22:32:53 -0700 (PDT) Date: Thu, 15 Jun 2000 22:32:53 -0700 (PDT) From: Radia Perlman Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Ran said: >> A counter-example is the Source Routing header, which can >> be authenticated hop-by-hop with AH ... How do you authenticate something hop-by-hop when the key is only known end-to-end? Are you maybe assuming hop-by-hop IPSec tunnels between the routers listed in the source route header? Radia From dkatz@juniper.net Sun, 18 Jun 2000 21:03:59 -0700 (PDT) Date: Sun, 18 Jun 2000 21:03:59 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Maximum number of adjacencies There should be no need for an absolute maximum number. The dominant implementations have demonstrated hundreds of adjacencies. There will be a point, of course, where things will no longer work, but there is nothing in the protocol precluding arbitrary numbers of neighbors. X-Sent: 15 Jun 2000 13:56:37 GMT From: "ben abarbanel" Date: Thu, 15 Jun 2000 09:58:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01BFD6B0.4CCDB100" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the absolute maximum number of adjacencies per router various = vendors have defined in their software? I know we have a circuit ID maximum of 255, but assuming we can solve = that with IS-IS 3 way handshake. Thanks in advance for your input. Ben ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the absolute maximum number of = adjacencies=20 per router various vendors have defined in their software?
I know we have a circuit ID maximum of = 255, but=20 assuming we can solve that with IS-IS 3 way handshake.
 
Thanks in advance for your = input.
 
Ben
 
 
------=_NextPart_000_0015_01BFD6B0.4CCDB100-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From emmanuel.dauvergne@rd.francetelecom.fr Mon, 19 Jun 2000 11:56:14 +0200 Date: Mon, 19 Jun 2000 11:56:14 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] reservation and preemption Hello, In RFC2702, it's planned to use the preemptive (preemptor and/or preemptable) characteristics of reservations to choose one path or another. To provide this, shouldn't we distinguish the "unreserved bandwidth" from the 'bandwidth already reserved but preemptable", and therefore introduce a new sub-TLV in TLV 22 ? Or is this the aim of the three additional TE-metrics defined in draft-fedyk-isis-ospf-te-metrics-00.txt ? Thanks for clarification Manu From E.T.Metz@kpn.com Mon, 19 Jun 2000 15:40:56 +0100 Date: Mon, 19 Jun 2000 15:40:56 +0100 From: Metz, E.T. E.T.Metz@kpn.com Subject: [Isis-wg] Areas in ISIS Hi all, is it possible to have an ISIS network with different areas, but without an explicit backbone area? I thought it could be done because the L1/L2 routers in each of the areas will form (L2) adjacencies and exchange routing info. So even without a real backbone area, traffic will still flow between differents areas. Is the above correct? Does it make any sense? cheers, Eduard From mshand@cisco.com Mon, 19 Jun 2000 14:56:44 +0100 Date: Mon, 19 Jun 2000 14:56:44 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Areas in ISIS At 15:40 19/06/2000 +0100, Metz, E.T. wrote: >Hi all, > >is it possible to have an ISIS network with different areas, but without an >explicit backbone area? > >I thought it could be done because the L1/L2 routers in each of the areas >will form (L2) adjacencies and exchange routing info. So even without a real >backbone area, traffic will still flow between differents areas. > >Is the above correct? Does it make any sense? Yes, no problem. All that is required is that there is a connected L2 path linking all the areas. In paritcular if areas A and C are connected through area B, there must be a connected path of L2 routers through B. Mike >cheers, > Eduard > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From amartey@cisco.com Mon, 19 Jun 2000 09:43:36 -0700 Date: Mon, 19 Jun 2000 09:43:36 -0700 From: Abe Martey amartey@cisco.com Subject: [Isis-wg] Areas in ISIS On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > Hi all, > > is it possible to have an ISIS network with different areas, but without an > explicit backbone area? Sure! Each router belongs to one area and there is no need for a physically distinct backbone area. The backbone refers to the level-2 routing domain which is a logical area....the group of routers involved in level-2 routing (as you describe below) form the isis backbone...the backbone stretch just has to be contiguous... Cheers. - abe > > I thought it could be done because the L1/L2 routers in each of the areas > will form (L2) adjacencies and exchange routing info. So even without a real > backbone area, traffic will still flow between differents areas. > > Is the above correct? Does it make any sense? > > cheers, > Eduard > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 From Radia.Perlman@East.Sun.COM Mon, 19 Jun 2000 13:54:40 -0400 (EDT) Date: Mon, 19 Jun 2000 13:54:40 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Areas in ISIS Years ago (like 10) Chris Gunner and I did an internet-draft explaining how a router capable of running multiple instances of IS-IS could be configured to interconnect two areas. It just has to be configured with which ports are in which areas, and which addresses to pass along from one area to another. NLSP did this, and extended the idea with something called "area-hops" which said how many areas you were allowed to learn the address range and pass it along. This allowed interconnecting two areas but not allowing through traffic from other areas (set area-hops to 1), and cut down on the count-to-infinity behavior that could be caused by complex interconnections of areas without a level 2 backbone. This isn't a protocol issue, if you don't add "area-hops". It's solely an implementation issue at the multi-area router. If someone wants to build a router that can do multiple instances of IS-IS and be configured with what to pass between the areas, none of the other routers need to know that this is going on. Radia From: Abe Martey To: "Metz, E.T." Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] Areas in ISIS Mime-Version: 1.0 X-Mailman-Version: 1.0rc3 List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > Hi all, > > is it possible to have an ISIS network with different areas, but without an > explicit backbone area? Sure! Each router belongs to one area and there is no need for a physically distinct backbone area. The backbone refers to the level-2 routing domain which is a logical area....the group of routers involved in level-2 routing (as you describe below) form the isis backbone...the backbone stretch just has to be contiguous... Cheers. - abe > > I thought it could be done because the L1/L2 routers in each of the areas > will form (L2) adjacencies and exchange routing info. So even without a real > backbone area, traffic will still flow between differents areas. > > Is the above correct? Does it make any sense? > > cheers, > Eduard > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From dkatz@juniper.net Mon, 19 Jun 2000 13:19:50 -0700 (PDT) Date: Mon, 19 Jun 2000 13:19:50 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Areas in ISIS I fail to see the distinction between what is described and a "physically distinct backbone area." In particular, if there are going to be distinct L1 areas, there must be a contiguous L2 backbone (which could be as small as a single link) to connect the L2 routers. An L1/L2 router is essentially the same thing as an OSPF router with at least one interface in the backbone area and at least one interface in another area. --Dave Date: Mon, 19 Jun 2000 09:43:36 -0700 From: Abe Martey Cc: isis-wg@external.juniper.net References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i 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 On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > Hi all, > > is it possible to have an ISIS network with different areas, but without an > explicit backbone area? Sure! Each router belongs to one area and there is no need for a physically distinct backbone area. The backbone refers to the level-2 routing domain which is a logical area....the group of routers involved in level-2 routing (as you describe below) form the isis backbone...the backbone stretch just has to be contiguous... Cheers. - abe > > I thought it could be done because the L1/L2 routers in each of the areas > will form (L2) adjacencies and exchange routing info. So even without a real > backbone area, traffic will still flow between differents areas. > > Is the above correct? Does it make any sense? > > cheers, > Eduard > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From dkatz@juniper.net Mon, 19 Jun 2000 13:26:29 -0700 (PDT) Date: Mon, 19 Jun 2000 13:26:29 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Areas in ISIS This isn't "physically distinct" in the sense that L1 traffic can traverse some of the same links that make up the L2 topology, but it is important to think of the L2 topology as distinct when you design your network, or you can end up in a world of hurt. In particular, if areas A, B, and C are connected through a loop, and there are parts of area B that depend on those L1L2 links for L1 connectivity, a break of the path through area B could not be healed via A and C. In the topology you describe, I would visualize the L2 path as being on the edge of area B, as it (at least to me) presents the weaknesses of the topology more clearly. --Dave X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 19 Jun 2000 14:56:44 +0100 From: Mike Shand Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 15:40 19/06/2000 +0100, Metz, E.T. wrote: >Hi all, > >is it possible to have an ISIS network with different areas, but without an >explicit backbone area? > >I thought it could be done because the L1/L2 routers in each of the areas >will form (L2) adjacencies and exchange routing info. So even without a real >backbone area, traffic will still flow between differents areas. > >Is the above correct? Does it make any sense? Yes, no problem. All that is required is that there is a connected L2 path linking all the areas. In paritcular if areas A and C are connected through area B, there must be a connected path of L2 routers through B. Mike >cheers, > Eduard > >_______________________________________________ >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 amartey@cisco.com Mon, 19 Jun 2000 15:29:33 -0700 Date: Mon, 19 Jun 2000 15:29:33 -0700 From: Abe Martey amartey@cisco.com Subject: [Isis-wg] Areas in ISIS Dave Katz wrote: > > I fail to see the distinction between what is described and a "physically > distinct backbone area." In particular, if there are going to be distinct > L1 areas, there must be a contiguous L2 backbone (which could be as small > as a single link) to connect the L2 routers. An L1/L2 router is > essentially the same thing as an OSPF router with at least one >interface in the backbone area and at least one interface in another >area. Technically yes...but IS-IS would allow a linear layout of multiple areas whereas OSPF needs all areas touching a _common_ centrally located area 0...unless you wanted to play with virtual links. The IS-IS backbone is not as clearly carved out as the OSPF area 0...a difference probably rooted in ISO node-based addressing vs IP link-based addressing. I'll agree however that in a real network, the IS-IS backbone should be as distinctly carved out as an OSPF backbone.... > > --Dave > > Date: Mon, 19 Jun 2000 09:43:36 -0700 > From: Abe Martey > Cc: isis-wg@external.juniper.net > References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > X-Mailer: Mutt 1.0i > 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 > > On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > > Hi all, > > > > is it possible to have an ISIS network with different areas, but without an > > explicit backbone area? > > Sure! Each router belongs to one area and there is no need for a > physically distinct backbone area. The backbone refers to the level-2 > routing domain which is a logical area....the group of routers involved > in level-2 routing (as you describe below) form the isis backbone...the > backbone stretch just has to be contiguous... > > Cheers. > > - abe > > > > > I thought it could be done because the L1/L2 routers in each of the areas > > will form (L2) adjacencies and exchange routing info. So even without a real > > backbone area, traffic will still flow between differents areas. > > > > Is the above correct? Does it make any sense? > > > > cheers, > > Eduard > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > ==.==.==.==.== > Abe Martey > San Jose, CA > 408 527 9149 > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Radia.Perlman@East.Sun.COM Mon, 19 Jun 2000 19:26:38 -0400 (EDT) Date: Mon, 19 Jun 2000 19:26:38 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Ran, another basic question... What's the threat solved by authenticating the source route header at intermediate points? What would be the problem if a packet showed up at the destination, not having traversed the route you wanted? I'm assuming you're not trying to solve the confidentiality problem by making sure that the packet stays in "friendly" parts of the net, and therefore doesn't need encryption, but if it took a different route it would need encryption. Radia From truskows@cisco.com Mon, 19 Jun 2000 18:04:28 PDT Date: Mon, 19 Jun 2000 18:04:28 PDT From: Mike Truskowski truskows@cisco.com Subject: [Isis-wg] Areas in ISIS Sounds to me like you are saying the same things here only in different ways... The difference occurs at the logical layer... an area in OSI is dictated by the nsap while an area in ospf is a logical mapping... OSI backbones can have multiple osi areas while an ospf area 0 is one area with the backbone belonging to it... mike > > I fail to see the distinction between what is described and a "physically > distinct backbone area." In particular, if there are going to be distinct > L1 areas, there must be a contiguous L2 backbone (which could be as small > as a single link) to connect the L2 routers. An L1/L2 router is > essentially the same thing as an OSPF router with at least one interface > in the backbone area and at least one interface in another area. > > --Dave > > Date: Mon, 19 Jun 2000 09:43:36 -0700 > From: Abe Martey > Cc: isis-wg@external.juniper.net > References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > X-Mailer: Mutt 1.0i > 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 > > > On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > > Hi all, > > > > is it possible to have an ISIS network with different areas, but without an > > explicit backbone area? > > Sure! Each router belongs to one area and there is no need for a > physically distinct backbone area. The backbone refers to the level-2 > routing domain which is a logical area....the group of routers involved > in level-2 routing (as you describe below) form the isis backbone...the > backbone stretch just has to be contiguous... > > Cheers. > > - abe > > > > > I thought it could be done because the L1/L2 routers in each of the areas > > will form (L2) adjacencies and exchange routing info. So even without a real > > backbone area, traffic will still flow between differents areas. > > > > Is the above correct? Does it make any sense? > > > > cheers, > > Eduard > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > > ==.==.==.==.== > Abe Martey > San Jose, CA > 408 527 9149 > > _______________________________________________ > 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 truskows@cisco.com Mon, 19 Jun 2000 18:14:31 PDT Date: Mon, 19 Jun 2000 18:14:31 PDT From: Mike Truskowski truskows@cisco.com Subject: [Isis-wg] Areas in ISIS I think that you are saying that if you build heirarchically then OSPF and ISIS topologies are the same... AREA0 is equivalent to all those L2 adjacencies... And I agree...but the difference is shown by a little different topology... In ospf, if A is the area0 and B and C are cascading with a virtual link from C to A.. then all traffic from C to B goes thru A... But in ISIS with A being L2/L1 cascaded to B cascaded to C as in above... with L2 connectivity to from A thru B to C, then traffic from C to B merely goes directly to B and never is seen by A... As long as the "loop" is never completed then the topology is fine... The major weakness I see with ISIS in this sense is that a L1 instance must choose the "closest" L2 router which may not be the best L2. Mike > > This isn't "physically distinct" in the sense that L1 traffic can traverse > some of the same links that make up the L2 topology, but it is important > to think of the L2 topology as distinct when you design your network, or > you can end up in a world of hurt. In particular, if areas A, B, and C > are connected through a loop, and there are parts of area B that depend > on those L1L2 links for L1 connectivity, a break of the path through > area B could not be healed via A and C. > > In the topology you describe, I would visualize the L2 path as being > on the edge of area B, as it (at least to me) presents the weaknesses > of the topology more clearly. > > > --Dave > > X-Sender: mshand@jaws.cisco.com > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 > Date: Mon, 19 Jun 2000 14:56:44 +0100 > From: Mike Shand > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > 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 > > At 15:40 19/06/2000 +0100, Metz, E.T. wrote: > >Hi all, > > > >is it possible to have an ISIS network with different areas, but without an > >explicit backbone area? > > > >I thought it could be done because the L1/L2 routers in each of the areas > >will form (L2) adjacencies and exchange routing info. So even without a real > >backbone area, traffic will still flow between differents areas. > > > >Is the above correct? Does it make any sense? > > Yes, no problem. All that is required is that there is a connected L2 path > linking all the areas. In paritcular if areas A and C are connected through > area B, there must be a connected path of L2 routers through B. > > Mike > > > > >cheers, > > Eduard > > > >_______________________________________________ > >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 NZvaig@adtech-inc.com Mon, 19 Jun 2000 16:31:57 -1000 Date: Mon, 19 Jun 2000 16:31:57 -1000 From: Nava.Zvaig NZvaig@adtech-inc.com Subject: [Isis-wg] ISIS code 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_01BFDA5F.B4BB817E Content-Type: text/plain; charset="iso-8859-1" Is there any software/shareware/freeware available for ISIS and ISIS-TE? TIA, Nava ------_=_NextPart_001_01BFDA5F.B4BB817E Content-Type: text/html; charset="iso-8859-1" ISIS code

Is there any software/shareware/freeware available for ISIS and ISIS-TE?

TIA,
Nava

------_=_NextPart_001_01BFDA5F.B4BB817E-- From mshand@cisco.com Tue, 20 Jun 2000 08:02:19 +0100 Date: Tue, 20 Jun 2000 08:02:19 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Areas in ISIS At 13:26 19/06/2000 -0700, Dave Katz wrote: >This isn't "physically distinct" in the sense that L1 traffic can traverse >some of the same links that make up the L2 topology, but it is important >to think of the L2 topology as distinct when you design your network, or >you can end up in a world of hurt. In particular, if areas A, B, and C >are connected through a loop, and there are parts of area B that depend >on those L1L2 links for L1 connectivity, a break of the path through >area B could not be healed via A and C. > >In the topology you describe, I would visualize the L2 path as being >on the edge of area B, as it (at least to me) presents the weaknesses >of the topology more clearly. Dave, I couldn't agree more. The difference between IS-IS and OSPF is not primarily one of network design, but one of nomenclature. i.e. in IS-IS you still need to design a 'backbone', but the backbone isn't named as a single area (0) as it is in OSPF. In fact it isn't named at all. Its just defined by the connected set of L2 routers. In some designs that will correspond to a single L1 area, but in others it may traverse (or as you rightly point out ,it is better to think of it as skirting around the edge of) multiple L1 areas. Mike From E.T.Metz@kpn.com Tue, 20 Jun 2000 20:14:11 +0100 Date: Tue, 20 Jun 2000 20:14:11 +0100 From: Metz, E.T. E.T.Metz@kpn.com Subject: [Isis-wg] Areas in ISIS Thanks for the clarifications ... As for the situation I was thinking of, this was indeed the case where you have multiple areas and the backbone is formed of the "edges" of the areas and the links between the areas. I didn't really think of a "chain" of areas, the loop issue is although interesting. I like the concept of this "virtual backbone" is ISIS, although in (re)designing networks you'll probably have to clearly keep in mind to keep the backbone contiguos and avoid chains (loops) of areas. While in OSPF this is more or less forced upon th designer due to the explicit area 0 that has to present, and to which all other areas should connect. cheers, Eduard ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would it? It needs to be L2 or L1/L2 at least. > ---------- > From: Mike Shand[SMTP:mshand@cisco.com] > Sent: dinsdag 20 juni 2000 9:02 > To: Dave Katz > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > Subject: Re: [Isis-wg] Areas in ISIS > > At 13:26 19/06/2000 -0700, Dave Katz wrote: > >This isn't "physically distinct" in the sense that L1 traffic can > traverse > >some of the same links that make up the L2 topology, but it is important > >to think of the L2 topology as distinct when you design your network, or > >you can end up in a world of hurt. In particular, if areas A, B, and C > >are connected through a loop, and there are parts of area B that depend > >on those L1L2 links for L1 connectivity, a break of the path through > >area B could not be healed via A and C. > > > >In the topology you describe, I would visualize the L2 path as being > >on the edge of area B, as it (at least to me) presents the weaknesses > >of the topology more clearly. > > Dave, > I couldn't agree more. The difference between IS-IS and OSPF is > not primarily one of network design, but one of nomenclature. i.e. in > IS-IS > you still need to design a 'backbone', but the backbone isn't named as a > single area (0) as it is in OSPF. In fact it isn't named at all. Its just > defined by the connected set of L2 routers. In some designs that will > correspond to a single L1 area, but in others it may traverse (or as you > rightly point out ,it is better to think of it as skirting around the edge > > of) multiple L1 areas. > > Mike > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mshand@cisco.com Tue, 20 Jun 2000 19:34:48 +0100 Date: Tue, 20 Jun 2000 19:34:48 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Areas in ISIS At 20:14 20/06/2000 +0100, Metz, E.T. wrote: >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would >it? It needs to be L2 or L1/L2 at least. Were running into terminological inexactitudes here :-) Yes it does need to be L2, but one way of designing an IS-IS network is to make an area of L1/L2 routers which constitutes the backbone and then hang all the other areas off this one. Of course you need at least one L1/L2 router in each of those areas, so the backbone (in the sense we were talking before, i.e. the set of connected L2 routers - or the distribution domain of L2 LSPs) spans multiple areas. But it does look rather like the OSPF case, where the backbone is a single area (0 in that case). Mike (S) From E.T.Metz@kpn.com Tue, 20 Jun 2000 20:50:38 +0100 Date: Tue, 20 Jun 2000 20:50:38 +0100 From: Metz, E.T. E.T.Metz@kpn.com Subject: [Isis-wg] Areas in ISIS Small question (related to below), if you do create a separate backbone (physically, or at least similar to OSPF area 0), is it then needed or advantagous to have L1 routing in this area. Instead of just L2? cheers, Eduard > ---------- > From: Mike Shand[SMTP:mshand@cisco.com] > Sent: dinsdag 20 juni 2000 20:34 > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > Subject: RE: [Isis-wg] Areas in ISIS > > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > would > >it? It needs to be L2 or L1/L2 at least. > > Were running into terminological inexactitudes here :-) > > Yes it does need to be L2, but one way of designing an IS-IS network is to > > make an area of L1/L2 routers which constitutes the backbone and then hang > > all the other areas off this one. Of course you need at least one L1/L2 > router in each of those areas, so the backbone (in the sense we were > talking before, i.e. the set of connected L2 routers - or the distribution > > domain of L2 LSPs) spans multiple areas. But it does look rather like the > OSPF case, where the backbone is a single area (0 in that case). > > Mike (S) > > From amartey@cisco.com Wed, 21 Jun 2000 09:05:14 -0700 Date: Wed, 21 Jun 2000 09:05:14 -0700 From: Abe Martey amartey@cisco.com Subject: [Isis-wg] Areas in ISIS On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: > Small question (related to below), if you do create a separate backbone > (physically, or at least similar to OSPF area 0), is it then needed or > advantagous to have L1 routing in this area. Instead of just L2? You could have a physical area x designated as the "core" of the backbone..and all routers in this area don't have to run L1. Actually they shouldn't since it'll be a resource waste....however your "true" isis backbone will extend to the L1L2 border routers of the various other areas. [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] |---area 1----| |--area x---| |----Area 2----| |----------isis backbone-----------| Cheers. - abe > > cheers, > Eduard > > > ---------- > > From: Mike Shand[SMTP:mshand@cisco.com] > > Sent: dinsdag 20 juni 2000 20:34 > > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > > Subject: RE: [Isis-wg] Areas in ISIS > > > > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > > would > > >it? It needs to be L2 or L1/L2 at least. > > > > Were running into terminological inexactitudes here :-) > > > > Yes it does need to be L2, but one way of designing an IS-IS network is to > > > > make an area of L1/L2 routers which constitutes the backbone and then hang > > > > all the other areas off this one. Of course you need at least one L1/L2 > > router in each of those areas, so the backbone (in the sense we were > > talking before, i.e. the set of connected L2 routers - or the distribution > > > > domain of L2 LSPs) spans multiple areas. But it does look rather like the > > OSPF case, where the backbone is a single area (0 in that case). > > > > Mike (S) > > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 From truskows@cisco.com Wed, 21 Jun 2000 9:44:15 PDT Date: Wed, 21 Jun 2000 9:44:15 PDT From: Mike Truskowski truskows@cisco.com Subject: [Isis-wg] Areas in ISIS Ugh... I think this might be a little confusing.... No doubt that this will work but ... Area X "must" have a contiguous space of L2 or L2/L1 connected to each Area N... In other words, Assuming that the Area N's are only connected thru Area X, then there must be a set of L2 instances w/i area X that connect Area N to Area M.... Hence, the L2(/L1) routers in area X and the L1/L2 routers in Area N form the backbone... The L1's are not part of the backbone. The L2's are analogus to ospf's area 0. Not the L1's. Personally, I try to stay far away from this. mike > > > > On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: > > Small question (related to below), if you do create a separate backbone > > (physically, or at least similar to OSPF area 0), is it then needed or > > advantagous to have L1 routing in this area. Instead of just L2? > > You could have a physical area x designated as the "core" of the > backbone..and all routers in this area don't have to run L1. Actually > they shouldn't since it'll be a resource waste....however your > "true" isis backbone will extend to the L1L2 border routers of the > various other areas. > > [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] > > |---area 1----| |--area x---| |----Area 2----| > |----------isis backbone-----------| > > > Cheers. > > - abe > > > > > cheers, > > Eduard > > > > > ---------- > > > From: Mike Shand[SMTP:mshand@cisco.com] > > > Sent: dinsdag 20 juni 2000 20:34 > > > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > > > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > > > Subject: RE: [Isis-wg] Areas in ISIS > > > > > > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > > > would > > > >it? It needs to be L2 or L1/L2 at least. > > > > > > Were running into terminological inexactitudes here :-) > > > > > > Yes it does need to be L2, but one way of designing an IS-IS network is to > > > > > > make an area of L1/L2 routers which constitutes the backbone and then hang > > > > > > all the other areas off this one. Of course you need at least one L1/L2 > > > router in each of those areas, so the backbone (in the sense we were > > > talking before, i.e. the set of connected L2 routers - or the distribution > > > > > > domain of L2 LSPs) spans multiple areas. But it does look rather like the > > > OSPF case, where the backbone is a single area (0 in that case). > > > > > > Mike (S) > > > > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > > ==.==.==.==.== > Abe Martey > San Jose, CA > 408 527 9149 > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > From jparker@nexabit.com Fri, 23 Jun 2000 10:05:59 -0400 Date: Fri, 23 Jun 2000 10:05:59 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE > Folks, > > Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt > be accepted as a work group document. So far I've only seen support. > If there are no objects by 6/27, we'll declare it so. > > ...George I find this draft a useful addition to the discussion of TE, and would support it's adoption as an MPLS group document. However, I am a bit puzzled by the last paragraph before section 4.3 (bottom of page 5). "Route computation procedures should not perform two-way connectivity check on the links used by the procedures. That is, the two way check should not be performed on one-way pipes, as they will fail." I agree that relaxing this test for one-way links is a Good Thing. But looking at the aged out draft "IS-IS extensions for Traffic Engineering" I don't understand how we distinguish "forward adjacencies" that are unidirectional LSPs from point-to-point adjacencies, where we should retain the test. Perhaps this will be addressed in the next rev of the IS-IS TE doc. - jeff parker - Lucent Technologies From naiming@redback.com Fri, 23 Jun 2000 14:49:29 -0700 Date: Fri, 23 Jun 2000 14:49:29 -0700 From: Naiming Shen naiming@redback.com Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE don't want to speak for the authors, but the difference from a disabled TE link is that this LSP link has a usable TE metric set. this hierarchy scheme is independent of LSP bundling, you can announce and set different metric on different LSPs the same source/dest pair. so i don't see why the Mux TLV should be required. an interesting question is how do you set the link metric to be max(1, (the TE metric of the FA-LSP path) - 1)? something like the one mentioned in an expired draft:-) thanks. ]Naiming Shen wrote: ] ]> I think you can use the cue which normal IS-IS ignores this type of ]> links, which is the links are having the default metric of (2^24 - 1). ] ]there is a chance to confuse that with a disabled TE link of course. ]Also (although that's minor) it's a disadvantage that if i choose not to ]support LSP bundling. I'd loose control about which of the forwarding ]adjacencies other LSRs prefer based on admin metric. ] ]It seems to me much wiser to use the presence of the Link Mux Capability sub- TLV ]as indication that only a one-way check is necessary. I assume that ]sub-TLV is mandatory on forwarding adjacencies, the draft is not 100% ]clear about that one. ] ] any clarification from the authors ? ] ] -- tony ] ] ]> ]> ]> ]> Folks, ]> ]> ]> ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.t xt ]> ]> be accepted as a work group document. So far I've only seen support. ]> ]> If there are no objects by 6/27, we'll declare it so. ]> ]> ]> ]> ...George ]> ] ]> ]I find this draft a useful addition to the discussion of TE, and would ]> ]support it's adoption as an MPLS group document. ]> ] ]> ]However, I am a bit puzzled by the last paragraph before ]> ]section 4.3 (bottom of page 5). ]> ] ]> ] "Route computation procedures should not perform two-way ]> ] connectivity check on the links used by the procedures. ]> ] That is, the two way check should not be performed on ]> ] one-way pipes, as they will fail." ]> ] ]> ]I agree that relaxing this test for one-way links is a Good Thing. But ]> ]looking at the aged out draft "IS-IS extensions for Traffic Engineering" ]> ] I don't understand how we distinguish ]> ]"forward adjacencies" that are unidirectional LSPs from point-to-point ]> ]adjacencies, where we should retain the test. ]> ] ]> ]Perhaps this will be addressed in the next rev of the IS-IS TE doc. ]> ] ] ] ] - Naiming From naiming@redback.com Fri, 23 Jun 2000 08:27:43 -0700 Date: Fri, 23 Jun 2000 08:27:43 -0700 From: Naiming Shen naiming@redback.com Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE I think you can use the cue which normal IS-IS ignores this type of links, which is the links are having the default metric of (2^24 - 1). ]> Folks, ]> ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt ]> be accepted as a work group document. So far I've only seen support. ]> If there are no objects by 6/27, we'll declare it so. ]> ]> ...George ] ]I find this draft a useful addition to the discussion of TE, and would ]support it's adoption as an MPLS group document. ] ]However, I am a bit puzzled by the last paragraph before ]section 4.3 (bottom of page 5). ] ] "Route computation procedures should not perform two-way ] connectivity check on the links used by the procedures. ] That is, the two way check should not be performed on ] one-way pipes, as they will fail." ] ]I agree that relaxing this test for one-way links is a Good Thing. But ]looking at the aged out draft "IS-IS extensions for Traffic Engineering" ] I don't understand how we distinguish ]"forward adjacencies" that are unidirectional LSPs from point-to-point ]adjacencies, where we should retain the test. ] ]Perhaps this will be addressed in the next rev of the IS-IS TE doc. ] ]- jeff parker ]- Lucent Technologies ] ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From kireeti@juniper.net Fri, 23 Jun 2000 10:10:36 -0700 (PDT) Date: Fri, 23 Jun 2000 10:10:36 -0700 (PDT) From: Kireeti Kompella kireeti@juniper.net Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE Hi Jeff, > I find this draft a useful addition to the discussion of TE, and would > support it's adoption as an MPLS group document. Thanks! > However, I am a bit puzzled by the last paragraph before > section 4.3 (bottom of page 5). > "Route computation procedures should not perform two-way > connectivity check on the links used by the procedures. > That is, the two way check should not be performed on > one-way pipes, as they will fail." Here's the deal: if you have a unidirectional FA-LSP from A to B, but no LSP from B to A, and you want to compute a _TE_ path for another LSP to tunnel over the FA-LSP, the two-way check will not allow the FA-LSP to be used. Hence the above statement. > I agree that relaxing this test for one-way links is a Good Thing. Note that for CSPF (i.e., TE path) computation, discarding the two-way check will not cause routing loops. However, it's trivial to come up with an example where if a router doesn't do the two-way check for 'regular' SPF but other routers do, you will get permanent routing loops. Yes, it might be a Good Thing to eventually relax the two-way check for regular SPF as well, but that would take much more work. > looking at the aged out draft "IS-IS extensions for Traffic Engineering" > I don't understand how we distinguish > "forward adjacencies" that are unidirectional LSPs from point-to-point > adjacencies, where we should retain the test. Forwarding adjacencies are (almost) indistinguishable from point-to-point links. However, the distinction we're making is CSPF vs. regular SPF, not FAs vs. p2p links. For *all* CSPF computations, we recommend not doing the two-way check. For all SPF computations, we _highly_ recommend doing the two-way check (for fear of routing loops) until such time that there is means to achieve consensus among *all* the routers in an ISIS level/OSPF area not to do the two-way check. Kireeti. From prz@redback.com Fri, 23 Jun 2000 11:07:19 -0700 Date: Fri, 23 Jun 2000 11:07:19 -0700 From: Tony Przygienda prz@redback.com Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE Naiming Shen wrote: > I think you can use the cue which normal IS-IS ignores this type of > links, which is the links are having the default metric of (2^24 - 1). there is a chance to confuse that with a disabled TE link of course. Also (although that's minor) it's a disadvantage that if i choose not to support LSP bundling. I'd loose control about which of the forwarding adjacencies other LSRs prefer based on admin metric. It seems to me much wiser to use the presence of the Link Mux Capability sub-TLV as indication that only a one-way check is necessary. I assume that sub-TLV is mandatory on forwarding adjacencies, the draft is not 100% clear about that one. any clarification from the authors ? -- tony > > > ]> Folks, > ]> > ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt > ]> be accepted as a work group document. So far I've only seen support. > ]> If there are no objects by 6/27, we'll declare it so. > ]> > ]> ...George > ] > ]I find this draft a useful addition to the discussion of TE, and would > ]support it's adoption as an MPLS group document. > ] > ]However, I am a bit puzzled by the last paragraph before > ]section 4.3 (bottom of page 5). > ] > ] "Route computation procedures should not perform two-way > ] connectivity check on the links used by the procedures. > ] That is, the two way check should not be performed on > ] one-way pipes, as they will fail." > ] > ]I agree that relaxing this test for one-way links is a Good Thing. But > ]looking at the aged out draft "IS-IS extensions for Traffic Engineering" > ] I don't understand how we distinguish > ]"forward adjacencies" that are unidirectional LSPs from point-to-point > ]adjacencies, where we should retain the test. > ] > ]Perhaps this will be addressed in the next rev of the IS-IS TE doc. > ] From david.wang@metro-optix.com Sat, 17 Jun 2000 16:04:26 -0500 Date: Sat, 17 Jun 2000 16:04:26 -0500 From: David Wang david.wang@metro-optix.com Subject: [Isis-wg] Basic Question about IS-IS Routing protocol Dear Friends, I need to learn some basics of IS-IS routing protocol and how it works in IP environment. I cannot find a book, a tutorial or a white paper. 1. Can somebody recommend me some book or tutorial or a white papers? 2. Who is running CLNP instead of IP in their network beside SONET network management software? Can I learn IS-IS with touch CLNP? 3. What is the major difference between IS-IS and OSPF? 4. When use IS-IS to route IP packets the Link State Advertisement packets are also IP packets. People don't have to worry about the OSI CLNP protocol in IP environment. Is this correct? 5. Any other comment and information about IS-IS protocol. Thanks for your help David From danny@ambernetworks.com Fri, 23 Jun 2000 18:20:22 -0600 Date: Fri, 23 Jun 2000 18:20:22 -0600 From: Danny McPherson danny@ambernetworks.com Subject: [Isis-wg] Basic Question about IS-IS Routing protocol > 1. Can somebody recommend me some book or tutorial or a white papers? Radia Perlman's "Interconnections, Second Edition" is the most useful book I'm aware of. > 2. Who is running CLNP instead of IP in their network beside SONET network > management software? Can I learn IS-IS with touch CLNP? Yes, as CLNS traffic forwarding isn't required (though OSI stack support is per IS-IS packet maintain their original format). IP-only IS-IS is actually the most common implementation of IS-IS today in IP routers (most don't support CLNS traffic forwarding). For IP-only IS-IS, the only OSIish thing you need is NSAP, which is used to determine the routers area and give it a system ID. > 3. What is the major difference between IS-IS and OSPF? The primary difference is that OSPF is an "open standard protocol", was designed expressly for IP, and runs on top of IP. IS-IS was initially designed to support CLNP, then extended to support IP as well. There are lots of other differences, though I'd rather not trigger yet another debate on them. Consulting the MPLS WG mailing list archives, and perhaps the NANOG archives (www.nanog.org) should yield some useful information. > 4. When use IS-IS to route IP packets the Link State Advertisement packets > are also IP packets. People don't have to worry about the OSI CLNP protocol > in IP environment. Is this correct? No. IS-IS LSPs (somewhat synonymous to OSPF LS Updates) contain TLVs that describe IP or CLNP. The encapsulation remains the same and OSI stack support is required. Though again, forwarding capability necessarily isn't. > 5. Any other comment and information about IS-IS protocol. ISO10589 & RFC 1195 may provide some useful information. The OSPF RFC(s) contain a nice "tutorial" on LS routing and the like. -danny From jjl@one.com Mon, 26 Jun 2000 12:18:37 -0400 Date: Mon, 26 Jun 2000 12:18:37 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Areas in ISIS It's not important to avoid loops of areas. This does not contradict what Mike Shand said. Another way to think of it is that, for robustness, you want to make sure that your backbone is constructed in a way so that no single link or router failure could partition the backbone. Likewise, each area should be constructed so that no single link or router failure can partition the area. In Mike's example, the backbone wouldn't be partitioned, but the area would. As Mike says, you need to carefully plan the toplogy of your "Level 2 subdomain", as it's called in ISO 10589, just as you carefully plan the topology of each area. When showing a graphic of the whole topology, it's usually a good idea to render the L2 links in a special color, so that it jumps out even though it's not physically separate from the rest of the network. Of course, this highlighting is unnecessary if you always plan an "Area 0" containing most (but not all!) of your Level 2 backbone. The rest of the L2 backbone would be the one-hop links from the Area 0 routers to the L2 routers in the other areas. For robustness, you would want at least two L2 routers in each area, each with its own link to a different router in Area 0. But as soon as you depart from this plan (by chaining subtended areas, for example), then you need to look at your L2 backbone and make sure it is contiguous (even in the event of a link or router failure). Regards, Jeff At 08:14 PM 6/20/00 +0100, you wrote: > >Thanks for the clarifications ... > >As for the situation I was thinking of, this was indeed the case where you >have multiple areas and the backbone is formed of the "edges" of the areas >and the links between the areas. I didn't really think of a "chain" of >areas, the loop issue is although interesting. > >I like the concept of this "virtual backbone" is ISIS, although in >(re)designing networks you'll probably have to clearly keep in mind to keep >the backbone contiguos and avoid chains (loops) of areas. While in OSPF this >is more or less forced upon th designer due to the explicit area 0 that has >to present, and to which all other areas should connect. > >cheers, > Eduard > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would >it? It needs to be L2 or L1/L2 at least. > >> ---------- >> From: Mike Shand[SMTP:mshand@cisco.com] >> Sent: dinsdag 20 juni 2000 9:02 >> To: Dave Katz >> Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net >> Subject: Re: [Isis-wg] Areas in ISIS >> >> At 13:26 19/06/2000 -0700, Dave Katz wrote: >> >This isn't "physically distinct" in the sense that L1 traffic can >> traverse >> >some of the same links that make up the L2 topology, but it is important >> >to think of the L2 topology as distinct when you design your network, or >> >you can end up in a world of hurt. In particular, if areas A, B, and C >> >are connected through a loop, and there are parts of area B that depend >> >on those L1L2 links for L1 connectivity, a break of the path through >> >area B could not be healed via A and C. >> > >> >In the topology you describe, I would visualize the L2 path as being >> >on the edge of area B, as it (at least to me) presents the weaknesses >> >of the topology more clearly. >> >> Dave, >> I couldn't agree more. The difference between IS-IS and OSPF is >> not primarily one of network design, but one of nomenclature. i.e. in >> IS-IS >> you still need to design a 'backbone', but the backbone isn't named as a >> single area (0) as it is in OSPF. In fact it isn't named at all. Its just >> defined by the connected set of L2 routers. In some designs that will >> correspond to a single L1 area, but in others it may traverse (or as you >> rightly point out ,it is better to think of it as skirting around the edge >> >> of) multiple L1 areas. >> >> Mike >> >> >> >> _______________________________________________ >> 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 > > ____________________________________________________________________ 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 jjl@one.com Mon, 26 Jun 2000 12:22:11 -0400 Date: Mon, 26 Jun 2000 12:22:11 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Areas in ISIS For CLNP, you would need to run L1 as well as L2. Otherwise, you wouldn't be able to manage the routers in Area 0. When a packet arrives in Area 0, the L1 FDB would be consulted, but would be empty or missing, causing the packet to be dropped. I suspect the same might be true for IP traffic. At 09:05 AM 6/21/00 -0700, Abe Martey wrote: > > >On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: >> Small question (related to below), if you do create a separate backbone >> (physically, or at least similar to OSPF area 0), is it then needed or >> advantagous to have L1 routing in this area. Instead of just L2? > >You could have a physical area x designated as the "core" of the >backbone..and all routers in this area don't have to run L1. Actually >they shouldn't since it'll be a resource waste....however your >"true" isis backbone will extend to the L1L2 border routers of the >various other areas. > > [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] > > |---area 1----| |--area x---| |----Area 2----| > |----------isis backbone-----------| > > >Cheers. > >- abe > >> >> cheers, >> Eduard >> >> > ---------- >> > From: Mike Shand[SMTP:mshand@cisco.com] >> > Sent: dinsdag 20 juni 2000 20:34 >> > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' >> > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net >> > Subject: RE: [Isis-wg] Areas in ISIS >> > >> > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: >> > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area >> > would >> > >it? It needs to be L2 or L1/L2 at least. >> > >> > Were running into terminological inexactitudes here :-) >> > >> > Yes it does need to be L2, but one way of designing an IS-IS network is to >> > >> > make an area of L1/L2 routers which constitutes the backbone and then hang >> > >> > all the other areas off this one. Of course you need at least one L1/L2 >> > router in each of those areas, so the backbone (in the sense we were >> > talking before, i.e. the set of connected L2 routers - or the distribution >> > >> > domain of L2 LSPs) spans multiple areas. But it does look rather like the >> > OSPF case, where the backbone is a single area (0 in that case). >> > >> > Mike (S) >> > >> > >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- > > >==.==.==.==.== >Abe Martey >San Jose, CA >408 527 9149 > >_______________________________________________ >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 truskows@cisco.com Mon, 26 Jun 2000 11:12:52 PDT Date: Mon, 26 Jun 2000 11:12:52 PDT From: Mike Truskowski truskows@cisco.com Subject: [Isis-wg] Areas in ISIS Somehow I'm lost here... I thought we were talking about what is the backbone... Another way to look at this is to consider it from the L1 router view point...in ISIS. I have a hard time following the discussion when scalability and topologies get in the way... How does a L1 router choose an external path... By closest L2 router. How does a router in one area talk to another in a different area? By L2 path. Hence, the backbone must be the set of all L2 routers with external reachability.... irregardless of connectability Now if you want any2any reachability...then the set of L2 routers must be contiguous... so connect the L2 routers like connecting dots in a drawing. Now, do you want to talk topology? Avoiding loops are important. That is why heirarchical networks are easier to maintain and scale... Further, loops just cause more L2 paths to maintain. So avoid loops. And network reliability and robustness... well you can build a network with single L1/L2 paths between areas... when a L2 path goes down then part of the network goes down... you can help the reliability if there are redundant paths out of an area to the backbone.... miket > > It's not important to avoid loops of areas. This does not contradict > what Mike Shand said. > > Another way to think of it is that, for robustness, you want to make sure > that your backbone is constructed in a way so that no single link or > router failure could partition the backbone. Likewise, each area should > be constructed so that no single link or router failure can partition the > area. In Mike's example, the backbone wouldn't be partitioned, but the > area would. > > As Mike says, you need to carefully plan the toplogy of your "Level 2 > subdomain", as it's called in ISO 10589, just as you carefully plan > the topology of each area. When showing a graphic of the whole topology, > it's usually a good idea to render the L2 links in a special color, > so that it jumps out even though it's not physically separate from > the rest of the network. > > Of course, this highlighting is unnecessary if you always plan an > "Area 0" containing most (but not all!) of your Level 2 backbone. > The rest of the L2 backbone would be the one-hop links from the Area > 0 routers to the L2 routers in the other areas. For robustness, you > would want at least two L2 routers in each area, each with its own link > to a different router in Area 0. But as soon as you depart from this > plan (by chaining subtended areas, for example), then you need to > look at your L2 backbone and make sure it is contiguous (even in the > event of a link or router failure). > > Regards, > Jeff > > At 08:14 PM 6/20/00 +0100, you wrote: > > > >Thanks for the clarifications ... > > > >As for the situation I was thinking of, this was indeed the case where you > >have multiple areas and the backbone is formed of the "edges" of the areas > >and the links between the areas. I didn't really think of a "chain" of > >areas, the loop issue is although interesting. > > > >I like the concept of this "virtual backbone" is ISIS, although in > >(re)designing networks you'll probably have to clearly keep in mind to keep > >the backbone contiguos and avoid chains (loops) of areas. While in OSPF this > >is more or less forced upon th designer due to the explicit area 0 that has > >to present, and to which all other areas should connect. > > > >cheers, > > Eduard > > > > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would > >it? It needs to be L2 or L1/L2 at least. > > > >> ---------- > >> From: Mike Shand[SMTP:mshand@cisco.com] > >> Sent: dinsdag 20 juni 2000 9:02 > >> To: Dave Katz > >> Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > >> Subject: Re: [Isis-wg] Areas in ISIS > >> > >> At 13:26 19/06/2000 -0700, Dave Katz wrote: > >> >This isn't "physically distinct" in the sense that L1 traffic can > >> traverse > >> >some of the same links that make up the L2 topology, but it is important > >> >to think of the L2 topology as distinct when you design your network, or > >> >you can end up in a world of hurt. In particular, if areas A, B, and C > >> >are connected through a loop, and there are parts of area B that depend > >> >on those L1L2 links for L1 connectivity, a break of the path through > >> >area B could not be healed via A and C. > >> > > >> >In the topology you describe, I would visualize the L2 path as being > >> >on the edge of area B, as it (at least to me) presents the weaknesses > >> >of the topology more clearly. > >> > >> Dave, > >> I couldn't agree more. The difference between IS-IS and OSPF is > >> not primarily one of network design, but one of nomenclature. i.e. in > >> IS-IS > >> you still need to design a 'backbone', but the backbone isn't named as a > >> single area (0) as it is in OSPF. In fact it isn't named at all. Its just > >> defined by the connected set of L2 routers. In some designs that will > >> correspond to a single L1 area, but in others it may traverse (or as you > >> rightly point out ,it is better to think of it as skirting around the edge > >> > >> of) multiple L1 areas. > >> > >> Mike > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > ____________________________________________________________________ > > 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 NZvaig@adtech-inc.com Mon, 26 Jun 2000 11:00:23 -1000 Date: Mon, 26 Jun 2000 11:00:23 -1000 From: Nava.Zvaig NZvaig@adtech-inc.com Subject: [Isis-wg] ISIS code 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_01BFDFB1.912A6686 Content-Type: text/plain; charset="iso-8859-1" Hi all, I resubmit this message in case someone has some info... > Is there any software/shareware/freeware available for ISIS and ISIS-TE? > TIA, > Nava ------_=_NextPart_001_01BFDFB1.912A6686 Content-Type: text/html; charset="iso-8859-1" ISIS code

Hi all,

I resubmit this message in case someone has some info...


> Is there any software/shareware/freeware available for ISIS and ISIS-TE?

> TIA,
> Nava

------_=_NextPart_001_01BFDFB1.912A6686-- From naiming@redback.com Mon, 26 Jun 2000 15:39:53 -0700 Date: Mon, 26 Jun 2000 15:39:53 -0700 From: Naiming Shen naiming@redback.com Subject: [Isis-wg] Areas in ISIS For IP, level-1 routes can be imported into level-2 domain on the L12 routers. This is done by default on some of the popular ISIS implementations. ] ]For CLNP, you would need to run L1 as well as L2. Otherwise, ]you wouldn't be able to manage the routers in Area 0. ]When a packet arrives in Area 0, the L1 FDB would ]be consulted, but would be empty or missing, causing the ]packet to be dropped. ] ]I suspect the same might be true for IP traffic. ] ]At 09:05 AM 6/21/00 -0700, Abe Martey wrote: ]> ]> ]>On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: ]>> Small question (related to below), if you do create a separate backbone ]>> (physically, or at least similar to OSPF area 0), is it then needed or ]>> advantagous to have L1 routing in this area. Instead of just L2? ]> ]>You could have a physical area x designated as the "core" of the ]>backbone..and all routers in this area don't have to run L1. Actually ]>they shouldn't since it'll be a resource waste....however your ]>"true" isis backbone will extend to the L1L2 border routers of the ]>various other areas. ]> ]> [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] ]> ]> |---area 1----| |--area x---| |----Area 2----| ]> |----------isis backbone-----------| ]> ]> ]>Cheers. ]> ]>- abe ]> ]>> ]>> cheers, ]>> Eduard ]>> ]>> > ---------- ]>> > From: Mike Shand[SMTP:mshand@cisco.com] ]>> > Sent: dinsdag 20 juni 2000 20:34 ]>> > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' ]>> > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net ]>> > Subject: RE: [Isis-wg] Areas in ISIS ]>> > ]>> > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: ]>> > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area ]>> > would ]>> > >it? It needs to be L2 or L1/L2 at least. ]>> > ]>> > Were running into terminological inexactitudes here :-) ]>> > ]>> > Yes it does need to be L2, but one way of designing an IS-IS network ]is to ]>> > ]>> > make an area of L1/L2 routers which constitutes the backbone and then ]hang ]>> > ]>> > all the other areas off this one. Of course you need at least one L1/L2 ]>> > router in each of those areas, so the backbone (in the sense we were ]>> > talking before, i.e. the set of connected L2 routers - or the ]distribution ]>> > ]>> > domain of L2 LSPs) spans multiple areas. But it does look rather like ]the ]>> > OSPF case, where the backbone is a single area (0 in that case). ]>> > ]>> > Mike (S) ]>> > ]>> > ]>> ]>> _______________________________________________ ]>> Isis-wg mailing list - Isis-wg@external.juniper.net ]>> http://external.juniper.net/mailman/listinfo/isis-wg ]> ]>-- ]> ]> ]>==.==.==.==.== ]>Abe Martey ]>San Jose, CA ]>408 527 9149 ]> ]>_______________________________________________ ]>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 ]____________________________________________________________________ ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From azinin@cisco.com Tue, 27 Jun 2000 08:13:16 -0700 Date: Tue, 27 Jun 2000 08:13:16 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Areas in ISIS Also, IP forwarding doesn't care about route types. L1 or L2, it just looks for the best match in the very (and single, which is important) routing table. > For IP, level-1 routes can be imported into level-2 domain on the > L12 routers. This is done by default on some of the popular ISIS > implementations. > ] > ]For CLNP, you would need to run L1 as well as L2. Otherwise, > ]you wouldn't be able to manage the routers in Area 0. > ]When a packet arrives in Area 0, the L1 FDB would > ]be consulted, but would be empty or missing, causing the > ]packet to be dropped. > ] > ]I suspect the same might be true for IP traffic. > ] > ]At 09:05 AM 6/21/00 -0700, Abe Martey wrote: > ]> > ]> > ]>On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: > ]>> Small question (related to below), if you do create a separate backbone > ]>> (physically, or at least similar to OSPF area 0), is it then needed or > ]>> advantagous to have L1 routing in this area. Instead of just L2? > ]> > ]>You could have a physical area x designated as the "core" of the > ]>backbone..and all routers in this area don't have to run L1. Actually > ]>they shouldn't since it'll be a resource waste....however your > ]>"true" isis backbone will extend to the L1L2 border routers of the > ]>various other areas. > ]> > ]> [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] > ]> > ]> |---area 1----| |--area x---| |----Area 2----| > ]> |----------isis backbone-----------| > ]> > ]> > ]>Cheers. > ]> > ]>- abe > ]> > ]>> > ]>> cheers, > ]>> Eduard > ]>> > ]>> > ---------- > ]>> > From: Mike Shand[SMTP:mshand@cisco.com] > ]>> > Sent: dinsdag 20 juni 2000 20:34 > ]>> > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > ]>> > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > ]>> > Subject: RE: [Isis-wg] Areas in ISIS > ]>> > > ]>> > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > ]>> > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > ]>> > would > ]>> > >it? It needs to be L2 or L1/L2 at least. > ]>> > > ]>> > Were running into terminological inexactitudes here :-) > ]>> > > ]>> > Yes it does need to be L2, but one way of designing an IS-IS network > ]is to > ]>> > > ]>> > make an area of L1/L2 routers which constitutes the backbone and then > ]hang > ]>> > > ]>> > all the other areas off this one. Of course you need at least one L1/L2 > ]>> > router in each of those areas, so the backbone (in the sense we were > ]>> > talking before, i.e. the set of connected L2 routers - or the > ]distribution > ]>> > > ]>> > domain of L2 LSPs) spans multiple areas. But it does look rather like > ]the > ]>> > OSPF case, where the backbone is a single area (0 in that case). > ]>> > > ]>> > Mike (S) > ]>> > > ]>> > > ]>> > ]>> _______________________________________________ > ]>> Isis-wg mailing list - Isis-wg@external.juniper.net > ]>> http://external.juniper.net/mailman/listinfo/isis-wg > ]> > ]>-- > ]> > ]> > ]>==.==.==.==.== > ]>Abe Martey > ]>San Jose, CA > ]>408 527 9149 > ]> > ]>_______________________________________________ > ]>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 > ]____________________________________________________________________ > ] > ]_______________________________________________ > ]Isis-wg mailing list - Isis-wg@external.juniper.net > ]http://external.juniper.net/mailman/listinfo/isis-wg > - Naiming > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Internet-Drafts@ietf.org Tue, 11 Jul 2000 06:29:49 -0400 Date: Tue, 11 Jul 2000 06:29:49 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mesh-group-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Mesh Groups Author(s) : R. Balay, D. Katz, J. Parker Filename : draft-ietf-isis-wg-mesh-group-01.txt Pages : 9 Date : 10-Jul-00 This document describes a mechanism to reduce redundant packet transmissions for the IS-IS Routing protocol, as described in ISO 10589 [1]. The described mechanism can be used to reduce the flooding of Link State PDUs (LSPs) in IS-IS topologies. The net effect is to engineer a flooding topology for LSPs which is a subset of the physical topology. This draft serves to document the existing behavior in deployed implementations. The draft describes behaviors that are backwards compatible with implementations that do not support this feature. This document is provided to the IETF working group on IS-IS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mesh-group-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-mesh-group-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-mesh-group-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000710151110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mesh-group-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mesh-group-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151110.I-D@ietf.org> --OtherAccess-- --NextPart-- From jparker@nexabit.com Tue, 11 Jul 2000 09:50:40 -0400 Date: Tue, 11 Jul 2000 09:50:40 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Updates to the ISIS Mib I sent out a list of differences and changes to the ISIS working group about 10 days ago, shortly after the MIB was announced on the mailing list. http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-03.txt It appears that my message was too big to be bounced automatically off the mail relay, and it is sitting now in some relay server limbo waiting to be vetted and sent out. If you would like to get a copy of these files, I would be happy to e-mail them to you privately. > Enclosed below is a high-level list of the changes (changes.txt) > and an edited version of (most of) the diffs between versions -02 and -03. > Suggestions and editorial comments always welcome. > > - jeff parker - jeff parker - Lucent Technology From Internet-Drafts@ietf.org Wed, 12 Jul 2000 06:30:02 -0400 Date: Wed, 12 Jul 2000 06:30:02 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-domain-wide-03.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Domain-wide Prefix Distribution with Two-Level IS-IS Author(s) : T. Li, T. Przygienda, H. Smit Filename : draft-ietf-isis-domain-wide-03.txt Pages : 10 Date : 11-Jul-00 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-domain-wide-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-domain-wide-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-domain-wide-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000711134432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-domain-wide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-domain-wide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711134432.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed, 12 Jul 2000 06:32:48 -0400 Date: Wed, 12 Jul 2000 06:32:48 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-snp-checksum-02.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Optional Checksums in ISIS Author(s) : A. Przygienda Filename : draft-ietf-isis-wg-snp-checksum-02.txt Pages : 3 Date : 11-Jul-00 This draft describes an optional extension to IS-IS [ISO90, Cal90a, Cal90b], used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. IS-IS originally doesn't provide CSNP adn PSNP checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional TLV providing checksums. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-snp-checksum-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-snp-checksum-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-snp-checksum-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000711142807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-snp-checksum-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-snp-checksum-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711142807.I-D@ietf.org> --OtherAccess-- --NextPart-- From Radia.Perlman@East.Sun.COM Wed, 12 Jul 2000 13:14:50 -0400 (EDT) Date: Wed, 12 Jul 2000 13:14:50 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-snp-checksum-02.txt >> The implementation MUST either omit the optional checksum on an >> interface or send a 0 checksum value if it includes in the PDU >> signatures that provide equivalent or stronger functionality, such as >> HMAC or MD5. Just for curiosity...why not just say it must omit it? What value is there in including the TLV with a 0 checksum value? Radia From david.wang@metro-optix.com Thu, 6 Jul 2000 10:24:55 -0500 Date: Thu, 6 Jul 2000 10:24:55 -0500 From: David Wang david.wang@metro-optix.com Subject: [Isis-wg] Basic Question about IS-IS Routing protocol Dear Friends, Thank you very much for all the precious help you give to me. I am reading those documents and books. At the mean time I want to ask your help one more time. 1. What documents specify all the layer 2 encapsulations for the IS-IS PDU in IP-only environment? For example when use Ethernet, 802.3/LLC frame format must be used and Ethernet II frame format cannot be used. I got this information from draft-kaplan-is-is-ext-eth-02.txt. I assume I should use 0xFE for the SAP value for ISO in the 802.3/LLC frame. How about PPP encapsulation? What value should be put in the "protocol" field of the PPP frame and what NCP packets are used to choose and configure the network-layer protocols? For HDLC what has to be done to accommodate the IS-IS PDU? 2. There is no CLNP address in the IS-IS PDU but why FRC 1195 still ask each node to have OSI-style address? Following are from RFC 1195 section 3.3 : 3.3 Addressing Routers in IS-IS Packets The IS-IS packet formats explicitly require that OSI-style addresses of routers appear in the IS-IS packets. For example, these addresses are used to determine area membership of routers. It is therefore necessary for all routers making use of the IS-IS protocol to have OSI style addresses assigned. For IP-only routers, these addresses will be used only in the operation of the IS-IS protocol, and are not used for any other purpose (such as the operation of EGP, ICMP, or other TCP/IP protocols). 3. What is the possibility that the "IS-IS over IPv4" and the "Extended Ethernet Frame Size Support" be accepted by the industry? Thank You very much David From prz@redback.com Wed, 12 Jul 2000 11:57:16 -0700 Date: Wed, 12 Jul 2000 11:57:16 -0700 From: Tony Przygienda prz@redback.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-snp-checksum-02.txt Radia Perlman - Boston Center for Networking wrote: > >> The implementation MUST either omit the optional checksum on an > >> interface or send a 0 checksum value if it includes in the PDU > >> signatures that provide equivalent or stronger functionality, such as > >> HMAC or MD5. > > Just for curiosity...why not just say it must omit it? What value is > there in including the TLV with a 0 checksum value? probably MUST omit would be better, you're right ;-) -- tony From dkatz@juniper.net Wed, 12 Jul 2000 20:16:22 -0700 (PDT) Date: Wed, 12 Jul 2000 20:16:22 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Basic Question about IS-IS Routing protocol 1. What documents specify all the layer 2 encapsulations for the IS-IS PDU in IP-only environment? For example when use Ethernet, 802.3/LLC frame format must be used and Ethernet II frame format cannot be used. I got this information from draft-kaplan-is-is-ext-eth-02.txt. I assume I should use 0xFE for the SAP value for ISO in the 802.3/LLC frame. How about PPP encapsulation? What value should be put in the "protocol" field of the PPP frame and what NCP packets are used to choose and configure the network-layer protocols? For HDLC what has to be done to accommodate the IS-IS PDU? Standard OSI framing is used, so you get 802.2/SAP on LAN media, and RFC 1377 for PPP. The cisco HDLC kludge is to use ethertype FEFE. 2. There is no CLNP address in the IS-IS PDU but why FRC 1195 still ask each node to have OSI-style address? Following are from RFC 1195 section 3.3 : Backward compatibility, and laziness. There needs to be a six octet system ID, and at least a one octet area address, so you could configure it any way you want to that will produce values for these items. The first pervasive implementation was dual-mode and so NSAP addresses made sense; later implementations did it the same way since you need to configure those bytes somehow. 3. What is the possibility that the "IS-IS over IPv4" and the "Extended Ethernet Frame Size Support" be accepted by the industry? Extended frame size is likely (since folks want to use >1500 MTU on gigE and also want to use IS-IS), IPv4 framing doesn't seem to have much support among the dominant players (since it buys little or nothing, adds complexity, and removes one of the nice properties of IS-IS, namely, resistance to packet bombs.) --Dave From Internet-Drafts@ietf.org Thu, 13 Jul 2000 06:26:59 -0400 Date: Thu, 13 Jul 2000 06:26:59 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ipv6-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Routing IPv6 with IS-IS Author(s) : C. Hopps Filename : draft-ietf-isis-ipv6-01.txt Pages : 6 Date : 12-Jul-00 This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol [0]. The method utilizes the same mechanisms described in RFC 1195 [1]. This is accomplished by adding 2 new TLVs and defining their use. These new TLVs are patterned from the ones described in 'IS-IS extensions for Traffic Engineering' [2]. Just as in RFC 1195 [1] with IPv4 and OSI, this method allows one to route both IPv4 and IPv6 using a single intra-domain routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-ipv6-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-ipv6-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000712140131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140131.I-D@ietf.org> --OtherAccess-- --NextPart-- From phigginson@ascend.com Fri, 14 Jul 2000 16:20:04 +0100 Date: Fri, 14 Jul 2000 16:20:04 +0100 From: Peter Higginson phigginson@ascend.com Subject: [Isis-wg] ISIS at Pittsburg IETF? Is there going to be a meeting, we don't appear on the current draft agenda? Peter From Peter.Higginson@ascend.com Sun, 16 Jul 2000 08:15:08 +0100 Date: Sun, 16 Jul 2000 08:15:08 +0100 From: Peter Higginson Peter.Higginson@ascend.com Subject: [Isis-wg] ISIS at Pittsburg IETF? Is there going to be a meeting, we don't appear on the current draft agenda? Peter From Internet-Drafts@ietf.org Mon, 17 Jul 2000 06:39:12 -0400 Date: Mon, 17 Jul 2000 06:39:12 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-03.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Three-Way Handshake for IS-IS Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-3way-03.txt Pages : 7 Date : 14-Jul-00 The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-3way-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-3way-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000714142554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-3way-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-3way-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714142554.I-D@ietf.org> --OtherAccess-- --NextPart-- From kini@bell-labs.com Sun, 16 Jul 2000 03:01:24 -0400 Date: Sun, 16 Jul 2000 03:01:24 -0400 From: Sriganesh Kini kini@bell-labs.com Subject: [Isis-wg] status of TE draft ? What is the status of the draft draft-ietf-isis-traffic-0x.txt ? Thanks === Sriganesh Kini From kini@dnrc.bell-labs.com Mon, 17 Jul 2000 16:05:10 -0400 Date: Mon, 17 Jul 2000 16:05:10 -0400 From: Sriganesh Kini kini@dnrc.bell-labs.com Subject: [Isis-wg] status of TE draft ? What is the latest status of the draft draft-ietf-isis-traffic-xx.txt ? Thanks === Sriganesh Kini From flefauch@cisco.com Fri, 21 Jul 2000 11:24:20 +0200 Date: Fri, 21 Jul 2000 11:24:20 +0200 From: Francois Le Faucheur flefauch@cisco.com Subject: [Isis-wg] Announcing FYI: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to IS-IS, OSPF, RSVP and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki Filename : draft-lefaucheur-diff-te-ext-00.txt Pages : 14 Date : 14-Jul-00 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to OSPF, ISIS, RSVP and CR-LDP for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-ext-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lefaucheur-diff-te-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lefaucheur-diff-te-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20000714142705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lefaucheur-diff-te-ext-00.txt Francois From flefauch@cisco.com Fri, 21 Jul 2000 11:24:20 +0200 Date: Fri, 21 Jul 2000 11:24:20 +0200 From: Francois Le Faucheur flefauch@cisco.com Subject: [Isis-wg] Announcing FYI: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to IS-IS, OSPF, RSVP and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki Filename : draft-lefaucheur-diff-te-ext-00.txt Pages : 14 Date : 14-Jul-00 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to OSPF, ISIS, RSVP and CR-LDP for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-ext-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lefaucheur-diff-te-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lefaucheur-diff-te-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20000714142705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lefaucheur-diff-te-ext-00.txt Francois From iesg-secretary@ietf.org Fri, 21 Jul 2000 09:27:06 -0400 Date: Fri, 21 Jul 2000 09:27:06 -0400 From: The IESG iesg-secretary@ietf.org Subject: [Isis-wg] Document Action: Domain-wide Prefix Distribution with Two-Level IS-IS to Informational The IESG has approved the Internet-Draft 'Domain-wide Prefix Distribution with Two-Level IS-IS' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are David Oran and Rob Coltun. From azinin@cisco.com Sat, 22 Jul 2000 16:12:23 -0700 Date: Sat, 22 Jul 2000 16:12:23 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Flooding optimization ID Folks, FYI the draft below. http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-00.txt Authors: Alex Zinin, Mike Shand. Abstract: The flooding algorithm is one of the most important parts of any link state routing protocol. It ensures that all routers within a link state domain converge on the same topological information within a finite period of time. To ensure reliability, typical implementations of the flooding algorithm send new information via all interfaces other than the one the new piece of information was received on. This redundancy is necessary to guarantee that flooding is performed reliably, but implies considerable overhead of utilized bandwidth and CPU time if neighboring routers are connected with more than one link. This document describes a method that reduces this overhead. -- Alex Zinin From jjl@one.com Mon, 24 Jul 2000 13:20:52 -0400 Date: Mon, 24 Jul 2000 13:20:52 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Flooding optimization ID This RFC looks like a great idea. I have one concern, though, for the IS-IS changes. I think it would be a mistake to place L2-only circuits in the same group as circuits to L1 routers. If we do, we may inadvertently forward L1 packets on L2-only circuits, which would not be backwards compatible. A receiving system might drop it rather than propagate it. I'm not sure what the best fix is. L2 groups could kept separately from L1 groups, where a group's level indicates which kinds of PDUs can be forwarded on it. Thus L2+L1 routers would have two circuit groups. The rest of the text (other than the part defining the groups) could remain the same. Regards, Jeff At 04:12 PM 7/22/00 -0700, Alex Zinin wrote: > Folks, > > FYI the draft below. > > http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-00.txt > > Authors: Alex Zinin, Mike Shand. > > Abstract: > > The flooding algorithm is one of the most important parts of any link > state routing protocol. It ensures that all routers within a link > state domain converge on the same topological information within a > finite period of time. To ensure reliability, typical implementations > of the flooding algorithm send new information via all interfaces > other than the one the new piece of information was received on. This > redundancy is necessary to guarantee that flooding is performed > reliably, but implies considerable overhead of utilized bandwidth and > CPU time if neighboring routers are connected with more than one > link. This document describes a method that reduces this overhead. >-- >Alex Zinin > > > >_______________________________________________ >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 azinin@cisco.com Tue, 25 Jul 2000 14:27:08 -0700 Date: Tue, 25 Jul 2000 14:27:08 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Flooding optimization ID Jeff: It is definitely meant to keep L1 and L2 groups separately... We changed wording for clarity. Thanks for pointing this out. http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt -- Alex Zinin Monday, July 24, 2000, 10:20 AM, Jeff Learman wrote: > This RFC looks like a great idea. I have one concern, though, > for the IS-IS changes. > I think it would be a mistake to place L2-only circuits in the > same group as circuits to L1 routers. If we do, we may > inadvertently forward L1 packets on L2-only circuits, which would > not be backwards compatible. A receiving system might drop it > rather than propagate it. > I'm not sure what the best fix is. L2 groups could kept separately > from L1 groups, where a group's level indicates which kinds of PDUs > can be forwarded on it. Thus L2+L1 routers would have two circuit > groups. The rest of the text (other than the part defining the groups) > could remain the same. > Regards, > Jeff > At 04:12 PM 7/22/00 -0700, Alex Zinin wrote: >> Folks, >> >> FYI the draft below. >> >> http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-00.txt >> >> Authors: Alex Zinin, Mike Shand. >> >> Abstract: >> >> The flooding algorithm is one of the most important parts of any link >> state routing protocol. It ensures that all routers within a link >> state domain converge on the same topological information within a >> finite period of time. To ensure reliability, typical implementations >> of the flooding algorithm send new information via all interfaces >> other than the one the new piece of information was received on. This >> redundancy is necessary to guarantee that flooding is performed >> reliably, but implies considerable overhead of utilized bandwidth and >> CPU time if neighboring routers are connected with more than one >> link. This document describes a method that reduces this overhead. >>-- >>Alex Zinin >> >> >> >>_______________________________________________ >>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 > ____________________________________________________________________ > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From pst@juniper.net Tue, 25 Jul 2000 16:30:18 -0700 (PDT) Date: Tue, 25 Jul 2000 16:30:18 -0700 (PDT) From: Paul Traina pst@juniper.net Subject: [Isis-wg] isis-wg mailing list administrative information The machine that runs the IS-IS mailing list was mis-configured in our DNS for a short period of time. That caused it to generate mail sourced from a (seemingly) invalid host name, which set off spam filters for a number of you causing your machines to bounce mail sent via the list. You may wish to check the IS-IS WG archives at: http://external.juniper.net/mailman/listinfo/isis-wg for any e-mail your site might have bounced in the last week. I'm sorry for the problem, the NT weenie who messed with the DNS has been appropriately "educated." We now return you to your regular bits and bytes, Paul From prz@redback.com Thu, 27 Jul 2000 12:21:46 -0700 (PDT) Date: Thu, 27 Jul 2000 12:21:46 -0700 (PDT) From: prz@redback.com prz@redback.com Subject: [Isis-wg] Draft Agenda ... Here what I gathered so far Draft Agenda for Pittsburgh: 5 mins Tony Agenda bashing & result of last calls x draft-ietf-isis-domain-wide-02 x draft-ietf-isis-wg-mesh-group-00 x draft-kaplan-isis-ext-eth-01 10 mins Kireeti draft-kompella-isis-ompls-extensions-00 5 mins Mike draft-ietf-zinin-flood-opt-01 10 mins Francois draft-lefaucheur-diff-te-ext-00 5 mins Tony update draft-ietf-isis-wg-snp-checksum-02 I may have missed a request or two since I was digging up my last 3 months worth of mail to find all those and as goes without saying, it's a lot of mail ;-) Comments pls today/tommorow --- tony From prz@net4u.ch Sun, 30 Jul 2000 07:02:03 +0200 (MEST) Date: Sun, 30 Jul 2000 07:02:03 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] ISIS Agenda for Pittsburgh Agenda for Pittsburgh: 5 mins Tony Agenda bashing & result of last calls x draft-ietf-isis-domain-wide-02 x draft-ietf-isis-wg-mesh-group-00 x draft-kaplan-isis-ext-eth-01 10 mins Kireeti draft-kompella-isis-ompls-extensions-00 5 mins Mike draft-ietf-zinin-flood-opt-01 10 mins Francois draft-lefaucheur-diff-te-ext-00 10 mins Christian draft-ietf-isis-ipv6-01 5 mins Tony update draft-ietf-isis-wg-snp-checksum-02 From jchin@equipecom.com Thu, 3 Aug 2000 12:26:39 -0400 Date: Thu, 3 Aug 2000 12:26:39 -0400 From: Jasper Chin jchin@equipecom.com Subject: [Isis-wg] General info about IS-IS I'm new to IS-IS and am looking to learn about this routing protocol. Could anyone suggest a roadmap of reading material that would be beneficial? Is there a FAQ on this topic? TIA, J. Chin From oran@cisco.com Sun, 30 Jul 2000 00:18:27 -0400 Date: Sun, 30 Jul 2000 00:18:27 -0400 From: Dave Oran oran@cisco.com Subject: [Isis-wg] FW: SC6 Liaison Statement to the IETF on IS-IS Routing This is a multi-part message in MIME format. ------=_NextPart_000_004E_01BFF9BB.AF0ABBA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004F_01BFF9BB.AF10D620" ------=_NextPart_001_004F_01BFF9BB.AF10D620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: jhouldsworth [mailto:jhouldsworth@iclway.co.uk] Sent: Tuesday, July 25, 2000 3:53 AM To: dave oran Cc: Jim Long Subject: SC6 Liaison Statement to the IETF on IS-IS Routing Dave, you should have received the attached liaison statement from the SC6 Secretariat on the proposed creation of an updated version of the IS-IS Standard. I haven't seen it on the wire so I thought it wise to make sure that you have a copy before the upcoming IETF meeting. You will also see that SC6 is requesting a short BOF at the San Diego meeting to make sure that the IETF requirements are properly taken into account. I will not be at the August meeting but both Jim Long (the new WG7 Convenor) and I will be in San Diego. We welcome your comments and assistance with scheduling the requested BOF with your group. Regards Jack Houldsworth ------=_NextPart_001_004F_01BFF9BB.AF10D620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
-----Original Message-----
From: jhouldsworth=20 [mailto:jhouldsworth@iclway.co.uk]
Sent: Tuesday, July 25, = 2000 3:53=20 AM
To: dave oran
Cc: Jim Long
Subject: SC6 = Liaison=20 Statement to the IETF on IS-IS Routing

Dave, you should have received the = attached=20 liaison statement from the SC6 Secretariat on the proposed creation of = an=20 updated version of the IS-IS Standard.  I haven't seen it on the = wire so I=20 thought it wise to make sure that you have a copy before the upcoming = IETF=20 meeting. 
 
You will also see that SC6 is requesting a short BOF = at the=20 San Diego meeting to make sure that the IETF requirements are properly = taken=20 into account.  I will not be at the August meeting but both Jim = Long (the=20 new WG7 Convenor) and I will be in San Diego.
 
We welcome your comments and assistance with = scheduling the=20 requested BOF with your group.
 
Regards
 
Jack Houldsworth
------=_NextPart_001_004F_01BFF9BB.AF10D620-- ------=_NextPart_000_004E_01BFF9BB.AF0ABBA0 Content-Type: application/msword; name="isisliaison.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="isisliaison.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJQAAAAAAAAAA EAAAJwAAAAEAAAD+////AAAAACQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEARwAJCAAAABK/AAAAAAAAEAAAAAAABAAACQ4AAA4AYmpiao7ZjtkAAAAAAAAAAAAAAAAAAAAA AAAJBBYAHhYAAOyzAQDsswEACQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJIAAAAAAAAAkgAAAJIA AAAAAAAAkgAAAAAAAACSAAAAAAAAAJIAAAAAAAAAkgAAABQAAAAAAAAAAAAAAKYAAAAAAAAApgAA AAAAAACmAAAAAAAAAKYAAAAAAAAApgAAAAwAAACyAAAADAAAAKYAAAAAAAAAFwUAALYAAADKAAAA AAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAA AAAA3AQAAAIAAADeBAAAAAAAAN4EAAAAAAAA3gQAAAAAAADeBAAAAAAAAN4EAAAAAAAA3gQAACQA AADNBQAA9AEAAMEHAAB6AAAAAgUAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgAAAAAAAADKAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAAIFAAAAAAAA AgEAAAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAAAAAAAAAAAMoAAAAAAAAAygAAAAAAAAAC AQAAAAAAAAIBAAAAAAAAAgEAAAAAAADKAAAACgAAAJIAAAAAAAAAygAAAAAAAACSAAAAAAAAAMoA AAAAAAAA3AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAApgAAAAAAAACmAAAAAAAAAJIAAAAAAAAAkgAA AAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAADcBAAAAAAAAAIBAADaAwAAAgEAAAAAAAAAAAAA AAAAANwEAAAAAAAAkgAAAAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3AQAAAAAAADKAAAAAAAAAL4AAAAMAAAAAFkz2gn2 vwGmAAAAAAAAAKYAAAAAAAAA1AAAAC4AAADcBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQkJ CQkJCQkJCTdQMjANDVRpdGxlOiBMaWFpc29uIFJlcG9ydCB0byB0aGUgSUVURiBSb3V0aW5nIEFy ZWEgRGlyZWN0b3Igb24gMm5kIENEIGZvciBJU08vSUVDIDEwNTg5IChJUy1JUyBSb3V0aW5nKQ0N U291cmNlOiBJU08vSUVDIEpUQzEvU0M2DQ1JU08vSUVDIEpUQzEvU0M2IFdHNyBpcyBjdXJyZW50 bHkgY3JlYXRpbmcgYSBuZXcgYmFzZSB0ZXh0IGZvciBJU08xMDU4OS4gICBTQzYgaW50ZW5kcyB0 byB1c2UgdGhpcyBuZXcgdmVyc2lvbiAyIGFzIHRoZSBiYXNlIGZvciBhZGRpbmcgdGhlIGVuaGFu Y2VtZW50cyB3aGljaCBoYXZlIGJlZW4gcmVxdWVzdGVkIGJ5IHRoZSBJRVRGIHRvIG9wdGltaXNl IHRoZSB1c2Ugb2YgSVNPIDEwNTg5IGZvciBJbnRlcm5ldCByb3V0aW5nIHNvbHV0aW9ucy4gIFRo ZSBJRVRGIElTLUlTIFdHIGNvbnZlbm9yIG9yaWdpbmFsbHkgaWRlbnRpZmllZCAgSW50ZXJuZXQg RHJhZnRzOiA8ZHJhZnQtaWV0Zi1pc2lzLWR5bmFtZS0wMi50eHQ+IGFuZCA8ZHJhZnQtaWV0Zi1p c2lzLXRyYWZmaWMtMDEudHh0PiBhcyB0aGUgc291cmNlIGRvY3VtZW50cyB3aGljaCBzcGVjaWZ5 IHRoZXNlIGVuaGFuY2VtZW50cy4gICBTQzYgaW52aXRlcyB0aGUgSUVURiB0byBjb25maXJtIHRo YXQgdGhlIGFib3ZlIEludGVybmV0IERyYWZ0cyBhcmUgdGhlIGNvcnJlY3QgcmVmZXJlbmNlcyBh bmQgdG8gaW5mb3JtIFNDNiBpZiB0aGVyZSBhcmUgYWRkaXRpb25hbCBJRVRGIGRvY3VtZW50cyB3 aGljaCByZWZlciB0byBhbnkgb3RoZXIgcmVxdWlyZW1lbnRzIGZvciAgSVMtSVMgUm91dGluZyBl bmhhbmNlbWVudHMuDQ0gU0M2IHdvdWxkIGxpa2UgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgSUVURiBv biBjbGFyaWZ5aW5nIHRoZSBkZXRhaWxlZCByZXF1aXJlbWVudHMgaW4gdGhlIGhvcGUgdGhhdCBp dCBtYXkgYmUgcG9zc2libGUgdG8gIGludHJvZHVjZSB0aGVtIGR1cmluZyB0aGUgZWRpdGluZyBj eWNsZSBmb3IgdmVyc2lvbiAyIG9mIHRoZSBzdGFuZGFyZC4gICBUbyB0aGlzIGVuZCwgd2Ugd291 bGQgbGlrZSB0aGUgUm91dGluZyBBcmVhIERpcmVjdG9ycyB0byBhcnJhbmdlIGFuIElTLUlTIEJP RiBhdCB0aGUgU2FuIERpZWdvIElFVEYgbWVldGluZyB0byBkaXNjdXNzIHRoZXNlIHJlcXVpcmVt ZW50cyBhbmQgaG93IHRoZXkgY2FuIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBuZXcgdmVyc2lv biBvZiAgSVNPIDEwNTg5Lg0NIFNDNiB3aWxsIHBvc3QgYW4gaW5pdGlhbCBkcmFmdCB2ZXJzaW9u IG9mIHRoZSBuZXcgYmFzZSBkb2N1bWVudCBhcyBhbiBJbnRlcm5ldCBEcmFmdCBpbiBBdWd1c3Qg MjAwMCBidXQgdGhpcyB3aWxsIG5vdCBjb250YWluIHRoZSBjaGFuZ2VzIHJlcXVlc3RlZCBieSB0 aGUgSUVURi4gIEEgYmFsbG90IGNsb3N1cmUgZGF0ZSBvZiBGZWJydWFyeSAyMDAxIGhhcyBiZWVu IHNldCBmb3IgdGhlIDJuZCBDRCBCYWxsb3QgdG8gYWxsb3cgaW5jb3Jwb3JhdGlvbiBvZiBmaW5h bCBpbnB1dCBvbiB0aGUgSW50ZXJuZXQgcmVxdWlyZW1lbnRzIGlmIHRoZXkgY2FuIGJlIGFncmVl ZCBhdCB0aGUgRGVjZW1iZXIgMjAwMCBJRVRGIG1lZXRpbmcuIA0NRm9yIGluZm9ybWF0aW9uLCB0 aGUgY3VycmVudCBpbnN0cnVjdGlvbnMgdG8gdGhlIGVkaXRvciBhcmUgdGhhdCBoZSBzaG91bGQg dXNlIElTTy9JRUMgMTA1ODk6MTk5MiBhcyBhIGJhc2UgZm9yIGVkaXRpbmcsIGFuZCBzaGFsbCBh cHBseSB0aGUgbWluaW11bSB0ZXh0dWFsIGNoYW5nZXMgbWFuZGF0ZWQgYnkgdGhlIGZvbGxvd2lu ZyBUQ3MgYW5kIERSczoNDSAgIElTTy9JRUMgMTA1ODk6MTk5Mi9Db3IuMToxOTkzDSAgIElTTy9J RUMgMTA1ODk6MTk5Mi9Db3IuMjoxOTk2DSAgIElTTy9JRUMgMTA1ODk6MTk5Mi9Db3IuMzoxOTk2 DSAgIElTTy9JRUMgMTA1ODk6MTk5Mi9BbWQgMToxOTk2DSAgIDZOMTAzMjMgLSBEZWZlY3QgUmVw b3J0cyA3LTI2DSAgIDZOMTA2NTkgLSBEZWZlY3QgUmVwb3J0cyAyNy0zNA0gICA2TjEwNzMzIC0g VGVjaG5pY2FsIENvcnJpZ2VuZHVtIDQNICAgVGhlIGVkaXRvciB3aWxsIGFsc28gYXBwbHkgdGhl IG1pbmltYWwgY2hhbmdlcyBuZWNlc3NhcnkgdG8gcmVzb2x2ZSBhZGRpdGlvbmFsIERlZmVjdCBS ZXBvcnRzIDM1LTQ0Lg0NSWYgU0M2IGFuZCB0aGUgSUVURiBhcmUgdW5hYmxlIHRvIHJlc29sdmUg dGhlIHJlcXVpcmVkIGNoYW5nZXMsIHRoZSBFZGl0b3Igd2lsbCBhZGQgYSB0ZW1wb3Jhcnkgbm90 ZSB0byB0aGUgY292ZXIgcGFnZSBhbmQgdGhlIHNjb3BlIGNsYXVzZSBzdGF0aW5nIHRoYXQ6ICCT IElTTyAxMDU4OSBkb2VzIG5vdCBjdXJyZW50bHkgaW5jbHVkZSB0aGUgZXh0ZW5zaW9ucyBvcmln aW5hbGx5IHJlcXVlc3RlZCBieSB0aGUgSUVURiBpbiBJbnRlcm5ldCBEcmFmdHM6IDxkcmFmdC1p ZXRmLWlzaXMtZHluYW1lLTAyLnR4dD4gYW5kIDxkcmFmdC1pZXRmLWlzaXMtdHJhZmZpYy0wMS50 eHQ+LiAgIE5hdGlvbmFsIEJvZHkgYW5kIExpYWlzb24gb3JnYW5pemF0aW9uIGNvbW1lbnRzIGFy ZSBpbnZpdGVkIG9uIHRoZSBiZXN0IHdheSB0byBwcm9ncmVzcyB0aGVzZSBleHRlbnNpb25zLpQN DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAoEAAAP BAAAEAQAAEwEAABOBAAAjgQAAAkOAAAA+wD59fkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY1CIFIKgEAAzUIgQc1CIFDShwAAAcABAAADwQAABAE AAB0BAAAdQQAAI4EAACPBAAALgcAAC8HAADBCAAAwggAACwKAAAtCgAA+QoAAPoKAAAbCwAAPAsA AF0LAAB+CwAAnwsAAMELAADmCwAATgwAAE8MAAAIDgAACQ4AAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAGQAEAAAPBAAAEAQA AHQEAAB1BAAAjgQAAI8EAAAuBwAALwcAAMEIAADCCAAALAoAAC0KAAD5CgAA+goAABsLAAA8CwAA XQsAAH4LAACfCwAAwQsAAOYLAABODAAATwwAAAgOAAAJDgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZHAAfsNAvILDgPSGw CAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAA8ACgABAFsADwAC AAAAAAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkEAAAAAAAAAAAAAAAA AAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABG AG8AbgB0AAAAAAAAAAAAAAAAAAAAAAAJCgAABQAAFgAAAAD/////AAQAAAkOAAAIAAAAAAQAAAkO AAAJAAAAAAQAAAkOAAAKAAAAAAAAAAsKAAAHAAAAAAAvAwAAMAMAAPIDAACyBAAAuQQAAMAEAAAL CgAABwAHAAcABwAaAAcABwD//xQAAAALAGgAbwB1AGwAZABzAHcAbwByAHQAaAASAEEAOgBcAGwA aQBhAGkAcwBvAG4AaQBzAGkAcwAuAGQAbwBjAAsAaABvAHUAbABkAHMAdwBvAHIAdABoABIAQQA6 AFwAbABpAGEAaQBzAG8AbgBpAHMAaQBzAC4AZABvAGMACwBoAG8AdQBsAGQAcwB3AG8AcgB0AGgA EgBBADoAXABsAGkAYQBpAHMAbwBuAGkAcwBpAHMALgBkAG8AYwALAGgAbwB1AGwAZABzAHcAbwBy AHQAaAAqAEMAOgBcAGQAbwBjAHUAbQBlAG4AdABzAFwAcwB0AGEAbgBkAGEAcgBkAHMAXABzAGMA NgBcAGwAaQBhAGkAcwBvAG4AaQBzAGkAcwAuAGQAbwBjAAsAaABvAHUAbABkAHMAdwBvAHIAdABo ABIAQQA6AFwAbABpAGEAaQBzAG8AbgBpAHMAaQBzAC4AZABvAGMAEABKAGEAYwBrACAASABvAHUA bABkAHMAdwBvAHIAdABoACYAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABvAG0AXAAy ADcAMQBcAGwAaQBhAGkAcwBvAG4AaQBzAGkAcwAuAGQAbwBjABAASgBhAGMAawAgAEgAbwB1AGwA ZABzAHcAbwByAHQAaAAuAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAcwB0AGEAbgBk AGEAcgBkAHMAXABpAHMAdAA2AFwAaQBzAGkAcwBsAGkAYQBpAHMAbwBuAC4AZABvAGMAEABKAGEA YwBrACAASABvAHUAbABkAHMAdwBvAHIAdABoAC4AQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0 AHMAXABzAHQAYQBuAGQAYQByAGQAcwBcAGkAcwB0ADYAXABpAHMAaQBzAGwAaQBhAGkAcwBvAG4A LgBkAG8AYwAQAEoAYQBjAGsAIABIAG8AdQBsAGQAcwB3AG8AcgB0AGgALgBDADoAXABNAHkAIABE AG8AYwB1AG0AZQBuAHQAcwBcAHMAdABhAG4AZABhAHIAZABzAFwAaQBzAHQANgBcAGkAcwBpAHMA bABpAGEAaQBzAG8AbgAuAGQAbwBjABAASgBhAGMAawAgAEgAbwB1AGwAZABzAHcAbwByAHQAaAAt AEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAcwB0AGEAbgBkAGEAcgBkAHMAXAB3AGcA NwBcAGkAcwBpAHMAbABpAGEAaQBzAG8AbgAuAGQAbwBjAP9AAYABAF8BAABfAQAABNh0AAcABwBf AQAAAAAAAF8BAAAAAAAAAhAAAAAAAAAACQoAAFAAAAgAQAAAAwAAAEcWkAEAAAICBgMFBAUCAwQD AAAAAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUW kAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEA AAILBgQCAgICAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAAiAAQA8AiIGAAA 0AIAAGgBAAAAABvKR0YbykdGAAAAAAIAAAAAAHMBAABGCAAAAQAEAAAABAADEBEAAAAAAAAAAAAA AAEAAQAAAAEAAAAAAAAAJAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACA ADIwAAAQABkAZAAAABkAAAApCgAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAAALAEUAdABoAGEAbgAg AEYAcgBvAG0AZQAAAAUARQB0AGgAYQBuAAAACABFAFcALwBMAE4ALwBDAEIAEABKAGEAYwBrACAA SABvAHUAbABkAHMAdwBvAHIAdABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAA AAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAgAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKwA AAAEAAAAuAAAAAUAAADMAAAABgAAANwAAAAHAAAA6AAAAAgAAAD4AAAACQAAABQBAAASAAAAIAEA AAoAAAA8AQAADAAAAEgBAAANAAAAVAEAAA4AAABgAQAADwAAAGgBAAAQAAAAcAEAABMAAAB4AQAA AgAAAOQEAAAeAAAADAAAAEV0aGFuIEZyb21lAB4AAAABAAAAAHRoYR4AAAAJAAAARVcvTE4vQ0IA bWUAHgAAAAYAAABFdGhhbgBDQh4AAAABAAAAAHRoYR4AAAAHAAAATm9ybWFsAEIeAAAAEQAAAEph Y2sgSG91bGRzd29ydGgAAGQAHgAAAAIAAAAyAGNrHgAAABMAAABNaWNyb3NvZnQgV29yZCA4LjAA AEAAAAAAAAAAAAAAAEAAAAAA+ny4Cfa/AUAAAAAA+ny4Cfa/AQMAAAABAAAAAwAAAHMBAAADAAAA RggAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC 1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5IAQAABAEAAAwAAAABAAAAaAAAAA8A AABwAAAABQAAAIwAAAAGAAAAlAAAABEAAACcAAAAFwAAAKQAAAALAAAArAAAABAAAAC0AAAAEwAA ALwAAAAWAAAAxAAAAA0AAADMAAAADAAAAOQAAAACAAAA5AQAAB4AAAAUAAAATHVjZW50IFRlY2hu b2xvZ2llcwADAAAAEQAAAAMAAAAEAAAAAwAAACkKAAADAAAAsw0IAAsAAAAAAAAACwAAAAAAAAAL AAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAMAAAARXRoYW4gRnJvbWUADBAAAAIAAAAeAAAABgAAAFRp dGxlAAMAAAABAAAAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAA AF9QSURfR1VJRAACAAAA5AQAAEEAAABOAAAAewA0AEQAQgAwAEUAMAA1ADUALQA2AEIANgAyAC0A NAAzADkAQwAtAEEARgBFADgALQAxADIARgAyADEANwAxAEUANwBDADQAOAB9AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAP7///8NAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA/v///xUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAD+////HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAAP7////9////JgAA AP7////+/////v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA RgAAAADAQvPZCfa/AeAhRNoJ9r8BKAAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgH/////BQAAAP////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAABAAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC AQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeFgAA AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFAAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0 IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_004E_01BFF9BB.AF0ABBA0 Content-Type: application/msword; name="isisinstruct.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="isisinstruct.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIwAAAAAAAAAA EAAAJQAAAAEAAAD+////AAAAACIAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEARwAJCAAAABK/AAAAAAAAEAAAAAAABAAAQwoAAA4AYmpiao7ZjtkAAAAAAAAAAAAAAAAAAAAA AAAJBBYAHhIAAOyzAQDsswEAQwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJIAAAAAAAAAkgAAAJIA AAAAAAAAkgAAAAAAAACSAAAAAAAAAJIAAAAAAAAAkgAAABQAAAAAAAAAAAAAAKYAAAAAAAAApgAA AAAAAACmAAAAAAAAAKYAAAAAAAAApgAAAAwAAACyAAAADAAAAKYAAAAAAAAAhwUAALYAAADKAAAA AAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAA AAAATAUAAAIAAABOBQAAAAAAAE4FAAAAAAAATgUAAAAAAABOBQAAAAAAAE4FAAAAAAAATgUAACQA AAA9BgAA9AEAADEIAAAMAQAAcgUAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgAAAAAAAADKAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAHIFAAAAAAAA kgEAAAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAAAAAAAAAAAMoAAAAAAAAAygAAAAAAAACS AQAAAAAAAJIBAAAAAAAAkgEAAAAAAADKAAAAIgAAAJIAAAAAAAAAygAAAAAAAACSAAAAAAAAAMoA AAAAAAAATAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAApgAAAAAAAACmAAAAAAAAAJIAAAAAAAAAkgAA AAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAABMBQAAAAAAAJIBAAC6AwAAkgEAAAAAAAAAAAAA AAAAAEwFAAAAAAAAkgAAAAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAUAAAAAAADKAAAAAAAAAL4AAAAMAAAAoEJzAQr2 vwGmAAAAAAAAAKYAAAAAAAAA7AAAAKYAAABMBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVGl0 bGU6IEluc3RydWN0aW9ucyB0byBFZGl0b3IgZm9yIHByb2R1Y3Rpb24gb2YgMm5kIENEIGZvciBJ U08vSUVDIDEwNTg5DVNvdXJjZTogSVNPL0lFQyBKVEMxL1NDNg0NVGhlIHByZWZlcnJlZCBkYXRl IG9mIGNsb3N1cmUgZm9yIHRoZSAoZm91ciBvciAgZml2ZSBtb250aCkgMm5kIENEIEJhbGxvdCBz aG91bGQgaW4gRmVicnVhcnkgMjAwMSwgdG8gZW5hYmxlIGluY29ycG9yYXRpb24gb2YgcG9zc2li bGUgaW5wdXQgb24gaG93IHRvIHByb2dyZXNzIGVuaGFuY2VtZW50cyB0byBtZWV0IEludGVybmV0 IHJlcXVpcmVtZW50cywgcmVjZWl2ZWQgYWZ0ZXIgdGhlIERlY2VtYmVyIDIwMDAgSUVURiBtZWV0 aW5nLg0NU3BlY2lmaWMgSW5zdHJ1Y3Rpb25zIHRvIHRoZSBFZGl0b3I6DQ0xKSBUaGUgZWRpdG9y IHNoYWxsIHVzZSBJU08vSUVDIDEwNTg5OjE5OTIgYXMgYSBiYXNlIGZvciBlZGl0aW5nLCBhbmQg c2hhbGwgYXBwbHkgdGhlIG1pbmltdW0gdGV4dHVhbCBjaGFuZ2VzIG1hbmRhdGVkIGJ5IHRoZSBm b2xsb3dpbmcgIFRDcyBhbmQgRFJzOg0NICAgSVNPL0lFQyAxMDU4OToxOTkyL0Nvci4xOjE5OTMN ICAgSVNPL0lFQyAxMDU4OToxOTkyL0Nvci4yOjE5OTYNICAgSVNPL0lFQyAxMDU4OToxOTkyL0Nv ci4zOjE5OTYNICAgSVNPL0lFQyAxMDU4OToxOTkyL0FtZCAxOjE5OTYNICAgNk4xMDMyMyAtIERl ZmVjdCBSZXBvcnRzIDctMjYNICAgNk4xMDY1OSAtIERlZmVjdCBSZXBvcnRzIDI3LTM0DSAgIDZO MTA3MzMgLSBUZWNobmljYWwgQ29ycmlnZW5kdW0gNA0NMikgVGhlIGVkaXRvciBzaGFsbCBhcHBs eSB0aGUgbWluaW1hbCBjaGFuZ2VzIG5lY2Vzc2FyeSB0byByZXNvbHZlIGFkZGl0aW9uYWwgRGVm ZWN0IFJlcG9ydHMgMzUtNDQuDQ0zKSBUaGUgZWRpdG9yIHNoYWxsIGFkZCB0aGUgZm9sbG93aW5n IHRlbXBvcmFyeSBub3RlIHRvIHRoZSBjb3ZlciBwYWdlIGFuZCB0aGUgc2NvcGUgY2xhdXNlOg0i DVRlbXBvcmFyeSBOb3RlOglUaGUgdGV4dCBpbiB0aGlzIDJuZCBGaW5hbCBDRCBpbmNvcnBvcmF0 ZXMgY2hhbmdlcyB0byB0aGUgMTk5MiBlZGl0aW9uLCByZXN1bHRpbmcgZnJvbSBhcHByb3ZlZCB0 ZWNobmljYWwgY29ycmlnZW5kYSwgYW1lbmRtZW50cywgYW5kIHByb3Bvc2VkIHJlc29sdXRpb25z IHRvIERlZmVjdCBSZXBvcnRzIDM1IC0gNDQuICBUaGUgcHVycG9zZSBvZiB0aGlzIDJuZCBGaW5h bCBDRCBpcyB0byBjcmVhdGUgYSBzdGFibGUgdGV4dCB3aGljaCBjYW4gYmUgdXNlZCBhcyB0aGUg YmFzaXMgZm9yIG9uZ29pbmcgd29yay4NDUl0IGRvZXMgbm90IGN1cnJlbnRseSBpbmNsdWRlIHRo ZSBleHRlbnNpb25zIG9yaWdpbmFsbHkgcmVxdWVzdGVkIGJ5IHRoZSBJRVRGICAoaW4gSW50ZXJu ZXQgRHJhZnRzOiANPGRyYWZ0LWlldGYtaXNpcy1keW5hbWUtMDIudHh0PiwgPGRyYWZ0LWlldGYt aXNpcy10cmFmZmljLTAxLnR4dD4gKSB0byBtZWV0IEludGVybmV0IHJlcXVpcmVtZW50cy4gIE5h dGlvbmFsIEJvZHkgYW5kIExpYWlzb24gb3JnYW5pemF0aW9uIGNvbW1lbnRzIGFyZSBpbnZpdGVk IHRvIGNvbW1lbnQgb24gdGhlIGJlc3Qgd2F5IHRvIHByb2dyZXNzIHRoZXNlIGV4dGVuc2lvbnMu DSINDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAMQQA ADMEAACgBAAAogQAAO8HAADxBwAAqQgAAKsIAABDCgAAAP0A/QD9AP0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANIKgEACQAEAABJBAAA YgQAAGMEAABeBQAAXwUAAIQFAACFBQAAGwYAABwGAAA9BgAAXgYAAH8GAACgBgAAwQYAAOMGAAAI BwAACQcAAG0HAABuBwAAywcAAM0HAAABCQAAAgkAAGcJAABACgAAQgoAAEMKAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAbAAQAAEkEAABi BAAAYwQAAF4FAABfBQAAhAUAAIUFAAAbBgAAHAYAAD0GAABeBgAAfwYAAKAGAADBBgAA4wYAAAgH AAAJBwAAbQcAAG4HAADLBwAAzQcAAAEJAAACCQAAZwkAAEAKAABCCgAAQwoAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABscAB+w0C8gsOA9 IbAIByKwCAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIADwAKAAEAWwAP AAIAAAAAAAAAJAAAQPH/AgAkAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAEAG1ICQQAAAAAAAAAAAAA AAAAAAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAg AEYAbwBuAHQAAAAAAAAAAAAAAAAAAAAAAEMGAAAFAAASAAAAAP////8ABAAAQwoAAAYAAAAABAAA QwoAAAcAAAAABAAAQwoAAAgAAAAAAAAADgIAABECAAAWAgAAGQIAAEUGAAAHABwABwAcAAcAAAAA AGIAAABjAAAAjwAAAJcAAABdAQAAhQEAAAMCAAARAgAAGgIAABwCAAA3AgAAPAIAAD0CAABYAgAA XQIAAF4CAAB5AgAAfgIAAJQEAADLBAAA1QQAAAAFAABnBQAAaAUAAIUFAADLBQAARQYAAAcABAAH ABoABwAHAAcAGgAHAAcABwAaAAcABwAaAAcABwAaAAcABwAaAAcABwAHABoABwAHAP//EAAAAAgA VABvAG0AIABSAHUAdAB0ADIAQwA6AFwAdwBpAG4AZABvAHcAcwBcAFQARQBNAFAAXABBAHUAdABv AFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAG8AYwB1AG0AZQBuAHQAMQAuAGEA cwBkAAgAVABvAG0AIABSAHUAdAB0ACcARAA6AFwAZABhAHQAYQBcAHMAYwA2AFwAdwBnADcAXABw AHIAYQBoAGEAXABpAHMAaQBzAGUAZABpAHQAaQBuAHMAdAByAC4AZABvAGMACABUAG8AbQAgAFIA dQB0AHQANgBDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2 AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAGkAcwBpAHMAZQBkAGkAdABpAG4AcwB0AHIALgBhAHMA ZAAIAFQAbwBtACAAUgB1AHQAdAA2AEMAOgBcAHcAaQBuAGQAbwB3AHMAXABUAEUATQBQAFwAQQB1 AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAaQBzAGkAcwBlAGQAaQB0AGkA bgBzAHQAcgAuAGEAcwBkAAgAVABvAG0AIABSAHUAdAB0ACcARAA6AFwAZABhAHQAYQBcAHMAYwA2 AFwAdwBnADcAXABwAHIAYQBoAGEAXABpAHMAaQBzAGUAZABpAHQAaQBuAHMAdAByAC4AZABvAGMA EABKAGEAYwBrACAASABvAHUAbABkAHMAdwBvAHIAdABoACgAQwA6AFwATQB5ACAARABvAGMAdQBt AGUAbgB0AHMAXABvAG0AXAAyADcAMQBcAGkAcwBpAHMAZQBkAGkAdABpAG4AcwB0AHIALgBkAG8A YwAQAEoAYQBjAGsAIABIAG8AdQBsAGQAcwB3AG8AcgB0AGgAMABDADoAXABNAHkAIABEAG8AYwB1 AG0AZQBuAHQAcwBcAHMAdABhAG4AZABhAHIAZABzAFwAaQBzAHQANgBcAGkAcwBpAHMAZQBkAGkA dABpAG4AcwB0AHIALgBkAG8AYwAQAEoAYQBjAGsAIABIAG8AdQBsAGQAcwB3AG8AcgB0AGgALgBD ADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAHMAdABhAG4AZABhAHIAZABzAFwAdwBnADcA XABpAHMAaQBzAGkAbgBzAHQAcgB1AGMAdAAuAGQAbwBjAP9AAIABAAAAAAAAAAAA+BEyAQEAAQAA AAAAAAAAAAAAAAAAAAAAAhAAAAAAAAAAQwYAAFAAAAgAQAAAAwAAAEcWkAEAAAICBgMFBAUCAwQD AAAAAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUW kAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEA AAILBgQCAgICAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAAiAAQAcAiIGAAA 0AIAAGgBAAAAAB3KR0YdykdGAAAAAAIAAQAAAOcAAAApBQAAAQACAAAABAADEAsAAAAAAAAAAAAA AAEAAQAAAAEAAAAAAAAAJAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACA ADIwAAAAAAAAAAAAAAAAAABWBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAABZAFQAaABlACAAZQBk AGkAdABvAHIAIABzAGgAYQBsAGwAIABhAGQAZAAgAHQAaABlACAAZgBvAGwAbABvAHcAaQBuAGcA IAB0AGUAbQBwAG8AcgBhAHIAeQAgAG4AbwB0AGUAIAB0AG8AIAB0AGgAZQAgAGMAbwB2AGUAcgAg AHAAYQBnAGUAIABhAG4AZAAgAHQAaABlACAAcwBjAG8AcABlACAAYwBsAGEAdQBzAGUAOgAAAAAA AAAIAFQAbwBtACAAUgB1AHQAdAAQAEoAYQBjAGsAIABIAG8AdQBsAGQAcwB3AG8AcgB0AGgAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAADMAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAA /AAAAAQAAAAIAQAABQAAABwBAAAGAAAAKAEAAAcAAAA0AQAACAAAAEQBAAAJAAAAYAEAABIAAABs AQAACgAAAIgBAAAMAAAAlAEAAA0AAACgAQAADgAAAKwBAAAPAAAAtAEAABAAAAC8AQAAEwAAAMQB AAACAAAA5AQAAB4AAABaAAAAVGhlIGVkaXRvciBzaGFsbCBhZGQgdGhlIGZvbGxvd2luZyB0ZW1w b3Jhcnkgbm90ZSB0byB0aGUgY292ZXIgcGFnZSBhbmQgdGhlIHNjb3BlIGNsYXVzZToAIAAeAAAA AQAAAABoZSAeAAAACQAAAFRvbSBSdXR0AHIgcx4AAAABAAAAAG9tIB4AAAABAAAAAG9tIB4AAAAH AAAATm9ybWFsAHQeAAAAEQAAAEphY2sgSG91bGRzd29ydGgAYWRkHgAAAAIAAAAyAGNrHgAAABMA AABNaWNyb3NvZnQgV29yZCA4LjAAZEAAAAAARsMjAAAAAEAAAAAAhgMACva/AUAAAAAAhgMACva/ AQMAAAABAAAAAwAAAOcAAAADAAAAKQUAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAA AALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rpQBAABQAQAADAAAAAEAAABoAAAA DwAAAHAAAAAFAAAAjAAAAAYAAACUAAAAEQAAAJwAAAAXAAAApAAAAAsAAACsAAAAEAAAALQAAAAT AAAAvAAAABYAAADEAAAADQAAAMwAAAAMAAAAMgEAAAIAAADkBAAAHgAAABQAAABMdWNlbnQgVGVj aG5vbG9naWVzAAMAAAALAAAAAwAAAAIAAAADAAAAVgYAAAMAAACzDQgACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAFoAAABUaGUgZWRpdG9yIHNoYWxsIGFkZCB0aGUgZm9s bG93aW5nIHRlbXBvcmFyeSBub3RlIHRvIHRoZSBjb3ZlciBwYWdlIGFuZCB0aGUgc2NvcGUgY2xh dXNlOgAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYA AAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQAAEEAAABOAAAAewA0AEQAQgAw AEUAMAA1ADUALQA2AEIANgAyAC0ANAAzADkAQwAtAEEARgBFADgALQAxADIARgAyADEANwAxAEUA NwBDADQAOAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AP7///8LAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA/v///xMAAAAUAAAAFQAAABYAAAAXAAAA GAAAABkAAAD+////GwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAAP7////9////JAAAAP7////+ /////v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAA AABGAAAAAMCubgEK9r8BYGp8AQr2vwEmAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAf////8FAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAAEAAAAAAAAFcAbwByAGQA RABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa AAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4S AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAASAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBm AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3Nv ZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_004E_01BFF9BB.AF0ABBA0-- From jjl@one.com Thu, 03 Aug 2000 14:52:34 -0400 Date: Thu, 03 Aug 2000 14:52:34 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] General info about IS-IS --=====================_278714320==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jasper, RFC 1195, "ftp://ftp.isi.edu/in-notes/rfc1195.txt", has a great overview of IS-IS. After that, I recommend Radia Perlman's "Interconnections", although that covers both bridges and routers and a variety of related protocols, and only a relatively small portion of the book concerns IS-IS. But it's very useful because it explains the concepts of link-state routing as differentiated from distance-vector routing, and has amusing anecdotes as well. For a somewhat fluffier overview, you can see "ftp://ftp.atis.org/pub/sif/arch/ar970820.ppt", although this was prepared for an audience that was familiar with OSI addressing. Ignore the last three slides, which are specific to carrier-class SONET management networks. Regards, Jeff At 12:26 PM 8/3/00 -0400, Jasper Chin wrote: >I'm new to IS-IS and am looking to learn about >this routing protocol. > >Could anyone suggest a roadmap of reading material >that would be beneficial? Is there a FAQ on this >topic? > >TIA, > >J. Chin ____________________________________________________________________ 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 ____________________________________________________________________ --=====================_278714320==_.ALT Content-Type: text/html; charset="us-ascii"
Jasper,

RFC 1195, "ftp://ftp.isi.edu/in-notes/rfc1195.txt", has a great
overview of IS-IS.  After that, I recommend Radia Perlman's
"Interconnections", although that covers both bridges and routers
and a variety of related protocols, and only a relatively small
portion of the book concerns IS-IS.  But it's very useful because
it explains the concepts of link-state routing as differentiated
from distance-vector routing, and has amusing anecdotes as well.

For a somewhat fluffier overview, you can see
"ftp://ftp.atis.org/pub/sif/arch/ar970820.ppt", although this was
prepared for an audience that was familiar with OSI addressing.
Ignore the last three slides, which are specific to carrier-class
SONET management networks.

Regards,
Jeff

At 12:26 PM 8/3/00 -0400, Jasper Chin wrote:
I'm new to IS-IS and am looking to learn about
this routing protocol.

Could anyone suggest a roadmap of reading material
that would be beneficial?  Is there a FAQ on this
topic?

TIA,

J. Chin


____________________________________________________________________

  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
____________________________________________________________________ --=====================_278714320==_.ALT-- From isip00@yahoo.com Fri, 4 Aug 2000 17:15:54 -0700 (PDT) Date: Fri, 4 Aug 2000 17:15:54 -0700 (PDT) From: Oka Learner isip00@yahoo.com Subject: [Isis-wg] Clarification on isisCircInitFails Could someone please explain me this object? If initialization fails, how a circuit be created? Advance thanks for any response. __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From iesg-secretary@ietf.org Tue, 15 Aug 2000 16:18:21 -0400 Date: Tue, 15 Aug 2000 16:18:21 -0400 From: The IESG iesg-secretary@ietf.org Subject: [Isis-wg] Document Action: IS-IS Mesh Groups to Informational The IESG has approved the Internet-Draft 'IS-IS Mesh Groups' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are David Oran and Rob Coltun. From iesg-secretary@ietf.org Tue, 15 Aug 2000 16:18:21 -0400 Date: Tue, 15 Aug 2000 16:18:21 -0400 From: The IESG iesg-secretary@ietf.org Subject: [Isis-wg] Document Action: IS-IS Mesh Groups to Informational The IESG has approved the Internet-Draft 'IS-IS Mesh Groups' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are David Oran and Rob Coltun. From cai@baynetworks.com Mon, 7 Aug 2000 15:52:06 -0400 (EDT) Date: Mon, 7 Aug 2000 15:52:06 -0400 (EDT) From: Karl Cai cai@baynetworks.com Subject: [Isis-wg] looking for PS version of rfc1195 Hi, Could somebody tell me where I can find a copy of rfc1195 postscript version? I download it from ftp.ietf.org (rfc1195.ps) but it breaks on page9 when I use ghostview to view/print it. Thanks. -- Karl From prz@net4u.ch Mon, 21 Aug 2000 20:43:59 +0200 (MEST) Date: Mon, 21 Aug 2000 20:43:59 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] IETF 48 meeting minutes Thanks to Alex for initial version: * Agenda bashing & Administrativa 1. domain-wide passed last call, unfortunately credits have not been given to Quaizar who contributed some key ideas 2. mesh-groups passed last call 3. isis-ext-eth passed last call 4. expired te draft will be re-submitted latest 2 weeks after IETF or another party will take control of the draft * Draft on flooding optimization has not been presented. Couple of comments were made and will be sent to authors. * Kireeti presented draft-kompella-isis-ompls-extensions-00 summarizing extensions to ISIS to support MPL()S. Q: How is this work relative to transport rings? Kireeti: Not quite sure. We can introduce transport ring support if necessary Q: Wrt link protection, not all protection schemes are covered (N:N, and N:1 are not included), why? K: We tried to keep it simple. K: The way to proceed with the draft seems to be to go to the new WG and reach the consensus there and then come back to ISIS WG. TonyP: Agree, let's give it a chance to be discussed in the new WG to fit into any "bigger" scheme of things. If that doesn't happen, we'll take on to work on the issue. * Francois presented draft-lefaucheur-diff-te-ext-00 describing the extensions that need to be made to ISIS TE TLVs to support DiffServ-aware MPLS TE. The main idea is to provide BW info for each class using new sub-TLVs in existing TE TLVs. Francois requested the feedback from the ISIS WG. K: Not sure this is the right forum, but this can be coded more optimal if (announce overall unreserved BW and reserved BW per class ???) F: We couldn't make it work, would be happy to discuss this. (Discussion to go off-line) Curtis: 4 class types is very restrictive and 8 preemption levels may be too much F: Those are sort of things which relate to the definition of requirements and should be discussed in MPLS/TE WGs. TP: You do not address the situation where routers do not udnerstand the new TLVs. This could lead to loops in loose source routes scenarios. F : It is addressed in the signaling component, which is not in the draft TP: it is still a good idea to specify what to do with TLVs if they are not understood. Draft may end up in the new routing area working group or MPLS and architectural/requirement issues will be worked out there first. Output of that work may find its way back into ISIS working group. * Ran Atkinson (engineer at large :) spoke up about draft-ietf-isis-hmac-01.txt. The document was described as stable and clear for implementation. Ran encouraged WG members to read it and post the issues (if any) to the list. TP: There's some confusion about support of 2 keys, people wonder if it's necessary. R : Yes it is, in particular to support smooth key roll-over. TP: Paragraph on the IIH protection is still missing. Contact info needs update. * Chris presented draft-ietf-isis-ipv6-01.txt. The draft describes extensions to ISIS to propagate IPv6 routing information using TLVs similar to wide-metric TLVs for IPv4. One known implementation is gated, other vendors claim to be looking into this. K: Shouldn't the cost be 24 bits as in TE extensions, not 32 bits as in the draft? C: TE has different metrics K: There should be some allignment with TE metrics (24 bits) TP: Double check this, pls. C: I will Mike Shand: What about IPv6-incapable routers? C: Implementations may calculate 2 SPFs---one for IPv4, and another one for IPv6 excluding IPv6-incapable routers. Seems to be more administrative issue. Q: The draft differentiates btw internal and external routes, while TE doesn't, why? A: The draft sticks with original 1195 semantics that was dropped by TE extensions, so the question is to TE authors. T: TE simplified the semantics because nobody was actually using it. It makes sense to stick with 1195 to avoid redistribution loops. IPv6 draft is not implementing the I/E bit (which was not necessary) but only differentiates between external and internal routes which is necessary to prevent those loops. * TP: draft-ietf-isis-hmac-01.txt is to go through the last call after the comments are being incorporated and new version submitted. === tony From rathi@cisco.com Mon, 04 Sep 2000 15:28:44 +0530 Date: Mon, 04 Sep 2000 15:28:44 +0530 From: Ravindra Rathi rathi@cisco.com Subject: [Isis-wg] Doubts in draft-ietf-isis-wg-mib-03.txt Hello all, I have few doubts as well as suggestions for the current version of this draft. Please go through them and let me know your comments. 1. Following object identifiers have "null" description clause in the draft a. isisSystem b. isisCirc c. isisIsAdj d isisReachAddr e. isisIPReachAddr f. isisIPDest Normally description clauses are not null. So either descriptions can be added to them. (The descriptions are already there in the draft before the start of the mib module.) or we can have just something like this. e.g isisSystem OBJECT IDENTIFIER ::= {isis 1 } isisCirc OBJECT IDENTIFIER ::= { isis 2 } etc. 2. At present, type TOS is defined as follows. TOS ::= INTEGER { default(1), delay(2), expense(3), error(4) } This could also have been a TEXTUAL-CONVENTION instead INTEGER. The same thing applies to type 'PathCost.' Am I missing something ? 3. For all of the following tables in the MIB, one of the indices of the table identifies the instance of Integrated IS-IS to which the particular row corresponds. Tables of interest are a. isisSysTable b. isis isisManAreaAddrTable c. isisAreaAddrTable d. isisSysProtSuppTable e. isisSummAddrTable Instead of each of these tables defining one object which acts as an index to identify the same thing (i.e instance of Integrated IS-IS), only one table can (say isisSysTable) define the object to identify the instance of the integrated IS-IS. Presently the object which identifies the instance of Integrated IS-IS in "isisSysTable" is "isisSysInstance". All other tables can use this object as an index(external indexing ) instead of defining their own object to serve the same purpose. Also by using the same object for indexing for all the tables consistency is maintained across the tables to identify the instance of Integrated IS-IS. 4. ResettingTimer behaviour definition The description there applies to objects who follow ResettingTimer behaviour. Defining TEXTUAL-CONVENTION can be better way of documenting the behaviour provided it is possible. I suppose this is not possible here. Same thing applies to "OperationalState behaviour definition". Also definition of these behaviours use the phrase "This object". I feel it would have been more appropriate to use the phrase "objects following this behaviour". 5. The description clause of many objects refer to "replaceOnlyWhile Disabled behaviour". But I was not able to find documentation for this behaviour in the draft. 6. Description clause of few objects is not very clear. e.g for "isisSysPartChanges" it is DESCRIPTION "partition changes". The above description not really indicates what aspect of "partition changes" is being managed by this object ? I might me missing something in above doubts. So please enlighten me with the same. Thanks Rathi -- Ravindra Rathi Cisco Systems "Waterford", #9, Brunton Road Bangalore-560 001 Tel: +91-80-532 1300 - 1306 x: 6315 From henk@Procket.com Tue, 5 Sep 2000 05:17:39 +0200 (MEST) Date: Tue, 5 Sep 2000 05:17:39 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] FYI: just submitted draft-ietf-isis-traffic-03.txt Submitted to internet-drafts@ietf.org, I guess it will show up in the drafts repository soon. Just a few minor changes to the previous version. Anyway, here it is for you already. Henk. ---- Network Working Group Tony Li INTERNET DRAFT Procket Networks Henk Smit Procket Networks September 2000 IS-IS extensions for Traffic Engineering Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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 Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. 2.0 Introduction An IS-IS LSP is composed of a fixed header and a number of tuples, each consisting of a Type, a Length, and a Value. Such tuples are commonly known as TLVs, and are a good way of encoding information in a flexible and extensible format. The changes in this document include the design of new TLVs to replace the existing IS Neighbor TLV, IP Reachability TLV and add additional information. Mechanisms and procedures to migrate to the new TLVs are not discussed in this document. The primary goal of these extensions is to add more information about the characteristics of a particular link to an IS-IS's LSP. Secondary goals include increasing the dynamic range of the IS-IS metric and improving the encoding of IP prefixes. The router id is useful for traffic engineering purposes because it describes a single address that can always be used to reference a particular router. This document is a publication of the IS-IS Working Group within the IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual inclusion with ISO 10589. 3.0 The Traffic Engineering router ID TLV The Traffic Engineering router ID TLV is TLV type 134. The router ID TLV contains the 4-octet router ID of the router originating the LSP. This is useful in several regards: For traffic engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces. If OSPF is also active in the domain, traffic engineering can compute the mapping between the OSPF and IS-IS topologies. If a router advertises the Traffic Engineering router ID TLV in its LSP, and if it advertises BGP routes with the BGP next hop attribute set to the BGP router ID, in that case the Traffic Engineering router ID should be the same as the BGP router ID. 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. 4.0 The extended IP reachability TLV The extended IP reachability TLV is TLV type 135. The existing IP reachability TLV is a single TLV that carries IP prefixes in a format that is analogous to the IS neighbor TLV. It carries four metrics, of which only the default metric is commonly used. Of this, the default metric has a possible range of 0-63. This limitation is one of the restrictions that we would like to lift. In addition, route redistribution (a.k.a. route leaking) is a key problem that is not addressed by the existing IP reachability TLV. This problem occurs when an IP prefix is injected into a level one area, redistributed into level 2, subsequently redistributed into a second level one area, and then redistributed from the second level one area back into level two. This problem occurs because the path that the information can take forms a loop. The likely result is a forwarding loop. To address these issues, the proposed extended IP reachability TLV provides for a 32 bit metric and adds one bit to indicate that a prefix has been redistributed 'down' in the hierarchy. The proposed extended IP reachability TLV contains a new data structure, consisting of: 4 bytes of metric information 1 byte of control information, consisting of 1 bit of up/down information 1 bit indicating the existence of sub-TLVs 6 bits of prefix length 0-4 bytes of IPv4 prefix 0-250 optional octets of sub-TVLs, if present consisting of 1 octet of length of sub-TLVs 0-249 octets of sub-TLVs This data structure can be replicated within the TLV, not to exceed the maximum length of the TLV. The up/down bit shall be set to 0 when a prefix is first injected into IS-IS. If a prefix is redistributed from a higher level to a lower level (e.g. level two to level one), the bit shall be set to 1, to indicate that the prefix has travelled down the hierarchy. Prefixes that have the up/down bit set to 1 must not be redistributed. 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. These semantics apply even if IS-IS is extended in the future to have additional levels. By insuring that prefixes follow only the IS-IS hierarchy, we have insured that the information does not loop, thereby insuring that there are no persistent forwarding loops. If there are no sub-TLVs associated with this IP prefix, the bit indicating the presence of sub-TVLs shall be set to 0. If this bit is set to 1, the first octet after the prefix will be interpreted as the length of sub-TLVs. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall extended IP reachability TLV. The practical maximum is 255 octets minus the 5-9 octets described above, or 250 octets. No sub- TLVs for the extended IP reachability TLV have been defined yet. The 6 bits of prefix length can have the values 0-32 and indicate the number of significant bits in the prefix. The prefix is encoded in the minimal number of bytes for the given number of significant bits. This implies: Significant bits Bytes 0 0 1-8 1 9-16 2 17-24 3 25-32 4 The remaining bits of prefix are transmitted as zero and ignored upon receipt. 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. 5.0 The extended IS reachability TLV The extended IS reachability TLV is TLV type 22. The existing IS reachability TLV is a single TLV that contains information about a series of IS neighbors. For each neighbor, there is a structure that contains the default metric, the delay, the monetary cost, the reliability, and the 7-octet ID of the adjacent neighbor. Of this information, the default metric is commonly used. The default metric is currently one octet, with one bit used to indicate that the metric is present and one bit used to indicate whether the metric is internal or external. The remaining 6 bits are used to store the actual metric, resulting a possible metric range of 0-63. This limitation is one of the restrictions that we would like to lift. The remaining three metrics (delay, monetary cost, and reliability) are not commonly implemented and reflect unused overhead in the TLV. The neighbor is identified by its system Id (typically 6-octets), plus one octet to indicate the pseudonode number if the neighbor is on a LAN interface. Thus, the existing TLV consumes 11 octets per neighbor, with 4 octets for metric and 7 octets for neighbor identification. To indicate multiple adjacencies, this structure is repeated within the IS reachability TLV. Because the TLV is limited to 255 octets of content, a single TLV can describe up to 23 neighbors. The IS reachability TLV can be repeated within the LSP fragments to describe further neighbors. The proposed extended IS reachability TLV contains a new data structure, consisting of 7 octets of system Id and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs Thus, if no sub-TLVs are used, the new encoding requires 11 octets and can contain up to 23 neighbors. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall IS reachability TLV. The practical maximum is 255 octets minus the 11 octets described above, or 244 octets. Further, there is no defined mechanism for extending the sub-TLV space for a particular neighbor. Thus, wasting sub-TLV space is discouraged. The metric octets are encoded as a 24-bit unsigned integer. Note that the metric field in the new extended IP reachability TLV is encoded as a 32-bit unsigned integer. These different sizes were chosen so that it is very unlikely that the cost of an intra-area route has to be chopped off to fit in the metric field of an inter-area route. To preclude overflow within an SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC shall be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). If a link is advertised with the maximum link metric (2^24 - 1), this link should not be considered during the normal SPF computation. This will allow advertisment of a link for other purposes than building the normal Shortest Path Tree. An example is a link that is available for traffic engineering, but not for hop-by-hop routing. Certain sub-TLVs are proposed here: Sub-TLV type Length (octets) Name 3 4 Administrative group (color) 6 4 IPv4 interface address 8 4 IPv4 neighbor address 11 32 Unreserved bandwidth 18 3 TE Default metric Each of these sub-TLVs is described below. Unless stated otherwise, multiple occurrences of the information are supported by multiple inclusions of the sub-TLV. 5.1 Sub-TLV 3: Administrative group (color, resource class) The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. By convention the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'. 5.2 Sub-TLV 6: IPv4 interface address This sub-TLV contains a 4-octet IPv4 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times. If the interface being advertised for Traffic Engineering purposes is unnumbered, the IPv4 interface address sub-TLV is set to the router ID of the advertising router. In combination with the IPv4 neighbor address sub-TLV this identifies the unnumbered link over which the advertised adjacency has been established. Implementations MUST NOT inject a /32 prefix for the interface address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV. If a router implements the basic TLV extensions in this document, it is free to add or omit this sub-TLV to the description of an adjacency. If a router implements traffic engineering, it must include this sub-TLV. 5.3 Sub-TLV 8: IPv4 neighbor address This sub-TLV contains a single IPv4 address for a neighboring router on this link. This sub-TLV can occur multiple times. If the interface being advertised for Traffic Engineering purposes is unnumbered, the first two octets of the IPv4 neighbor address sub-TLV are set to zero and the next two octets are set to the interface ID of the unnumbered interface. In combination with the IPv4 interface address sub-TLV this identifies the unnumbered link over which the advertised adjacency has been established. Implementations MUST NOT inject a /32 prefix for the neighbor address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV. If a router implements the basic TLV extensions in this document, it is free to add or omit this sub-TLV to the description of an adjacency. If a router implements traffic engineering, it must include this sub-TLV on point-to-point adjacencies. 5.4 Sub-TLV 11: Unreserved bandwidth This sub-TLV contains the amount of bandwidth reservable on this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link. Because of the need for priority and preemption, each head end needs to know the amount of reserved bandwidth at each priority level. Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. The units are bytes (not bits!) per second. The values correspond to the bandwidth that can be reserved with a holding of priority 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub-TLV, and priority 7 at the end of the sub-TLV. For stability reasons, rapid changes in the values in this sub-TLV should not cause rapid generation of LSPs. 5.5 Sub-TLV 18: Traffic Engineering Default metric This sub-TLV contains a 24-bit unsigned integer. This metric is administratively assigned and can be used to present a differently weighted topology to traffic engineering SPF calculations. To preclude overflow within an SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC shall be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). If a link is advertised without this sub-TLV, traffic engineering SPF calculations must use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV. 6.0 Security Considerations This document raises no new security issues for IS-IS. 7.0 Acknowledgments The authors would like to thank Yakov Rekhter and Dave Katz for their comments on this work. 8.0 References [1] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September 1999. [2] 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] [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 9.0 Authors' Addresses Tony Li Procket Networks, Inc. 3850 North First Street San Jose, CA 95134 Email: tli@procket.com Voice: +1 408 9547900 Fax: +1 408 9876166 Henk Smit Procket Networks, Inc. 3850 North First Street San Jose, CA 95134 Email: henk@procket.com Voice: +1 408 9547900 Fax: +1 408 9876166 From Internet-Drafts@ietf.org Wed, 06 Sep 2000 06:44:06 -0400 Date: Wed, 06 Sep 2000 06:44:06 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-02.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS extensions for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-traffic-02.txt Pages : 9 Date : 05-Sep-00 This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-traffic-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-traffic-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000905135154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-traffic-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-traffic-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135154.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed, 06 Sep 2000 06:44:37 -0400 Date: Wed, 06 Sep 2000 06:44:37 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-dharanikota-interarea-mpls-te-ext-00.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF, IS-IS, RSVP, CR-LDP Extensions to Support Inter-Area Traffic Engineering Using MPLS TE Author(s) : S. Dharanikota, S. Venkatachalam Filename : draft-dharanikota-interarea-mpls-te-ext-00.txt Pages : 20 Date : 05-Sep-00 In this draft, we propose the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A companion document [INTER_AREA_FWK] provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document [INTER_AREA_FWK]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dharanikota-interarea-mpls-te-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000905135234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-dharanikota-interarea-mpls-te-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135234.I-D@ietf.org> --OtherAccess-- --NextPart-- From oran@cisco.com Thu, 7 Sep 2000 11:44:20 -0400 Date: Thu, 7 Sep 2000 11:44:20 -0400 From: David Oran oran@cisco.com Subject: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing This is a multi-part message in MIME format. ------=_NextPart_000_018E_01C018C0.F5C6AE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit For those of you who hate MSWORD, I append the text at the end of the message text as well. Are there other drafts they should fold it? If so, please craft a response and I'll get it to them. -----Original Message----- From: Matthew Deane [mailto:mdeane@ANSI.org] Sent: Thursday, September 07, 2000 11:35 AM To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; 'mankin@east.isi.edu' Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' Subject: JTC 1/SC 6 Liaison Statement on Routeing > Dear IETF Directors, > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the following > document is forwarded to IETF Routeing and Transport Area Directors for > consideration: > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) > > > Please do not hesitate to contact me should you have any questions. > > Sincerely, > > Matt Deane > JTC 1/SC 6 Secretariat > > <<06n1618.rtf>> SC 6 N 11618 Title: Liaison Report to the IETF Routing Area Director on 2nd CD for ISO/IEC 10589 (IS-IS Routing) Source: ISO/IEC JTC1/SC6 ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for ISO10589. SC6 intends to use this new version 2 as the base for adding the enhancements which have been requested by the IETF to optimise the use of ISO 10589 for Internet routing solutions. The IETF IS-IS WG convenor originally identified Internet Drafts: and as the source documents which specify these enhancements. SC6 invites the IETF to confirm that the above Internet Drafts are the correct references and to inform SC6 if there are additional IETF documents which refer to any other requirements for IS-IS Routing enhancements. SC6 would like to interact with the IETF on clarifying the detailed requirements in the hope that it may be possible to introduce them during the editing cycle for version 2 of the standard. To this end, we would like the Routing Area Directors to arrange an IS-IS BOF at the San Diego IETF meeting to discuss these requirements and how they can be incorporated into the new version of ISO 10586. SC6 will post an initial draft version of the new base document as an Internet Draft in August 2000 but this will not contain the changes requested by the IETF. A ballot closure date of February 2001 has been set for the 2nd CD Ballot to allow incorporation of final input on the Internet requirements if they can be agreed at the December 2000 IETF meeting. For information, the current instructions to the editor are that he should use ISO/IEC 10589:1992 as a base for editing, and shall apply the minimum textual changes mandated by the following TCs and DRs: ISO/IEC 10589:1992/Cor.1:1993 ISO/IEC 10589:1992/Cor.2:1996 ISO/IEC 10589:1992/Cor.3:1996 ISO/IEC 10589:1992/Amd 1:1996 6N10323 - Defect Reports 7-26 6N10659 - Defect Reports 27-34 6N10733 - Technical Corrigendum 4 The editor will also apply the minimal changes necessary to resolve additional Defect Reports 35-44. If SC6 and the IETF are unable to resolve the required changes, the Editor will add a temporary note to the cover page and the scope clause stating that: “ ISO 10589 does not currently include the extensions originally requested by the IETF in Internet Drafts: and . National Body and Liaison organization comments are invited to comment on the best way to progress these extensions.” ------=_NextPart_000_018E_01C018C0.F5C6AE40 Content-Type: application/msword; name="06n1618.rtf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="06n1618.rtf" {\rtf1\ansi\ansicpg1252\uc1 = \deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\p= anose 02020603050405020304}Times New Roman{\*\falt CG = Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose = 02070309020205020404}Courier New;}} {\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue255= ;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red255= \green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\green= 128\blue128;\red0\green128\blue0; \red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red12= 8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adju= stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default Paragraph = Font;}{\s15\nowidctlpar \tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx9590= \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title = Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew = Deane}{\creatim\yr2000\mo6\dy9\hr18\min52} {\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\nof= words533}{\nofchars3040}{\*\company Lucent = Technologies}{\nofcharsws3733}{\vern89}} \widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nospa= ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot = \fet0\sectd \linex0\endnhere\sectdefaultcl = {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}} {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta = .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta = .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta = )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}} {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}}{\*\pnseclvl9 \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain = \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx76= 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{ Telecommunications and Information =20 \par Exchange Between Systems = =20 \par=20 \par=20 \par ISO/IEC JTC 1/SC06 N 11618 =20 \par=20 \par DATE: 2000-06-16 =20 \par=20 \par REPLACES =20 \par=20 \par DOC TYPE: \par Outgoing Liaison Statement =20 \par=20 \par TITLE: \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) = =20 \par=20 \par SOURCE: \par SC 6/WG 7 Convener = =20 \par=20 \par PROJECT: =20 \par=20 \par STATUS: \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to = IETF =20 \par for consideration. = =20 \par=20 \par ACTION ID: ACT=20 \par=20 \par DUE DATE: =20 \par=20 \par DISTRIBUTION: P & L Members; SC Chair; WG Conveners and = Secretaries =20 \par=20 \par=20 \par MEDIUM: =20 \par=20 \par DISKETTE NO.: =20 \par=20 \par NO. OF PAGES: 1 =20 \par=20 \par=20 \par ISO/IEC JTC 1/SC 6 Secretariat = =20 \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA = =20 \par }\pard = \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx76= 72\tx8631\adjustright {Tel: +1 212 642 4992; Fax: +1 212 84}{0 2298; = E-mail: }{mdeane@ansi.org}{\tab \tab \tab \tab \tab \tab = \tab }{\b\fs28=20 \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20 \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618 \par }{ \par }{\b Title: Liaison Report to the IETF Routing Area Director on = 2}{\b\super nd}{\b CD for ISO/IEC 10589 (IS-IS Routing) \par=20 \par Source: ISO/IEC JTC1/SC6 \par }{ \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for = ISO10589. SC6 intends to use this new version 2 as the base for adding = the enhancements which have been requested by the IETF=20 to optimise the use of ISO 10589 for Internet routing solutions. The = IETF IS-IS WG convenor originally identified Internet Drafts: = and as = the source documents which specify these enhanceme nts. SC6 invites the IETF to confirm that the above Internet Drafts = are the correct references and to inform SC6 if there are additional = IETF documents which refer to any other requirements for IS-IS Routing = enhancements. \par=20 \par SC6 would like to interact wit h the IETF on clarifying the detailed requirements in the hope that it = may be possible to introduce them during the editing cycle for version = 2 of the standard. To this end, we would like the Routing Area = Directors to arrange an IS-IS BOF at the San Di ego IETF meeting to discuss these requirements and how they can be = incorporated into the new version of ISO 10586. \par=20 \par SC6 will post an initial draft version of the new base document as = an Internet Draft in August 2000 but this will not contain the changes r equested by the IETF. A ballot closure date of February 2001 has been = set for the 2nd CD Ballot to allow incorporation of final input on the = Internet requirements if they can be agreed at the December 2000 IETF = meeting.=20 \par=20 \par For information, the current instructions to the editor are that he = should use ISO/IEC 10589:1992 as a base for editing, and shall apply the = minimum textual changes mandated by the following TCs and DRs: \par=20 \par ISO/IEC 10589:1992/Cor.1:1993 \par ISO/IEC 10589:1992/Cor.2:1996 \par ISO/IEC 10589:1992/Cor.3:1996 \par ISO/IEC 10589:1992/Amd 1:1996 \par 6N10323 - Defect Reports 7-26 \par 6N10659 - Defect Reports 27-34 \par 6N10733 - Technical Corrigendum 4 \par The editor will also apply the minimal changes necessary to = resolve additional Defect Reports 35-44. \par=20 \par If SC6 and the IETF are unable to resolve the required changes, the = Editor will add a temporary note to the cover page and the scope clause = stating that: \ldblquote=20 ISO 10589 does not currently include the extensions originally = requested by the IETF in Internet D rafts: and = . National Body and Liaison = organization comments are invited to comment on the best way to progress = these extensions.\rdblquote=20 \par=20 \par=20 \par }} ------=_NextPart_000_018E_01C018C0.F5C6AE40-- From oran@cisco.com Thu, 7 Sep 2000 16:23:02 -0400 Date: Thu, 7 Sep 2000 16:23:02 -0400 From: David Oran oran@cisco.com Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing Copying the WG... -----Original Message----- From: Henk Smit [mailto:henk@Procket.com] Sent: Thursday, September 07, 2000 3:50 PM To: David Oran Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > For those of you who hate MSWORD, I append the text at the end of the > message text as well. Thank you, I appreciate it ! Pretty weird that a standards body like ISO is using a proprietary files format. ;-) > Are there other drafts they should fold it? If so, please craft a > response and I'll get it to them. draft-ietf-isis-dyname-02.txt is not a draft anymore. It is now an RFC: RFC2763. I have just submitted a new version of draft-ietf-isis-traffic-01.txt, draft-ietf-isis-traffic-02.txt. It might be a while before it becomes an RFC. And what about RFC1195 itself ? There is no mention that this RFC will be incorporated ? If RFC1195 is incorporated, there is one more ISIS draft that I would like to see added. Tony Li, Tony Prziegynda and myself are also authors of a draft that is related. draft-ietf-isis-domain-wide-02.txt. It is slated to be an RFC pretty soon, just waiting for the RFC editor to process it. If 10589 is including IP specific stuff, I think this one should be incorporated too. Henk. > -----Original Message----- > From: Matthew Deane [mailto:mdeane@ANSI.org] > Sent: Thursday, September 07, 2000 11:35 AM > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > 'mankin@east.isi.edu' > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > Dear IETF Directors, > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the following > > document is forwarded to IETF Routeing and Transport Area Directors > for > > consideration: > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > version) > > > > > > Please do not hesitate to contact me should you have any questions. > > > > Sincerely, > > > > Matt Deane > > JTC 1/SC 6 Secretariat > > > > <<06n1618.rtf>> > > > SC 6 N 11618 > > Title: Liaison Report to the IETF Routing Area Director on 2nd CD for > ISO/IEC 10589 (IS-IS Routing) > > Source: ISO/IEC JTC1/SC6 > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for ISO10589. > SC6 intends to use this new version 2 as the base for adding the > enhancements which have been requested by the IETF to optimise the use > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG convenor > originally identified Internet Drafts: > and as the source documents which > specify these enhancements. SC6 invites the IETF to confirm that the > above Internet Drafts are the correct references and to inform SC6 if > there are additional IETF documents which refer to any other > requirements for IS-IS Routing enhancements. > > SC6 would like to interact with the IETF on clarifying the detailed > requirements in the hope that it may be possible to introduce them > during the editing cycle for version 2 of the standard. To this end, > we would like the Routing Area Directors to arrange an IS-IS BOF at the > San Diego IETF meeting to discuss these requirements and how they can be > incorporated into the new version of ISO 10586. > > SC6 will post an initial draft version of the new base document as an > Internet Draft in August 2000 but this will not contain the changes > requested by the IETF. A ballot closure date of February 2001 has been > set for the 2nd CD Ballot to allow incorporation of final input on the > Internet requirements if they can be agreed at the December 2000 IETF > meeting. > > For information, the current instructions to the editor are that he > should use ISO/IEC 10589:1992 as a base for editing, and shall apply the > minimum textual changes mandated by the following TCs and DRs: > > ISO/IEC 10589:1992/Cor.1:1993 > ISO/IEC 10589:1992/Cor.2:1996 > ISO/IEC 10589:1992/Cor.3:1996 > ISO/IEC 10589:1992/Amd 1:1996 > 6N10323 - Defect Reports 7-26 > 6N10659 - Defect Reports 27-34 > 6N10733 - Technical Corrigendum 4 > The editor will also apply the minimal changes necessary to resolve > additional Defect Reports 35-44. > > If SC6 and the IETF are unable to resolve the required changes, the > Editor will add a temporary note to the cover page and the scope clause > stating that: “ ISO 10589 does not currently include the extensions > originally requested by the IETF in Internet Drafts: > and . > National Body and Liaison organization comments are invited to comment > on the best way to progress these extensions.” > > ------=_NextPart_000_018E_01C018C0.F5C6AE40 > Content-Type: application/msword; > name="06n1618.rtf" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="06n1618.rtf" > > {\rtf1\ansi\ansicpg1252\uc1 = > \deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\ p= > anose 02020603050405020304}Times New Roman{\*\falt CG = > Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose = > 02070309020205020404}Courier New;}} > {\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue25 5= > ;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red25 5= > \green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\gree n= > 128\blue128;\red0\green128\blue0; > \red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red1 2= > 8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adj u= > stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default Paragraph = > Font;}{\s15\nowidctlpar > \tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx959 0= > \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title = > Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew = > Deane}{\creatim\yr2000\mo6\dy9\hr18\min52} > {\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\no f= > words533}{\nofchars3040}{\*\company Lucent = > Technologies}{\nofcharsws3733}{\vern89}} > \widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nosp a= > ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot = > \fet0\sectd \linex0\endnhere\sectdefaultcl = > {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}} > {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta = > .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta = > .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta = > )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}} > {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}}{\*\pnseclvl9 > \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain = > \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 6= > 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{ > Telecommunications and Information =20 > \par Exchange Between Systems = > =20 > \par=20 > \par=20 > \par ISO/IEC JTC 1/SC06 N 11618 =20 > \par=20 > \par DATE: 2000-06-16 =20 > \par=20 > \par REPLACES =20 > \par=20 > \par DOC TYPE: > \par Outgoing Liaison Statement =20 > \par=20 > \par TITLE: > \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) = > =20 > \par=20 > \par SOURCE: > \par SC 6/WG 7 Convener = > =20 > \par=20 > \par PROJECT: =20 > \par=20 > \par STATUS: > \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to = > IETF =20 > \par for consideration. = > =20 > \par=20 > \par ACTION ID: ACT=20 > \par=20 > \par DUE DATE: =20 > \par=20 > \par DISTRIBUTION: P & L Members; SC Chair; WG Conveners and = > Secretaries =20 > \par=20 > \par=20 > \par MEDIUM: =20 > \par=20 > \par DISKETTE NO.: =20 > \par=20 > \par NO. OF PAGES: 1 =20 > \par=20 > \par=20 > \par ISO/IEC JTC 1/SC 6 Secretariat = > =20 > \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA = > =20 > \par }\pard = > \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 6= > 72\tx8631\adjustright {Tel: +1 212 642 4992; Fax: +1 212 84}{0 2298; = > E-mail: }{mdeane@ansi.org}{\tab \tab \tab \tab \tab \tab = > \tab }{\b\fs28=20 > \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20 > \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618 > \par }{ > \par }{\b Title: Liaison Report to the IETF Routing Area Director on = > 2}{\b\super nd}{\b CD for ISO/IEC 10589 (IS-IS Routing) > \par=20 > \par Source: ISO/IEC JTC1/SC6 > \par }{ > \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for = > ISO10589. SC6 intends to use this new version 2 as the base for adding = > the enhancements which have been requested by the IETF=20 > to optimise the use of ISO 10589 for Internet routing solutions. The = > IETF IS-IS WG convenor originally identified Internet Drafts: = > and as = > the source documents which specify these enhanceme > nts. SC6 invites the IETF to confirm that the above Internet Drafts = > are the correct references and to inform SC6 if there are additional = > IETF documents which refer to any other requirements for IS-IS Routing = > enhancements. > \par=20 > \par SC6 would like to interact wit > h the IETF on clarifying the detailed requirements in the hope that it = > may be possible to introduce them during the editing cycle for version = > 2 of the standard. To this end, we would like the Routing Area = > Directors to arrange an IS-IS BOF at the San Di > ego IETF meeting to discuss these requirements and how they can be = > incorporated into the new version of ISO 10586. > \par=20 > \par SC6 will post an initial draft version of the new base document as = > an Internet Draft in August 2000 but this will not contain the changes r > equested by the IETF. A ballot closure date of February 2001 has been = > set for the 2nd CD Ballot to allow incorporation of final input on the = > Internet requirements if they can be agreed at the December 2000 IETF = > meeting.=20 > \par=20 > \par For information, the current instructions to the editor are that he = > should use ISO/IEC 10589:1992 as a base for editing, and shall apply the = > minimum textual changes mandated by the following TCs and DRs: > \par=20 > \par ISO/IEC 10589:1992/Cor.1:1993 > \par ISO/IEC 10589:1992/Cor.2:1996 > \par ISO/IEC 10589:1992/Cor.3:1996 > \par ISO/IEC 10589:1992/Amd 1:1996 > \par 6N10323 - Defect Reports 7-26 > \par 6N10659 - Defect Reports 27-34 > \par 6N10733 - Technical Corrigendum 4 > \par The editor will also apply the minimal changes necessary to = > resolve additional Defect Reports 35-44. > \par=20 > \par If SC6 and the IETF are unable to resolve the required changes, the = > Editor will add a temporary note to the cover page and the scope clause = > stating that: \ldblquote=20 > ISO 10589 does not currently include the extensions originally = > requested by the IETF in Internet D > rafts: and = > . National Body and Liaison = > organization comments are invited to comment on the best way to progress = > these extensions.\rdblquote=20 > \par=20 > \par=20 > \par }} > ------=_NextPart_000_018E_01C018C0.F5C6AE40-- > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mbartell@cisco.com Thu, 07 Sep 2000 16:57:25 -0500 Date: Thu, 07 Sep 2000 16:57:25 -0500 From: Micah Bartell mbartell@cisco.com Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing Folks, I will say that the only documents that I integrated into the ISO 10589 2nd edition were those specified in the "Instructions" from the ISO meeting in Prague. The changes consist of the following documents: ISO/IEC 10589:1992/Cor.1:1993 ISO/IEC 10589:1992/Cor.2:1996 ISO/IEC 10589:1992/Cor.3:1996 ISO/IEC 10589:1992/Amd 1:1996 6N10323 - Defect Reports 7-26 6N10659 - Defect Reports 27-34 6N10733 - Technical Corrigendum 4 The editor will also apply the minimal changes necessary to resolve additional Defect Reports 35-44. Regarding the changes proposed for DR 35-44, the SIF recommendation was used in place of these DRs. Nothing IP specific was added to ISO 10589. The question that the ISO is presenting here to the IETF as I understand it is: What does the IETF recommend as the best method moving forward to handle changes to the ISO spec by the IETF and how best should the IP specific information be handled? The ISO world does not seem intent upon making great sweeping changes to the spec, to the best of my knowledge and most new work is being handled within the IETF. I think it would be wise to develop a method for dealing with all IETF changes before setting the precedent of integrating ANY of the IETF ID's or RFC's directly into the spec. That document is already getting unwieldly in Word and if it is going to be accepting another 100 pages of material, it will very likely need to be restructured. The question of whether the ISO wishes to continue to maintain this spec also needs to be asked. If not, it may be possible to publish the ISO 10589 as a standards track RFC. This would likely require some modification to the structure of the document. ( Does an RFC really need 30 pages of complex conformance tables? ) Also the ISO 10589 spec is not friendly to a purely text based representation. These are just some of my thoughts on the matter. While, I am the current editor for the document, I am not presenting these suggestions as a "representative" of the ISO, or stating this to be their official position. I will investigate further making available the PDF version that I have of the 2nd Edition. This is pending a response from ANSI. /mpb At 04:23 PM 9/7/2000 -0400, David Oran wrote: >Copying the WG... > >-----Original Message----- >From: Henk Smit [mailto:henk@Procket.com] >Sent: Thursday, September 07, 2000 3:50 PM >To: David Oran >Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > > > > > For those of you who hate MSWORD, I append the text at the end of the > > message text as well. > > Thank you, I appreciate it ! > Pretty weird that a standards body like ISO is using a proprietary > files format. ;-) > > > Are there other drafts they should fold it? If so, please craft a > > response and I'll get it to them. > > draft-ietf-isis-dyname-02.txt is not a draft anymore. > It is now an RFC: RFC2763. > > I have just submitted a new version of draft-ietf-isis-traffic-01.txt, > draft-ietf-isis-traffic-02.txt. It might be a while before it becomes > an RFC. > > And what about RFC1195 itself ? There is no mention that this RFC > will be incorporated ? > > If RFC1195 is incorporated, there is one more ISIS draft that I would > like to see added. Tony Li, Tony Prziegynda and myself are also authors > of a draft that is related. draft-ietf-isis-domain-wide-02.txt. It is > slated to be an RFC pretty soon, just waiting for the RFC editor to > process it. If 10589 is including IP specific stuff, I think this one > should be incorporated too. > > Henk. > > > > > -----Original Message----- > > From: Matthew Deane [mailto:mdeane@ANSI.org] > > Sent: Thursday, September 07, 2000 11:35 AM > > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > > 'mankin@east.isi.edu' > > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > Dear IETF Directors, > > > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the >following > > > document is forwarded to IETF Routeing and Transport Area Directors > > for > > > consideration: > > > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > > version) > > > > > > > > > Please do not hesitate to contact me should you have any questions. > > > > > > Sincerely, > > > > > > Matt Deane > > > JTC 1/SC 6 Secretariat > > > > > > <<06n1618.rtf>> > > > > > > SC 6 N 11618 > > > > Title: Liaison Report to the IETF Routing Area Director on 2nd CD for > > ISO/IEC 10589 (IS-IS Routing) > > > > Source: ISO/IEC JTC1/SC6 > > > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for >ISO10589. > > SC6 intends to use this new version 2 as the base for adding the > > enhancements which have been requested by the IETF to optimise the use > > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG >convenor > > originally identified Internet Drafts: > > > and as the source documents which > > specify these enhancements. SC6 invites the IETF to confirm that the > > above Internet Drafts are the correct references and to inform SC6 if > > there are additional IETF documents which refer to any other > > requirements for IS-IS Routing enhancements. > > > > SC6 would like to interact with the IETF on clarifying the detailed > > requirements in the hope that it may be possible to introduce them > > during the editing cycle for version 2 of the standard. To this end, > > we would like the Routing Area Directors to arrange an IS-IS BOF at >the > > San Diego IETF meeting to discuss these requirements and how they can >be > > incorporated into the new version of ISO 10586. > > > > SC6 will post an initial draft version of the new base document as an > > Internet Draft in August 2000 but this will not contain the changes > > requested by the IETF. A ballot closure date of February 2001 has >been > > set for the 2nd CD Ballot to allow incorporation of final input on the > > Internet requirements if they can be agreed at the December 2000 IETF > > meeting. > > > > For information, the current instructions to the editor are that he > > should use ISO/IEC 10589:1992 as a base for editing, and shall apply >the > > minimum textual changes mandated by the following TCs and DRs: > > > > ISO/IEC 10589:1992/Cor.1:1993 > > ISO/IEC 10589:1992/Cor.2:1996 > > ISO/IEC 10589:1992/Cor.3:1996 > > ISO/IEC 10589:1992/Amd 1:1996 > > 6N10323 - Defect Reports 7-26 > > 6N10659 - Defect Reports 27-34 > > 6N10733 - Technical Corrigendum 4 > > The editor will also apply the minimal changes necessary to resolve > > additional Defect Reports 35-44. > > > > If SC6 and the IETF are unable to resolve the required changes, the > > Editor will add a temporary note to the cover page and the scope >clause > > stating that: “ ISO 10589 does not currently include the extensions > > originally requested by the IETF in Internet Drafts: > > and . > > National Body and Liaison organization comments are invited to comment > > on the best way to progress these extensions.” > > > > ------=_NextPart_000_018E_01C018C0.F5C6AE40 > > Content-Type: application/msword; > > name="06n1618.rtf" > > Content-Transfer-Encoding: quoted-printable > > Content-Disposition: attachment; > > filename="06n1618.rtf" > > > > {\rtf1\ansi\ansicpg1252\uc1 = > > >\deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\ >p= > > anose 02020603050405020304}Times New Roman{\*\falt CG = > > Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose = > > 02070309020205020404}Courier New;}} > > >{\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue25 >5= > > >;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red25 >5= > > >\green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\gree >n= > > 128\blue128;\red0\green128\blue0; > > >\red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red1 >2= > > >8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adj >u= > > stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default >Paragraph = > > Font;}{\s15\nowidctlpar > > >\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx959 >0= > > \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title >= > > Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew = > > Deane}{\creatim\yr2000\mo6\dy9\hr18\min52} > > >{\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\no >f= > > words533}{\nofchars3040}{\*\company Lucent = > > Technologies}{\nofcharsws3733}{\vern89}} > > >\widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nosp >a= > > >ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot >= > > \fet0\sectd \linex0\endnhere\sectdefaultcl = > > {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}} > > {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta = > > .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta = > > .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta = > > )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta >= > > )}} > > {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > > )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta >= > > )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb >(}{\pntxta = > > )}}{\*\pnseclvl9 > > \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain >= > > >\s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 >6= > > 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{ > > Telecommunications and Information >=20 > > \par Exchange Between Systems >= > > =20 > > \par=20 > > \par=20 > > \par ISO/IEC JTC 1/SC06 N 11618 =20 > > \par=20 > > \par DATE: 2000-06-16 =20 > > \par=20 > > \par REPLACES =20 > > \par=20 > > \par DOC TYPE: > > \par Outgoing Liaison Statement >=20 > > \par=20 > > \par TITLE: > > \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) >= > > =20 > > \par=20 > > \par SOURCE: > > \par SC 6/WG 7 Convener >= > > =20 > > \par=20 > > \par PROJECT: =20 > > \par=20 > > \par STATUS: > > \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to = > > IETF =20 > > \par for consideration. >= > > =20 > > \par=20 > > \par ACTION ID: ACT=20 > > \par=20 > > \par DUE DATE: =20 > > \par=20 > > \par DISTRIBUTION: P & L Members; SC Chair; WG Conveners and = > > Secretaries =20 > > \par=20 > > \par=20 > > \par MEDIUM: =20 > > \par=20 > > \par DISKETTE NO.: =20 > > \par=20 > > \par NO. OF PAGES: 1 =20 > > \par=20 > > \par=20 > > \par ISO/IEC JTC 1/SC 6 Secretariat >= > > =20 > > \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA >= > > =20 > > \par }\pard = > > >\s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 >6= > > 72\tx8631\adjustright {Tel: +1 212 642 4992; Fax: +1 212 84}{0 >2298; = > > E-mail: }{mdeane@ansi.org}{\tab \tab \tab \tab \tab \tab >= > > \tab }{\b\fs28=20 > > \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20 > > \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618 > > \par }{ > > \par }{\b Title: Liaison Report to the IETF Routing Area Director on = > > 2}{\b\super nd}{\b CD for ISO/IEC 10589 (IS-IS Routing) > > \par=20 > > \par Source: ISO/IEC JTC1/SC6 > > \par }{ > > \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for = > > ISO10589. SC6 intends to use this new version 2 as the base for >adding = > > the enhancements which have been requested by the IETF=20 > > to optimise the use of ISO 10589 for Internet routing solutions. The >= > > IETF IS-IS WG convenor originally identified Internet Drafts: = > > and >as = > > the source documents which specify these enhanceme > > nts. SC6 invites the IETF to confirm that the above Internet Drafts >= > > are the correct references and to inform SC6 if there are additional = > > IETF documents which refer to any other requirements for IS-IS >Routing = > > enhancements. > > \par=20 > > \par SC6 would like to interact wit > > h the IETF on clarifying the detailed requirements in the hope that it >= > > may be possible to introduce them during the editing cycle for >version = > > 2 of the standard. To this end, we would like the Routing Area = > > Directors to arrange an IS-IS BOF at the San Di > > ego IETF meeting to discuss these requirements and how they can be = > > incorporated into the new version of ISO 10586. > > \par=20 > > \par SC6 will post an initial draft version of the new base document >as = > > an Internet Draft in August 2000 but this will not contain the changes >r > > equested by the IETF. A ballot closure date of February 2001 has been >= > > set for the 2nd CD Ballot to allow incorporation of final input on the >= > > Internet requirements if they can be agreed at the December 2000 IETF >= > > meeting.=20 > > \par=20 > > \par For information, the current instructions to the editor are that >he = > > should use ISO/IEC 10589:1992 as a base for editing, and shall apply >the = > > minimum textual changes mandated by the following TCs and DRs: > > \par=20 > > \par ISO/IEC 10589:1992/Cor.1:1993 > > \par ISO/IEC 10589:1992/Cor.2:1996 > > \par ISO/IEC 10589:1992/Cor.3:1996 > > \par ISO/IEC 10589:1992/Amd 1:1996 > > \par 6N10323 - Defect Reports 7-26 > > \par 6N10659 - Defect Reports 27-34 > > \par 6N10733 - Technical Corrigendum 4 > > \par The editor will also apply the minimal changes necessary to = > > resolve additional Defect Reports 35-44. > > \par=20 > > \par If SC6 and the IETF are unable to resolve the required changes, >the = > > Editor will add a temporary note to the cover page and the scope >clause = > > stating that: \ldblquote=20 > > ISO 10589 does not currently include the extensions originally = > > requested by the IETF in Internet D > > rafts: and = > > . National Body and Liaison = > > organization comments are invited to comment on the best way to >progress = > > these extensions.\rdblquote=20 > > \par=20 > > \par=20 > > \par }} > > ------=_NextPart_000_018E_01C018C0.F5C6AE40-- > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From henk@Procket.com Fri, 8 Sep 2000 00:23:44 +0200 (MEST) Date: Fri, 8 Sep 2000 00:23:44 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > What does the IETF recommend as the best method moving forward to > handle changes to the ISO spec by the IETF and how best should the IP > specific information be handled? Personally I would be in favor of combining all ISO documents and IETF RFCs into one, and then splitting it up in three separate documents. *) one document that specifies the core of ISIS. How to set up adjacencies, what an LSP looks like, what TLVs are, what areas are to ISIS, how to run the SPF itself, etc. *) one document that specifies all TLVs and algorithms related to routing of iso8473 (aka CLNP) *) one document that specifies all TLVs and algorithms related to routing of IP I think especially splitting the core of IS-IS from iso8473 related details will make the protocol much more understandable. Just my 2 cents, I guess it will never happen ... :-( Henk. From ginsberg@pluris.com Thu, 7 Sep 2000 15:38:24 -0700 Date: Thu, 7 Sep 2000 15:38:24 -0700 From: Les Ginsberg ginsberg@pluris.com Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing The original intent of the workplan submitted to ISO was a two step process: 1)To provide a revised version of the base ISO 10589 spec that incorporates the known DRs etc. This is the work that Micah has taken on - for which he deserves much applause as it involved considerable effort and I am sure not all of it was fun. 2)Moving forward from the output of Step #1, to incorporate the IP related extensions so that there was a unified document/set of documents which accurately reflected the current usage of the protocol given its deployment in both OSI and IP environments. The need for this is driven by the evolution of the usage of the protocol in the IP environment and the (potential) use of IS-IS in dual environments. Also, there is the feeling of some (myself included) that the current fragmented definition is less than optimal. How best to implement Step #2 is a question yet to be answered. Whether to try to put everything into a single document or provide a set of documents? How to manage these documents (within IETF, within ISO, liason)? There are obviously very different approaches to both organizations as far as document formats, approval processes, participation in the process etc. The fact that the IETF has been invited into this process is a very good thing for it means that all the interested parties can easily have a voice in defining at least the content of what should go into the document(s). How such documents are to be maintained, while an important issue, I think should be separated from the more immediate questions of: o What set of inputs should be used to create the document(s)? o What form should the document(s) take? I certainly think that RFC 1195, appropriately revised, should be part of the input set. as well as those extensions that are agreed upon. In addition to those extensions mentioned by others I would also add the "3-way handshake" draft as an essential. Les > -----Original Message----- > From: Micah Bartell [mailto:mbartell@cisco.com] > Sent: Thursday, September 07, 2000 2:57 PM > To: David Oran; ISIS WG > Subject: Re: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement > on Routeing > > > Folks, > > I will say that the only documents that I integrated into the > ISO 10589 2nd edition were those specified in the > "Instructions" from the ISO meeting in Prague. The changes > consist of the following documents: > > ISO/IEC 10589:1992/Cor.1:1993 > ISO/IEC 10589:1992/Cor.2:1996 > ISO/IEC 10589:1992/Cor.3:1996 > ISO/IEC 10589:1992/Amd 1:1996 > 6N10323 - Defect Reports 7-26 > 6N10659 - Defect Reports 27-34 > 6N10733 - Technical Corrigendum 4 > The editor will also apply the minimal changes necessary to resolve > additional Defect Reports 35-44. > > Regarding the changes proposed for DR 35-44, the SIF > recommendation was used in place of these DRs. > > Nothing IP specific was added to ISO 10589. The question > that the ISO is presenting here to the IETF as I understand it is: > > What does the IETF recommend as the best method moving > forward to handle changes to the ISO spec by the IETF and how > best should the IP specific information be handled? > > > The ISO world does not seem intent upon making great sweeping > changes to the spec, to the best of my knowledge and most new > work is being handled within the IETF. > > I think it would be wise to develop a method for dealing with > all IETF changes before setting the precedent of integrating > ANY of the IETF ID's or RFC's directly into the spec. That > document is already getting unwieldly in Word and if it is > going to be accepting another 100 pages of material, it will > very likely need to be restructured. > > The question of whether the ISO wishes to continue to > maintain this spec also needs to be asked. If not, it may be > possible to publish the ISO 10589 as a standards track RFC. > This would likely require some modification to the structure > of the document. ( Does an RFC really need 30 pages of > complex conformance tables? ) Also the ISO 10589 spec is not > friendly to a purely text based representation. > > These are just some of my thoughts on the matter. While, I > am the current editor for the document, I am not presenting > these suggestions as a "representative" of the ISO, or > stating this to be their official position. > > I will investigate further making available the PDF version > that I have of the 2nd Edition. This is pending a response from ANSI. > > /mpb > > > At 04:23 PM 9/7/2000 -0400, David Oran wrote: > >Copying the WG... > > > >-----Original Message----- > >From: Henk Smit [mailto:henk@Procket.com] > >Sent: Thursday, September 07, 2000 3:50 PM > >To: David Oran > >Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > For those of you who hate MSWORD, I append the text at > the end of the > > > message text as well. > > > > Thank you, I appreciate it ! > > Pretty weird that a standards body like ISO is using a proprietary > > files format. ;-) > > > > > Are there other drafts they should fold it? If so, please craft a > > > response and I'll get it to them. > > > > draft-ietf-isis-dyname-02.txt is not a draft anymore. > > It is now an RFC: RFC2763. > > > > I have just submitted a new version of > draft-ietf-isis-traffic-01.txt, > > draft-ietf-isis-traffic-02.txt. It might be a while before > it becomes > > an RFC. > > > > And what about RFC1195 itself ? There is no mention that this RFC > > will be incorporated ? > > > > If RFC1195 is incorporated, there is one more ISIS draft > that I would > > like to see added. Tony Li, Tony Prziegynda and myself are > also authors > > of a draft that is related. > draft-ietf-isis-domain-wide-02.txt. It is > > slated to be an RFC pretty soon, just waiting for the RFC editor to > > process it. If 10589 is including IP specific stuff, I > think this one > > should be incorporated too. > > > > Henk. > > > > > > > > > -----Original Message----- > > > From: Matthew Deane [mailto:mdeane@ANSI.org] > > > Sent: Thursday, September 07, 2000 11:35 AM > > > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > > > 'mankin@east.isi.edu' > > > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > > > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > > Dear IETF Directors, > > > > > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the > >following > > > > document is forwarded to IETF Routeing and Transport > Area Directors > > > for > > > > consideration: > > > > > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > > > version) > > > > > > > > > > > > Please do not hesitate to contact me should you have > any questions. > > > > > > > > Sincerely, > > > > > > > > Matt Deane > > > > JTC 1/SC 6 Secretariat > > > > > > > > <<06n1618.rtf>> > > > > > > > > > > SC 6 N 11618 > > > > > > Title: Liaison Report to the IETF Routing Area Director > on 2nd CD for > > > ISO/IEC 10589 (IS-IS Routing) > > > > > > Source: ISO/IEC JTC1/SC6 > > > > > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for > >ISO10589. > > > SC6 intends to use this new version 2 as the base for adding the > > > enhancements which have been requested by the IETF to > optimise the use > > > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG > >convenor > > > originally identified Internet Drafts: > > > > > and as the source documents which > > > specify these enhancements. SC6 invites the IETF to > confirm that the > > > above Internet Drafts are the correct references and to > inform SC6 if > > > there are additional IETF documents which refer to any other > > > requirements for IS-IS Routing enhancements. > > > > > > SC6 would like to interact with the IETF on clarifying > the detailed > > > requirements in the hope that it may be possible to > introduce them > > > during the editing cycle for version 2 of the standard. > To this end, > > > we would like the Routing Area Directors to arrange an > IS-IS BOF at > >the > > > San Diego IETF meeting to discuss these requirements and > how they can > >be > > > incorporated into the new version of ISO 10586. > > > > > > SC6 will post an initial draft version of the new base > document as an > > > Internet Draft in August 2000 but this will not contain > the changes > > > requested by the IETF. A ballot closure date of February 2001 has > >been > > > set for the 2nd CD Ballot to allow incorporation of final > input on the > > > Internet requirements if they can be agreed at the > December 2000 IETF > > > meeting. > > > > > > For information, the current instructions to the editor > are that he > > > should use ISO/IEC 10589:1992 as a base for editing, and > shall apply > >the > > > minimum textual changes mandated by the following TCs and DRs: > > > > > > ISO/IEC 10589:1992/Cor.1:1993 > > > ISO/IEC 10589:1992/Cor.2:1996 > > > ISO/IEC 10589:1992/Cor.3:1996 > > > ISO/IEC 10589:1992/Amd 1:1996 > > > 6N10323 - Defect Reports 7-26 > > > 6N10659 - Defect Reports 27-34 > > > 6N10733 - Technical Corrigendum 4 > > > The editor will also apply the minimal changes > necessary to resolve > > > additional Defect Reports 35-44. > > > > > > If SC6 and the IETF are unable to resolve the required > changes, the > > > Editor will add a temporary note to the cover page and the scope > >clause > > > stating that: " ISO 10589 does not currently include the > extensions > > > originally requested by the IETF in Internet Drafts: > > > and > . > > > National Body and Liaison organization comments are > invited to comment > > > on the best way to progress these extensions." > > > From jude@tcb.net Fri, 8 Sep 2000 21:06:38 -0600 (MDT) Date: Fri, 8 Sep 2000 21:06:38 -0600 (MDT) From: Jude V. Ballard jude@tcb.net Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing Speaking as someone who is in the early stages of experience with this protocol, I would love to see this as a set of documents managed by the IETF. If for no other reason than to have a unified source, and format for the information. (I find the ISO format to be a bit unwieldy, but that is an opinion and not very relevant) It may also lead to development of protocol analysis, and "experience with" docs (additional benifits to the internet community.) I would be more than willing to volunteer my time in order to help complete this work. (Although the majority of you are probably more qualified.) -Jude On Thu, 7 Sep 2000, Les Ginsberg wrote: > The original intent of the workplan submitted to ISO was a two step process: > > 1)To provide a revised version of the base ISO 10589 spec that incorporates > the known DRs etc. This is the work that Micah has taken on - for which he > deserves much applause as it involved considerable effort and I am sure not > all of it was fun. > > 2)Moving forward from the output of Step #1, to incorporate the IP related > extensions so that there was a unified document/set of documents which > accurately reflected the current usage of the protocol given its deployment > in both OSI and IP environments. The need for this is driven by the > evolution of the usage of the protocol in the IP environment and the > (potential) use of IS-IS in dual environments. Also, there is the feeling of > some (myself included) that the current fragmented definition is less than > optimal. > > How best to implement Step #2 is a question yet to be answered. Whether to > try to put everything into a single document or provide a set of documents? > How to manage these documents (within IETF, within ISO, liason)? > > There are obviously very different approaches to both organizations as far > as document formats, approval processes, participation in the process etc. > > The fact that the IETF has been invited into this process is a very good > thing for it means that all the interested parties can easily have a voice > in defining at least the content of what should go into the document(s). How > such documents are to be maintained, while an important issue, I think > should be separated from the more immediate questions of: > > o What set of inputs should be used to create the document(s)? > o What form should the document(s) take? > > I certainly think that RFC 1195, appropriately revised, should be part of > the input set. as well as those extensions that are agreed upon. In addition > to those extensions mentioned by others I would also add the "3-way > handshake" draft as an essential. > > Les > > > -----Original Message----- > > From: Micah Bartell [mailto:mbartell@cisco.com] > > Sent: Thursday, September 07, 2000 2:57 PM > > To: David Oran; ISIS WG > > Subject: Re: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement > > on Routeing > > > > > > Folks, > > > > I will say that the only documents that I integrated into the > > ISO 10589 2nd edition were those specified in the > > "Instructions" from the ISO meeting in Prague. The changes > > consist of the following documents: > > > > ISO/IEC 10589:1992/Cor.1:1993 > > ISO/IEC 10589:1992/Cor.2:1996 > > ISO/IEC 10589:1992/Cor.3:1996 > > ISO/IEC 10589:1992/Amd 1:1996 > > 6N10323 - Defect Reports 7-26 > > 6N10659 - Defect Reports 27-34 > > 6N10733 - Technical Corrigendum 4 > > The editor will also apply the minimal changes necessary to resolve > > additional Defect Reports 35-44. > > > > Regarding the changes proposed for DR 35-44, the SIF > > recommendation was used in place of these DRs. > > > > Nothing IP specific was added to ISO 10589. The question > > that the ISO is presenting here to the IETF as I understand it is: > > > > What does the IETF recommend as the best method moving > > forward to handle changes to the ISO spec by the IETF and how > > best should the IP specific information be handled? > > > > > > The ISO world does not seem intent upon making great sweeping > > changes to the spec, to the best of my knowledge and most new > > work is being handled within the IETF. > > > > I think it would be wise to develop a method for dealing with > > all IETF changes before setting the precedent of integrating > > ANY of the IETF ID's or RFC's directly into the spec. That > > document is already getting unwieldly in Word and if it is > > going to be accepting another 100 pages of material, it will > > very likely need to be restructured. > > > > The question of whether the ISO wishes to continue to > > maintain this spec also needs to be asked. If not, it may be > > possible to publish the ISO 10589 as a standards track RFC. > > This would likely require some modification to the structure > > of the document. ( Does an RFC really need 30 pages of > > complex conformance tables? ) Also the ISO 10589 spec is not > > friendly to a purely text based representation. > > > > These are just some of my thoughts on the matter. While, I > > am the current editor for the document, I am not presenting > > these suggestions as a "representative" of the ISO, or > > stating this to be their official position. > > > > I will investigate further making available the PDF version > > that I have of the 2nd Edition. This is pending a response from ANSI. > > > > /mpb > > > > > > At 04:23 PM 9/7/2000 -0400, David Oran wrote: > > >Copying the WG... > > > > > >-----Original Message----- > > >From: Henk Smit [mailto:henk@Procket.com] > > >Sent: Thursday, September 07, 2000 3:50 PM > > >To: David Oran > > >Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > > > > > For those of you who hate MSWORD, I append the text at > > the end of the > > > > message text as well. > > > > > > Thank you, I appreciate it ! > > > Pretty weird that a standards body like ISO is using a proprietary > > > files format. ;-) > > > > > > > Are there other drafts they should fold it? If so, please craft a > > > > response and I'll get it to them. > > > > > > draft-ietf-isis-dyname-02.txt is not a draft anymore. > > > It is now an RFC: RFC2763. > > > > > > I have just submitted a new version of > > draft-ietf-isis-traffic-01.txt, > > > draft-ietf-isis-traffic-02.txt. It might be a while before > > it becomes > > > an RFC. > > > > > > And what about RFC1195 itself ? There is no mention that this RFC > > > will be incorporated ? > > > > > > If RFC1195 is incorporated, there is one more ISIS draft > > that I would > > > like to see added. Tony Li, Tony Prziegynda and myself are > > also authors > > > of a draft that is related. > > draft-ietf-isis-domain-wide-02.txt. It is > > > slated to be an RFC pretty soon, just waiting for the RFC editor to > > > process it. If 10589 is including IP specific stuff, I > > think this one > > > should be incorporated too. > > > > > > Henk. > > > > > > > > > > > > > -----Original Message----- > > > > From: Matthew Deane [mailto:mdeane@ANSI.org] > > > > Sent: Thursday, September 07, 2000 11:35 AM > > > > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > > > > 'mankin@east.isi.edu' > > > > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > > > > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > > > > > Dear IETF Directors, > > > > > > > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the > > >following > > > > > document is forwarded to IETF Routeing and Transport > > Area Directors > > > > for > > > > > consideration: > > > > > > > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > > > > version) > > > > > > > > > > > > > > > Please do not hesitate to contact me should you have > > any questions. > > > > > > > > > > Sincerely, > > > > > > > > > > Matt Deane > > > > > JTC 1/SC 6 Secretariat > > > > > > > > > > <<06n1618.rtf>> > > > > > > > > > > > > > > SC 6 N 11618 > > > > > > > > Title: Liaison Report to the IETF Routing Area Director > > on 2nd CD for > > > > ISO/IEC 10589 (IS-IS Routing) > > > > > > > > Source: ISO/IEC JTC1/SC6 > > > > > > > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for > > >ISO10589. > > > > SC6 intends to use this new version 2 as the base for adding the > > > > enhancements which have been requested by the IETF to > > optimise the use > > > > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG > > >convenor > > > > originally identified Internet Drafts: > > > > > > > and as the source documents which > > > > specify these enhancements. SC6 invites the IETF to > > confirm that the > > > > above Internet Drafts are the correct references and to > > inform SC6 if > > > > there are additional IETF documents which refer to any other > > > > requirements for IS-IS Routing enhancements. > > > > > > > > SC6 would like to interact with the IETF on clarifying > > the detailed > > > > requirements in the hope that it may be possible to > > introduce them > > > > during the editing cycle for version 2 of the standard. > > To this end, > > > > we would like the Routing Area Directors to arrange an > > IS-IS BOF at > > >the > > > > San Diego IETF meeting to discuss these requirements and > > how they can > > >be > > > > incorporated into the new version of ISO 10586. > > > > > > > > SC6 will post an initial draft version of the new base > > document as an > > > > Internet Draft in August 2000 but this will not contain > > the changes > > > > requested by the IETF. A ballot closure date of February 2001 has > > >been > > > > set for the 2nd CD Ballot to allow incorporation of final > > input on the > > > > Internet requirements if they can be agreed at the > > December 2000 IETF > > > > meeting. > > > > > > > > For information, the current instructions to the editor > > are that he > > > > should use ISO/IEC 10589:1992 as a base for editing, and > > shall apply > > >the > > > > minimum textual changes mandated by the following TCs and DRs: > > > > > > > > ISO/IEC 10589:1992/Cor.1:1993 > > > > ISO/IEC 10589:1992/Cor.2:1996 > > > > ISO/IEC 10589:1992/Cor.3:1996 > > > > ISO/IEC 10589:1992/Amd 1:1996 > > > > 6N10323 - Defect Reports 7-26 > > > > 6N10659 - Defect Reports 27-34 > > > > 6N10733 - Technical Corrigendum 4 > > > > The editor will also apply the minimal changes > > necessary to resolve > > > > additional Defect Reports 35-44. > > > > > > > > If SC6 and the IETF are unable to resolve the required > > changes, the > > > > Editor will add a temporary note to the cover page and the scope > > >clause > > > > stating that: " ISO 10589 does not currently include the > > extensions > > > > originally requested by the IETF in Internet Drafts: > > > > and > > . > > > > National Body and Liaison organization comments are > > invited to comment > > > > on the best way to progress these extensions." > > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From yakov@cisco.com Mon, 04 Sep 2000 10:20:01 -0700 Date: Mon, 04 Sep 2000 10:20:01 -0700 From: Yakov Rekhter yakov@cisco.com Subject: [Isis-wg] draft-kompella-isis-ompls-extensions-00.txt Tony and Tony, Kireeti and myself would like to ask the ISIS working group to accept draft-kompella-isis-ompls-extensions-00.txt as the ISIS WG document. Yakov. From tony1@home.net Sat, 09 Sep 2000 11:15:23 -0700 Date: Sat, 09 Sep 2000 11:15:23 -0700 From: Tony Li tony1@home.net Subject: [Isis-wg] Re: draft-kompella-isis-ompls-extensions-00.txt > Kireeti and myself would like to ask the ISIS working group > to accept draft-kompella-isis-ompls-extensions-00.txt as the > ISIS WG document. I've seen no comments or objections. Please consider this a WG document. Tony From vikram_isis@hotmail.com Mon, 11 Sep 2000 23:15:03 GMT Date: Mon, 11 Sep 2000 23:15:03 GMT From: vikram isis vikram_isis@hotmail.com Subject: [Isis-wg] Hello Intervals Hi, A question on hello interval timers. Cisco implements hellos times as follows: 1> hello interval : 10 2> hello multiplier: 3 does anybody have some suggestions as to where these values have been specified? Any help is appreciated. Vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From Radia.Perlman@East.Sun.COM Mon, 11 Sep 2000 19:39:03 -0400 (EDT) Date: Mon, 11 Sep 2000 19:39:03 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Hello Intervals >> From: "vikram isis" >> 1> hello interval : 10 >> 2> hello multiplier: 3 >> does anybody have some suggestions as to where these values have been >> specified? I think the Cisco numbers are reasonable. The hello timer must be settable, and perhaps the holding multiplier is as well. So the "hello interval" of 10 is a default, right? By the way, the holding multiplier was something I discovered, to my surprise (and not happiness) that 10589 specified to be a constant, and 10 times the hello timer, which is way too much. I think it was specified as 2+fudge factor, or perhaps 3, in the DECnet Phase 5 routing spec. At any rate, when I asked on the mailing list about how the multiplier got to be specified as 10 (and not settable...an architectural constant), the answer was that everyone was ignoring that, so it wasn't a problem! There's no magic to the numbers, and there was no careful analysis done, but 2 or 3 times for the multiplier seems about right, and 10 times seems definitely wrong. As for the hello timer, I'd think it would have to be a parameter, since if you want to notice a router down within a few seconds, you'll have to send more frequent hellos, and if it were always, say, 1 second, that might be too much overhead in most cases. Radia From danny@tcb.net Mon, 11 Sep 2000 18:02:48 -0600 Date: Mon, 11 Sep 2000 18:02:48 -0600 From: Danny McPherson danny@tcb.net Subject: [Isis-wg] Hello Intervals > There's no magic to the numbers, and there was no careful analysis > done, but 2 or 3 times for the multiplier > seems about right, and 10 times seems definitely > wrong. As for the hello timer, I'd think it would have to be > a parameter, since if you want to notice a router down within a few > seconds, you'll have to send more frequent hellos, and if it were > always, say, 1 second, that might be too much overhead in most cases. Several service provider networks I'm familiar with actually increase the multiplier to 4 or 5 and lower the interval to 1-2s. The b/w utilization is negligible (especially on OC-n connections), and even less when implementations stop padding hellos after adjacency establishment. The benefit (i.e. detecting faults nearly an order of magnitude faster) certainly is interesting, especially when comparing to typical default values. Then again, others increase the interval to cut down on chatting (especially w/large NBMA clouds -- where they need it most *8^/). Of course, it goes without saying -- mucking with values without understanding the full impact on the network is a bad idea. -danny From Radia.Perlman@East.Sun.COM Mon, 11 Sep 2000 21:17:01 -0400 (EDT) Date: Mon, 11 Sep 2000 21:17:01 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Hello Intervals >> From: Danny McPherson >> Several service provider networks I'm familiar with actually increase the >> multiplier to 4 or 5 and lower the interval to 1-2s. What is the value in increasing the multiplier? I understand why you'd want to set the hello interval to be small in order to detect failure quickly. The only reason I could imagine for setting the multiplier higher is if the link is very flaky and it's likely you'll miss several hellos in a row. Are the networks you refer to using very fast and very flaky links? Or are the routers likely to lose a lot of packets without looking at them first, so that most hellos do get lost? Just curious... Radia From danny@tcb.net Mon, 11 Sep 2000 20:13:41 -0600 Date: Mon, 11 Sep 2000 20:13:41 -0600 From: Danny McPherson danny@tcb.net Subject: [Isis-wg] Hello Intervals > What is the value in increasing the multiplier? I understand why you'd > want to set the hello interval to be small in order to detect failure > quickly. The only reason I could imagine for setting the multiplier > higher is if the link is very flaky and it's likely you'll miss > several hellos in a row. Are the networks you refer to > using very fast and very flaky links? > Or are the routers likely to lose a lot of packets without looking at > them first, so that most hellos do get lost? There are a number of reasons, actually. A couple of the networks I refer to are indeed very fast and usually very reliable, though the reasoning equally applies to the lower-speed networks as well. Increasing the multiplier seems to provide a sense of security when decreasing the interval, primarily in order to avoid instability or oscillation as a result of bursts of errors (on usually very reliable links, perhaps when switching to protected SONET paths, though applicable to "non-protected" links as well), or dealing with bursty traffic resulting in temporal congestion (perhaps as the result of circuit failures or other anomalies in the network). And, of course, to deal with "platform" issues (e.g. lack or system bandwidth, processor cycles, plain old flakiness, etc..). Similarly, such models have been deployed w/BGP and other routing protocols, as well as link layer keepalives, etc.. -danny From selvarajr@future.futsoft.com Mon, 11 Sep 2000 20:44:56 +0530 Date: Mon, 11 Sep 2000 20:44:56 +0530 From: selvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt Hi, My doubt is regarding , having more than one adjacency with same system Id but different SNPA. I hope this is possible when there is any backup link present I assume that, if any Hello PDU be received by an IS with system Id same as the received IS, then it can be discarded. ie Receiving own hello PDU. IS - 1 IS - 2 | | | c1 | c2 ----------------------------------------------------------- c3 | | c4 | | | | IS - 3 For the above broadcast topology let, IS-1, IS-2 & IS-3 be three L1 intermediate systems c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up link for IS-3. Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ystem Id but, different SNPA. But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 and vice versa DOUBTS: 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say c3 as the DR. So the LAN will have more than on DR at a time 2. If the IS won't have two interfaces on the same LAN as in the above topology , then why do we need to check for system ID and SNPA. for creating new adjacency over a circuit. I feel checking for System ID alone sufficient. So we can discard duplicate IIH. Pls correct me , if I'm wrong. Selva. From selvarajr@future.futsoft.com Mon, 11 Sep 2000 20:44:56 +0530 Date: Mon, 11 Sep 2000 20:44:56 +0530 From: selvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt ------ =_NextPart_000_01C01C9D.78498060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, My doubt is regarding , having more than one adjacency with same system Id but different SNPA. I hope this is possible when there is any backup link present I assume that, if any Hello PDU be received by an IS with system Id same as the received IS, then it can be discarded. ie Receiving own hello PDU. IS - 1 IS - 2 | | | c1 | c2 ----------------------------------------------------------- c3 | | c4 | | | | IS - 3 For the above broadcast topology let, IS-1, IS-2 & IS-3 be three L1 intermediate systems c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up link for IS-3. Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ystem Id but, different SNPA. But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 and vice versa DOUBTS: 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say c3 as the DR. So the LAN will have more than on DR at a time 2. If the IS won't have two interfaces on the same LAN as in the above topology , then why do we need to check for system ID and SNPA. for creating new adjacency over a circuit. I feel checking for System ID alone sufficient. So we can discard duplicate IIH. Pls correct me , if I'm wrong. Selva. ------ =_NextPart_000_01C01C9D.78498060 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhUEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAUAAAAL AA8OAAAAAAIB/w8BAAAAbQAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAAO07sbk4atQRlnAAIDUf kqCEhQAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJU1dHAFNNVFAAaXNpcy13Z0BleHRlcm5h bC5qdW5pcGVyLm5ldAAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACQAAACdJU0lT V0cnAAAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAcAAABJU0lTV0cAAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAAO07sbk4atQRlnAAIDUfkqCEhQAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAAUWVgEEgAEABgAAAERvdWJ0AP4BAQWAAwAOAAAA0AcJAAsAFAAsADgAAQBkAQEggAMA DgAAANAHCQALABMALQABAAEALQEBCYABACEAAAA3RkNENTk0N0NEODdENDExOTY3MDAwMjAzNTFG OTJBMAAABwEDkAYAaAsAACAAAAALAAIAAQAAAAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMANgAA AAAAQAA5AIDwOQsDHMABHgBwAAEAAAAGAAAARG91YnQAAAACAXEAAQAAABYAAAABwBwDCuZHWc2+ h80R1JZwACA1H5KgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAAHQAAAHNlbHZhcmFqckBm dXR1cmUuZnV0c29mdC5jb20AAAAAAwAGEEHHhQYDAAcQ2AMAAB4ACBABAAAAZQAAAEhJLE1ZRE9V QlRJU1JFR0FSRElORyxIQVZJTkdNT1JFVEhBTk9ORUFESkFDRU5DWVdJVEhTQU1FU1lTVEVNSURC VVRESUZGRVJFTlRTTlBBSUhPUEVUSElTSVNQT1NTSUJMRVcAAAAAAgEJEAEAAABcCAAAWAgAABwT AABMWkZ1dX1fHgMACgByY3BnMTI1cjIMYGMxAzABBwtgbpEOEDAzMw8WZmUPkk8B9wKkA2MCAGNo CsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdCFAdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQA9T7Ef8T C2IT4RRQE7IY9BTQiwcTFeQ2EY4yMzgXVKIgB20gQ0UV5Dcaf6cUQBuvHLV5chXkORGOrxpQFjEe /wOCRwnRawKD3wwBIP8OUCIvA3NUCHAj1LsWMSENOBphJZ8DgkIHQP50DeAj1CVhFmwbeAcTHQb/ G3Aq/x63LJUgVQ4wFk4h6P8slCOJGmEwTiVmLJQm5x2RvzBNKJcslComApEI5jsJb+owOL9lDjA1 Oeo7ATq//zvJOdQ78jpfPi897T1vO5/zOe8QYDI4Q7pE0USPRZn/OdRFwkQvR/9HvUc/RW9JNH45 DlBMhE3hRgNN4AKCc6h0eWwHkGgJ4HQAAGED8GRjdGwKsQBgZMxqdU9QBRBnaAVCFjIdDAFjCcBQ IAMwc25lvngXMAewBbAAwAJzcwBQWHNiMhRQT0BhE/Bc+msJ4HALkFAYCGBQUAuA+mVPgHZVwAFA ULsMMFGEbxuQVGAEoAuAZ0XRUgZi+mEXEGQCIFLAUmZPsFCw+VfxIDFPEw5QU79Uz1XT/wBRVlwA oFGOWN9Z5k8ED8D/Wu9b/1XTDlBWT16vX79aE/YzAoITEGNTgGaBULBaEJMqUFXwIEQBEGF1KkAU IFAKwGEJwGFwaJwgRgIhU0QwEWktD5BeOAFAVZBrE1AYYgsgcs8JUGxyFqBscnc0QyEXAP5wAdBo UlDfZX9mhmqwaXBbBRACMC1qEANhOikQb6Fx0FN1YmoFkHRx0OBEYXRlOlNEGmFq//9sD20fbixP oFoDDiFmgVcWNw5Qb49wnlJV4RcBIEj/WfEEkFNEHZFzr3S/dc9VXy93Dw+BghAI0GIKsHQ4/2Ta D1RhsHkfeiaCoHswC1C8eS9qIHYQCxF7pXNTRP8bkXyvfb9+z24vbz+Ez4XZf3HycZRyySDQUB+L NIJTOYeLf4yPkcBEb2N1B4CfAjAF0GngN+GP8m93kDD7iTEBgG5yUABgCfBogJQgdwIBUwB3smUA 8JQgT2BwSTxgXHYIkHdrC4Bk/x7Al8IE8AdAEGEBQA4AiQL3WeKZJQIQbwVCFyES8nLgjm0LUXLg HQA6XFxxIHpvacFtahADEAeQm9BNkw3gA2BzbwGAIE8BIGsN4JcQXJ2GRQDAAxAufWZQdJTwFxCQ MFJBgBJ4ewFAliFuT7A40J8kaRRjzwMgEvMAgAWQbHZdQWJw/w5wUwChsgGQACCiQpgRlGH/AcGh sRbgD3AAAGJwDNABkPwgLjfyoagOUKJiKkBQkP+i36PvpP8PwGJwBYGmn6ev7ai/bB7AYnBspl+r H6wlPimlLDAQqf+u36wUYiD+KAKRr/+h8xpgra+yb7N//7SPoiAdkLXSoq+3P7hPpSz/G5C137tf vG+9f6IgINC6X/+/78D/wgQK+QMwkA+LP1IxEHtIaSwKhU15IK9mUHJABUAEACA40GcLEfVaIixZ 0GGXwFoxBGA40PQgdKvBIAIgE4DIQQDQ3QnwY8qwA/DM4CBh8AeATc5QeU9QmzAgSVJAYj9/8MrA BpAQUDjQlHFTTqhQQS4KhUlZ0G+XgPfM0csxyzFwE2AAkAJgE4D+d0+wA6DM4KBhyyIAcMqwQWYQ Y2t1cCCAEWt/0dA40BcQAjAKhdCHZiBz25RBzNJ0zADLIGbTQ3uw5mwJAGlwRFXPQBOAONDfncBo wc8xyrADkUkF8M4U/87HzmNmINKy19jY0MwA0sH7A6BooCCYsAOg17FaEJih+wsgCYAuyyATgHsw 2AJaIv+VQAOgT7DXNdB21MzgGNjR33FwDpDhL+H64MMy37/gEf584f/lv+RU42/kcw6B6L/35i/b 8ONWLeuP7J/tr+4ls+c/4BljM+SV6HE07z+/6d/m3/Tv84/0n+AtM9TMt4YB2mMBoG9o0YkAb8hA 35iwT1DM0NEgCPFnyrDT8H8XIMom4JOHkMwA/QEpACaf/PLxANexzOAJ0SBMDpC/cUEEkAeAWhCb cs6lc/bIrw6AzADq8ADxMwDxNP4UP9fCimBycWjC2NBDwHF1Z5pgzpHb8GlylDBooHPf3QDSccyx AZjTkiDT1paRt/3D0HbgEUwXINRBafoQ/2igyrCdQOiC17EPkADy16L/DAABMteiFBDTQVJAAZQU UP/ezXuwOND9Qp+AliFmIGoA/+ihChIMKSkAFnDXMMwSzMH+d9dQzWeX0NMwBhIMGvEA384fzyTM AM+fylNCEjIQHP9mYAMGmnAOY9bSzXgIEWigXwMI3fHdAwGRyzFummFr/xjA3gH7gPDiDQKXwJ3A GfAFe2Fh3txET1VCVNRTOt7VMd0AQZWwV8D5aPBSIIBBAoFmYOiCCMP/ChUOE2Hw+/ABkdpFHPDd AN8T0fDiHqcZgx94U9dQ2nL5/qBBTg4JzJoc4nLQzWDXzNAl8d7VMt0ASdaw2mP/2NIVDw6y/uNp IJ3AF8HSo/8RJCKC2kHHYfpI+4fbZdJw/8qyENAIgFKA2EEZYk+wBWH7BhLOtkQKA9AzBgPDcFnw 9zewWjFSgHcWSntRJIEDpf/dAOChBgA5QKFgLHNaIgYS/lMtKDhQzUHV4J2Sl9DGQP8h4yvB3ALc dcrA09CAEJiwkZuBSUlI3s1QbNMw/9vw+hDX4Zpw2hHMANahzxD7AwacUHedEHgA3s85k8YBp8Fg ciCAgHZhpRB7OlaPxtPHj8iVO5d9AAA+sAMAEBAAAAAAAwAREAEAAAADAIAQ/////0AABzAgT4Ss +hvAAUAACDAgT4Ss+hvAAQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAA AAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMA B4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUA AAEAAAAFAAAAOC4wNAAAAAALAAmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAe AAyACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAA AEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAA AAAAAAAeAD0AAQAAAAEAAAAAAAAAAwANNP03AAARAw== ------ =_NextPart_000_01C01C9D.78498060-- From raszuk@cisco.com Mon, 11 Sep 2000 20:55:16 -0700 Date: Mon, 11 Sep 2000 20:55:16 -0700 From: Robert Raszuk raszuk@cisco.com Subject: [Isis-wg] Hello Intervals Radia, One of the reasons I know of for incresing the multiplier would be to avoid unnecessary adj. flaps when you have bursts of traffic - hence temporary congestions - and your hardware is not capable of separating discarded protocol packets from data packets on an ingress line card. (I know a few boxes which have such a characteristic :). R. > >> From: Danny McPherson > > >> Several service provider networks I'm familiar with actually increase > the > >> multiplier to 4 or 5 and lower the interval to 1-2s. > > What is the value in increasing the multiplier? I understand why you'd > want to set the hello interval to be small in order to detect failure > quickly. The only reason I could imagine for setting the multiplier > higher is if the link is very flaky and it's likely you'll miss > several hellos in a row. Are the networks you refer to > using very fast and very flaky links? > Or are the routers likely to lose a lot of packets without looking at > them first, so that most hellos do get lost? > > Just curious... > > Radia > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From tli@Procket.com Mon, 11 Sep 2000 22:53:52 -0700 (PDT) Date: Mon, 11 Sep 2000 22:53:52 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Hello Intervals | One of the reasons I know of for incresing the multiplier would be to | avoid unnecessary adj. flaps when you have bursts of traffic - hence | temporary congestions - and your hardware is not capable of separating | discarded protocol packets from data packets on an ingress line card. (I | know a few boxes which have such a characteristic :). And before this provokes a discussion, I think most folks would agree that that's not a particularly robust implementation. Tony From naiming@redback.com Tue, 12 Sep 2000 00:34:14 -0700 Date: Tue, 12 Sep 2000 00:34:14 -0700 From: Naiming Shen naiming@redback.com Subject: [Isis-wg] Doubt ] ] IS - 1 IS - 2 ] | | ] | c1 | c2 ]----------------------------------------------------------- ] c3 | | c4 ] | | ] | | ] IS - 3 ] ]For the above broadcast topology let, ] IS-1, IS-2 & IS-3 be three L1 intermediate systems ] c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up ]link for IS-3. ] Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. ] ]Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ]ystem Id but, different SNPA. ]But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 ]and vice versa ] ]DOUBTS: ]1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say ] c3 as the DR. So the LAN will have more than on DR at a time this actually will be worse, the IS-1 and IS-2 may randomly setup adjacnecies with IS-3 on either c3 or c4 depends on the timing. since they will rejects the second adjacency setup due to conflict in systemID and mac addresses. ]2. If the IS won't have two interfaces on the same LAN as in the above ]topology , then why do we need to check for system ID and SNPA. for ]creating new adjacency over a circuit. I feel checking for System ID ]alone sufficient. So we can discard duplicate IIH. i guess the idea was to prevent accident. if you want to bring a new router into the LAN and misconfigure the systemID which duplicates the one already in operation, the proper behaviour should be the new router can not join the ISIS on this LAN instead of knocking off the one already working. since the chances are the new router probably is configured wrong. so this check on both systemID and mac address is useful. ] ]Pls correct me , if I'm wrong. ] - Naiming From larmer@commsense.net Tue, 12 Sep 2000 10:29:11 -0400 Date: Tue, 12 Sep 2000 10:29:11 -0400 From: larmer@commsense.net larmer@commsense.net Subject: [Isis-wg] Doubt Hi Selva, >I assume that, if any Hello PDU be received by an IS with system >Id same as the received IS, then it can be discarded. ie Receiving >own hello PDU. I could not find reference to this in ISO 10589, where is this spelled out? If they were not discarded, wouldn't the DR election process work correctly? > DOUBTS: > 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 >will say c3 as the DR. So the LAN will have more than one DR at a >time ISO 10589 states the following pertinent information in section 8.4.4 LAN Designated Intermediate Systems: d)After waiting ISISHelloTimer * 2 seconds, run the Level 1 and or the Level 2 Designated Intermediate System election process depending on the Intermediate system type. This shall be run subsequently whenever an IIH PDU is received or transmitted...(For these purposes, the transmission of the system's own IIH PDU is equivalent to receiving it)... If IS-3 discards one of the IIH PDUs, I don't believe the DR election process during circuit initialization will work properly. However, subsequent DR elections should work properly because IS-3 will know about both IIH PDUs being generated. Am I off in the weeds? Cheers, Ken Larmer CommSense Networks From larmer@commsense.net Tue, 12 Sep 2000 16:44:27 -0400 Date: Tue, 12 Sep 2000 16:44:27 -0400 From: larmer@commsense.net larmer@commsense.net Subject: [Isis-wg] SRMflag & SSNflag settings --larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074 Content-Type: text/plain; charset="iso-8859-1" Hi, I hope this is the correct forum for asking these questions. I am developing an IS-IS technology course and I have some questions, which I can't seem to get the answers to. I have included a text version of my questions and also a word attachment. I apologize for the lengthy questionnaire, though I appreciate any assistance in this area! I am trying to determine the correct settings for the SRMflag and SSNflag when a CSNP or PSNP are received over a Point-to-Point or Broadcast link. ISO-10589, Section 7.3.15.2, sub-section b) details what actions to take with respect to the SRMflag and the SSNflag when a SNP (either CSNP or PSNP) are received over a circuit (either broadcast or non-broadcast). It states the following: My interpretations and questions are proceeded by #. 7.3.15.2 Action on Receipt of a Sequence Numbers PDU When a Sequence Numbers PDU (Complete or Partial...) is received on circuit C the IS shall perform the following functions: a) Perform the following PDU acceptance tests: ... ... ... ... b) For each LSP reported in the Sequence Number PDU: 1)If the reported value equals the database value and C is a non-broadcast Circuit, Clear SRMflag for C for that LSP. #Non-broadcast: #PSNP received - Acknowledged receipt of LSP. #What do we do with the SSNflag? #CSNP received - Don't update a LSP on a circuit where an adjacent IS already possesses it. #Again, what do we do with the SSNflag? #Broadcast: #PSNP received - The DR sets the SRMflag for this LSP to update the LAN IS requesting this LSP. #Is this interpretation correct? #CSNP received - Do nothing, the LSP databases are synchronized with respect to this LSP. #Is this interpretation correct? 2)If the reported value is older than the database value, Clear SSNflag, and Set SRMflag. #Non-broadcast: #PSNP received - Acknowledgement of a received LSP, however, since the LSP was propagated minimumLSPTransmissionInterval expiration (lastSent) onto this circuit, the receiving IS has received a newer version of this LSP. Consequently, it will update the adjacent IS. #Is this why the SSNflag is cleared? #CSNP received - Update the adjacent IS. Why are we clearing the SSNflag? If this is circuit initialization, because we just received a CSNP, should any SSNflags for this circuit be set? Or, could the circuit have restarted and the SSNflags may represent a left over state? #Broadcast: #PSNP received - Does this mean that the requesting IS is out of date (perhaps dropped the latest CSNP due to congestion and is just getting around to requesting an update) and DR may have had its LSP updated since it sent the last CSNP? #If not, why are we requesting an older LSP? #CSNP received - Update the DR. 3)If the reported value is newer than the database value, Set SSNflag, and if C is a non-broadcast circuit Clear SRMflag. #Non-broadcast: #PSNP received - We are acknowledging a newer LSP than the adjacent IS possesses. #Why is the adjacent IS acknowledging a LSP we have not sent them? Or could this be a previous incarnation? #CSNP received - Do not update the adjacent IS with an older LSP. #Though, why set the SSNflag? #Broadcast: #PSNP received - We are requesting a newer LSP than the DR possesses. Why is this IS requesting a newer LSP and what should the DR do in this situation? #CSNP received - Request an updated LSP from the DR. 4)If no database entry exists for the LSP, and the reported Remaining Lifetime, Checksum and Sequence Number fields of the LSP are all non-zero, create an entry with sequence number 0 and set SSNflag for that entry and circuit C. Under no circumstances shall SRMflag be set for such an LSP with zero sequence number. #Non-Broadcast: #PSNP received - This makes no sense for a PSNP. #??? #CSNP received - Create an entry, but do not propagate. #Why set the SSNflag for a LSP we have not yet received? #Broadcast: #PSNP received - This makes no sense for a PSNP. #??? #CSNP received - Create an entry, but do not propagate and request this LSP from the DR. Regards, Ken Larmer CommSense Networks --larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074 Content-Type: application/msword Content-Disposition: attachment; filename="SRMflag & SSNflag.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKwAAAAAAAAAA EAAALQAAAAEAAAD+////AAAAACoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAmhMAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIh4AADd8AAA3fAAAmg8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKgAAAAAAAAAqAAAAKgA AAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAqAAAABQAAAAAAAAAAAAAALwAAAAAAAAAMgcA AAAAAAAyBwAAAAAAADIHAAAAAAAAMgcAAAwAAAA+BwAAHAAAALwAAAAAAAAA+Q8AALYAAABmBwAA AAAAAGYHAAAAAAAAZgcAAAAAAABmBwAAAAAAAGYHAAAAAAAAZgcAAAAAAABmBwAAAAAAAGYHAAAA AAAAeA8AAAIAAAB6DwAAAAAAAHoPAAAAAAAAeg8AAAAAAAB6DwAAAAAAAHoPAAAAAAAAeg8AACQA AACvEAAAIAIAAM8SAAD4AAAAng8AABUAAAAAAAAAAAAAAAAAAAAAAAAAqAAAAAAAAABmBwAAAAAA AAAAAAAAAAAAAAAAAAAAAABmBwAAAAAAAGYHAAAAAAAAZgcAAAAAAABmBwAAAAAAAJ4PAAAAAAAA hgcAAAAAAACoAAAAAAAAAKgAAAAAAAAAZgcAAAAAAAAAAAAAAAAAAGYHAAAAAAAAsw8AABYAAACG BwAAAAAAAIYHAAAAAAAAhgcAAAAAAABmBwAAFgAAAKgAAAAAAAAAZgcAAAAAAACoAAAAAAAAAGYH AAAAAAAAeA8AAAAAAAAAAAAAAAAAAIYHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAZgcAAAAAAAB4DwAAAAAAAIYHAAB+BQAAhgcAAAAAAAAEDQAA HgAAACwPAAAYAAAAqAAAAAAAAACoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeA8AAAAAAABmBwAAAAAAAFoHAAAMAAAAEKYAjPIc wAG8AAAAdgYAADIHAAAAAAAAfAcAAAoAAABEDwAACAAAAAAAAAAAAAAAeA8AAAAAAADJDwAAMAAA APkPAAAAAAAATA8AACwAAADHEwAAAAAAAIYHAAAAAAAAxxMAAAAAAAB4DwAAAAAAAIYHAAAAAAAA vAAAAAAAAAC8AAAAAAAAAKgAAAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAAgDZAAAASGks DQ0gICAgSSBob3BlIHRoaXMgaXMgdGhlIGNvcnJlY3QgZm9ydW0gZm9yIGFza2luZyB0aGVzZSBx dWVzdGlvbnMuIEkgYW0gZGV2ZWxvcGluZyBhbiBJUy1JUyB0ZWNobm9sb2d5IGNvdXJzZSBhbmQg SSBoYXZlIHNvbWUgcXVlc3Rpb25zLCB3aGljaCBJIGNhbpJ0IHNlZW0gdG8gZ2V0IHRoZSBhbnN3 ZXJzIHRvLiBJIGhhdmUgaW5jbHVkZWQgYSB0ZXh0IHZlcnNpb24gb2YgbXkgcXVlc3Rpb25zIGFu ZCBhbHNvIGEgd29yZCBhdHRhY2htZW50LiBJIGFwb2xvZ2l6ZSBmb3IgdGhlIGxlbmd0aHkgcXVl c3Rpb25uYWlyZSwgdGhvdWdoIEkgYXBwcmVjaWF0ZSBhbnkgYXNzaXN0YW5jZSBpbiB0aGlzIGFy ZWEhIA0NICAgIEkgYW0gdHJ5aW5nIHRvIGRldGVybWluZSB0aGUgY29ycmVjdCBzZXR0aW5ncyBm b3IgdGhlIFNSTWZsYWcgYW5kIFNTTmZsYWcgd2hlbiBhIENTTlAgb3IgUFNOUCBhcmUgcmVjZWl2 ZWQgb3ZlciBhIFBvaW50LXRvLVBvaW50IG9yIEJyb2FkY2FzdCBsaW5rLiBJU08tMTA1ODksIFNl Y3Rpb24gNy4zLjE1LjIsIHN1Yi1zZWN0aW9uIGIpIGRldGFpbHMgd2hhdCBhY3Rpb25zIHRvIHRh a2Ugd2l0aCByZXNwZWN0IHRvIHRoZSBTUk1mbGFnIGFuZCB0aGUgU1NOZmxhZyB3aGVuIGEgU05Q IChlaXRoZXIgQ1NOUCBvciBQU05QKSBhcmUgcmVjZWl2ZWQgb3ZlciBhIGNpcmN1aXQgKGVpdGhl ciBicm9hZGNhc3Qgb3IgUG9pbnQtdG8tUG9pbnQpLiBJdCBzdGF0ZXMgdGhlIGZvbGxvd2luZzog TXkgaW50ZXJwcmV0YXRpb25zIGFuZCBxdWVzdGlvbnMgYXJlIHByb2NlZWRlZCBieSAjLg0NNy4z LjE1LjIgQWN0aW9uIG9uIFJlY2VpcHQgb2YgYSBTZXF1ZW5jZSBOdW1iZXJzIFBEVQ1XaGVuIGEg U2VxdWVuY2UgTnVtYmVycyBQRFUgKENvbXBsZXRlIG9yIFBhcnRpYWyFKSBpcyByZWNlaXZlZCBv biBjaXJjdWl0IEMgdGhlIElTIHNoYWxsIHBlcmZvcm0gdGhlIGZvbGxvd2luZyBmdW5jdGlvbnM6 DWEpIIUNhQ2FDYUNhQ1iKSBGb3IgZWFjaCBMU1AgcmVwb3J0ZWQgaW4gdGhlIFNlcXVlbmNlIE51 bWJlciBQRFU6DQ1JZiB0aGUgcmVwb3J0ZWQgdmFsdWUgZXF1YWxzIHRoZSBkYXRhYmFzZSB2YWx1 ZSBhbmQgQyBpcyBhIG5vbi1icm9hZGNhc3QgQ2lyY3VpdCwgQ2xlYXIgU1JNZmxhZyBmb3IgQyBm b3IgdGhhdCBMU1AuDQ0jTm9uLWJyb2FkY2FzdDoNI1BTTlAgcmVjZWl2ZWQgliBBY2tub3dsZWRn ZWQgcmVjZWlwdCBvZiBMU1AuIA0jV2hhdCBkbyB3ZSBkbyB3aXRoIHRoZSBTU05mbGFnPw0NI0NT TlAgcmVjZWl2ZWQgLSBEb26SdCB1cGRhdGUgYSBMU1Agb24gYSBjaXJjdWl0IHdoZXJlIGFuIGFk amFjZW5jeSBJUy4gI2FscmVhZHkgcG9zc2Vzc2VzIGl0Lg0jQWdhaW4sIHdoYXQgZG8gd2UgZG8g d2l0aCB0aGUgU1NOZmxhZz8NDSNCcm9hZGNhc3Q6DSNQU05QIHJlY2VpdmVkIJYgVGhlIERSIHNl dHMgdGhlIFNSTWZsYWcgZm9yIHRoaXMgTFNQIHRvIHVwZGF0ZSB0aGUgTEFOIElTICNyZXF1ZXN0 aW5nIHRoaXMgTFNQLg0jV2h5IGlzbpJ0IHRoaXMgc3RhdGVkPw0NI0NTTlAgcmVjZWl2ZWQgliBE byBub3RoaW5nLCB0aGUgTFNQIGRhdGFiYXNlcyBhcmUgc3luY2hyb25pemVkIHdpdGggcmVzcGVj dCAjdG8gdGhpcyBMU1AuDSNBZ2Fpbiwgd2h5IGlzbpJ0IHRoaXMgc3RhdGVkDQ1JZiB0aGUgcmVw b3J0ZWQgdmFsdWUgaXMgb2xkZXIgdGhhbiB0aGUgZGF0YWJhc2UgdmFsdWUsIENsZWFyIFNTTmZs YWcsIGFuZCBTZXQgU1JNZmxhZy4NDSNOb24tYnJvYWRjYXN0Og0jUFNOUCByZWNlaXZlZCCWIEFj a25vd2xlZGdlbWVudCBvZiBhIHJlY2VpdmVkIExTUCwgaG93ZXZlciwgc2luY2UgdGhlIExTUCAj d2FzIHByb3BhZ2F0ZWQgbWluaW11bUxTUFRyYW5zbWlzc2lvbkludGVydmFsIGV4cGlyYXRpb24g KGxhc3RTZW50KSBvbnRvICN0aGlzIGNpcmN1aXQsIHRoZSByZWNlaXZpbmcgSVMgaGFzIHJlY2Vp dmVkIGEgbmV3ZXIgdmVyc2lvbiBvZiB0aGlzIExTUC4gI0NvbnNlcXVlbnRseSBpdCB3aWxsIHVw ZGF0ZSB0aGUgYWRqYWNlbnQgSVMuIA0jSXMgdGhpcyB3aHkgdGhlIFNTTmZsYWcgaXMgY2xlYXJl ZD8gDQ0jQ1NOUCByZWNlaXZlZCAtIFVwZGF0ZSB0aGUgYWRqYWNlbnQgSVMuDSNXaHkgYXJlIHdl IGNsZWFyaW5nIHRoZSBTU05mbGFnPyBJZiB0aGlzIGlzIGNpcmN1aXQgaW5pdGlhbGl6YXRpb24s IGJlY2F1c2Ugd2UganVzdCAjcmVjZWl2ZWQgYSBDU05QLCBzaG91bGQgYW55IFNTTmZsYWdzIGZv ciB0aGlzIGNpcmN1aXQgYmUgc2V0PyBPciwgY291bGQgdGhlICNjaXJjdWl0IGhhdmUgcmVzdGFy dGVkIGFuZCB0aGUgU1NOZmxhZ3MgbWF5IHJlcHJlc2VudCBhIGxlZnQgb3ZlciBzdGF0ZT8NDSNC cm9hZGNhc3Q6DSNQU05QIHJlY2VpdmVkIJYgRG9lcyB0aGlzIG1lYW4gdGhhdCB0aGUgcmVxdWVz dGluZyBJUyBpcyBvdXQgb2YgZGF0ZSAocGVyaGFwcyBkcm9wcGVkIHRoZSBsYXRlc3QgQ1NOUCBk dWUgdG8gY29uZ2VzdGlvbiBhbmQgaXMganVzdCBnZXR0aW5nIGFyb3VuZCB0byByZXF1ZXN0aW5n IGFuIHVwZGF0ZSkgYW5kIERSIG1heSBoYXZlIGhhZCBpdHMgTFNQIHVwZGF0ZWQgc2luY2UgaXQg c2VudCB0aGUgbGFzdCBDU05QPw0jSWYgbm90LCB3aHkgYXJlIHdlIHJlcXVlc3RpbmcgYW4gb2xk ZXIgTFNQPyANDSNDU05QIHJlY2VpdmVkIJYgVXBkYXRlIHRoZSBEUi4NDUlmIHRoZSByZXBvcnRl ZCB2YWx1ZSBpcyBuZXdlciB0aGFuIHRoZSBkYXRhYmFzZSB2YWx1ZSwgU2V0IFNTTmZsYWcsIGFu ZCBpZiBDIGlzIGEgbm9uLWJyb2FkY2FzdCBjaXJjdWl0IENsZWFyIFNSTWZsYWcuDQ0jTm9uLWJy b2FkY2FzdDoNI1BTTlAgcmVjZWl2ZWQgliBXZSBhcmUgYWNrbm93bGVkZ2luZyBhIG5ld2VyIExT UCB0aGFuIHRoZSBhZGphY2VudCBJUyAjcG9zc2Vzc2VzLg0jV2h5IGlzIHRoZSBhZGphY2VudCBJ UyBhY2tub3dsZWRnaW5nIGEgTFNQIHdlIGhhdmUgbm90IHNlbnQgdGhlbT8gT3IgY291bGQgI3Ro aXMgYmUgYSBwcmV2aW91cyBpbmNhcm5hdGlvbiBvZiBzb21lIHNvcnQ/DQ0jQ1NOUCByZWNlaXZl ZCCWIERvIG5vdCB1cGRhdGUgdGhlIGFkamFjZW50IElTIHdpdGggYW4gb2xkZXIgTFNQLiANI1Ro b3VnaCwgd2h5IHNldCB0aGUgU1NOZmxhZz8gDQ0jQnJvYWRjYXN0Og0jUFNOUCByZWNlaXZlZCCW IFdlIGFyZSByZXF1ZXN0aW5nIGEgbmV3ZXIgTFNQIHRoYW4gdGhlIERSIHBvc3Nlc3Nlcy4NI1do eSBpcyB0aGlzIElTIHJlcXVlc3RpbmcgYSBuZXdlciBMU1AgYW5kIHdoYXQgc2hvdWxkIHRoZSBE UiBkbyBpbiB0aGlzICNzaXR1YXRpb24/IA0NI0NTTlAgcmVjZWl2ZWQgliBSZXF1ZXN0IGFuIHVw ZGF0ZWQgTFNQIGZyb20gdGhlIERSLiAgDQ1JZiBubyBkYXRhYmFzZSBlbnRyeSBleGlzdHMgZm9y IHRoZSBMU1AsIGFuZCB0aGUgcmVwb3J0ZWQgUmVtYWluaW5nIExpZmV0aW1lLCBDaGVja3N1bSBh bmQgU2VxdWVuY2UgTnVtYmVyIGZpZWxkcyBvZiB0aGUgTFNQIGFyZSBhbGwgbm9uLXplcm8sIGNy ZWF0ZSBhbiBlbnRyeSB3aXRoIHNlcXVlbmNlIG51bWJlciAwIGFuZCBzZXQgU1NOZmxhZyBmb3Ig dGhhdCBlbnRyeSBhbmQgY2lyY3VpdCBDLiBVbmRlciBubyBjaXJjdW1zdGFuY2VzIHNoYWxsIFNS TWZsYWcgYmUgc2V0IGZvciBzdWNoIGFuIExTUCB3aXRoIHplcm8gc2VxdWVuY2UgbnVtYmVyLg0N I05vbi1Ccm9hZGNhc3Q6DSNQU05QIHJlY2VpdmVkIJYgVGhpcyBtYWtlcyBubyBzZW5zZSBmb3Ig YSBQU05QLiANIz8/Pw0NI0NTTlAgcmVjZWl2ZWQgliBDcmVhdGUgYW4gZW50cnksIGJ1dCBkbyBu b3QgcHJvcGFnYXRlLg0jV2h5IHNldCB0aGUgU1NOZmxhZyBmb3IgYSBMU1Agd2UgaGF2ZSBub3Qg eWV0IHJlY2VpdmVkPw0NI0Jyb2FkY2FzdDoNI1BTTlAgcmVjZWl2ZWQgliBUaGlzIG1ha2VzIG5v IHNlbnNlIGZvciBhIFBTTlAuDSM/Pz8NDSNDU05QIHJlY2VpdmVkIJYgQ3JlYXRlIGFuIGVudHJ5 LCBidXQgZG8gbm90IHByb3BhZ2F0ZSBhbmQgcmVxdWVzdCB0aGlzIExTUCAjZnJvbSB0aGUgRFIu DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAACaEwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAQAAAQEAAAFBAAA XgUAAF8FAAAdBwAAHgcAAFMHAADNBwAA0gcAANQHAADWBwAA2AcAANoHAAAPCAAAEAgAAIQIAACF CAAAlQgAAMQIAADlCAAA5ggAAEUJAABtCQAAbgkAAHoJAADbCQAA8wkAAPQJAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAA AAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADy AAAAAAAAAAAAAAAAAAAAAAAFAAAPhNACXoTQAgUAAAomAAtGAQAAAQAAABwABAAAmhMAAP0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAfQJAABPCgAAbQoAAG4K AADGCgAAxwoAANcKAADlCwAACwwAAAwMAAA1DAAAIQ0AACINAAAuDQAAHA4AAEoOAABLDgAAaw4A AGwOAADkDgAA5Q4AAPUOAABIDwAAwg8AAMMPAAAGEAAAJRAAACYQAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADyAAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAA AAAABQAAD4RoAV6EaAEFAAAKJgALRgEAAAEAAAAFAAAPhNACXoTQAgAbJhAAADIQAAB4EAAAzhAA AM8QAAAGEQAABxEAAEISAABDEgAAUxIAAIUSAACKEgAAixIAAMMSAAD8EgAA/RIAAAkTAAA6EwAA PxMAAEATAACaEwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAFAAAKJgALRgEAAAUAAA+EaAFehGgBAAUAAA+E0AJehNACABQgADGQaAEfsNAvILDgPSGw CAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQADwAKAAEAaQAPAAMAAAAA AAAAAAA4AABA8f8CADgADAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNI CQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0ACAAUABh AHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAAAAAAACaDwAACwAAHgAADAD///// AAAAAAQAAAAFAAAAXgEAAF8BAAAdAwAAHgMAAFMDAADNAwAA0gMAANQDAADWAwAA2AMAANoDAAAP BAAAEAQAAIQEAACFBAAAlQQAAMQEAADlBAAA5gQAAEUFAABtBQAAbgUAAHoFAADbBQAA8wUAAPQF AABPBgAAbQYAAG4GAADGBgAAxwYAANcGAADlBwAACwgAAAwIAAA1CAAAIQkAACIJAAAuCQAAHAoA AEoKAABLCgAAawoAAGwKAADkCgAA5QoAAPUKAABICwAAwgsAAMMLAAAGDAAAJQwAACYMAAAyDAAA eAwAAM4MAADPDAAABg0AAAcNAABCDgAAQw4AAFMOAACFDgAAig4AAIsOAADDDgAA/A4AAP0OAAAJ DwAAOg8AAD8PAABADwAAnA8AAJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAASAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAASAAMAEAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAASAAMAIA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAASAAMAMAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAA gAAEAACaEwAACgAAAAAEAAD0CQAAJhAAAJoTAAALAAAADQAAAA4AAAAABAAAmhMAAAwAAAAAAAAA ZQkAAGcJAACcDwAABwAbAAcAAAAAAJwPAAAHAP//FAAAAAoASwBlAG4AIABMAGEAcgBtAGUAcgAl AEQAOgBcAEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMA TgBmAGwAYQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByAGsAQwA6AFwARABvAGMAdQBt AGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAEwAYQByAG0AZQByAFwAQQBwAHAA bABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABc AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMAUgBNAGYAbABhAGcA IAAmACAAUwBTAE4AZgBsAGEAZwAuAGEAcwBkAAoASwBlAG4AIABMAGEAcgBtAGUAcgAlAEQAOgBc AEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMATgBmAGwA YQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByACUARAA6AFwASQBzAC0AaQBzACAAYwBv AHUAcgBzAGUAXABTAFIATQBmAGwAYQBnACAAJgAgAFMAUwBOAGYAbABhAGcALgBkAG8AYwAKAEsA ZQBuACAATABhAHIAbQBlAHIAJQBEADoAXABJAHMALQBpAHMAIABjAG8AdQByAHMAZQBcAFMAUgBN AGYAbABhAGcAIAAmACAAUwBTAE4AZgBsAGEAZwAuAGQAbwBjAAoASwBlAG4AIABMAGEAcgBtAGUA cgAlAEQAOgBcAEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABT AFMATgBmAGwAYQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByAGsAQwA6AFwARABvAGMA dQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAEwAYQByAG0AZQByAFwAQQBw AHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIA ZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMAUgBNAGYAbABh AGcAIAAmACAAUwBTAE4AZgBsAGEAZwAuAGEAcwBkAAoASwBlAG4AIABMAGEAcgBtAGUAcgAlAEQA OgBcAEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMATgBm AGwAYQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByACUARAA6AFwASQBzAC0AaQBzACAA YwBvAHUAcgBzAGUAXABTAFIATQBmAGwAYQBnACAAJgAgAFMAUwBOAGYAbABhAGcALgBkAG8AYwAK AEsAZQBuACAATABhAHIAbQBlAHIAawBDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAA UwBlAHQAdABpAG4AZwBzAFwATABhAHIAbQBlAHIAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABE AGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYA ZQByAHkAIABzAGEAdgBlACAAbwBmACAAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMATgBmAGwAYQBn AC4AYQBzAGQAAQC2YxwzOChgO/8P/w//D/8P/w//D/8P/w//DxAAAQAAAAAAAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/gIAAAApAAEAAAAEgAEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAA AAAAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACAAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAA AAAAAAAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAA AAAAAAAAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEgAEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAAoIBAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAALZjHDMA AAAAAAAAAAAAAAD///////8BAAAAAAD//wEAAAASABEACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8A CQQZAAkEGwAJBP9AA4ABAIwPAACMDwAArIxzAAEAMACMDwAAAAAAAIwPAAAAAAAAAhAAAAAAAAAA mg8AALAAAAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAA AP//AAACAP//AAAAAP//AAACAP//AAAAAAMAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAA AAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcG AgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIE h3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAIgAEAHEIiRgA8NACAABoAQAAAABV Y0lG8WNJRgAAAAAIAJQAAABBAgAA3QwAAAEABgAAAAQAAxAbAAAAAAAAAAAAAAABAAEAAAABAAAA AAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgHoAW0ALQAgYFyMAAAAAAAAAAA AAAAAAAAzA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEIOAAAA AAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAACDKDUQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP//EgAAAAAAUABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBl AHQAdABpAG4AZwBzAFwATABhAHIAbQBlAHIAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEA dABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABUAGUAbQBwAGwAYQB0AGUAcwBcAE4AbwByAG0AYQBs AC4AZABvAHQAAwBIAGkALAAAAAAAAAAKAEsAZQBuACAATABhAHIAbQBlAHIACgBLAGUAbgAgAEwA YQByAG0AZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAA AOCFn/L5T2gQq5EIACsns9kwAAAAcAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKQAAAAEAAAA sAAAAAUAAADEAAAABgAAANAAAAAHAAAA3AAAAAgAAADwAAAACQAAAAQBAAASAAAAEAEAAAoAAAAs AQAADAAAADgBAAANAAAARAEAAA4AAABQAQAADwAAAFgBAAAQAAAAYAEAABMAAABoAQAAAgAAAOQE AAAeAAAABAAAAEhpLAAeAAAAAQAAAABpLAAeAAAACwAAAEtlbiBMYXJtZXIAAB4AAAABAAAAAGVu IB4AAAABAAAAAGVuIB4AAAALAAAATm9ybWFsLmRvdAAAHgAAAAsAAABLZW4gTGFybWVyAAAeAAAA AgAAADgAbiAeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMAAAQAAAAAB45KwUAAAAQAAAAAAm09Hd HMABQAAAAACet37yHMABAwAAAAEAAAADAAAAQQIAAAMAAADdDAAAAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4b EJOXCAArLPmuMAAAAAABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAA oAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAANAAAA0AAAAAwAAADg AAAAAgAAAOQEAAAeAAAAFgAAAENvbW1TZW5zZSBFbmdpbmVlcmluZwBlAAMAAAAbAAAAAwAAAAYA AAADAAAAzA8AAAMAAACgCgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAA AAQAAABIaSwADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAA AAwAAAANAAAADgAAAA8AAAD+////EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA /v///xsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAD+////IwAAACQAAAAlAAAAJgAAACcAAAAo AAAAKQAAAP7////9////LAAAAP7////+/////v////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAA AAAAAAAAADBHCIzyHMABLgAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAxxMAAAAAAABXAG8AcgBkAEQAbwBjAHUA bQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD/ /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiHgAAAAAAAAUA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh AHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAiAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBv AGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAwRwiM8hzAATBHCIzyHMABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQg RG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA --larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074-- From Radia.Perlman@East.Sun.COM Tue, 12 Sep 2000 18:08:12 -0400 (EDT) Date: Tue, 12 Sep 2000 18:08:12 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] SRMflag & SSNflag settings I don't have the time to answer thoroughly, but let me make a comment that will hopefully make things easier to understand. I don't remember why this was specified as two binary flags SRM and SSN. Instead I think it's clearer to think of it as a single "state" variable with 3 settings: OK (don't need to send ack or LSP) ACK (i.e., SSN, need to send ack) XMIT (i.e., SRM, need to transmit LSP) You never should have both SSN and SRM flags set. You send an ack once and then change the state to "OK". You send an LSP if SRM is set (state is "XMIT") until you get an ack or the same LSP from that neighbor. If an ack, you change state to "OK". If you receive the same LSP from a neighbor N you set the state to "ack" for that neighbor. If you receive a new LSP from N you set the state to N to "ack" and to everyone else as "XMIT". You keep transmitting to a neighbor until you get an ack from that nbr, or the same LSP from that nbr. This isn't very complete, I'm sure...but the main thing I wanted to clarify is (unless I've completely forgotten this...it's been about 85 years ... ) that you'd never want both SSN and SRM set. Radia From selvarajr@future.futsoft.com Thu, 14 Sep 2000 15:29:12 +0530 Date: Thu, 14 Sep 2000 15:29:12 +0530 From: selvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt >this actually will be worse, the IS-1 and IS-2 may randomly setup >adjacnecies with IS-3 on either c3 or c4 depends on the timing. since >they will rejects the second adjacency setup due to conflict in systemID >and mac addresses. Yes that is possible if c1 and c2 already exist on the network before c3 or c4. For instance if another IS , IS-4, be commimg up then there is no gaurentee that IS-4 also will form the same adjacency with IS-3 as IS-1 & IS-2. Selva -----Original Message----- From: Naiming Shen [SMTP:naiming@redback.com] Sent: Tuesday, September 12, 2000 1:04 PM To: selvarajr@future.futsoft.com Cc: 'ISISWG' Subject: Re: [Isis-wg] Doubt ] ] IS - 1 IS - 2 ] | | ] | c1 | c2 ]----------------------------------------------------------- ] c3 | | c4 ] | | ] | | ] IS - 3 ] ]For the above broadcast topology let, ] IS-1, IS-2 & IS-3 be three L1 intermediate systems ] c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up ]link for IS-3. ] Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. ] ]Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ]ystem Id but, different SNPA. ]But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 ]and vice versa ] ]DOUBTS: ]1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say ] c3 as the DR. So the LAN will have more than on DR at a time this actually will be worse, the IS-1 and IS-2 may randomly setup adjacnecies with IS-3 on either c3 or c4 depends on the timing. since they will rejects the second adjacency setup due to conflict in systemID and mac addresses. ]2. If the IS won't have two interfaces on the same LAN as in the above ]topology , then why do we need to check for system ID and SNPA. for ]creating new adjacency over a circuit. I feel checking for System ID ]alone sufficient. So we can discard duplicate IIH. i guess the idea was to prevent accident. if you want to bring a new router into the LAN and misconfigure the systemID which duplicates the one already in operation, the proper behaviour should be the new router can not join the ISIS on this LAN instead of knocking off the one already working. since the chances are the new router probably is configured wrong. so this check on both systemID and mac address is useful. ] ]Pls correct me , if I'm wrong. ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From selvarajr@future.futsoft.com Thu, 14 Sep 2000 15:31:46 +0530 Date: Thu, 14 Sep 2000 15:31:46 +0530 From: selvarajR selvarajr@future.futsoft.com Subject: FW: [Isis-wg] Doubt Hi, I was out of station for the past two days. So I couldn't reply imedietly Sorry. If adjacency with neighbours having same system Id as the local system be established then those neighbours won't get in the SPF tree construction. Because local systems cost will be zero and hence the neighbour gets overridden. So no way the adjacency is usefull. If there is no such validation then there will be a possibility that all IS on the LAN ( even whole domain) having same system ID. Won't it be ? So neighbours with conflicting SNPA and System ID be detected it can better be ignored. In any way it is NOT useful. Having useless things is better not having it. Selva. -----Original Message----- From: larmer@commsense.net [SMTP:larmer@commsense.net] Sent: Tuesday, September 12, 2000 7:59 PM To: selvarajr@kailash.future.futsoft.com Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Doubt Hi Selva, >I assume that, if any Hello PDU be received by an IS with system >Id same as the received IS, then it can be discarded. ie Receiving >own hello PDU. I could not find reference to this in ISO 10589, where is this spelled out? If they were not discarded, wouldn't the DR election process work correctly? > DOUBTS: > 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 >will say c3 as the DR. So the LAN will have more than one DR at a >time ISO 10589 states the following pertinent information in section 8.4.4 LAN Designated Intermediate Systems: d)After waiting ISISHelloTimer * 2 seconds, run the Level 1 and or the Level 2 Designated Intermediate System election process depending on the Intermediate system type. This shall be run subsequently whenever an IIH PDU is received or transmitted...(For these purposes, the transmission of the system's own IIH PDU is equivalent to receiving it)... If IS-3 discards one of the IIH PDUs, I don't believe the DR election process during circuit initialization will work properly. However, subsequent DR elections should work properly because IS-3 will know about both IIH PDUs being generated. Am I off in the weeds? Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From ben.abarbanel@ipoptical.com Thu, 14 Sep 2000 10:52:59 -0400 Date: Thu, 14 Sep 2000 10:52:59 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C01E39.F2750BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a = question came to mind regarding=20 unreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth = states "for stability reasons, rapid changes in the values in this = sub-TLV should not cause rapid generation of LSPs".=20 =20 I was wondering what if 2 ingress (head end RSVP) LSR routers are = provisioning LSPs (each wanting 100 Mbytes) through the same core = convergent LSR interface and each one of the routers at the time they = privision their LSP think there is 100 Mbyte of bandwidth free to = complete the job. In reality there is a total of 100 MBYTE for the whole = interface, the first RSVP reservation succeeds while the second fails.=20 =20 The second LSP Ingress router would ask TE Source routing for another = next bandwidth constraint best path to setup the LSP. How efficient is = that if many LSPs coverge in the core of the network this way and there = is no precise way to say what is available at the time RSVP is trigered = on? Also, since the IS-IS and its TE source routing engine take snap shots = of the bandwidth resources in the network it has a tunnel view of what = other IS-IS(LSR) routers are doing to this information at that moment in = time, and are making inaccurate determination of what is reserved and = what is free. The IS-IS route convergent time could be much slower than = the RSVP signalling time. The following is my assumption, please clarify if I am wrong, thanks if a series of LSP requests are hitting a given IS-IS router (TE source = routing engine) at the same processing window/cycle, it makes = assignments based on a frozen snap shot of the bandwidth in the network. = Assignments are made without consideration for their RSVP signalling = success/failure and eventually the signalling components would fail = their reservation requests causing turbulance with LSP attempts. Assuming most of what i said is true, do we need another more precise = mechanism to solve this? =20 Regards, Ben=20 =20 Ben Abarbanel, Software Engineering, =20 Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ------=_NextPart_000_0047_01C01E39.F2750BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
I was reading the latest draft=20 "draft-ietf-isis-traffic-02.txt" and a question came to mind regarding=20
unreserved bandwidth. In section 5.4 = SUB-TLV 11:=20 Unreserved bandwidth states "for stability reasons, rapid changes in the values in this sub-TLV should not cause = rapid=20 generation of LSPs".
 
I was wondering what=20 if  2 ingress (head end RSVP) LSR routers are provisioning LSPs = (each=20 wanting 100 Mbytes) through the same = core=20 convergent LSR interface and each one = of the routers at the time they = privision their LSP think there is 100 Mbyte of bandwidth free to complete = the job. In reality there is a total of 100 MBYTE = for the=20 whole interface, the first RSVP reservation succeeds while the second = fails.=20
 
The second LSP Ingress router = would ask TE=20 Source routing for another next bandwidth constraint best path to setup = the=20 LSP.  How efficient is that if many LSPs coverge in the core of the network this = way and=20 there is no precise way to say what is available=20 at the time RSVP is trigered on?
 
Also, since the IS-IS and its TE = source=20 routing engine take snap shots of the bandwidth resources in the = network it=20 has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are = making=20 inaccurate determination of what is reserved and what is free. The IS-IS = route=20 convergent time could be much slower than the RSVP signalling = time.
 
The following is my assumption, please clarify if I am wrong, = thanks
 
if a series of LSP=20 requests are hitting a given IS-IS router (TE source routing = engine) at the=20 same processing window/cycle, it makes=20 assignments based on a frozen snap shot of the bandwidth in the network. = Assignments are made without consideration for=20 their RSVP signalling success/failure and eventually the signalling = components=20 would fail their reservation requests causing turbulance with LSP attempts.
 
 
Assuming most of what i said is true, = do we need=20 another more precise mechanism to solve this? 
 
Regards,
Ben 
 
 
Ben Abarbanel,  Software = Engineering, =20
 
Phone:  703 456=20 2982
FAX:     703 456 2952
 
IPOptical, Inc.
11480 Sunset Hills = Road
Suite=20 #200E
Reston, VA 20190
------=_NextPart_000_0047_01C01E39.F2750BA0-- From sudheer@nayna.com Thu, 14 Sep 2000 08:05:12 -0700 Date: Thu, 14 Sep 2000 08:05:12 -0700 From: Sudheer Dharnikota sudheer@nayna.com Subject: [Isis-wg] IS-IS TE Question Bena: This is a famous problem with the receiver-oriented reservation mechanims. Where on the downstream side you do the CAC and on the upstream side you do the actual reservaion. I am not sure if we have a straight-forward answer for this. I would also assume that the geneic consensus is pray god that it will not happen (which is the generic approach taken till now) or use different criteria for the second LSP after it failed - as proposed in draft-dharanikota-interarea-mpls-te-ext-00.txt Cheers, sudheer > ben abarbanel wrote: > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a > question came to mind regarding > unreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth > states "for stability reasons, rapid changes in the values in this > sub-TLV should not cause rapid generation of LSPs". > > I was wondering what if 2 ingress (head end RSVP) LSR routers are > provisioning LSPs (each wanting 100 Mbytes) through the same core > convergent LSR interface and each one of the routers at the time they > privision their LSP think there is 100 Mbyte of bandwidth free to > complete the job. In reality there is a total of 100 MBYTE for the > whole interface, the first RSVP reservation succeeds while the second > fails. > > The second LSP Ingress router would ask TE Source routing for another > next bandwidth constraint best path to setup the LSP. How efficient > is that if many LSPs coverge in the core of the network this way and > there is no precise way to say what is available at the time RSVP is > trigered on? > > Also, since the IS-IS and its TE source routing engine take snap shots > of the bandwidth resources in the network it has a tunnel view of what > other IS-IS(LSR) routers are doing to this information at that moment > in time, and are making inaccurate determination of what is reserved > and what is free. The IS-IS route convergent time could be much slower > than the RSVP signalling time. > > The following is my assumption, please clarify if I am wrong, thanks > > if a series of LSP requests are hitting a given IS-IS router (TE > source routing engine) at the same processing window/cycle, it makes > assignments based on a frozen snap shot of the bandwidth in the > network. Assignments are made without consideration for their RSVP > signalling success/failure and eventually the signalling components > would fail their reservation requests causing turbulance with LSP > attempts. > > > Assuming most of what i said is true, do we need another more precise > mechanism to solve this? > > Regards, > Ben > > > Ben Abarbanel, Software Engineering, > > Phone: 703 456 2982 > FAX: 703 456 2952 > > IPOptical, Inc. > 11480 Sunset Hills Road > Suite #200E > Reston, VA 20190 From dareks@nortelnetworks.com Thu, 14 Sep 2000 12:25:29 -0400 Date: Thu, 14 Sep 2000 12:25:29 -0400 From: Darek Skalecki dareks@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question This is a multi-part message in MIME format. --------------7D3D0D0254DA76A03206253F Content-Type: multipart/alternative; boundary="------------5FA9CB3C8BB65B95B52F29AF" --------------5FA9CB3C8BB65B95B52F29AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote: > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a > question came to mind regardingunreserved bandwidth. In section 5.4 > SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid > changes in the values in this sub-TLV should not cause rapid > generation of LSPs". > I was wondering what if 2 ingress (head end RSVP) LSR routers are > provisioning LSPs (each wanting 100 Mbytes) through the same core > convergent LSR interface and each one of the routers at the time they > privision their LSP think there is 100 Mbyte of bandwidth free to > complete the job. In reality there is a total of 100 MBYTE for the > whole interface, the first RSVP reservation succeeds while the second > fails. > The second LSP Ingress router would ask TE Source routing for another > next bandwidth constraint best path to setup the LSP. How efficient > is that if many LSPs coverge in the core of the network this way and > there is no precise way to say what is available at the time RSVP is > trigered on? > Also, since the IS-IS and its TE source routing engine take snap shots > of the bandwidth resources in the network it has a tunnel view of what > other IS-IS(LSR) routers are doing to this information at that moment > in time, and are making inaccurate determination of what is reserved > and what is free. The IS-IS route convergent time could be much slower > than the RSVP signalling time. For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is carried towards the source. The feedback information is then input into TE database at source and a new route computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is described in: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > The following is my assumption, please clarify if I am wrong, thanks > if a series of LSP requests are hitting a given IS-IS router (TE > source routing engine) at the same processing window/cycle, it makes > assignments based on a frozen snap shot of the bandwidth in the > network. Assignments are made without consideration for their RSVP > signalling success/failure and eventually the signalling components > would fail their reservation requests causing turbulance with LSP > attempts. > Assuming most of what i said is true, do we need another more precise > mechanism to solve this? Regards, The feedback provides you ability to try, fail, learn and try again. >From our experience, a proprietary signaling protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route was found). > Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 > FAX: 703 456 2952 IPOptical, Inc. > 11480 Sunset Hills Road > Suite #200E > Reston, VA 20190 -- Darek Skalecki Nortel (613) 765-2252 --------------5FA9CB3C8BB65B95B52F29AF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote:
I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the values in this sub-TLV should not cause rapid generation of LSPs".
I was wondering what if  2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) through the same core convergent LSR interface and each one of the routers at the time they privision their LSP think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the whole interface, the first RSVP reservation succeeds while the second fails.
The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup the LSP.  How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way to say what is available at the time RSVP is trigered on?
Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much slower than the RSVP signalling time.
For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is carried towards the source. The feedback information is then input into TE database at source and a new route computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is described in:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt
The following is my assumption, please clarify if I am wrong, thanks
if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made without consideration for their RSVP signalling success/failure and eventually the signalling components would fail their reservation requests causing turbulance with LSP attempts.
Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards,
The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route was found).
 
Ben  Ben Abarbanel,  Software Engineering, Phone:  703 456 2982
FAX:     703 456 2952 IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190
-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------5FA9CB3C8BB65B95B52F29AF-- --------------7D3D0D0254DA76A03206253F Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-mpls-te-feed-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="draft-ietf-mpls-te-feed-01.txt" MPLS Working Group Peter Ashwood-Smit= h Internet Draft Bilel Jamoussi Expiration Date: December 2000 Don Fedyk Darek Skalecki Nortel Networks July 2000 Improving Topology Data Base Accuracy with LSP Feedback draft-ietf-mpls-te-feed-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. We propose a new mechanism whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy Ashwood-Smith, et. al. [Page 1] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 of the overall routing solution by significantly reducing the database discrepancies. 1. Introduction Because the network is a distributed system, it is necessary to have a mechanism to advertise information about links to all nodes in the network [IS-IS], [OSPF]. A node can then build a topology map of the network. This information is required to be as up-to-date as possible for accurate traffic engineered paths. Information about link or node failures must be rapidly propagated through the network so that recovery can be initiated. Other information about links that may be useful for reasons of quality of service include parameters such as available bandwidth, and delay. The information in this topology database is often out of date with respect to the real network. Available bandwidth is the most critical of these attributes and it can drift substantially with respect to reality due to the low frequency of link state updates that can be sustained in a very large topology. We refer to the deviation in the topology database available bandwidth as being optimistic if the database shows more available bandwidth than there really is, or pessimistic if the topology database shows less bandwidth than there really is. This distinction is important because we shall propose an efficient algorithm to deal with optimistic databases without resorting to shorter flooding intervals. One of the major problems for a constraint based routing system is dealing with changing constraints. Obviously, since bandwidth is one of the essential constraints, dealing with the rapid changes in reserved bandwidth poses some interesting challenges. In smaller networks, one can resort to higher frequency flooding but this obviously does not scale. The basic proposal is to add to the signaling protocol the ability to piggyback actual link bandwidth availability information at every link that the signaling traverses. This is done as part of the reverse messaging on success or failure (mapping, release, withdraw or notification). What this means is that every time signaling messages flow backwards toward a source to tell it of the success, failure or termination of a request, that message contains a detailed slice of bandwidth availability information for the exact path that the message has followed. This slice of reservation information, which is very up to date, is received by the source node and attached to the source node's topology database prior to making any further source route computations. The result is that the source node's topology database will tend to stay synchronized with the slices of the network through which it is establishing paths. This is nothing more than learning from successes and failures and represents an intelligent alternative to either waiting for floods or introducing non-determinism (guessing) into the source algorithms. It is important to note that the fed-back data is never Ashwood-Smith, et. al. July 2000 [Page 2] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 re-flooded. It simply overrides flooded information for the purpose of route computation until a superceding flood or fed-back value arrives. As such, it is not actually inserted into a topology database, most likely it simply is linked to that database as an override used only by source route computations. Operating a constraint based routing system without such feedback is inefficient at best since a source node will continue to give out incorrect route over and over again until it gets an IGP update. This could be minutes away and as a result the worst case blocking time for a new route is the minimum repeatable flooding interval (often several minutes in big networks). Alternatives to feedback mechanisms involve adding some non-determinism (randomness) to the routing algorithm in the hopes that it will stumble onto a path that works. These sorts of approaches are seen in ATM dynamic routing systems, which do not have these forms of feedback. In order to get a good understanding of how the feedback works, imagine a network with precisely one path (with sufficient unreserved bandwidth) available from the source to the destination. Further, imagine that the topology database at the source is significantly out of date with respect to the real network in that the source topology database sees sufficient bandwidth available on many different routes to the destination. We call this being optimistic with respect to the network since the source thinks that more bandwidth is available than there really is. When such an optimistic source selects its first path it will likely contain links that do not in reality have sufficient unreserved bandwidth. Therefore, the path is only established up to the link that does not have sufficient bandwidth. A notification message is formatted that contains the actual unreserved bandwidth for this blocking link which flows back toward the source, collapsing the partially created path as it goes. In addition, at every link that this notification traverses, the current unreserved bandwidth information for each corresponding link is appended to the vector of unreserved bandwidth along the path. In this manner, an accurate view of the slice through the network we are traversing is constructed. Eventually this message arrives back at the source node, where the vector is taken and used to temporarily override the topology database for route computations. This node has just learned from its mistake and is now slightly less optimistic with respect to the real network conditions. Path selection can be attempted again but this time the node will not make the same mistake it made the previous time. The link in question, at which rejection occurred the first time, will not even be eligible this time around, so a source route computation is guaranteed to produce a different path (or none). The same procedure may be repeated as many times as is necessary, each time learning from its mistakes, until eventually no paths remain in the source topology to the destination, or we actually find a path that works. Ashwood-Smith, et. al. July 2000 [Page 3] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 This tendency to converge either to a solution or determine that there is no solution is an important property of a routing system (it actually behaves a lot like a depth first search). This property is not present with flooding mechanisms alone since the source node must randomly hunt, or continually make the same mistakes, or abort until the next flood arrives. In addition to feeding back bandwidth on failure, we also recommend feedback on success. This has important consequences on our ability to spread load or to spill over to new links as existing links fill. It is true that spilling over to new links does not require feedback on success since we could simply wait for a feedback on failure, but we can achieve better load spreading earlier. Finally, when a path is torn down the release/withdraw messages also contain bandwidth information that can be fed back to override the source topology database. This is very important during failure scenarios where the links we need to use to reroute the path share common sub-segments with the failed path. Without the feedback, the common sub-segments may not indicate sufficient available bandwidth until we get a flood that may mean many seconds without a connection. With feedback at least we will be up to date with respect to available bandwidth up to the point of failure in the path. Also since failure involves many paths tearing down and re- establishing this is the time that it is most critical to have an accurate view. When preemption is being employed it is also extremely important that the topology database inconsistencies be small. If not, high setup priority LSPs may unnecessarily preempt lower holding priority LSPs to obtain bandwidth that, had they had a more up to date view of unreserved bandwidth, they would have been able to find elsewhere. Since preempted LSPs may in turn preempt other LSPs in a domino like effect, the results of such database inconsistencies can have wide reaching ripple like impacts. These feedback mechanisms help reduce these occurrences significantly. There are a number of network conditions where feedback shows its value. One can think of a constraint-based network as being in one of three conditions. The first is called ramp-up, this is when the rate of arriving reservations exceeds the rate of departing reservations. The second is called steady-state, this is when the rate of arriving reservations is about the same as the rate of departing reservations. Finally, the ramp-down condition is that which has a greater rate of departing reservations than arriving reservations. These three network conditions show distinctly different types of error in the topology databases. In particular an optimistic view of available bandwidth by a source node is characteristic of the ramp- up condition of a network. A pessimistic view of available bandwidth by a source node is characteristic of the ramp-down condition of a Ashwood-Smith, et. al. July 2000 [Page 4] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 network. If one plots the average error in the topology databases with respect to the real network for the three different network conditions, one will see the error slowly go positive during ramp up, slowly go negative during ramp down, and drift slowly around 0 for the steady condition. The effect of flooding on this plot is to periodically snap the error back to 0 at flooding intervals. The effect of the feedback algorithm is to bring an optimistic error back to zero without having to wait for the flood interval. On average then, the feedback algorithm tends to halve the absolute error, keeping it mostly negative or pessimistic. This makes sense since a routing system will never give paths to links that it thinks do not have resources and as a result its pessimistic view of the world stays that way until it gets a flood. This relieves the IGP updates of the most urgent requirement of flooding when bandwidth is consumed. Availability of new bandwidth occurs when paths are released or new links become available. New links are accompanied by floods. Significant releases of bandwidth can be broadcast at relatively low frequencies in the order of several minutes with little operational impact. Extensive operational experience with this feedback protocol in proprietary Nortel Networks (pre-standard CR-LDP) products has shown it to work very well for networks up to 1000 nodes with significant flooding intervals damped to several minutes. Without this protocol, these networks would block setups for up to several minutes. With this protocol, the blocking in most cases is reduced to a small number of retry attempts which is usually sub-second depending mostly on the propagation delays in the network. These feedback algorithms have been particularly beneficial in cases of failure recovery during which the network is in a sudden condition of ramp-up. Since a large number of reservations must be remade, it is highly likely that we will exceed the limits of certain key links in the network. Without feedback, the rerouting must block until a flood arrives telling us of the situation at those key links at which time rerouting can continue. With feedback, the rerouting simply continues until a feedback indicates that a link is full. In addition since reservation-balancing algorithms are also often used, feedback allows the balancing algorithms to make better distribution decisions based on immediate feedback. We have also explored through simulation and implementation a variety of mechanisms to deal with the pessimistic error in the database. One simple proposal is to use selective forgetting. In this algorithm, a reserved bandwidth value slowly drops back to zero over a relatively short time interval. The theory being that you shift the network back to an optimistic state (by forgetting your pessimism) where the feedback algorithm will again correctly operate. These algorithms have not shown any great advantage and are actually non-optimal when the error is purely optimistic. Ashwood-Smith, et. al. July 2000 [Page 5] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 Other algorithmic permutations we have explored include such variations as: Feeding-back to all intermediate nodes, information learned from control messages upstream of that intermediate node. Feeding back in both directions so that both the source and destination node's databases stay synchronized. Allowing a request to continue to its destination despite there being insufficient bandwidth at some intermediate hop. Then, rejecting the request with a full bandwidth vector slice all the way to the destination instead of just to the point of rejection. Our simulations have not show significant benefits relative to the simpler algorithm proposed here. However, it is an interesting research topic to explore and quantify the different feedback algorithms and their impacts on blocking times so we do not want to discourage the interested reader from exploring these concepts more fully. 2. Adding feedback TLVs to CR-LDP Two new TLVs are optionally added to the CR-LDP mapping, notification, and withdraw messages. There may be an arbitrary number of these TLV in any order or position in the message. It is recommended that they be placed such that they can be read and applied to override the topology database by scanning the message forwards and walking the topology database from the point where the last link feedback TLV left off. Each TLV consists of the 8 unreserved bandwidth values for each holding priority 0 through 7 as IEEE floating point numbers (the units are unidirectional bytes per second). Following this are the IP addresses of the two ends of the interface. Two TLVs are possible, one for IPV4 and one for IPV6 addressing of the link. Note: the feedback TLVs may also optionally be included in query or query-reply messages in response to bandwidth update queries from an LER. Details of this mechanism are provided in [QUERY]. 2.1 Bandwidth directionality considerations The order of the two addresses in the feedback TLV implies the direction in which the bandwidth is available. For example if the first address is A and the second address is B the bandwidth is unreserved in the A to B direction. It is possible for an implementation to provide both the A to B direction and the B to A direction as part of the same feedback message. This is done by simply including a TLV with A,B as the addresses of the link and a different TLV with B,A as the addresses Ashwood-Smith, et. al. July 2000 [Page 6] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 of the link. Should CR-LDP evolve to be able to support bi- directional traffic flow and reservations it is expected that bi- directional feedback would also be implemented via this mechanism. Ashwood-Smith, et. al. July 2000 [Page 7] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 3. IPV4 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x830 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (near end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (far end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. IPV6 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x831 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (near end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (far end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Detailed Procedures On receipt of a withdraw, notification, query-reply, or mapping message pertaining to a request made by CR-LDP (as opposed to LDP), a feedback TLV of the appropriate format for the interface over which the message was received is inserted into the message before forwarding it back to the source of the request. The 8 bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally the interface's address and far end address are placed in the TLV. Ashwood-Smith, et. al. July 2000 [Page 8] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 On receipt of a CR-LDP request message which cannot be satisfied. A notification message is formatted normally. The 8-bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally, the interface's address and far end address are placed in the TLV. On receipt of a CR-LDP request message which has been satisfied and which results in a mapping being generated. No feedback TLV is added since the previous node will insert the proper TLV when it receives the reverse flowing mapping. When an LDP session goes down either because of a link failure, TCP/IP timeout, keepalive timeout, adjacency timeout etc. Other LDP sessions in the module must generate either notification, withdraw or release messages for LSPs that traversed the LDP in question. In the case that the LSP was created by CR-LDP and that a withdraw or notification is about to be generated, LDP will insert a feedback TLV for the interface which just went down that contains 0's for all the bandwidth values and attach to it the proper interface addresses. When the LDP session that originated a CR-LDP label request receives a mapping that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that was just established. When the LDP session that originated a CR-LDP label request receives a notification that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that just failed to establish. The source node may then re-compute a path knowing that the computation will take into account the failure if it was caused by the topology database being in error with respect to the real network state. 6. IGP considerations Implementations MUST NOT permit bandwidth information learned by this feedback mechanism to be re-flooded via IS-IS, OSPF or any other IGP. The bandwidth information learned via these feedback mechanisms is to be used ONLY for source route computations on the nodes that are directly on the path that fed back the bandwidth. Normally only the source node of the LSP, or perhaps intermediate gateway nodes will use this information. It is however permitted for intermediate nodes that are forwarding this feedback information to store it for their own local source route computations. Ashwood-Smith, et. al. July 2000 [Page 9] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 There is a possibility of a race condition between the bandwidth information that is received via feedback and that which is received via a normal IGP flood. While there may be a discrepancy between the two, both are within a few 100 milliseconds of being correct. Solutions to allow us to determine which information is most up to date (say by adding a sequence number) do not add any significant benefit. Constraint based, source routed systems will always have errors in the local topology database with respect to the real network. We can reduce these errors through reduced flooding intervals, path following feedback and selective flooding but we cannot realistically reduce the errors below the second or so range. As a result propagation delay order race conditions are noise with respect to the average expected errors. An implementation SHOULD therefore consider the most recently received update (IGP or feedback) as being the most up to date. 7. Future considerations Constraint based routing systems such as CR-LDP will in the future offer other forms of constraint than simply reserved bandwidth. Actual utilization levels, current congestion levels, number of discrete channels/wavelengths available etc. are all possible constraints that change rapidly and which must be taken into consideration when computing a route. It is expected that this mechanism will be used to feedback these and other new forms of link constraining data. 8. RSVP consideration Nothing precludes the use of such feedback mechanisms with a similar TLV structure in the RSVP Resv and other reverse flowing messages although repeatedly applying a fed-back should be avoided since it increases the race condition window with flooded LSPs. This could be accomplished by a simple rule that only permits fed-back information on the original RESV, not on subsequent refreshes. 9. Intellectual Property Consideration The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 10. Security Considerations This document raises no new security considerations for CR-LDP, RSVP or MPLS in general. 11. Acknowledgments Ashwood-Smith, et. al. July 2000 [Page 10] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 The authors would like to thank Keith Dysart for his guidance, and Jerzy Miernik for helping implement these concepts and bringing them to life. 12. References [CR-LDP] Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr- ldp-04.txt [LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt [IS-IS] Extensions to IS-IS for traffic engineering, draft-ietf- isis-traffic-01.txt [QUERY] MPLS LDP Query Message Description, draft-paraschiv-mpls- lsp-query-00.txt. 13. Author's Addresses Peter Ashwood-Smith Bilel Jamoussi Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, ON K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-763-4534 phone: +1 978-288-4506 petera@nortelnetworks.com jamoussi@nortelnetworks.com Darek Skalecki Don Fedyk Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, On K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-765-2252 Phone: +1 978-228-3041 dareks@nortelnetworks.com dwfedyk@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Ashwood-Smith, et. al. July 2000 [Page 11] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Ashwood-Smith, et. al. July 2000 [Page 12] --------------7D3D0D0254DA76A03206253F-- From cmj@3Com.com Thu, 14 Sep 2000 11:50:36 -0700 Date: Thu, 14 Sep 2000 11:50:36 -0700 From: Cyndi Jung cmj@3Com.com Subject: [Isis-wg] Simple question about IS-IS mixed domains If you can't mix dual and non-dual routers in the same area and have routing work for the non-OSI protocols supported (IP and IPv6), then how can it work at Level 2 if all the Level 2 routers do not support all the same non-OSI protocols? It seems to have the same problem - routes will be computed through routers that do not support the protocol of the data, just because the link costs are lowest. Am I missing something? Cyndi From Mkontoff@Kontoff.com Thu, 14 Sep 2000 16:08:44 -0400 Date: Thu, 14 Sep 2000 16:08:44 -0400 From: Matthew Kontoff Mkontoff@Kontoff.com Subject: [Isis-wg] IS-IS TE Question Darek Skalecki wrote: > > ben abarbanel wrote: > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the > > values in this sub-TLV should not cause rapid generation of LSPs". You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth) changes. How you do this is up to you. For example, you could reflood LSPs at an interval that could be tied to the amount of bandwidth being used. The more frequently LSPs are reflooded the closer an approximation of actual unreserved bandwidth in the network you will have. > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) > > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP > > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the > > whole interface, the first RSVP reservation succeeds while the second fails. > > > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup > > the LSP. How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way > > to say what is available at the time RSVP is trigered on? > > > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it > > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are > > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much > > slower than the RSVP signalling time. > > For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at > interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, > if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is > carried towards the source. The feedback information is then input into TE database at source and a new route > computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is > described in: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs that contain up to the moment (second, millisecond, whatever) bandwidth info? > > The following is my assumption, please clarify if I am wrong, thanks > > > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing > > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made > > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail > > their reservation requests causing turbulance with LSP attempts. > > > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards, > > The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling > protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route > was found). I agree with the 'try fail and learn again' approach but I don't think you need a separate feedback mechanism other than recent IS-IS LSPs from other LSRs. Matt Kontoff From dareks@nortelnetworks.com Thu, 14 Sep 2000 16:29:06 -0400 Date: Thu, 14 Sep 2000 16:29:06 -0400 From: Darek Skalecki dareks@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question --------------B64AA65EFD07897516D25EF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Kontoff wrote: > Darek Skalecki wrote: > > > > ben abarbanel wrote: > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the > > > values in this sub-TLV should not cause rapid generation of LSPs". > > You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth) > changes. How you do this is up to you. For example, you could reflood LSPs at an interval > that could be tied to the amount of bandwidth being used. The more frequently LSPs > are reflooded the closer an approximation of actual unreserved bandwidth in the > network you will have. > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) > > > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP > > > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the > > > whole interface, the first RSVP reservation succeeds while the second fails. > > > > > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup > > > the LSP. How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way > > > to say what is available at the time RSVP is trigered on? > > > > > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it > > > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are > > > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much > > > slower than the RSVP signalling time. > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at > > interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, > > if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is > > carried towards the source. The feedback information is then input into TE database at source and a new route > > computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is > > described in: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs > that contain up to the moment (second, millisecond, whatever) bandwidth info? If your flooding interval is very short then there is no need for feedback but you don't want to flood too frequently or else only control traffic is running in the network and the network doesn't scale too well. We employed feedback in a system where regular floods were every 30 minutes, feedback updates were at path establishment rates, i.e. feedback information was piggy-backed on top of appropriate signaling messages. > > > > > The following is my assumption, please clarify if I am wrong, thanks > > > > > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing > > > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made > > > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail > > > their reservation requests causing turbulance with LSP attempts. > > > > > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards, > > > > The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling > > protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route > > was found). > > I agree with the 'try fail and learn again' approach but I don't think you need > a separate feedback mechanism other than recent IS-IS LSPs from other LSRs. > > Matt Kontoff -- Darek Skalecki Nortel (613) 765-2252 --------------B64AA65EFD07897516D25EF7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Kontoff wrote:
Darek Skalecki wrote:
>
> ben abarbanel wrote:
>
> > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved
> > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the
> > values in this sub-TLV should not cause rapid generation of LSPs".

You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth)
changes. How you do this is up to you. For example, you could reflood LSPs at an interval
that could be tied to the amount of bandwidth being used. The more frequently LSPs
are reflooded the closer an approximation of actual unreserved bandwidth in the
network you will have.

 

>
> > I was wondering what if  2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes)
> > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP
> > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the
> > whole interface, the first RSVP reservation succeeds while the second fails.
>
> > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup
> > the LSP.  How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way
> > to say what is available at the time RSVP is trigered on?
>
> > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it
> > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are
> > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much
> > slower than the RSVP signalling time.
>
> For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at
> interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback,
> if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is
> carried towards the source. The feedback information is then input into TE database at source and a new route
> computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is
> described in:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt

Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs
that contain up to the moment (second, millisecond, whatever) bandwidth info?

If your flooding interval is very short then there is no need for feedback but you don't want to flood too frequently or else only control traffic is running in the network and the network doesn't scale too well. We employed feedback in a system where regular floods were every 30 minutes, feedback updates were at path establishment rates, i.e. feedback information was piggy-backed on top of appropriate signaling messages.
 

> > The following is my assumption, please clarify if I am wrong, thanks
>
> > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing
> > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made
> > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail
> > their reservation requests causing turbulance with LSP attempts.
>
> > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards,
>
> The feedback provides you ability to try, fail, learn and try again. >From our experience, a proprietary signaling
> protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route
> was found).

I agree with the 'try fail and learn again' approach but I don't think you need
a separate feedback mechanism other than recent IS-IS LSPs from other LSRs.

Matt Kontoff

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------B64AA65EFD07897516D25EF7-- From ben.abarbanel@ipoptical.com Thu, 14 Sep 2000 16:44:25 -0400 Date: Thu, 14 Sep 2000 16:44:25 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question Matthew and Darek: I kind of like the feedback mechanism defined in "draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or Darek can add it to their spec is that a timestamp be added to both the flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the reservation denial and bandwidth sample was taken from the rejecting LSR. As the message is returned to the ingress LSR its bandwidth will be overwritten into the linkstate database, since its the most up to date information. I can see a race condition where IGP converging link state information might have older data then Reservation Release/Withdrawl messages containing the same (feedback) data. Thus its possible for the ingress LSR IGP to momentarily over-write newer bandwidth with bad/older bandwidth into the ingress LSR linkstate database. Ingress LSR IGP should check the timestamp in the database with its current LSA/LSP packet and only update the bandwidth value if it has the newer timestamp in the LSA/LSP packet. regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Matthew Kontoff" To: "Darek Skalecki" Cc: "ben abarbanel" ; "isis-wg" Sent: Thursday, September 14, 2000 4:08 PM Subject: Re: [Isis-wg] IS-IS TE Question > > > Darek Skalecki wrote: > > > > ben abarbanel wrote: > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the > > > values in this sub-TLV should not cause rapid generation of LSPs". > > You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth) > changes. How you do this is up to you. For example, you could reflood LSPs at an interval > that could be tied to the amount of bandwidth being used. The more frequently LSPs > are reflooded the closer an approximation of actual unreserved bandwidth in the > network you will have. > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) > > > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP > > > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the > > > whole interface, the first RSVP reservation succeeds while the second fails. > > > > > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup > > > the LSP. How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way > > > to say what is available at the time RSVP is trigered on? > > > > > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it > > > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are > > > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much > > > slower than the RSVP signalling time. > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at > > interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, > > if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is > > carried towards the source. The feedback information is then input into TE database at source and a new route > > computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is > > described in: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs > that contain up to the moment (second, millisecond, whatever) bandwidth info? > > > > The following is my assumption, please clarify if I am wrong, thanks > > > > > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing > > > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made > > > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail > > > their reservation requests causing turbulance with LSP attempts. > > > > > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards, > > > > The feedback provides you ability to try, fail, learn and try again. >From our experience, a proprietary signaling > > protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route > > was found). > > I agree with the 'try fail and learn again' approach but I don't think you need > a separate feedback mechanism other than recent IS-IS LSPs from other LSRs. > > > Matt Kontoff > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From ben.abarbanel@ipoptical.com Thu, 14 Sep 2000 14:02:03 -0400 Date: Thu, 14 Sep 2000 14:02:03 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C01E54.5BE69C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Darek: Thanks for the kind response. I was thinking about your answer. What = happens if you have multiple LSP attempts with multiple retries does the = originating LSR take into account potential attempts that have not = initiated yet, but could collide in the core LSR interface and thus = forces other potential LSP to go to different paths (although less = optimal), or does it simply assume that all colliding LSPs have plenty = of bandwidth even before they are actually assigned or signalled through = the domain? Second question, how do you keep the feedback information carried back = in CR/LDP from being overwritten by the IGP flooding of the same = bandwidth data? Could this propose a synchronization issue or is the = assumption that the IGP data will be as good as the feedback data? Regards, Ben Ben Abarbanel, Software Engineering, =20 Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message -----=20 From: Darek Skalecki=20 To: ben abarbanel=20 Cc: isis-wg=20 Sent: Thursday, September 14, 2000 12:25 PM Subject: Re: [Isis-wg] IS-IS TE Question ben abarbanel wrote:=20 I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and = a question came to mind regardingunreserved bandwidth. In section 5.4 = SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid = changes in the values in this sub-TLV should not cause rapid generation = of LSPs". I was wondering what if 2 ingress (head end RSVP) LSR routers are = provisioning LSPs (each wanting 100 Mbytes) through the same core = convergent LSR interface and each one of the routers at the time they = privision their LSP think there is 100 Mbyte of bandwidth free to = complete the job. In reality there is a total of 100 MBYTE for the whole = interface, the first RSVP reservation succeeds while the second fails. The second LSP Ingress router would ask TE Source routing for = another next bandwidth constraint best path to setup the LSP. How = efficient is that if many LSPs coverge in the core of the network this = way and there is no precise way to say what is available at the time = RSVP is trigered on? Also, since the IS-IS and its TE source routing engine take snap = shots of the bandwidth resources in the network it has a tunnel view of = what other IS-IS(LSR) routers are doing to this information at that = moment in time, and are making inaccurate determination of what is = reserved and what is free. The IS-IS route convergent time could be much = slower than the RSVP signalling time. For CR-LDP a feedback mechanism was proposed to learn at signaling = intervals/speed whether or not there was b/w at interfaces. A snapshot = of that b/w is fed into TE database based on which source routes are = computed. With feedback, if there is insufficient b/w at an interface to = accomodate an LSP, a notification message with a feedback TLV is carried = towards the source. The feedback information is then input into TE = database at source and a new route computed. That route should now not = contain the interface where there was insufficient b/w. The feedback = mechanism is described in:=20 http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt=20 The following is my assumption, please clarify if I am wrong, thanks if a series of LSP requests are hitting a given IS-IS router (TE = source routing engine) at the same processing window/cycle, it makes = assignments based on a frozen snap shot of the bandwidth in the network. = Assignments are made without consideration for their RSVP signalling = success/failure and eventually the signalling components would fail = their reservation requests causing turbulance with LSP attempts. Assuming most of what i said is true, do we need another more = precise mechanism to solve this? Regards, The feedback provides you ability to try, fail, learn and try again. = >From our experience, a proprietary signaling protocol with feedback = worked just fine, i.e. convergence was fast (one or two tries/failures = and a satisfactory route was found).=20 =20 Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982=20 FAX: 703 456 2952 IPOptical, Inc.=20 11480 Sunset Hills Road=20 Suite #200E=20 Reston, VA 20190 --=20 Darek Skalecki Nortel=20 (613) 765-2252 =20 -------------------------------------------------------------------------= ----- MPLS Working Group Peter = Ashwood-Smith Internet Draft Bilel Jamoussi Expiration Date: December 2000 Don Fedyk Darek Skalecki Nortel Networks July 2000 Improving Topology Data Base Accuracy with LSP Feedback draft-ietf-mpls-te-feed-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other = documents at any time. It is inappropriate to use Internet-Drafts as = reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a = set of constraints which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It = is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. We propose a new mechanism whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy Ashwood-Smith, et. al. [Page 1] Internet Draft LSP Feedback with CR-LDP July, 2000 of the overall routing solution by significantly reducing the database discrepancies. 1. Introduction Because the network is a distributed system, it is necessary to = have a mechanism to advertise information about links to all nodes in = the network [IS-IS], [OSPF]. A node can then build a topology map of the network. This information is required to be as up-to-date as possible for accurate traffic engineered paths. Information about link or node failures must be rapidly propagated through the = network so that recovery can be initiated. Other information about links that may be useful for reasons of quality of service include parameters such as available bandwidth, and delay. The information in this topology database is often out of date with respect to the real network. Available bandwidth is the most critical of these attributes and it can drift substantially with respect to reality due to the low frequency of link state updates that can be = sustained in a very large topology. We refer to the deviation in the topology database available bandwidth as being optimistic if the database shows more available bandwidth than there really is, or pessimistic if the topology database shows less bandwidth than there really is. This distinction is important because we shall propose an efficient algorithm to deal with optimistic databases without resorting to shorter flooding intervals. One of the major problems for a constraint based routing system is dealing with changing constraints. Obviously, since bandwidth is = one of the essential constraints, dealing with the rapid changes in reserved bandwidth poses some interesting challenges. In smaller networks, one can resort to higher frequency flooding but this obviously does not scale. The basic proposal is to add to the signaling protocol the ability to piggyback actual link bandwidth availability information at = every link that the signaling traverses. This is done as part of the reverse messaging on success or failure (mapping, release, withdraw or notification). What this means is that every time signaling messages flow backwards toward a source to tell it of the success, failure or termination of a request, that message contains a detailed slice of bandwidth availability information for the exact path that the message has followed. This slice of reservation information, which is very up to date, is received by the source node and attached to the source node's topology database prior to making any further source route computations. The result is that = the source node's topology database will tend to stay synchronized with the slices of the network through which it is establishing paths. This is nothing more than learning from successes and failures and represents an intelligent alternative to either waiting for floods or introducing non-determinism (guessing) into the source algorithms. It is important to note that the fed-back data is never Ashwood-Smith, et. al. July 2000 [Page 2] Internet Draft LSP Feedback with CR-LDP July, 2000 re-flooded. It simply overrides flooded information for the purpose of route computation until a superceding flood or fed-back value arrives. As such, it is not actually inserted into a topology database, most likely it simply is linked to that database as an override used only by source route computations. Operating a constraint based routing system without such feedback = is inefficient at best since a source node will continue to give out incorrect route over and over again until it gets an IGP update. This could be minutes away and as a result the worst case blocking time for a new route is the minimum repeatable flooding interval (often several minutes in big networks). Alternatives to feedback mechanisms involve adding some non-determinism (randomness) to the routing algorithm in the hopes that it will stumble onto a path = that works. These sorts of approaches are seen in ATM dynamic routing systems, which do not have these forms of feedback. In order to get a good understanding of how the feedback works, imagine a network with precisely one path (with sufficient unreserved bandwidth) available from the source to the destination. Further, imagine that the topology database at the source is significantly out of date with respect to the real network in that the source topology database sees sufficient bandwidth available on many different routes to the destination. We call this being optimistic with respect to the network since the source thinks that more bandwidth is available than there really is. When such an optimistic source selects its first path it will = likely contain links that do not in reality have sufficient unreserved bandwidth. Therefore, the path is only established up to the link that does not have sufficient bandwidth. A notification message is formatted that contains the actual unreserved bandwidth for this blocking link which flows back toward the source, collapsing the partially created path as it goes. In addition, at every link that this notification traverses, the current unreserved bandwidth information for each corresponding link is appended to the vector = of unreserved bandwidth along the path. In this manner, an accurate view of the slice through the network we are traversing is constructed. Eventually this message arrives back at the source node, where the vector is taken and used to temporarily override = the topology database for route computations. This node has just = learned from its mistake and is now slightly less optimistic with respect = to the real network conditions. Path selection can be attempted again but this time the node will not make the same mistake it made the previous time. The link in question, at which rejection occurred the first time, will not even be eligible this time around, so a source route computation is guaranteed to produce a different path (or none). The same = procedure may be repeated as many times as is necessary, each time learning from its mistakes, until eventually no paths remain in the source topology to the destination, or we actually find a path that works. Ashwood-Smith, et. al. July 2000 [Page 3] Internet Draft LSP Feedback with CR-LDP July, 2000 This tendency to converge either to a solution or determine that there is no solution is an important property of a routing system (it actually behaves a lot like a depth first search). This = property is not present with flooding mechanisms alone since the source node must randomly hunt, or continually make the same mistakes, or abort until the next flood arrives. In addition to feeding back bandwidth on failure, we also recommend feedback on success. This has important consequences on our ability to spread load or to spill over to new links as existing links = fill. It is true that spilling over to new links does not require = feedback on success since we could simply wait for a feedback on failure, = but we can achieve better load spreading earlier. Finally, when a path is torn down the release/withdraw messages = also contain bandwidth information that can be fed back to override the source topology database. This is very important during failure scenarios where the links we need to use to reroute the path share common sub-segments with the failed path. Without the feedback, the common sub-segments may not indicate sufficient available bandwidth until we get a flood that may mean many seconds without a connection. With feedback at least we will be up to date with respect to available bandwidth up to the point of failure in the path. Also since failure involves many paths tearing down and re- establishing this is the time that it is most critical to have an accurate view. When preemption is being employed it is also extremely important that the topology database inconsistencies be small. If not, high setup priority LSPs may unnecessarily preempt lower holding = priority LSPs to obtain bandwidth that, had they had a more up to date view of unreserved bandwidth, they would have been able to find elsewhere. Since preempted LSPs may in turn preempt other LSPs in a domino like effect, the results of such database inconsistencies = can have wide reaching ripple like impacts. These feedback mechanisms help reduce these occurrences significantly. There are a number of network conditions where feedback shows its value. One can think of a constraint-based network as being in one of three conditions. The first is called ramp-up, this is when the rate of arriving reservations exceeds the rate of departing reservations. The second is called steady-state, this is when the rate of arriving reservations is about the same as the rate of departing reservations. Finally, the ramp-down condition is that which has a greater rate of departing reservations than arriving reservations. These three network conditions show distinctly different types of error in the topology databases. In particular an optimistic view = of available bandwidth by a source node is characteristic of the ramp- up condition of a network. A pessimistic view of available = bandwidth by a source node is characteristic of the ramp-down condition of a Ashwood-Smith, et. al. July 2000 [Page 4] Internet Draft LSP Feedback with CR-LDP July, 2000 network. If one plots the average error in the topology databases with respect to the real network for the three different network conditions, one will see the error slowly go positive during ramp up, slowly go negative during ramp down, and drift slowly around 0 for the steady condition. The effect of flooding on this plot is to periodically snap the error back to 0 at flooding intervals. The effect of the feedback algorithm is to bring an optimistic error back to zero without having to wait for the flood interval. On average then, the feedback algorithm tends to halve the absolute error, keeping it mostly negative or pessimistic. This makes sense since a routing system will never give paths to links that it = thinks do not have resources and as a result its pessimistic view of the world stays that way until it gets a flood. This relieves the IGP updates of the most urgent requirement of flooding when bandwidth = is consumed. Availability of new bandwidth occurs when paths are released or new links become available. New links are accompanied by floods. Significant releases of bandwidth can be broadcast at relatively low frequencies in the order of several minutes with little operational impact. Extensive operational experience with this feedback protocol in proprietary Nortel Networks (pre-standard CR-LDP) products has = shown it to work very well for networks up to 1000 nodes with significant flooding intervals damped to several minutes. Without this = protocol, these networks would block setups for up to several minutes. With this protocol, the blocking in most cases is reduced to a small number of retry attempts which is usually sub-second depending mostly on the propagation delays in the network. These feedback algorithms have been particularly beneficial in = cases of failure recovery during which the network is in a sudden condition of ramp-up. Since a large number of reservations must be remade, it is highly likely that we will exceed the limits of certain key links in the network. Without feedback, the rerouting must block until a flood arrives telling us of the situation at those key links at which time rerouting can continue. With = feedback, the rerouting simply continues until a feedback indicates that a link is full. In addition since reservation-balancing algorithms = are also often used, feedback allows the balancing algorithms to make better distribution decisions based on immediate feedback. We have also explored through simulation and implementation a variety of mechanisms to deal with the pessimistic error in the database. One simple proposal is to use selective forgetting. In this algorithm, a reserved bandwidth value slowly drops back to = zero over a relatively short time interval. The theory being that you shift the network back to an optimistic state (by forgetting your pessimism) where the feedback algorithm will again correctly operate. These algorithms have not shown any great advantage and = are actually non-optimal when the error is purely optimistic. Ashwood-Smith, et. al. July 2000 [Page 5] Internet Draft LSP Feedback with CR-LDP July, 2000 Other algorithmic permutations we have explored include such variations as: Feeding-back to all intermediate nodes, information learned from control messages upstream of that intermediate node. Feeding back in both directions so that both the source and destination node's databases stay synchronized. Allowing a request to continue to its destination despite there being insufficient bandwidth at some intermediate hop. Then, rejecting the request with a full bandwidth vector slice all the = way to the destination instead of just to the point of rejection. Our simulations have not show significant benefits relative to the simpler algorithm proposed here. However, it is an interesting research topic to explore and quantify the different feedback algorithms and their impacts on blocking times so we do not want to discourage the interested reader from exploring these concepts more fully. 2. Adding feedback TLVs to CR-LDP Two new TLVs are optionally added to the CR-LDP mapping, notification, and withdraw messages. There may be an arbitrary number of these TLV in any order or position in the message. It is recommended that they be placed such that they can be read and applied to override the topology database by scanning the message forwards and walking the topology database from the point where the last link feedback TLV left off. Each TLV consists of the 8 unreserved bandwidth values for each holding priority 0 through 7 as IEEE floating point numbers (the units are unidirectional bytes per second). Following this are the IP addresses of the two ends of the interface. Two TLVs are possible, one for IPV4 and one for IPV6 addressing of the link. Note: the feedback TLVs may also optionally be included in query or query-reply messages in response to bandwidth update queries from = an LER. Details of this mechanism are provided in [QUERY]. 2.1 Bandwidth directionality considerations The order of the two addresses in the feedback TLV implies the direction in which the bandwidth is available. For example if the first address is A and the second address is B the bandwidth is unreserved in the A to B direction. It is possible for an implementation to provide both the A to B direction and the B to A direction as part of the same feedback message. This is done by simply including a TLV with A,B as the addresses of the link and a different TLV with B,A as the addresses Ashwood-Smith, et. al. July 2000 [Page 6] Internet Draft LSP Feedback with CR-LDP July, 2000 of the link. Should CR-LDP evolve to be able to support bi- directional traffic flow and reservations it is expected that bi- directional feedback would also be implemented via this mechanism. Ashwood-Smith, et. al. July 2000 [Page 7] Internet Draft LSP Feedback with CR-LDP July, 2000 3. IPV4 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x830 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (near end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (far end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. IPV6 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x831 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (near end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (far end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Detailed Procedures On receipt of a withdraw, notification, query-reply, or mapping message pertaining to a request made by CR-LDP (as opposed to LDP), a feedback TLV of the appropriate format for the interface over which the message was received is inserted into the message before forwarding it back to the source of the request. The 8 bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally the interface's address and far end address are placed in the TLV. Ashwood-Smith, et. al. July 2000 [Page 8] Internet Draft LSP Feedback with CR-LDP July, 2000 On receipt of a CR-LDP request message which cannot be satisfied. A notification message is formatted normally. The 8-bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally, the interface's address and far end address are placed in the TLV. On receipt of a CR-LDP request message which has been satisfied and which results in a mapping being generated. No feedback TLV is = added since the previous node will insert the proper TLV when it receives the reverse flowing mapping. When an LDP session goes down either because of a link failure, TCP/IP timeout, keepalive timeout, adjacency timeout etc. Other LDP sessions in the module must generate either notification, withdraw or release messages for LSPs that traversed the LDP in question. In the case that the LSP was created by CR-LDP and that a withdraw or notification is about to be generated, LDP will insert a feedback TLV for the interface which just went down that contains 0's for = all the bandwidth values and attach to it the proper interface addresses. When the LDP session that originated a CR-LDP label request = receives a mapping that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that was just established. When the LDP session that originated a CR-LDP label request = receives a notification that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that just failed to establish. The source node may then re-compute a path knowing that the computation will take into account the failure if it was caused by the topology database being in error with respect to the real network state. 6. IGP considerations Implementations MUST NOT permit bandwidth information learned by this feedback mechanism to be re-flooded via IS-IS, OSPF or any other IGP. The bandwidth information learned via these feedback mechanisms is to be used ONLY for source route computations on the nodes that are directly on the path that fed back the bandwidth. Normally only the source node of the LSP, or perhaps intermediate gateway nodes will use this information. It is however permitted = for intermediate nodes that are forwarding this feedback information to store it for their own local source route computations. Ashwood-Smith, et. al. July 2000 [Page 9] Internet Draft LSP Feedback with CR-LDP July, 2000 There is a possibility of a race condition between the bandwidth information that is received via feedback and that which is = received via a normal IGP flood. While there may be a discrepancy between = the two, both are within a few 100 milliseconds of being correct. Solutions to allow us to determine which information is most up to date (say by adding a sequence number) do not add any significant benefit. Constraint based, source routed systems will always have errors in the local topology database with respect to the real network. We can reduce these errors through reduced flooding intervals, path following feedback and selective flooding but we cannot realistically reduce the errors below the second or so = range. As a result propagation delay order race conditions are noise with respect to the average expected errors. An implementation SHOULD therefore consider the most recently received update (IGP or feedback) as being the most up to date. 7. Future considerations Constraint based routing systems such as CR-LDP will in the future offer other forms of constraint than simply reserved bandwidth. Actual utilization levels, current congestion levels, number of discrete channels/wavelengths available etc. are all possible constraints that change rapidly and which must be taken into consideration when computing a route. It is expected that this mechanism will be used to feedback these and other new forms of = link constraining data. 8. RSVP consideration Nothing precludes the use of such feedback mechanisms with a = similar TLV structure in the RSVP Resv and other reverse flowing messages although repeatedly applying a fed-back should be avoided since it increases the race condition window with flooded LSPs. This could = be accomplished by a simple rule that only permits fed-back = information on the original RESV, not on subsequent refreshes. 9. Intellectual Property Consideration The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 10. Security Considerations This document raises no new security considerations for CR-LDP, = RSVP or MPLS in general. 11. Acknowledgments Ashwood-Smith, et. al. July 2000 [Page 10] Internet Draft LSP Feedback with CR-LDP July, 2000 The authors would like to thank Keith Dysart for his guidance, and Jerzy Miernik for helping implement these concepts and bringing = them to life. 12. References [CR-LDP] Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr- ldp-04.txt [LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt [IS-IS] Extensions to IS-IS for traffic engineering, draft-ietf- isis-traffic-01.txt [QUERY] MPLS LDP Query Message Description, draft-paraschiv-mpls- lsp-query-00.txt. 13. Author's Addresses Peter Ashwood-Smith Bilel Jamoussi Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, ON K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-763-4534 phone: +1 978-288-4506 petera@nortelnetworks.com jamoussi@nortelnetworks.com Darek Skalecki Don Fedyk Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, On K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-765-2252 Phone: +1 978-228-3041 dareks@nortelnetworks.com dwfedyk@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. = This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain = it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Ashwood-Smith, et. al. July 2000 [Page 11] Internet Draft LSP Feedback with CR-LDP July, 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Ashwood-Smith, et. al. July 2000 [Page 12] ------=_NextPart_000_0092_01C01E54.5BE69C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Darek:
  Thanks for the kind response. I = was thinking=20 about your answer. What happens if you have multiple LSP attempts with = multiple=20 retries does the originating LSR take into account potential attempts = that have=20 not initiated yet, but could collide in the core LSR interface and thus = forces=20 other potential LSP to go to different paths (although less = optimal),=20 or does it simply assume that all colliding LSPs have plenty of = bandwidth even=20 before they are actually assigned or signalled through the=20 domain?
 
Second question, how do you keep the = feedback=20 information carried back in CR/LDP from being overwritten by the IGP = flooding of=20 the same bandwidth data?   Could this propose a = synchronization issue=20 or is the assumption that the IGP data will be as good as the feedback=20 data?
 
Regards,
Ben
 
 
Ben Abarbanel,  Software Engineering, 
 
Phone:  703 456 2982
FAX:      703 = 456=20 2952
 
IPOptical, Inc.
11480 Sunset Hills Road
Suite = #200E
Reston, VA=20 20190
----- Original Message -----
From:=20 Darek Skalecki
To: ben abarbanel
Cc: isis-wg
Sent: Thursday, September 14, = 2000 12:25=20 PM
Subject: Re: [Isis-wg] IS-IS TE = Question

ben abarbanel wrote:=20
I was reading the latest draft=20 "draft-ietf-isis-traffic-02.txt" and a question came to mind=20 regardingunreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved = bandwidth states "for stability reasons, rapid changes in the values = in this=20 sub-TLV should not cause rapid generation of = LSPs".
I was = wondering what=20 if  2 ingress (head end RSVP) LSR routers are provisioning LSPs = (each=20 wanting 100 Mbytes) through the same core convergent LSR interface = and each=20 one of the routers at the time they privision their LSP think there = is 100=20 Mbyte of bandwidth free to complete the job. In reality there is a = total of=20 100 MBYTE for the whole interface, the first RSVP reservation = succeeds while=20 the second fails.
The = second LSP=20 Ingress router would ask TE Source routing for another next = bandwidth=20 constraint best path to setup the LSP.  How efficient is that = if many=20 LSPs coverge in the core of the network this way and there is no = precise way=20 to say what is available at the time RSVP is trigered=20 on?
Also, = since the IS-IS=20 and its TE source routing engine take snap shots of the bandwidth = resources=20 in the network it has a tunnel view of what other IS-IS(LSR) routers = are=20 doing to this information at that moment in time, and are making = inaccurate=20 determination of what is reserved and what is free. The IS-IS route=20 convergent time could be much slower than the RSVP signalling=20 time.
For CR-LDP a feedback mechanism was = proposed=20 to learn at signaling intervals/speed whether or not there was b/w at=20 interfaces. A snapshot of that b/w is fed into TE database = based on=20 which source routes are computed. With feedback, if there is = insufficient b/w=20 at an interface to accomodate an LSP, a notification message with a = feedback=20 TLV is carried towards the source. The feedback information is = then input=20 into TE database at source and a new route computed. That route = should=20 now not contain the interface where there was insufficient b/w. The = feedback=20 mechanism is described in:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt= =20
The = following is my=20 assumption, please clarify if I am wrong, = thanks
if a = series of LSP=20 requests are hitting a given IS-IS router (TE source routing engine) = at the=20 same processing window/cycle, it makes assignments based on a frozen = snap=20 shot of the bandwidth in the network. Assignments are made without=20 consideration for their RSVP signalling success/failure and = eventually the=20 signalling components would fail their reservation requests causing=20 turbulance with LSP attempts.
Assuming = most of what=20 i said is true, do we need another more precise mechanism to solve=20 this? Regards,
The feedback provides you = ability=20 to try, fail, learn and try again. From our experience, a proprietary=20 signaling protocol with feedback worked just fine, i.e. convergence = was fast=20 (one or two tries/failures and a satisfactory route was found). =
 =20
Ben  Ben=20 Abarbanel,  Software Engineering, Phone:  703 456 2982
FAX:     703 456 2952 = IPOptical, Inc.
11480 Sunset Hills Road =
Suite #200E
Reston, VA = 20190
-- 
Darek Skalecki
Nortel 
(613) 765-2252
 =20



   MPLS Working=20 = Group           &n= bsp;           &nb= sp;         =20 Peter Ashwood-Smith
   Internet=20 = Draft           &n= bsp;           &nb= sp;           &nbs= p; =20 Bilel Jamoussi
   Expiration Date: December=20 = 2000           &nb= sp;         =20 Don=20 = Fedyk
          &nbs= p;            = ;            =             &= nbsp;      =20 Darek=20 = Skalecki
          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       =20 Nortel=20 = Networks

         &nb= sp;           &nbs= p;            = ;            =         =20 July 2000

         = Improving=20 Topology Data Base Accuracy with LSP=20 = Feedback

         &nb= sp;          =20 draft-ietf-mpls-te-feed-01.txt



Status of this=20 Memo

   This document is an Internet-Draft and is in = full=20 conformance with
   all provisions of Section 10 of=20 RFC2026.

   Internet-Drafts are working documents of = the=20 Internet Engineering
   Task Force (IETF), its areas, and = its=20 working groups. Note that
   other groups may also = distribute=20 working documents as Internet-
   = Drafts.

  =20 Internet-Drafts are draft documents valid for a maximum of = six
  =20 months and may be updated, replaced, or obsoleted by other=20 documents
   at any time. It is inappropriate to use=20 Internet-Drafts as reference
   material or to cite them = other=20 than as "work in progress."

   The list of current=20 Internet-Drafts can be accessed at
  =20 http://www.ietf.org/ietf/1id-abstracts.txt

   The = list of=20 Internet-Draft Shadow Directories can be accessed at
  =20 http://www.ietf.org/shadow.html.

Abstract

   = One key=20 component of traffic engineering is a concept known as
   = constraint based routing. In constraint based routing a=20 topology
   database is maintained on all participating = nodes.=20 This database
   contains a complete list of all the = links in the=20 network that
   participate in traffic engineering and = for each=20 of these links a set
   of constraints which those links = can=20 meet. Bandwidth, for example,
   is one essential = constraint.=20 Since the bandwidth available changes
   as new LSPs are=20 established and terminated the topology database
   will = develop=20 inconsistencies with respect to the real network. It = is
   not=20 possible to increase the flooding rates arbitrarily to keep=20 the
   database discrepancies from growing. We propose a = new=20 mechanism
   whereby a source node can learn about the = successes=20 or failures of
   its path selections by receiving = feedback from=20 the paths it is
   attempting. This fed-back information = can be=20 incorporated into
   subsequent route computations, which = greatly=20 improves the accuracy


Ashwood-Smith, et.=20 = al.           &nbs= p;            = ;            =    =20 [Page 1]
Internet Draft      LSP Feedback = with=20 CR-LDP    July, 2000


   of the = overall=20 routing solution by significantly reducing the
   = database=20 discrepancies.

1. Introduction

   Because the = network=20 is a distributed system, it is necessary to have
   a = mechanism=20 to advertise information about links to all nodes in = the
  =20 network [IS-IS], [OSPF].  A node can then build a topology map=20 of
   the network.  This information is required to = be as=20 up-to-date as
   possible for accurate traffic engineered = paths.  Information about
   link or node failures = must be=20 rapidly propagated through the network
   so that = recovery can be=20 initiated. Other information about links
   that may be = useful=20 for reasons of quality of service include
   parameters = such as=20 available bandwidth, and delay. The information
   in = this=20 topology database is often out of date with respect to = the
  =20 real network. Available bandwidth is the most critical of=20 these
   attributes and it can drift substantially with = respect=20 to reality
   due to the low frequency of link state = updates that=20 can be sustained
   in a very large topology. We refer to = the=20 deviation in the topology
   database available bandwidth = as=20 being optimistic if the database
   shows more available=20 bandwidth than there really is, or pessimistic
   if the = topology=20 database shows less bandwidth than there really is.
   = This=20 distinction is important because we shall propose an = efficient
  =20 algorithm to deal with optimistic databases without resorting=20 to
   shorter flooding intervals.

   One = of the=20 major problems for a constraint based routing system = is
  =20 dealing with changing constraints. Obviously, since bandwidth is=20 one
   of the essential constraints, dealing with the = rapid=20 changes in
   reserved bandwidth poses some interesting=20 challenges. In smaller
   networks, one can resort to = higher=20 frequency flooding but this
   obviously does not=20 scale.

   The basic proposal is to add to the = signaling=20 protocol the ability
   to piggyback actual link = bandwidth=20 availability information at every
   link that the = signaling=20 traverses. This is done as part of the
   reverse = messaging on=20 success or failure (mapping, release, withdraw
   or=20 notification). What this means is that every time = signaling
  =20 messages flow backwards toward a source to tell it of the=20 success,
   failure or termination of a request, that = message=20 contains a
   detailed slice of bandwidth availability=20 information for the exact
   path that the message has = followed.=20 This slice of reservation
   information, which is very = up to=20 date, is received by the source
   node and attached to = the=20 source node's topology database prior to
   making any = further=20 source route computations. The result is that the
   = source=20 node's topology database will tend to stay synchronized = with
  =20 the slices of the network through which it is establishing=20 paths.
   This is nothing more than learning from = successes and=20 failures and
   represents an intelligent alternative to = either=20 waiting for floods
   or introducing non-determinism = (guessing)=20 into the source
   algorithms. It is important to note = that the=20 fed-back data is never


Ashwood-Smith, et.=20 al.       July =20 2000        [Page 2]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   re-flooded. It simply overrides = flooded=20 information for the purpose
   of route computation until = a=20 superceding flood or fed-back value
   arrives. As such, = it is=20 not actually inserted into a topology
   database, most = likely it=20 simply is linked to that database as an
   override used = only by=20 source route computations.

   Operating a constraint = based=20 routing system without such feedback is
   inefficient at = best=20 since a source node will continue to give out
   = incorrect route=20 over and over again until it gets an IGP update.
   This = could be=20 minutes away and as a result the worst case blocking
   = time for=20 a new route is the minimum repeatable flooding = interval
   (often=20 several minutes in big networks). Alternatives to = feedback
  =20 mechanisms involve adding some non-determinism (randomness) to=20 the
   routing algorithm in the hopes that it will = stumble onto a=20 path that
   works. These sorts of approaches are seen in = ATM=20 dynamic routing
   systems, which do not have these forms = of=20 feedback.

   In order to get a good understanding of = how the=20 feedback works,
   imagine a network with precisely one = path=20 (with sufficient
   unreserved bandwidth) available from = the=20 source to the destination.
   Further, imagine that the = topology=20 database at the source is
   significantly out of date = with=20 respect to the real network in that
   the source = topology=20 database sees sufficient bandwidth available on
   many = different=20 routes to the destination. We call this being
   = optimistic with=20 respect to the network since the source thinks that
   = more=20 bandwidth is available than there really is.

   When = such an=20 optimistic source selects its first path it will = likely
  =20 contain links that do not in reality have sufficient=20 unreserved
   bandwidth. Therefore, the path is only = established=20 up to the link
   that does not have sufficient = bandwidth. A=20 notification message is
   formatted that contains the = actual=20 unreserved bandwidth for this
   blocking link which = flows back=20 toward the source, collapsing the
   partially created = path as it=20 goes. In addition, at every link that
   this = notification=20 traverses, the current unreserved bandwidth
   = information for=20 each corresponding link is appended to the vector of
  =20 unreserved bandwidth along the path. In this manner, an=20 accurate
   view of the slice through the network we are=20 traversing is
   constructed. Eventually this message = arrives=20 back at the source
   node, where the vector is taken and = used to=20 temporarily override the
   topology database for route=20 computations. This node has just learned
   from its = mistake and=20 is now slightly less optimistic with respect to
   the = real=20 network conditions.

   Path selection can be = attempted again=20 but this time the node will
   not make the same mistake = it made=20 the previous time. The link in
   question, at which = rejection=20 occurred the first time, will not even
   be eligible = this time=20 around, so a source route computation is
   guaranteed to = produce=20 a different path (or none). The same procedure
   may be = repeated=20 as many times as is necessary, each time learning
   from = its=20 mistakes, until eventually no paths remain in the = source
  =20 topology to the destination, or we actually find a path that=20 works.

Ashwood-Smith, et. = al.      =20 July  2000        [Page = 3]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   This tendency to converge either to = a=20 solution or determine that
   there is no solution is an=20 important property of a routing system
   (it actually = behaves a=20 lot like a depth first search). This property
   is not = present=20 with flooding mechanisms alone since the source node
   = must=20 randomly hunt, or continually make the same mistakes, or = abort
  =20 until the next flood arrives.

   In addition to = feeding back=20 bandwidth on failure, we also recommend
   feedback on = success.=20 This has important consequences on our ability
   to = spread load=20 or to spill over to new links as existing links fill.
   = It is=20 true that spilling over to new links does not require = feedback
  =20 on success since we could simply wait for a feedback on failure,=20 but
   we can achieve better load spreading=20 earlier.

   Finally, when a path is torn down the=20 release/withdraw messages also
   contain bandwidth = information=20 that can be fed back to override the
   source topology = database.=20 This is very important during failure
   scenarios where = the=20 links we need to use to reroute the path share
   common=20 sub-segments with the failed path. Without the feedback, = the
  =20 common sub-segments may not indicate sufficient available=20 bandwidth
   until we get a flood that may mean many = seconds=20 without a
   connection. With feedback at least we will = be up to=20 date with
   respect to available bandwidth up to the = point of=20 failure in the
   path. Also since failure involves many = paths=20 tearing down and re-
   establishing this is the time = that it is=20 most critical to have an
   accurate = view.

  =20 When preemption is being employed it is also extremely=20 important
   that the topology database inconsistencies = be small.=20 If not, high
   setup priority LSPs may unnecessarily = preempt=20 lower holding priority
   LSPs to obtain bandwidth that, = had they=20 had a more up to date view
   of unreserved bandwidth, = they would=20 have been able to find
   elsewhere. Since preempted LSPs = may in=20 turn preempt other LSPs in a
   domino like effect, the = results=20 of such database inconsistencies can
   have wide = reaching ripple=20 like impacts. These feedback mechanisms
   help reduce = these=20 occurrences significantly.

   There are a number of = network=20 conditions where feedback shows its
   value. One can = think of a=20 constraint-based network as being in one
   of three = conditions.=20 The first is called ramp-up, this is when the
   rate of = arriving=20 reservations exceeds the rate of departing
   = reservations. The=20 second is called steady-state, this is when the
   rate = of=20 arriving reservations is about the same as the rate of
   = departing reservations. Finally, the ramp-down condition is=20 that
   which has a greater rate of departing = reservations than=20 arriving
   reservations.

   These three = network=20 conditions show distinctly different types of
   error in = the=20 topology databases. In particular an optimistic view = of
  =20 available bandwidth by a source node is characteristic of the=20 ramp-
   up condition of a network. A pessimistic view of = available bandwidth
   by a source node is characteristic = of the=20 ramp-down condition of a

Ashwood-Smith, et.=20 al.       July =20 2000        [Page 4]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   network. If one plots the average = error in=20 the topology databases
   with respect to the real = network for=20 the three different network
   conditions, one will see = the error=20 slowly go positive during ramp
   up, slowly go negative = during=20 ramp down, and drift slowly around 0
   for the steady = condition.=20 The effect of flooding on this plot is to
   periodically = snap=20 the error back to 0 at flooding intervals. The
   effect = of the=20 feedback algorithm is to bring an optimistic error
   = back to=20 zero without having to wait for the flood interval. On
   = average=20 then, the feedback algorithm tends to halve the = absolute
  =20 error, keeping it mostly negative or pessimistic. This makes=20 sense
   since a routing system will never give paths to = links=20 that it thinks
   do not have resources and as a result = its=20 pessimistic view of the
   world stays that way until it = gets a=20 flood.  This relieves the IGP
   updates of the most = urgent=20 requirement of flooding when bandwidth is
   consumed.=20 Availability of new bandwidth occurs when paths are
   = released=20 or new links become available.  New links are = accompanied
  =20 by floods. Significant releases of bandwidth can be broadcast=20 at
   relatively low frequencies in the order of several = minutes=20 with
   little operational impact.

   = Extensive=20 operational experience with this feedback protocol in
  =20 proprietary Nortel Networks (pre-standard CR-LDP) products has=20 shown
   it to work very well for networks up to 1000 = nodes with=20 significant
   flooding intervals damped to several = minutes.=20 Without this protocol,
   these networks would block = setups for=20 up to several minutes. With
   this protocol, the = blocking in=20 most cases is reduced to a small
   number of retry = attempts=20 which is usually sub-second depending
   mostly on the=20 propagation delays in the network.

   These feedback=20 algorithms have been particularly beneficial in cases
   = of=20 failure recovery during which the network is in a = sudden
  =20 condition of ramp-up. Since a large number of reservations must=20 be
   remade, it is highly likely that we will exceed the = limits=20 of
   certain key links in the network. Without feedback, = the=20 rerouting
   must block until a flood arrives telling us = of the=20 situation at
   those key links at which time rerouting = can=20 continue. With feedback,
   the rerouting simply = continues until=20 a feedback indicates that a
   link is full. In addition = since=20 reservation-balancing algorithms are
   also often used, = feedback=20 allows the balancing algorithms to make
   better = distribution=20 decisions based on immediate feedback.

   We have = also=20 explored through simulation and implementation a
   = variety of=20 mechanisms to deal with the pessimistic error in the
   = database.=20 One simple proposal is to use selective forgetting. In
   = this=20 algorithm, a reserved bandwidth value slowly drops back to=20 zero
   over a relatively short time interval. The theory = being=20 that you
   shift the network back to an optimistic state = (by=20 forgetting your
   pessimism) where the feedback = algorithm will=20 again correctly
   operate. These algorithms have not = shown any=20 great advantage and are
   actually non-optimal when the = error is=20 purely optimistic.



Ashwood-Smith, et.=20 al.       July =20 2000        [Page 5]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   Other algorithmic permutations we = have=20 explored include such
   variations = as:

  =20 Feeding-back to all intermediate nodes, information learned=20 from
   control messages upstream of that intermediate=20 node.

   Feeding back in both directions so that both = the=20 source and
   destination node's databases stay=20 synchronized.

   Allowing a request to continue to = its=20 destination despite there
   being insufficient bandwidth = at some=20 intermediate hop. Then,
   rejecting the request with a = full=20 bandwidth vector slice all the way
   to the destination = instead=20 of just to the point of rejection.

   Our simulations = have=20 not show significant benefits relative to the
   simpler=20 algorithm proposed here. However, it is an interesting
   = research topic to explore and quantify the different = feedback
  =20 algorithms and their impacts on blocking times so we do not want=20 to
   discourage the interested reader from exploring = these=20 concepts more
   fully.

2. Adding feedback TLVs to = CR-LDP

   Two new TLVs are optionally added to the = CR-LDP=20 mapping,
   notification, and withdraw messages. There = may be an=20 arbitrary
   number of these TLV in any order or position = in the=20 message. It is
   recommended that they be placed such = that they=20 can be read and
   applied to override the topology = database by=20 scanning the message
   forwards and walking the topology = database from the point where the
   last link feedback = TLV left=20 off.

   Each TLV consists of the 8 unreserved = bandwidth=20 values for each
   holding priority 0 through 7 as IEEE = floating=20 point numbers (the
   units are unidirectional bytes per = second).=20 Following this are the
   IP addresses of the two ends of = the=20 interface. Two TLVs are
   possible, one for IPV4 and one = for=20 IPV6 addressing of the link.

   Note: the feedback = TLVs may=20 also optionally be included in query or
   query-reply = messages=20 in response to bandwidth update queries from an
   LER. = Details=20 of this mechanism are provided in [QUERY].

2.1 Bandwidth = directionality=20 considerations

   The order of the two addresses in = the=20 feedback TLV implies the
   direction in which the = bandwidth is=20 available. For example if the
   first address is A and = the=20 second address is B the bandwidth is
   unreserved in the = A to B=20 direction.

   It is possible for an implementation to = provide=20 both the A to B
   direction and the B to A direction as = part of=20 the same feedback
   message. This is done by simply = including a=20 TLV with A,B as the
   addresses of the link and a = different TLV=20 with B,A as the addresses

Ashwood-Smith, et.=20 al.       July =20 2000        [Page 6]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   of the link. Should CR-LDP evolve = to be=20 able to support bi-
   directional traffic flow and = reservations=20 it is expected that bi-
   directional feedback would = also be=20 implemented via this=20 = mechanism.
































=
















Ashwo= od-Smith,=20 et. al.       July =20 2000        [Page 7]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000



3. IPV4 specified link feedback=20 TLV

  =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9=20 0 1
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |U|F|         =20 = 0x830           =20 |     =20 = Length           &= nbsp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    =20 . . . . . . . .
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV4 address of interface (near=20 end)         |
   = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV4 address of interface (far=20 end)          = |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= 4.=20 IPV6 specified link feedback TLV

  =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9=20 0 1
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |U|F|         =20 = 0x831           =20 |     =20 = Length           &= nbsp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    =20 . . . . . . . .
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV6 address of interface (near=20 end)         |
   = = |            =             &= nbsp; =20 = _____           &n= bsp;           &nb= sp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV6 address of interface (far=20 end)          = |
  =20 = |            =             &= nbsp; =20 = _____           &n= bsp;           &nb= sp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= 5.=20 Detailed Procedures

   On receipt of a withdraw,=20 notification, query-reply, or mapping
   message = pertaining to a=20 request made by CR-LDP (as opposed to LDP),
   a feedback = TLV of=20 the appropriate format for the interface over
   which = the=20 message was received is inserted into the message = before
  =20 forwarding it back to the source of the request. The 8=20 bandwidth
   values are filled in with the outgoing = bandwidth=20 available on this
   interface for each of the 8 holding=20 priorities in bytes per second.
   Finally the = interface's=20 address and far end address are placed in
   the=20 TLV.



Ashwood-Smith, et. = al.      =20 July  2000        [Page = 8]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   On receipt of a CR-LDP request = message=20 which cannot be satisfied. A
   notification message is = formatted=20 normally. The 8-bandwidth values
   are filled in with = the=20 outgoing bandwidth available on this
   interface for = each of the=20 8 holding priorities in bytes per second.
   Finally, the = interface's address and far end address are placed in
   = the=20 TLV.

   On receipt of a CR-LDP request message which = has been=20 satisfied and
   which results in a mapping being = generated. No=20 feedback TLV is added
   since the previous node will = insert the=20 proper TLV when it receives
   the reverse flowing=20 mapping.

   When an LDP session goes down either = because of a=20 link failure,
   TCP/IP timeout, keepalive timeout, = adjacency=20 timeout etc. Other LDP
   sessions in the module must = generate=20 either notification, withdraw
   or release messages for = LSPs=20 that traversed the LDP in question. In
   the case that = the LSP=20 was created by CR-LDP and that a withdraw or
   = notification is=20 about to be generated, LDP will insert a feedback
   TLV = for the=20 interface which just went down that contains 0's for = all
   the=20 bandwidth values and attach to it the proper interface
   = addresses.

   When the LDP session that originated a = CR-LDP=20 label request receives
   a mapping that contains = feedback TLV's=20 it is recommended that these
   bandwidth values = supersede the=20 corresponding values in the node's
   topology database = for=20 source route computations. Doing so permits
   this node = to=20 immediately synchronize its topology with respect to
   = the real=20 bandwidth reservations along the path that was just
  =20 established.

   When the LDP session that originated = a CR-LDP=20 label request receives
   a notification that contains = feedback=20 TLV's it is recommended that
   these bandwidth values = supersede=20 the corresponding values in the
   node's topology = database for=20 source route computations. Doing so
   permits this node = to=20 immediately synchronize its topology with
   respect to = the real=20 bandwidth reservations along the path that just
   failed = to=20 establish. The source node may then re-compute a path
   = knowing=20 that the computation will take into account the failure = if
   it=20 was caused by the topology database being in error with=20 respect
   to the real network state.

   = 6. IGP=20 considerations

   Implementations MUST NOT permit = bandwidth=20 information learned by
   this feedback mechanism to be=20 re-flooded via IS-IS, OSPF or any
   other IGP. The = bandwidth=20 information learned via these feedback
   mechanisms is = to be=20 used ONLY for source route computations on the
   nodes = that are=20 directly on the path that fed back the bandwidth.
   = Normally=20 only the source node of the LSP, or perhaps = intermediate
  =20 gateway nodes will use this information. It is however permitted=20 for
   intermediate nodes that are forwarding this = feedback=20 information to
   store it for their own local source = route=20 computations.

Ashwood-Smith, et.=20 al.       July =20 2000        [Page 9]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   There is a possibility of a race = condition=20 between the bandwidth
   information that is received via = feedback and that which is received
   via a normal IGP = flood.=20 While there may be a discrepancy between the
   two, both = are=20 within a few 100 milliseconds of being correct.
   = Solutions to=20 allow us to determine which information is most up to
   = date=20 (say by adding a sequence number) do not add any = significant
  =20 benefit. Constraint based, source routed systems will always=20 have
   errors in the local topology database with = respect to the=20 real
   network. We can reduce these errors through = reduced=20 flooding
   intervals, path following feedback and = selective=20 flooding but we
   cannot realistically reduce the errors = below=20 the second or so range.
   As a result propagation delay = order=20 race conditions are noise with
   respect to the average = expected=20 errors. An implementation SHOULD
   therefore consider = the most=20 recently received update (IGP or
   feedback) as being = the most=20 up to date.

7. Future considerations

   = Constraint=20 based routing systems such as CR-LDP will in the = future
   offer=20 other forms of constraint than simply reserved = bandwidth.
  =20 Actual utilization levels, current congestion levels, number=20 of
   discrete channels/wavelengths available etc. are = all=20 possible
   constraints that change rapidly and which = must be=20 taken into
   consideration when computing a route. It is = expected that this
   mechanism will be used to feedback = these=20 and other new forms of link
   constraining = data.

8. RSVP=20 consideration

   Nothing precludes the use of such = feedback=20 mechanisms with a similar
   TLV structure in the RSVP = Resv and=20 other reverse flowing messages
   although repeatedly = applying a=20 fed-back should be avoided since it
   increases the race = condition window with flooded LSPs. This could be
   = accomplished=20 by a simple rule that only permits fed-back = information
   on the=20 original RESV, not on subsequent refreshes.

9. Intellectual = Property=20 Consideration

   The IETF has been notified of = intellectual=20 property rights claimed
   in regard to some or all of = the=20 specification contained in this
   document.  For = more=20 information consult the online list of claimed
  =20 rights.

10. Security Considerations

   This = document=20 raises no new security considerations for CR-LDP, RSVP
   = or MPLS=20 in general.

11. = Acknowledgments




Ashwood-Smith, et.=20 al.       July =20 2000        [Page 10]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   The authors would like to thank = Keith=20 Dysart for his guidance, and
   Jerzy Miernik for helping = implement these concepts and bringing them
   to = life.

12.=20 References

   [CR-LDP] Constraint-Based LSP Setup = using LDP,=20 draft-ietf-mpls-cr-
   ldp-04.txt

   = [LDP] LDP=20 Specification, draft-ietf-mpls-ldp-05.txt

   [IS-IS]=20 Extensions to IS-IS for traffic engineering, = draft-ietf-
  =20 isis-traffic-01.txt

   [QUERY] MPLS LDP Query Message = Description, draft-paraschiv-mpls-
  =20 lsp-query-00.txt.

13. Author's Addresses

   = Peter=20 = Ashwood-Smith          =     =20 Bilel Jamoussi
   Nortel Networks=20 = Corp.           &n= bsp;=20 Nortel Networks Corp.
   P.O. Box 3511 Station=20 C,          600 = Technology Park=20 Drive
   Ottawa, ON K1Y=20 = 4H7           &nbs= p;   =20 Billerica, MA 01821
  =20 = Canada           &= nbsp;           &n= bsp;   =20 USA
   Phone: +1=20 = 613-763-4534          &= nbsp;=20 phone: +1 978-288-4506
  =20 = petera@nortelnetworks.com        = =20 jamoussi@nortelnetworks.com

   Darek=20 = Skalecki           = ;        =20 Don Fedyk
   Nortel Networks=20 = Corp.           &n= bsp;=20 Nortel Networks Corp.
   P.O. Box 3511 Station=20 C,          600 = Technology Park=20 Drive
   Ottawa, On K1Y=20 = 4H7           &nbs= p;   =20 Billerica, MA 01821
  =20 = Canada           &= nbsp;           &n= bsp;   =20 USA
   Phone: +1=20 = 613-765-2252          &= nbsp;=20 Phone: +1 978-228-3041
  =20 = dareks@nortelnetworks.com        = =20 dwfedyk@nortelnetworks.com


Full Copyright=20 Statement

   Copyright (C) The Internet Society = (date). All=20 Rights Reserved. This
   document and translations of it = may be=20 copied and furnished to
   others, and derivative works = that=20 comment on or otherwise explain it
   or assist in its=20 implementation may be prepared, copied, published
   and=20 distributed, in whole or in part, without restriction of = any
  =20 kind, provided that the above copyright notice and this=20 paragraph
   are included on all such copies and = derivative=20 works. However, this
   document itself may not be = modified in=20 any way, such as by removing
   the copyright notice or=20 references to the Internet Society or other
   Internet=20 organizations, except as needed for the purpose of
   = developing=20 Internet standards in which case the procedures for
   = copyrights=20 defined in the Internet Standards process must be
   = followed, or=20 as required to translate it into languages other than
  =20 English.

Ashwood-Smith, et. = al.      =20 July  2000        [Page=20 11]
Internet Draft      LSP Feedback with=20 CR-LDP    July, 2000



   The = limited=20 permissions granted above are perpetual and will not = be
  =20 revoked by the Internet Society or its successors or=20 = assigns.















<= BR>
































Ashwood= -Smith,=20 et. al.       July =20 2000        [Page=20 12]
------=_NextPart_000_0092_01C01E54.5BE69C60-- From sudheer@nayna.com Thu, 14 Sep 2000 15:12:24 -0700 Date: Thu, 14 Sep 2000 15:12:24 -0700 From: Sudheer Dharnikota sudheer@nayna.com Subject: [Isis-wg] IS-IS TE Question Hi Guys: According to our draft.. our approach to this problem is: 1. use a primary criteria to find a path 2. if it fails due to any reasons (unavailability of the resources is being one of them) then use the crankback from the previous ABR by removing the links that are failed. Note that we donot have to consider the convergence problem in this case. 3. If there are no other paths with the same characteistic then use the secondary criteria to identify the best path. No links attached to the convergence and playing with the timers. Although i agree that changes in the ABW need to be propagated sooner. Cheers, sudheer Darek Skalecki wrote: > > Matthew Kontoff wrote: > > > Darek Skalecki wrote: > > > > > > ben abarbanel wrote: > > > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" > > and a question came to mind regardingunreserved > > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth > > states "for stability reasons, rapid changes in the > > > > values in this sub-TLV should not cause rapid generation of > > LSPs". > > > > You still need to regenerate and flood LSPs when an interface state > > (i.e. bandwidth) > > changes. How you do this is up to you. For example, you could > > reflood LSPs at an interval > > that could be tied to the amount of bandwidth being used. The more > > frequently LSPs > > are reflooded the closer an approximation of actual unreserved > > bandwidth in the > > network you will have. > > > > > > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers > > are provisioning LSPs (each wanting 100 Mbytes) > > > > through the same core convergent LSR interface and each one of > > the routers at the time they privision their LSP > > > > think there is 100 Mbyte of bandwidth free to complete the job. > > In reality there is a total of 100 MBYTE for the > > > > whole interface, the first RSVP reservation succeeds while the > > second fails. > > > > > > > The second LSP Ingress router would ask TE Source routing for > > another next bandwidth constraint best path to setup > > > > the LSP. How efficient is that if many LSPs coverge in the core > > of the network this way and there is no precise way > > > > to say what is available at the time RSVP is trigered on? > > > > > > > Also, since the IS-IS and its TE source routing engine take snap > > shots of the bandwidth resources in the network it > > > > has a tunnel view of what other IS-IS(LSR) routers are doing to > > this information at that moment in time, and are > > > > making inaccurate determination of what is reserved and what is > > free. The IS-IS route convergent time could be much > > > > slower than the RSVP signalling time. > > > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling > > intervals/speed whether or not there was b/w at > > > interfaces. A snapshot of that b/w is fed into TE database based > > on which source routes are computed. With feedback, > > > if there is insufficient b/w at an interface to accomodate an LSP, > > a notification message with a feedback TLV is > > > carried towards the source. The feedback information is then input > > into TE database at source and a new route > > > computed. That route should now not contain the interface where > > there was insufficient b/w. The feedback mechanism is > > > described in: > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > > > Why would you need a feedback mechanism if you regenerate and flood > > IS-IS LSPs with updated TE TLVs > > that contain up to the moment (second, millisecond, whatever) > > bandwidth info? > > If your flooding interval is very short then there is no need for > feedback but you don't want to flood too frequently or else only > control traffic is running in the network and the network doesn't > scale too well. We employed feedback in a system where regular floods > were every 30 minutes, feedback updates were at path establishment > rates, i.e. feedback information was piggy-backed on top of > appropriate signaling messages. > > > > > > > > > The following is my assumption, please clarify if I am wrong, > > thanks > > > > > > > if a series of LSP requests are hitting a given IS-IS router (TE > > source routing engine) at the same processing > > > > window/cycle, it makes assignments based on a frozen snap shot > > of the bandwidth in the network. Assignments are made > > > > without consideration for their RSVP signalling success/failure > > and eventually the signalling components would fail > > > > their reservation requests causing turbulance with LSP attempts. > > > > > > > > > Assuming most of what i said is true, do we need another more > > precise mechanism to solve this? Regards, > > > > > > The feedback provides you ability to try, fail, learn and try > > again. >From our experience, a proprietary signaling > > > protocol with feedback worked just fine, i.e. convergence was fast > > (one or two tries/failures and a satisfactory route > > > was found). > > > > I agree with the 'try fail and learn again' approach but I don't > > think you need > > a separate feedback mechanism other than recent IS-IS LSPs from > > other LSRs. > > > > Matt Kontoff > > -- > Darek Skalecki > Nortel > (613) 765-2252 > > From ben.abarbanel@ipoptical.com Thu, 14 Sep 2000 20:18:30 -0400 Date: Thu, 14 Sep 2000 20:18:30 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question Hi Sudheer: Your draft/idea sounds like a good alternative. But if I understand darek's spec. They are trying to adapt the topology to bandwidth changes as quickly as possible so that the source routing engines can give the best possible answer. I agree most solutions still have that level of inaccuracy, cause the data gathering mechanism (link state flooding) is much slower than the execution (signalling) mechanism. Regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Sudheer Dharnikota" To: "Darek Skalecki" Cc: "Matthew Kontoff" ; "ben abarbanel" ; "isis-wg" Sent: Thursday, September 14, 2000 6:12 PM Subject: Re: [Isis-wg] IS-IS TE Question > Hi Guys: > > According to our draft.. our approach to this problem is: > > 1. use a primary criteria to find a path > 2. if it fails due to any reasons (unavailability of the > resources is being one of them) then use the crankback > from the previous ABR by removing the links that are > failed. Note that we donot have to consider the > convergence problem in this case. > 3. If there are no other paths with the same characteistic > then use the secondary criteria to identify the > best path. > > No links attached to the convergence and playing with the > timers. Although i agree that changes in the ABW need to > be propagated sooner. > > Cheers, > > sudheer > > Darek Skalecki wrote: > > > > Matthew Kontoff wrote: > > > > > Darek Skalecki wrote: > > > > > > > > ben abarbanel wrote: > > > > > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" > > > and a question came to mind regardingunreserved > > > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth > > > states "for stability reasons, rapid changes in the > > > > > values in this sub-TLV should not cause rapid generation of > > > LSPs". > > > > > > You still need to regenerate and flood LSPs when an interface state > > > (i.e. bandwidth) > > > changes. How you do this is up to you. For example, you could > > > reflood LSPs at an interval > > > that could be tied to the amount of bandwidth being used. The more > > > frequently LSPs > > > are reflooded the closer an approximation of actual unreserved > > > bandwidth in the > > > network you will have. > > > > > > > > > > > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers > > > are provisioning LSPs (each wanting 100 Mbytes) > > > > > through the same core convergent LSR interface and each one of > > > the routers at the time they privision their LSP > > > > > think there is 100 Mbyte of bandwidth free to complete the job. > > > In reality there is a total of 100 MBYTE for the > > > > > whole interface, the first RSVP reservation succeeds while the > > > second fails. > > > > > > > > > The second LSP Ingress router would ask TE Source routing for > > > another next bandwidth constraint best path to setup > > > > > the LSP. How efficient is that if many LSPs coverge in the core > > > of the network this way and there is no precise way > > > > > to say what is available at the time RSVP is trigered on? > > > > > > > > > Also, since the IS-IS and its TE source routing engine take snap > > > shots of the bandwidth resources in the network it > > > > > has a tunnel view of what other IS-IS(LSR) routers are doing to > > > this information at that moment in time, and are > > > > > making inaccurate determination of what is reserved and what is > > > free. The IS-IS route convergent time could be much > > > > > slower than the RSVP signalling time. > > > > > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling > > > intervals/speed whether or not there was b/w at > > > > interfaces. A snapshot of that b/w is fed into TE database based > > > on which source routes are computed. With feedback, > > > > if there is insufficient b/w at an interface to accomodate an LSP, > > > a notification message with a feedback TLV is > > > > carried towards the source. The feedback information is then input > > > into TE database at source and a new route > > > > computed. That route should now not contain the interface where > > > there was insufficient b/w. The feedback mechanism is > > > > described in: > > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > > > > > Why would you need a feedback mechanism if you regenerate and flood > > > IS-IS LSPs with updated TE TLVs > > > that contain up to the moment (second, millisecond, whatever) > > > bandwidth info? > > > > If your flooding interval is very short then there is no need for > > feedback but you don't want to flood too frequently or else only > > control traffic is running in the network and the network doesn't > > scale too well. We employed feedback in a system where regular floods > > were every 30 minutes, feedback updates were at path establishment > > rates, i.e. feedback information was piggy-backed on top of > > appropriate signaling messages. > > > > > > > > > > > > > The following is my assumption, please clarify if I am wrong, > > > thanks > > > > > > > > > if a series of LSP requests are hitting a given IS-IS router (TE > > > source routing engine) at the same processing > > > > > window/cycle, it makes assignments based on a frozen snap shot > > > of the bandwidth in the network. Assignments are made > > > > > without consideration for their RSVP signalling success/failure > > > and eventually the signalling components would fail > > > > > their reservation requests causing turbulance with LSP attempts. > > > > > > > > > > > > Assuming most of what i said is true, do we need another more > > > precise mechanism to solve this? Regards, > > > > > > > > The feedback provides you ability to try, fail, learn and try > > > again. >From our experience, a proprietary signaling > > > > protocol with feedback worked just fine, i.e. convergence was fast > > > (one or two tries/failures and a satisfactory route > > > > was found). > > > > > > I agree with the 'try fail and learn again' approach but I don't > > > think you need > > > a separate feedback mechanism other than recent IS-IS LSPs from > > > other LSRs. > > > > > > Matt Kontoff > > > > -- > > Darek Skalecki > > Nortel > > (613) 765-2252 > > > > From tli@Procket.com Thu, 14 Sep 2000 23:15:33 -0700 (PDT) Date: Thu, 14 Sep 2000 23:15:33 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Simple question about IS-IS mixed domains | If you can't mix dual and non-dual routers in the same area and | have routing work for the non-OSI protocols supported (IP and IPv6), | then how can it work at Level 2 if all the Level 2 routers do not | support all the same non-OSI protocols? It seems to have the same | problem - routes will be computed through routers that do not support | the protocol of the data, just because the link costs are lowest. | | Am I missing something? If one Really Wanted to do this, then one would have to SPF independently for each protocol. Plus, because adjacency information is not carried on a per-protocol basis, you would still have the restriction that any link between two routers supporting a protocol would have to have the protocol working on that link. So for example, the link between two IPv6 routers had better be configured for IPv6. This seems like more complexity than it's worth. After all, there's only one important network layer. ;-) Tony From Internet-Drafts@ietf.org Fri, 15 Sep 2000 07:00:05 -0400 Date: Fri, 15 Sep 2000 07:00:05 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-00.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie, D. Saha, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-00.txt Pages : 11 Date : 14-Sep-00 This document specifies extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (previously known as Multi-Protocol Lambda Switching). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000914115817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000914115817.I-D@ietf.org> --OtherAccess-- --NextPart-- From dareks@nortelnetworks.com Fri, 15 Sep 2000 08:49:14 -0400 Date: Fri, 15 Sep 2000 08:49:14 -0400 From: Darek Skalecki dareks@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question --------------BC2DCA0DA047B7565F1C5115 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote: > Matthew and Darek: > I kind of like the feedback mechanism defined in > "draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or > Darek can add it to their spec is that a timestamp be added to both the > flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also > the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the > reservation denial and bandwidth sample was taken from the rejecting LSR. As > the message is returned to the ingress LSR its bandwidth will be overwritten > into the linkstate database, since its the most up to date information. > > I can see a race condition where IGP converging link state information might > have older data then Reservation Release/Withdrawl messages containing the > same (feedback) data. Thus its possible for the ingress LSR IGP to > momentarily over-write newer bandwidth with bad/older bandwidth into the > ingress LSR linkstate database. Ingress LSR IGP should check the timestamp > in the database with its current LSA/LSP packet and only update the > bandwidth value if it has the newer timestamp in the LSA/LSP packet. > > regards, > Ben > > Ben Abarbanel, Software Engineering, > > Phone: 703 456 2982 > FAX: 703 456 2952 > > IPOptical, Inc. > 11480 Sunset Hills Road > Suite #200E > Reston, VA 20190 Timestamping is a fine idea but in our proprietary system we simply wrote any learned information into a database, whether the information was from feedback or flooding. You are right that more-up-to-date feedback information may be then overwritten by older flooding information but in that case we may simply re-learn newer information via feedback when needed so we never implemented timestamping. Darek > > > > ----- Original Message ----- > From: "Matthew Kontoff" > To: "Darek Skalecki" > Cc: "ben abarbanel" ; "isis-wg" > > Sent: Thursday, September 14, 2000 4:08 PM > Subject: Re: [Isis-wg] IS-IS TE Question > > > > > > > Darek Skalecki wrote: > > > > > > ben abarbanel wrote: > > > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a > question came to mind regardingunreserved > > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for > stability reasons, rapid changes in the > > > > values in this sub-TLV should not cause rapid generation of LSPs". > > > > You still need to regenerate and flood LSPs when an interface state (i.e. > bandwidth) > > changes. How you do this is up to you. For example, you could reflood LSPs > at an interval > > that could be tied to the amount of bandwidth being used. The more > frequently LSPs > > are reflooded the closer an approximation of actual unreserved bandwidth > in the > > network you will have. > > > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are > provisioning LSPs (each wanting 100 Mbytes) > > > > through the same core convergent LSR interface and each one of the > routers at the time they privision their LSP > > > > think there is 100 Mbyte of bandwidth free to complete the job. In > reality there is a total of 100 MBYTE for the > > > > whole interface, the first RSVP reservation succeeds while the second > fails. > > > > > > > The second LSP Ingress router would ask TE Source routing for another > next bandwidth constraint best path to setup > > > > the LSP. How efficient is that if many LSPs coverge in the core of > the network this way and there is no precise way > > > > to say what is available at the time RSVP is trigered on? > > > > > > > Also, since the IS-IS and its TE source routing engine take snap shots > of the bandwidth resources in the network it > > > > has a tunnel view of what other IS-IS(LSR) routers are doing to this > information at that moment in time, and are > > > > making inaccurate determination of what is reserved and what is free. > The IS-IS route convergent time could be much > > > > slower than the RSVP signalling time. > > > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling > intervals/speed whether or not there was b/w at > > > interfaces. A snapshot of that b/w is fed into TE database based on > which source routes are computed. With feedback, > > > if there is insufficient b/w at an interface to accomodate an LSP, a > notification message with a feedback TLV is > > > carried towards the source. The feedback information is then input into > TE database at source and a new route > > > computed. That route should now not contain the interface where there > was insufficient b/w. The feedback mechanism is > > > described in: > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > > > Why would you need a feedback mechanism if you regenerate and flood IS-IS > LSPs with updated TE TLVs > > that contain up to the moment (second, millisecond, whatever) bandwidth > info? > > > > > > The following is my assumption, please clarify if I am wrong, thanks > > > > > > > if a series of LSP requests are hitting a given IS-IS router (TE > source routing engine) at the same processing > > > > window/cycle, it makes assignments based on a frozen snap shot of the > bandwidth in the network. Assignments are made > > > > without consideration for their RSVP signalling success/failure and > eventually the signalling components would fail > > > > their reservation requests causing turbulance with LSP attempts. > > > > > > > Assuming most of what i said is true, do we need another more precise > mechanism to solve this? Regards, > > > > > > The feedback provides you ability to try, fail, learn and try again. > >From our experience, a proprietary signaling > > > protocol with feedback worked just fine, i.e. convergence was fast (one > or two tries/failures and a satisfactory route > > > was found). > > > > I agree with the 'try fail and learn again' approach but I don't think you > need > > a separate feedback mechanism other than recent IS-IS LSPs from other > LSRs. > > > > > > Matt Kontoff > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg -- Darek Skalecki Nortel (613) 765-2252 --------------BC2DCA0DA047B7565F1C5115 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote:
Matthew and Darek:
  I kind of like the feedback mechanism defined in
"draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or
Darek can add it to their spec is that a timestamp be added to both the
flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also
the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the
reservation denial and bandwidth sample was taken from the rejecting LSR. As
the message is returned to the ingress LSR its bandwidth will be overwritten
into the linkstate database, since its the most up to date information.

I can see a race condition where IGP converging link state information might
have older data then Reservation Release/Withdrawl messages containing the
same (feedback) data. Thus its possible for the ingress LSR IGP to
momentarily over-write newer bandwidth with bad/older bandwidth into the
ingress LSR linkstate database. Ingress LSR IGP should check the timestamp
in the database with its current LSA/LSP packet and only update the
bandwidth value if it has the newer timestamp in the LSA/LSP packet.

regards,
Ben

Ben Abarbanel,  Software Engineering,

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

Timestamping is a fine idea but in our proprietary system we simply wrote any learned  information into a database,
whether the information was from feedback or flooding. You are right that more-up-to-date feedback information
may be then overwritten by older flooding information but in that case we may  simply re-learn newer information via feedback when needed so we never implemented timestamping.

Darek

 
 

----- Original Message -----
From: "Matthew Kontoff" <Mkontoff@Kontoff.com>
To: "Darek Skalecki" <dareks@nortelnetworks.com>
Cc: "ben abarbanel" <ben.abarbanel@ipoptical.com>; "isis-wg"
<isis-wg@spider.juniper.net>
Sent: Thursday, September 14, 2000 4:08 PM
Subject: Re: [Isis-wg] IS-IS TE Question

>
>
> Darek Skalecki wrote:
> >
> > ben abarbanel wrote:
> >
> > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a
question came to mind regardingunreserved
> > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for
stability reasons, rapid changes in the
> > > values in this sub-TLV should not cause rapid generation of LSPs".
>
> You still need to regenerate and flood LSPs when an interface state (i.e.
bandwidth)
> changes. How you do this is up to you. For example, you could reflood LSPs
at an interval
> that could be tied to the amount of bandwidth being used. The more
frequently LSPs
> are reflooded the closer an approximation of actual unreserved bandwidth
in the
> network you will have.
>
> >
> > > I was wondering what if  2 ingress (head end RSVP) LSR routers are
provisioning LSPs (each wanting 100 Mbytes)
> > > through the same core convergent LSR interface and each one of the
routers at the time they privision their LSP
> > > think there is 100 Mbyte of bandwidth free to complete the job. In
reality there is a total of 100 MBYTE for the
> > > whole interface, the first RSVP reservation succeeds while the second
fails.
> >
> > > The second LSP Ingress router would ask TE Source routing for another
next bandwidth constraint best path to setup
> > > the LSP.  How efficient is that if many LSPs coverge in the core of
the network this way and there is no precise way
> > > to say what is available at the time RSVP is trigered on?
> >
> > > Also, since the IS-IS and its TE source routing engine take snap shots
of the bandwidth resources in the network it
> > > has a tunnel view of what other IS-IS(LSR) routers are doing to this
information at that moment in time, and are
> > > making inaccurate determination of what is reserved and what is free.
The IS-IS route convergent time could be much
> > > slower than the RSVP signalling time.
> >
> > For CR-LDP a feedback mechanism was proposed to learn at signaling
intervals/speed whether or not there was b/w at
> > interfaces. A snapshot of that b/w is fed into TE database based on
which source routes are computed. With feedback,
> > if there is insufficient b/w at an interface to accomodate an LSP, a
notification message with a feedback TLV is
> > carried towards the source. The feedback information is then input into
TE database at source and a new route
> > computed. That route should now not contain the interface where there
was insufficient b/w. The feedback mechanism is
> > described in:
> > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt
>
> Why would you need a feedback mechanism if you regenerate and flood IS-IS
LSPs with updated TE TLVs
> that contain up to the moment (second, millisecond, whatever) bandwidth
info?
>
> > > The following is my assumption, please clarify if I am wrong, thanks
> >
> > > if a series of LSP requests are hitting a given IS-IS router (TE
source routing engine) at the same processing
> > > window/cycle, it makes assignments based on a frozen snap shot of the
bandwidth in the network. Assignments are made
> > > without consideration for their RSVP signalling success/failure and
eventually the signalling components would fail
> > > their reservation requests causing turbulance with LSP attempts.
> >
> > > Assuming most of what i said is true, do we need another more precise
mechanism to solve this? Regards,
> >
> > The feedback provides you ability to try, fail, learn and try again.
>From our experience, a proprietary signaling
> > protocol with feedback worked just fine, i.e. convergence was fast (one
or two tries/failures and a satisfactory route
> > was found).
>
> I agree with the 'try fail and learn again' approach but I don't think you
need
> a separate feedback mechanism other than recent IS-IS LSPs from other
LSRs.
>
>
> Matt Kontoff
>
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------BC2DCA0DA047B7565F1C5115-- From dwfedyk@nortelnetworks.com Fri, 15 Sep 2000 10:30:16 -0400 Date: Fri, 15 Sep 2000 10:30:16 -0400 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question 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_01C01F21.77860EB0 Content-Type: text/plain; charset="iso-8859-1" All Just to add one thing to the time stamping idea. We do not consider it necessary since the database is still really maintained by the IGP flood. (Which does not use timestamps but sequence numbers). The feedback is more targeted information that is used in the interim. Although there are small windows of opportunities for the feedback to be miss ordered this is still leagues ahead of not having feedback. By the way, the most likely misordering is an old LSP (LSA) announcing more bandwidth than actually exists and overwriting a feedback message that has reported less bandwidth. This could result in a LSP signaling that has to learn from feedback again. (We prefer to deal with the timing issues not pray they will not happen!). Relying on timestamps or sequence numbers for feedback requires synchronization between peers and designers of IGPs have way more years of experience and code to deal with this. Don -----Original Message----- From: Skalecki, Darek [CAR:CS56:EXCH] Sent: Friday, September 15, 2000 8:49 AM To: ben abarbanel Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH] Subject: Re: [Isis-wg] IS-IS TE Question ben abarbanel wrote: Matthew and Darek: I kind of like the feedback mechanism defined in "draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or Darek can add it to their spec is that a timestamp be added to both the flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the reservation denial and bandwidth sample was taken from the rejecting LSR. As the message is returned to the ingress LSR its bandwidth will be overwritten into the linkstate database, since its the most up to date information. I can see a race condition where IGP converging link state information might have older data then Reservation Release/Withdrawl messages containing the same (feedback) data. Thus its possible for the ingress LSR IGP to momentarily over-write newer bandwidth with bad/older bandwidth into the ingress LSR linkstate database. Ingress LSR IGP should check the timestamp in the database with its current LSA/LSP packet and only update the bandwidth value if it has the newer timestamp in the LSA/LSP packet. regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 Timestamping is a fine idea but in our proprietary system we simply wrote any learned information into a database, whether the information was from feedback or flooding. You are right that more-up-to-date feedback information may be then overwritten by older flooding information but in that case we may simply re-learn newer information via feedback when needed so we never implemented timestamping. Darek -- Darek Skalecki Nortel (613) 765-2252 ------_=_NextPart_001_01C01F21.77860EB0 Content-Type: text/html; charset="iso-8859-1"
All
 
Just to add one thing to the time stamping idea. We do not consider it necessary since
the database is still really maintained by the IGP flood. (Which does not use timestamps
but sequence numbers). The feedback is more targeted information that is used in the
interim. Although there are small windows of opportunities for the feedback to be miss ordered
this is still leagues ahead of not having feedback. By the way, the most likely misordering is an
old LSP (LSA) announcing more bandwidth than actually exists and overwriting a feedback message
that has reported less bandwidth. This could result in a LSP signaling that has to learn from feedback
again. (We prefer to deal with the timing issues not pray they will not happen!).
Relying on timestamps or sequence numbers for feedback requires synchronization between peers
and designers of IGPs have way more years of experience and code to deal with this.
 
Don
 
 
 -----Original Message-----
From: Skalecki, Darek [CAR:CS56:EXCH]
Sent: Friday, September 15, 2000 8:49 AM
To: ben abarbanel
Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH]
Subject: Re: [Isis-wg] IS-IS TE Question

ben abarbanel wrote:
Matthew and Darek:
  I kind of like the feedback mechanism defined in
"draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or
Darek can add it to their spec is that a timestamp be added to both the
flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also
the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the
reservation denial and bandwidth sample was taken from the rejecting LSR. As
the message is returned to the ingress LSR its bandwidth will be overwritten
into the linkstate database, since its the most up to date information.

I can see a race condition where IGP converging link state information might
have older data then Reservation Release/Withdrawl messages containing the
same (feedback) data. Thus its possible for the ingress LSR IGP to
momentarily over-write newer bandwidth with bad/older bandwidth into the
ingress LSR linkstate database. Ingress LSR IGP should check the timestamp
in the database with its current LSA/LSP packet and only update the
bandwidth value if it has the newer timestamp in the LSA/LSP packet.

regards,
Ben

Ben Abarbanel,  Software Engineering,

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

Timestamping is a fine idea but in our proprietary system we simply wrote any learned  information into a database,
whether the information was from feedback or flooding. You are right that more-up-to-date feedback information
may be then overwritten by older flooding information but in that case we may  simply re-learn newer information via feedback when needed so we never implemented timestamping.

Darek

 

-- 
Darek Skalecki
Nortel 
(613) 765-2252
 
------_=_NextPart_001_01C01F21.77860EB0-- From cmj@3Com.com Fri, 15 Sep 2000 10:47:07 -0700 Date: Fri, 15 Sep 2000 10:47:07 -0700 From: Cyndi Jung cmj@3Com.com Subject: [Isis-wg] Simple question about IS-IS mixed domains Of course, there is really only one important network layer, IP, but it has taken over the only routing protocol that CLNP ever had :-) So, it's most prevalent use is in IP-only networks, or purely dual domains. In fact, without the SPF per-protocol (assuming there were some information in the LSPs that they could use to imply the missing Supported Protocol field), a "mixed" domain is a misconfiguration, just as a mixed area is. Cyndi At 11:15 PM 9/14/00 -0700, Tony Li wrote: > > | If you can't mix dual and non-dual routers in the same area and > | have routing work for the non-OSI protocols supported (IP and IPv6), > | then how can it work at Level 2 if all the Level 2 routers do not > | support all the same non-OSI protocols? It seems to have the same > | problem - routes will be computed through routers that do not support > | the protocol of the data, just because the link costs are lowest. > | > | Am I missing something? > > >If one Really Wanted to do this, then one would have to SPF independently >for each protocol. > >Plus, because adjacency information is not carried on a per-protocol basis, >you would still have the restriction that any link between two routers >supporting a protocol would have to have the protocol working on that >link. So for example, the link between two IPv6 routers had better be >configured for IPv6. > >This seems like more complexity than it's worth. After all, there's only >one important network layer. ;-) > >Tony > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > From ben.abarbanel@ipoptical.com Fri, 15 Sep 2000 14:30:50 -0400 Date: Fri, 15 Sep 2000 14:30:50 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C01F21.8C0FC740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don: Comments below Ben Ben Abarbanel, Software Engineering, =20 Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message -----=20 From: Don Fedyk=20 To: Darek Skalecki ; ben abarbanel=20 Cc: Matthew Kontoff ; isis-wg ; Peter Ashwood-Smith ; Bilel Jamoussi=20 Sent: Friday, September 15, 2000 10:30 AM Subject: RE: [Isis-wg] IS-IS TE Question All =20 Just to add one thing to the time stamping idea. We do not consider it = necessary since=20 the database is still really maintained by the IGP flood. (Which does = not use timestamps but sequence numbers). The feedback is more targeted information that = is used in the=20 interim. Although there are small windows of opportunities for the = feedback to be miss ordered=20 this is still leagues ahead of not having feedback. By the way, the = most likely misordering is an old LSP (LSA) announcing more bandwidth than actually exists and = overwriting a feedback message that has reported less bandwidth. This could result in a LSP signaling = that has to learn from feedback=20 again. (We prefer to deal with the timing issues not pray they will = not happen!). Relying on timestamps or sequence numbers for feedback requires = synchronization between peers=20 and designers of IGPs have way more years of experience and code to = deal with this. =20 I only mentioned timestamp cause I did not think we can use the IGP = sequence number as it is picked for IGP flooding for LSP signalling. The timestamp is only relevent to the = router that is originating the LSA/LSP=20 so there is no synchronization requirements between peers/neighbors. = I think eventually the IGP flooding mechanism=20 will adjust to the correct value, but in the interim the routers in = the domain could drift of actual capacities and thus create more LSP reservation failures. It would be nice to cover this = hole no matter how small with a solution in the specification and leave it up to the implementor to choose. I = guess since you guys went this far in trying to close down the inaccuracies between the routers in the domain. Regards, Ben =20 -----Original Message----- From: Skalecki, Darek [CAR:CS56:EXCH]=20 Sent: Friday, September 15, 2000 8:49 AM To: ben abarbanel Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; = Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH] Subject: Re: [Isis-wg] IS-IS TE Question ben abarbanel wrote:=20 Matthew and Darek:=20 I kind of like the feedback mechanism defined in=20 "draft-ietf-mpls-te-feed-01.txt". I think what is missing and = maybe Bilel or=20 Darek can add it to their spec is that a timestamp be added to = both the=20 flooded LSA/LSP TE TLV to identify when the bandwidth sample was = taken. Also=20 the CR/LDP or RSVP-TE new TLV have a time stamp identifying when = the=20 reservation denial and bandwidth sample was taken from the = rejecting LSR. As=20 the message is returned to the ingress LSR its bandwidth will be = overwritten=20 into the linkstate database, since its the most up to date = information.=20 I can see a race condition where IGP converging link state = information might=20 have older data then Reservation Release/Withdrawl messages = containing the=20 same (feedback) data. Thus its possible for the ingress LSR IGP to = momentarily over-write newer bandwidth with bad/older bandwidth = into the=20 ingress LSR linkstate database. Ingress LSR IGP should check the = timestamp=20 in the database with its current LSA/LSP packet and only update = the=20 bandwidth value if it has the newer timestamp in the LSA/LSP = packet.=20 regards,=20 Ben=20 Ben Abarbanel, Software Engineering,=20 Phone: 703 456 2982=20 FAX: 703 456 2952=20 IPOptical, Inc.=20 11480 Sunset Hills Road=20 Suite #200E=20 Reston, VA 20190 Timestamping is a fine idea but in our proprietary system we simply = wrote any learned information into a database,=20 whether the information was from feedback or flooding. You are right = that more-up-to-date feedback information=20 may be then overwritten by older flooding information but in that = case we may simply re-learn newer information via feedback when needed = so we never implemented timestamping.=20 Darek=20 --=20 Darek Skalecki Nortel=20 (613) 765-2252 =20 ------=_NextPart_000_0029_01C01F21.8C0FC740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Don:
 Comments below
 
Ben
 
 
Ben Abarbanel,  Software Engineering, 
 
Phone:  703 456 2982
FAX:      703 = 456=20 2952
 
IPOptical, Inc.
11480 Sunset Hills Road
Suite = #200E
Reston, VA=20 20190
----- Original Message -----
From:=20 Don Fedyk
To: Darek=20 Skalecki ; ben abarbanel
Cc: Matthew Kontoff ; isis-wg ; Peter=20 Ashwood-Smith ; Bilel Jamoussi
Sent: Friday, September 15, = 2000 10:30=20 AM
Subject: RE: [Isis-wg] IS-IS TE = Question

All
 
Just=20 to add one thing to the time stamping idea. We do not consider it = necessary=20 since
the database is still really maintained by the = IGP flood.=20 (Which does not use timestamps
but=20 sequence numbers). The feedback is more targeted information that is = used in=20 the
interim. Although there are small windows of = opportunities=20 for the feedback to be miss ordered
this=20 is still leagues ahead of not having feedback. By the way, the most = likely=20 misordering is an
old LSP (LSA) announcing more bandwidth than = actually exists=20 and overwriting a feedback message
that has reported less bandwidth. This could = result in a LSP=20 signaling that has to learn from feedback
again. (We prefer to deal with the timing issues = not pray=20 they will not happen!).
Relying on timestamps or sequence numbers=20 for feedback requires synchronization between = peers=20
and=20 designers of IGPs have way more years of experience and code to deal = with=20 this.
 
I only mentioned timestamp cause I = did not think=20 we can use the IGP sequence number as it is picked for
IGP flooding for LSP signalling. The = timestamp is=20 only relevent to the router that is originating the LSA/LSP =
so there is no synchronization = requirements=20 between peers/neighbors.  I think eventually the IGP flooding = mechanism=20
will adjust to the correct value, but = in the=20 interim the routers in the domain could drift of actual capacities and = thus
create more LSP reservation failures. = It would be=20 nice to cover this hole no matter how small with a solution = in
the specification and leave it up to = the=20 implementor to choose. I guess since you guys went this far in trying = to=20 close
down the inaccuracies between = the routers in=20 the domain.
 
Regards,
Ben
 
 
 
 
 
 -----Original=20 Message-----
From: Skalecki, Darek [CAR:CS56:EXCH] =
Sent:=20 Friday, September 15, 2000 8:49 AM
To: ben = abarbanel
Cc:=20 Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, = Don=20 [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH]
Subject: = Re:=20 [Isis-wg] IS-IS TE Question

ben=20 abarbanel wrote:=20
Matthew and Darek:
  I kind of = like the=20 feedback mechanism defined in =
"draft-ietf-mpls-te-feed-01.txt". I=20 think what is missing and maybe Bilel or
Darek can add it to = their=20 spec is that a timestamp be added to both the
flooded LSA/LSP = TE TLV=20 to identify when the bandwidth sample was taken. Also
the = CR/LDP or=20 RSVP-TE new TLV have a time stamp identifying when the =
reservation=20 denial and bandwidth sample was taken from the rejecting LSR. As =
the=20 message is returned to the ingress LSR its bandwidth will be = overwritten=20
into the linkstate database, since its the most up to date=20 information.=20

I can see a race condition where IGP converging link state = information=20 might
have older data then Reservation Release/Withdrawl = messages=20 containing the
same (feedback) data. Thus its possible for the = ingress=20 LSR IGP to
momentarily over-write newer bandwidth with = bad/older=20 bandwidth into the
ingress LSR linkstate database. Ingress LSR = IGP=20 should check the timestamp
in the database with its current = LSA/LSP=20 packet and only update the
bandwidth value if it has the newer = timestamp in the LSA/LSP packet.=20

regards,
Ben=20

Ben Abarbanel,  Software Engineering,=20

Phone:  703 456 2982 =
FAX:      703=20 456 2952=20

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E =
Reston,=20 VA 20190

Timestamping is a fine idea but in our = proprietary=20 system we simply wrote any learned  information into a = database,=20
whether the information was from feedback or flooding. You are = right=20 that more-up-to-date feedback information
may be then = overwritten by=20 older flooding information but in that case we may  simply = re-learn=20 newer information via feedback when needed so we never implemented=20 timestamping.=20

Darek=20

 

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  ------=_NextPart_000_0029_01C01F21.8C0FC740-- From tli@Procket.com Fri, 15 Sep 2000 15:07:56 -0700 (PDT) Date: Fri, 15 Sep 2000 15:07:56 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] IS-IS TE Question Folks, About 99% of this conversation is about signaling and crankback and not about IS-IS. Could we take it to a more appropriate mailing list, please? Thanks, Tony co-chair From ben.abarbanel@ipoptical.com Fri, 15 Sep 2000 18:35:31 -0400 Date: Fri, 15 Sep 2000 18:35:31 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question Sure, I think I am done. Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Tony Li" To: "ben abarbanel" Cc: "Don Fedyk" ; "Darek Skalecki" ; "Matthew Kontoff" ; "isis-wg" ; "Peter Ashwood-Smith" ; "Bilel Jamoussi" Sent: Friday, September 15, 2000 6:07 PM Subject: Re: [Isis-wg] IS-IS TE Question > > > Folks, > > About 99% of this conversation is about signaling and crankback and not > about IS-IS. Could we take it to a more appropriate mailing list, please? > > Thanks, > Tony > co-chair > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From dwfedyk@nortelnetworks.com Fri, 15 Sep 2000 17:54:17 -0500 Date: Fri, 15 Sep 2000 17:54:17 -0500 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question 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_01C01F67.E03C88D0 Content-Type: text/plain; charset="iso-8859-1" Tony I am perplexed by your statement. This spreads across several groups and we get disjoint consensus. >From an IS-IS standpoint you should be concerned what scales and what does not. Feedback is in IS-IS's best interest. Are you suggesting anything that is accepted in MPLS just be rubber stamped in IS-IS? Don > -----Original Message----- > From: Tony Li [mailto:tli@Procket.com] > Sent: Friday, September 15, 2000 6:08 PM > To: ben abarbanel > Cc: Fedyk, Don [BL60:9553:EXCH]; Skalecki, Darek [CAR:CS56:EXCH]; > Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; > Jamoussi, Bilel [BL3:T823-M:EXCH] > Subject: Re: [Isis-wg] IS-IS TE Question > > > > > Folks, > > About 99% of this conversation is about signaling and > crankback and not > about IS-IS. Could we take it to a more appropriate mailing > list, please? > > Thanks, > Tony > co-chair > > ------_=_NextPart_001_01C01F67.E03C88D0 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] IS-IS TE Question

Tony

I am perplexed by your statement. This spreads across
several groups and we get disjoint consensus.

From an IS-IS standpoint you should be concerned what scales
and what does not. Feedback is in IS-IS's best interest.
Are you suggesting anything that is accepted in MPLS just
be rubber stamped in IS-IS?

Don


> -----Original Message-----
> From: Tony Li [mailto:tli@Procket.com]
> Sent: Friday, September 15, 2000 6:08 PM
> To: ben abarbanel
> Cc: Fedyk, Don [BL60:9553:EXCH]; Skalecki, Darek [CAR:CS56:EXCH];
> Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH];
> Jamoussi, Bilel [BL3:T823-M:EXCH]
> Subject: Re: [Isis-wg] IS-IS TE Question
>
>
>
>
> Folks,
>
> About 99% of this conversation is about signaling and
> crankback and not
> about IS-IS.  Could we take it to a more appropriate mailing
> list, please?
>
> Thanks,
> Tony
> co-chair
>
>

------_=_NextPart_001_01C01F67.E03C88D0-- From rja@extremenetworks.com Fri, 15 Sep 2000 19:04:39 -0400 Date: Fri, 15 Sep 2000 19:04:39 -0400 From: RJ Atkinson rja@extremenetworks.com Subject: [Isis-wg] IS-IS TE Question At 18:54 15/09/00, Don Fedyk wrote: Don, Going forward,could you kindly send mail to IETF lists using plain-text ASCII rather than some fancy format as you just did ? A lot of us are NOT using MS-Outlook and at least some folks are on low-bandwidth connectivity, so using IETF standard US-ASCII (or ISO-8859-N) in text/plain format is customary on all IETF mailing lists. Thanks very much, Ran rja@inet.org From vikram_isis@hotmail.com Tue, 19 Sep 2000 01:39:06 GMT Date: Tue, 19 Sep 2000 01:39:06 GMT From: vikram isis vikram_isis@hotmail.com Subject: [Isis-wg] DIS election question??? Hi, I just have question on DIS election. Assuming, an unintended DIS(less capacity or something) is elected, due to misconfiguration of priority or by virtue of its mac address. And that, it is unable to bear the load and submits to another DIS (less priority or low MAC address) in the next DRHold Interval. When its less loaded, is elected again as the DIS and the ping pong between DISs continue. Is there a mechanism by which the DIS which is stable can stick around by distributed/centralised mechanism for a certain period? Any insight would be helpful. Thanks Vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From dkatz@juniper.net Mon, 18 Sep 2000 18:46:49 -0700 (PDT) Date: Mon, 18 Sep 2000 18:46:49 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] DIS election question??? Use the priority mechanism. X-Originating-IP: [209.58.11.227] From: "vikram isis" Date: Tue, 19 Sep 2000 01:39:06 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 19 Sep 2000 01:39:06.0616 (UTC) FILETIME=[661D5780:01C021DA] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi, I just have question on DIS election. Assuming, an unintended DIS(less capacity or something) is elected, due to misconfiguration of priority or by virtue of its mac address. And that, it is unable to bear the load and submits to another DIS (less priority or low MAC address) in the next DRHold Interval. When its less loaded, is elected again as the DIS and the ping pong between DISs continue. Is there a mechanism by which the DIS which is stable can stick around by distributed/centralised mechanism for a certain period? Any insight would be helpful. Thanks Vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From ashish_b_mehta@hotmail.com Thu, 05 Oct 2000 20:45:55 GMT Date: Thu, 05 Oct 2000 20:45:55 GMT From: Ashish Mehta ashish_b_mehta@hotmail.com Subject: [Isis-wg] Complete sequence number packets Hi all, I am new member of this mailing list and had some issues with the complete sequence number PDU received from Juniper box. As per ISO 10589 standard, the SourceID in the CSNP header is ID Length + 1, where Source ID is the system ID of Intermidiate System(with zero Cicuit ID) generating this Sequence Number PDU. I have set up the following ISO NET address on the interface configured for ISIS 49.0001.00a0.c96b.c490.00. When I receive the packet I get following from the SourceID. srcid[0] 0x0 srcid[1] 0xa0 srcid[2] 0xc9 srcid[3] 0x6b srcid[4] 0xc4 srcid[5] 0x90 srcid[6] 0x2 If you see the last byte is 0x2 insted of 0x0. An update on this issue will be appreciated. Thanks. -Ashish _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From tli@Procket.com Thu, 5 Oct 2000 15:21:29 -0700 (PDT) Date: Thu, 5 Oct 2000 15:21:29 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Complete sequence number packets Sounds to me like the guy who did Juniper's IS-IS implementation bcopy'ed the system ID and forgot to zero the circuit ID. Not too surprising, I know him and he's an idiot. ;-) In any case, this is clearly a case for Juniper technical support, not an IETF issue. Thanks, Tony Ashish Mehta writes: | Hi all, | | I am new member of this mailing list and had some issues with the | complete sequence number PDU received from Juniper box. As per ISO 10589 | standard, the SourceID in the CSNP header is ID Length + 1, where Source | ID is the system ID of Intermidiate System(with zero Cicuit ID) | generating this Sequence Number PDU. | | I have set up the following ISO NET address on the interface | configured for ISIS 49.0001.00a0.c96b.c490.00. When I receive the packet | I get following from the SourceID. | | srcid[0] | 0x0 | srcid[1] | 0xa0 | srcid[2] | 0xc9 | srcid[3] | 0x6b | srcid[4] | 0xc4 | srcid[5] | 0x90 | srcid[6] | 0x2 | | If you see the last byte is 0x2 insted of 0x0. | An update on this issue will be appreciated. | | Thanks. | | -Ashish | | _________________________________________________________________________ | Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. | | Share information about yourself, create your own public profile at | http://profiles.msn.com. | | | | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg | | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external From azinin@cisco.com Mon, 9 Oct 2000 18:21:25 -0700 Date: Mon, 9 Oct 2000 18:21:25 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] draft-ietf-zinin-flood-opt-01.txt Folks, The new version of the flooding optimization draft has been submitted to the IETF directories today. So far, it is available at the following URL: http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt Regards, -- Alex Zinin From azinin@cisco.com Tue, 10 Oct 2000 11:19:23 -0700 Date: Tue, 10 Oct 2000 11:19:23 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Thanks, Jim. Regarding the fully meshed topo's. To begin with, I'm not a big fan (gently put) of "optimizing" dynamic algorithms with some manually configured stuff... So, for me personally, the mesh group in ISIS and LSA blocking in OSPF (yes, we have it implemented) is not an option (again, it's just my opinion). As far as automated algorithms are concerned, pure spanning flooding tree over the topo graph is a non-starter, I think. Redundant spanning tree may not be worth spending time since a) regions with highly redundant topology (like fully meshed groups) may be addressed more optimally, I guess, and b) not so redundant regions may not be interesting... We could discuss this, actually, with the first question being "do we really need this" ? ;) Cheers, -- Alex Zinin Tuesday, October 10, 2000, 2:48 AM, Jim Boyle wrote: > this is very good for addressing how to optimize flooding w/ multiple > links between two nodes. > How can a fully meshed topology w/ on the order of 1 link between each > node be addressed (I'm not sure how mesh groups work). > I've heard of a hack that limits flooding from N^2 to more like 6N > so there is an adjacency/forwarding topology and a flooding topology > This could be useful with either manual configuration like "no > ospf flood" or via automated pruning to a certain level of adjacency (even > with SRLGs taken into account, perhaps). > regards, > Jim > p.s. - pruned mpls wg > On Mon, 9 Oct 2000, Alex Zinin wrote: >> >> Folks, >> >> The new version of the flooding optimization draft >> has been submitted to the IETF directories today. >> >> So far, it is available at the following URL: >> >> http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt >> >> Regards, >> -- >> Alex Zinin >> From tli@Procket.com Tue, 10 Oct 2000 11:42:27 -0700 (PDT) Date: Tue, 10 Oct 2000 11:42:27 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt | We could discuss this, actually, with the first question being | "do we really need this" ? ;) IM(ns)HO, we are in dire need of a replacement flooding algorithm that scales much more nicely. It needs to adapt to the topology as end-users cannot be expected to provide us with additional configuration information about their topology. It needs to be robust in the case of failure, not causing massive pertubations of the flooding path on a single link failure. It needs to restrict the amount of flooding that any single node needs to do. Currently, my best guess is that a redundant spanning tree is the best known direction. Tony From dkatz@juniper.net Tue, 10 Oct 2000 11:51:08 -0700 (PDT) Date: Tue, 10 Oct 2000 11:51:08 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt I concur. The mesh group hack is just that, a hack. It saved our bacon in a pinch. The fact that it's been documented is a little embarassing. I tried to hide the awful truth, but I was exposed. Oh, well. ;-) IM(ns)HO, we are in dire need of a replacement flooding algorithm that scales much more nicely. It needs to adapt to the topology as end-users cannot be expected to provide us with additional configuration information about their topology. It needs to be robust in the case of failure, not causing massive pertubations of the flooding path on a single link failure. It needs to restrict the amount of flooding that any single node needs to do. From jboyle@Level3.net Tue, 10 Oct 2000 15:36:39 -0600 (MDT) Date: Tue, 10 Oct 2000 15:36:39 -0600 (MDT) From: Jim Boyle jboyle@Level3.net Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt I don't know. Imagine a 1000xOC192 router, and a service provider using it in say, 100 markets. You are going to get some meshing here. As for parallel links between two nodes, bundle the links if possible, if not (e.g. some go N some go S) - you're draft sounds good for that portion of the flooding. However, you are still left w/ a full mesh (or close) topology - perhaps one that isn't as bad as some of the ATM meshes of yesteryear, and processors are much faster today, so... maybe it's not worth it. Then again..... maybe that big old router doesn't want to deal w/ making 100 copies of the LSA, or checking the 100 or so he gets echo'd back. I just hope there aren't cases where that mesh loses, for instance, 25% of it's links, affecting 75% of the routers. Hmmm... 75 routers, 75 LSAs, 75-100 to flood (to non-affected adjacencies), that's 75^2 before we even get to the echo. Then again.... with link bundling, infinitely huge routers, dirt cheap router ports (and OEO), maybe we can pull all IP traffic through most routers, even if it's transit. Then with a simple topology, we have no worries. Jim On Tue, 10 Oct 2000, Alex Zinin wrote: > > Thanks, Jim. > > Regarding the fully meshed topo's. > > To begin with, I'm not a big fan (gently put) of "optimizing" > dynamic algorithms with some manually configured stuff... > So, for me personally, the mesh group in ISIS and LSA blocking > in OSPF (yes, we have it implemented) is not an option (again, > it's just my opinion). > > As far as automated algorithms are concerned, pure spanning > flooding tree over the topo graph is a non-starter, I think. > Redundant spanning tree may not be worth spending time since > a) regions with highly redundant topology (like fully meshed groups) > may be addressed more optimally, I guess, and b) not so redundant > regions may not be interesting... > > We could discuss this, actually, with the first question being > "do we really need this" ? ;) > > Cheers, > > -- > Alex Zinin > > Tuesday, October 10, 2000, 2:48 AM, Jim Boyle wrote: > > > > this is very good for addressing how to optimize flooding w/ multiple > > links between two nodes. > > > How can a fully meshed topology w/ on the order of 1 link between each > > node be addressed (I'm not sure how mesh groups work). > > > I've heard of a hack that limits flooding from N^2 to more like 6N > > so there is an adjacency/forwarding topology and a flooding topology > > This could be useful with either manual configuration like "no > > ospf flood" or via automated pruning to a certain level of adjacency (even > > with SRLGs taken into account, perhaps). > > > regards, > > > Jim > > > p.s. - pruned mpls wg > > > On Mon, 9 Oct 2000, Alex Zinin wrote: > > >> > >> Folks, > >> > >> The new version of the flooding optimization draft > >> has been submitted to the IETF directories today. > >> > >> So far, it is available at the following URL: > >> > >> http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt > >> > >> Regards, > >> -- > >> Alex Zinin > >> > From rfc-ed@ISI.EDU Wed, 11 Oct 2000 11:59:09 -0700 Date: Wed, 11 Oct 2000 11:59:09 -0700 From: RFC Editor rfc-ed@ISI.EDU Subject: [Isis-wg] RFC 2973 on IS-IS Mesh Groups --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2973 Title: IS-IS Mesh Groups Author(s): R. Balay, D. Katz, J. Parker Status: Informational Date: October 2000 Mailbox: Rajesh.Balay@cosinecom.com, jparker@axiowave.com, jparker@nexabit.com Pages: 8 Characters: 14846 Updates/Obsoletes/SeeAlso: none I-D Tag: draft-ietf-isis-wg-mesh-group-01.txt URL: ftp://ftp.isi.edu/in-notes/rfc2973.txt This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. The described mechanism can be used to reduce the flooding of Link State PDUs (Protocol Data Units) (LSPs) in IS-IS topologies. The net effect is to engineer a flooding topology for LSPs which is a subset of the physical topology. This document serves to document the existing behavior in deployed implementations. The document describes behaviors that are backwards compatible with implementations that do not support this feature. This document is a product of the IS-IS for IP Internets Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001011115719.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2973 --OtherAccess Content-Type: Message/External-body; name="rfc2973.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001011115719.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From jboyle@Level3.net Tue, 10 Oct 2000 03:48:16 -0600 (MDT) Date: Tue, 10 Oct 2000 03:48:16 -0600 (MDT) From: Jim Boyle jboyle@Level3.net Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt this is very good for addressing how to optimize flooding w/ multiple links between two nodes. How can a fully meshed topology w/ on the order of 1 link between each node be addressed (I'm not sure how mesh groups work). I've heard of a hack that limits flooding from N^2 to more like 6N so there is an adjacency/forwarding topology and a flooding topology This could be useful with either manual configuration like "no ospf flood" or via automated pruning to a certain level of adjacency (even with SRLGs taken into account, perhaps). regards, Jim p.s. - pruned mpls wg On Mon, 9 Oct 2000, Alex Zinin wrote: > > Folks, > > The new version of the flooding optimization draft > has been submitted to the IETF directories today. > > So far, it is available at the following URL: > > http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt > > Regards, > -- > Alex Zinin > From rfc-ed@ISI.EDU Wed, 11 Oct 2000 11:56:52 -0700 Date: Wed, 11 Oct 2000 11:56:52 -0700 From: RFC Editor rfc-ed@ISI.EDU Subject: [Isis-wg] RFC 2966 on Domain-wide Prefix Distribution --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2966 Title: Domain-wide Prefix Distribution with Two-Level IS-IS Author(s): T. Li, T. Przygienda, H. Smit Status: Informational Date: October 2000 Mailbox: tli@procket.com, prz@redback.com, henk@procket.com Pages: 14 Characters: 32465 Updates/Obsoletes/SeeAlso: none I-D Tag: draft-ietf-isis-domain-wide-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2966.txt This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. 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. This document is a product of the IS-IS for IP Internets Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001011115456.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2966 --OtherAccess Content-Type: Message/External-body; name="rfc2966.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001011115456.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From azinin@cisco.com Wed, 11 Oct 2000 17:43:56 -0700 Date: Wed, 11 Oct 2000 17:43:56 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Tony: > | We could discuss this, actually, with the first question being > | "do we really need this" ? ;) > IM(ns)HO, we are in dire need of a replacement flooding algorithm that > scales much more nicely. I don't really like that "replacement" word ;), but I agree we may need to modify the algo in some places... > It needs to adapt to the topology as end-users cannot be expected to > provide us with additional configuration information about their topology. Agree. > It needs to be robust in the case of failure, not causing massive > pertubations of the flooding path on a single link failure. Agree. > It needs to restrict the amount of flooding that any single node needs to > do. Not sure what you mean here... > Currently, my best guess is that a redundant spanning tree is the best > known direction. If there are enough interested parties, we could create a design group made of ISIS and OSPF guys and consider possible options. Alex. From tli@Procket.com Wed, 11 Oct 2000 18:07:52 -0700 (PDT) Date: Wed, 11 Oct 2000 18:07:52 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt | > It needs to restrict the amount of flooding that any single node needs to | > do. | | Not sure what you mean here... Think about the amount of replication that a single node needs to perform. Imagine that you have a network of tens of thousands of routers that are fully meshed on a L2 fabric. All of the other requirements as specified might result in a single node being selected as the replication engine and it having to transmit each LSP/LSA tens of thousands of times. This does not scale. However, hierarchy would scale. If the result is a flooding tree where each node performs a limited number of replications, then no processor is unduly burdened. The only question now is how much replication we would like a processor to do. More formally, what is the degree of the node in the flooding graph? Higher degree requires more processor but results in a shallower tree with lower flooding latency. Lower degree results in less work and longer latency. | > IM(ns)HO, we are in dire need of a replacement flooding algorithm that | > scales much more nicely. | | I don't really like that "replacement" word ;), but I agree we | may need to modify the algo in some places... If you can meet all of the requirements and still interoperate or even function without a flag day, that would be a genuine coup. ;-) | > Currently, my best guess is that a redundant spanning tree is the best | > known direction. | | If there are enough interested parties, we could create | a design group made of ISIS and OSPF guys and consider | possible options. I'm game. However, interest to date on this has been.... low. Tony From riad@caspiannetworks.com Wed, 11 Oct 2000 19:02:18 -0700 Date: Wed, 11 Oct 2000 19:02:18 -0700 From: Riad Hartani riad@caspiannetworks.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt I would support Alex's idea to create an OSPF/ISIS design group working on this problem. Reducing flooding in Link State Protocols under failure conditions is certainly a very interesting and useful problem to work on. Obviously, one of the key problems would be to remain backward compatible. There have been some attempts in the past within the ATM F to discuss some techniques to analyze/reduce flooding in PNNI (e.g. ATMF 00-0249 for problem statement). Nothing specified though. Some research has been going on as well in terms of OSPF/ISIS flooding reduction with proposals ranging from the use of broadcast servers to increased hierarchy/partitioning to preemptive acknowledgment of updates, etc. Nothing concrete at this stage. Riad > -----Original Message----- > From: Alex Zinin [mailto:azinin@cisco.com] > Sent: Wednesday, October 11, 2000 5:44 PM > To: Tony Li > Cc: Jim Boyle; ospf@discuss.microsoft.com; 'ISISWG' > Subject: Re: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt > > > > Tony: > > > | We could discuss this, actually, with the first question being > > | "do we really need this" ? ;) > > > IM(ns)HO, we are in dire need of a replacement flooding > algorithm that > > scales much more nicely. > > I don't really like that "replacement" word ;), but I agree we > may need to modify the algo in some places... > > > It needs to adapt to the topology as end-users cannot be expected to > > provide us with additional configuration information about > their topology. > > Agree. > > > It needs to be robust in the case of failure, not causing massive > > pertubations of the flooding path on a single link failure. > > Agree. > > > It needs to restrict the amount of flooding that any single > node needs to > > do. > > Not sure what you mean here... > > > Currently, my best guess is that a redundant spanning tree > is the best > > known direction. > > If there are enough interested parties, we could create > a design group made of ISIS and OSPF guys and consider > possible options. > > > Alex. > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From azinin@cisco.com Wed, 11 Oct 2000 19:16:00 -0700 Date: Wed, 11 Oct 2000 19:16:00 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Tony: > Think about the amount of replication that a single node needs to perform. Agree. This could be *partially* be addressed with: a) good pointer-work in the code :) b) notion of "replication groups" when flooding newly installed LS{A|P}s over a bunch of interfaces. This can be "a bit" of mess, though (the keyword is "peer-groups" ;). > Imagine that you have a network of tens of thousands of routers that are > fully meshed on a L2 fabric. Sounds familiar :) > All of the other requirements as specified > might result in a single node being selected as the replication engine and > it having to transmit each LSP/LSA tens of thousands of times. Yeah... Multicast/broadcast capabilities of the L2 part would definitely help, but I agree, if we have a large number of interfaces in a box and the guy with sysadmin rights has configured them to be in one area... > This does not scale. > However, hierarchy would scale. If the result is a flooding tree where > each node performs a limited number of replications, then no processor is > unduly burdened. There's always the other part in this equation --- the number of LSAs... If we continue going the same direction (flat IGP domains, flat TE domains, etc.), we may hit the same problem later... > The only question now is how much replication we would > like a processor to do. More formally, what is the degree of the node in > the flooding graph? Higher degree requires more processor but results in a > shallower tree with lower flooding latency. Lower degree results in less > work and longer latency. Not only this is the question. We would need to assure the same level of determinism in flooding as we have today. It's definitely going to be more than just pruning the flooding topo to the tree. > | I don't really like that "replacement" word ;), but I agree we > | may need to modify the algo in some places... > If you can meet all of the requirements and still interoperate or even > function without a flag day, that would be a genuine coup. ;-) I do not think we should consider other options... > I'm game. However, interest to date on this has been.... low. Yeah... And this time, I'm not going to ask on the NANOG list :) Those who are interested or have something to say, please, speak up. So far we have Jim, Tony, Dave [if I understood him correctly ;)] and me... Alex. From tli@Procket.com Wed, 11 Oct 2000 23:04:04 -0700 (PDT) Date: Wed, 11 Oct 2000 23:04:04 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Alex, | Agree. | This could be *partially* be addressed with: | | a) good pointer-work in the code :) | | b) notion of "replication groups" when flooding newly installed LS{A|P}s | over a bunch of interfaces. This can be "a bit" of mess, though | (the keyword is "peer-groups" ;). With all due respect, I don't believe that these are sufficient. Even with optimal pointer work, you're maintaining a list of transmissions and retransmissions per adjacency, or a scanner and one bit per adjacency. This implies that your overhead scales linearly with the number of adjacencies, which is exactly the situation that we'd like to avoid. The "peer groups" (ala BGP) are really only of use when you have to compute the updates and can amortize the computation across the numbers of the group. | > However, hierarchy would scale. If the result is a flooding tree where | > each node performs a limited number of replications, then no processor is | > unduly burdened. | | There's always the other part in this equation --- the number of | LSAs... If we continue going the same direction (flat IGP domains, | flat TE domains, etc.), we may hit the same problem later... Correct, this would decrease the other multiplier. However, when a network operator is given the choice of restricting the growth of his network, restricting its feature set and therefore optimality or inspiring his network equipment vendor to work harder, which do you think they will prefer? Yes, that's a rhetorical question. ;-) | We would need to assure the same level of determinism in flooding as | we have today. It's definitely going to be more than just pruning | the flooding topo to the tree. I'm not sure that I understand this requirement. Are you suggesting that we need a deterministic flooding algorithm? Or that there needs to be user control over the resulting active flooding topology? Tony From azinin@cisco.com Thu, 12 Oct 2000 11:18:22 -0700 Date: Thu, 12 Oct 2000 11:18:22 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Tony: > With all due respect, I don't believe that these are sufficient. [...] That's why I said "*partially* addressed". > | > However, hierarchy would scale. If the result is a flooding tree where > | > each node performs a limited number of replications, then no processor is > | > unduly burdened. > | > | There's always the other part in this equation --- the number of > | LSAs... If we continue going the same direction (flat IGP domains, > | flat TE domains, etc.), we may hit the same problem later... > Correct, this would decrease the other multiplier. However, when a network > operator is given the choice of restricting the growth of his network, > restricting its feature set and therefore optimality or inspiring his > network equipment vendor to work harder, which do you think they will > prefer? > Yes, that's a rhetorical question. ;-) I think I meant a bit different thing, but I won't start another discussion... ;) > | We would need to assure the same level of determinism in flooding as > | we have today. It's definitely going to be more than just pruning > | the flooding topo to the tree. > I'm not sure that I understand this requirement. Are you suggesting that > we need a deterministic flooding algorithm? Or that there needs to be user > control over the resulting active flooding topology? I mean we need to make sure the flooding algorithm (if modified) guarantees the same results in PDU delivery in the presence of arbitrary topology changes (including those killing both branches of the redundant tree), as the current one. Alex. From prz@net4u.ch Thu, 12 Oct 2000 20:58:21 +0200 (MEST) Date: Thu, 12 Oct 2000 20:58:21 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] test message (ignore please) just test to see whether this one gets through, looks like my messages don't get out to the list (again ;-) and I grew tired of re-typing messages trying to get them out -- tony From prz@net4u.ch Fri, 13 Oct 2000 08:47:16 +0200 (MEST) Date: Fri, 13 Oct 2000 08:47:16 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Here's my jest on the flooding-optimization problem: First, I think it's a good idea to get a small group of people in a room and after some high-flying discussions get some rough-cut proposal out that preferrably a Ph.D. candidate or an agressive company goes off to tinker with and comes back with implemenation results as either papers or competitive advantage. To get anything done, my opinion is that group has to be restricted to people with at least one deployed commercial link-state under their belt or serious researchers that dealt with link-state and a group of more than 15 people won't get anything done anyway ;-) BTW, I tried to encourage 2-3 candidates in last years to pick up the topic but without success. Either the topic is not sexy enough or I'm a really bad sales-guy ;-) Withough someone willing to go and do the work on gated or a commercial piece of software the topic will end up as it always ended up so far, an interesting discussion without practical implications. There was a flurry of activity on the research side about 2-3 years ago and to my knowledge 2 streams of thinking are around: one is the spanning tree on top of topology (Bala's paper is an example, convergence has been proven) algorithms are variations of 802.1 mostly or distributed Bellman-Ford, the other one, much less known is a variation of a token-passing algorithm building hierarchical trees (kind like multi-cast in PNNI, not algorithm- wise but in the sense of trees built). Some thinking was spend on building 2 redundant trees that can fall-over when first one is cut or alternatively the two sides of the tree operate independently until merged again. Not sure that has been published and if, it's a while and not in IP context. Both approaches have an obvious common underlying problem: When converging the tree, the very underlying mechanism (flooding) is being fiddled with, possibly affecting flooding-speed and therefore the convergence of the tree. So the so-formed control-loop needs to be broken or dampened somehow obviously. so who's game & when ? -- tony From prz@net4u.ch Fri, 13 Oct 2000 09:19:29 +0200 (MEST) Date: Fri, 13 Oct 2000 09:19:29 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] ISO ballot --ELM971421569-26217-0_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Following ballot from ISO for the working group. I honestly tried to convert the enclosed word to PDF first but mickey-soft word just died repeatedly on me so I just added the ZIP containing version 2 of the spec and the attached ballot. I know it's humongeous and some people downloading through slow phone lines will hate me but I couldn't think of a better way to get it out. Looks like the ballot is open to the whole working group so everybody goes ahead and posts input to the list and Tony & me will summarize to ISO I guess ... thanks -- tony ------------------------------------------- Telecommunications and Information Exchange Between Systems ISO/IEC JTC 1/SC06 N 11704 DATE: 2000-09-20 REPLACES DOC TYPE: Text for CD ballot or comment TITLE: ISO/IEC FCD 10589, Information technology – Telecommunications and information exchange between systems – Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473) SOURCE: Project Editor (M. Bartell) PROJECT: STATUS: Per SC 6 Prague Resolution 6.7.5, this text is circulated for FCD ballot closing 2001-02-15 to allow IETF input to the process so that extensions for IETF requirements can be included as ballot comments. ACTION ID: LB DUE DATE: 2001-02-15 DISTRIBUTION: P & L Members; SC Chair; WG Conveners and Secretaries MEDIUM: DISKETTE NO.: NO. OF PAGES: 175 ISO/IEC JTC 1/SC 6 Secretariat ANSI, 11 W. 42nd Street, New York, NY 10036, USA Tel: +1 212 642 4992; Fax: +1 212 840 2298; E-mail: mdeane@ansi.org --ELM971421569-26217-0_ Content-Type: *unknown*/ Content-Disposition: attachment; filename=06n1704.ZIP Content-Description: 06n1704.ZIP Content-Transfer-Encoding: base64 UEsDBBQAAAAIAPCCNClFRUhlpwkAAAAwAAAMAAAAMDZuMTcwNGMuZG9j7VpdbBTXFT6z9hobvGA7 4FDHrW6AUii22V1sY4PS2l6vYYP/6l2HUJEq492Ld2B3xszOYsxDFauq+lCSkFQKeUhVU0HbkKpS 2kpVf6TSqI+tiqOmaqVKMWoeKpQ+xOKhNAnb78zM2uu1wUahUmn3s47OzDnn/p177t17z/j6H2rn Lr3ZcIOK8AUqozu5KqookCmgDfmXGqJqV3Ynl8uxaD0oV8JDhb9eSVJ8rqqc508WzDWmn65WEn1Y R8tw1btctgwbid4qW+Rv1Trie/HN4H9y39fCOd7mXJ6Xvw8eAr/pvn8S7iGnProPvhf+ehr8G+BW gbwY+XHfXNB7sdYU/BX3pBjF+veL3os9u9Z67saL6yl+L67/2X/cuNK1/ZpSPGOrRcBq/fjPICZT Mm6k01ldi6uWZugZoeoJEdFPGGbaFog1wBc+G0+q+rgUPdKalFIX0amMJdOZ1YsWwufzRaJDeyPh kHgyFhKBvdGQv10MikBgv7+12LS3OxY+IETQ7/c3+zubg35XPhIe7u8OhaMr1L8cqGYoJGLHhsMH fDF51hIYtgj1ijE1lTIsgRd2jtSt1aty4fPFIrF+VJcfSR+qC/jbOjqblnjVkvGkbqSM8SnxirjL LGgF9jLv4THXwxnXw6+gWkuaaZnQVEu6YmEZK4o13TLV5oSRVjVdmEbWkpo+vnI7E6ZhGXEjZbsk m5GwgjP0k1k9bhtOalZSWMkiQ7yc0RJcKatgr0vbPCUzmea0kZBiEP03zFMiKs0zWlyKXXCU6Gjd v283pj86NDoSgvOGTeMkCopwQrNQ666BFtGjmpZMpXavPgWL8PmGR4aeDIdiB1ZURmPdsdEoWpOm iIZEuxg21fGsFCMyY6Sy9ijbW/a3tDVhMFoGU4YAAY9rZjybglcT9pD7FuMlnjIyPHYEZaDZH2wO tPFEsG5SRMKxPvhwImuxzHVcHG4RGX5VLbjeknrGnn2u1y5gytNZzZQcgmhY1TH9qCSeyibQuppZ aNiJ0kyLz9cdikWGBkWkF2Pu77FDfDQsFleL2zGII9HYSKRnlM2hGhY7Rb8YkOkxaWYOsj9CSVUz D4qjh0TI0M9IHXI7LKMybkpLNTWZWXClbyDcGxkdOGC/oOYj4VgsLAaHWpZ43ueDRAz1ieHuQ+Eo VIH9bYu6ZYsfM7LQlrrmJejrHoxGmrBpiKMtojXIHbZMKa0mhN6kOIbYw9MxrEn/vvYmMRrtvks1 WJTo4Z6ACAaCor01KFo7O4MHhehTzy7KO1r9Ihjs7IA83IxVlSqONF86IVVddqmY2RbDHF+xrdXh 8wm6pNBFem3G++0Z7+Xre6/MPfG9Ge/3Z7w/mPG+PuO9uvpeX8IKcM95vwPRnVWtS/gfgiereHj+ D4FeAL0IugD6OegXoFnQ23yGx+1AAW0AjYCioC+Dnsc94AXQi6CLoHdBc6CPQB+DvLg8zoLeBv0N 9B7oX6APQYfWER0GRUAx0CjIAE2Avgk6D3oe9EfQY4jNMdDrle6dxOl+ia2F3aYi8I29XNCmcuXM Z6lpI+2mSsiO0CZbu4Oo64OcB7xikM9EKft2tSVB9QnahxuKWlUe31pcJbCNurvmc5fA63vlCTWb ssSwitOEqU4kRZ+hWwW2O+nOkEIeZSdtgq2ma/ZJI4bDGqEvm2gLUT3bfd62mwcvtOvXMhbnIWqo NqnkTWkrbOdztcpWWr9oixvcU9ONTmvUSJ7DAYRyHVUqlTQ6HffTqR3U4GoboA1C+wi0XtbCEYW6 fdBtzusauVVHVw9dK3RboPNAV1imDfL6fJnNS+trh+7RvK6GSLg6Qeu6EwkTxyL2xVbXFzwOx+Jl RdD6npQRP3U6a1gSNp+imqQCVxBGxj64pNRReSgSC9ul6m3Zm0o9ZEO9YczgM2WEzrD8u/QbyCvD 6YmkmtEytn2DLZ9VGqjq8NSENFOafoo3gK8oY55ttu6Gso1q+ww+08lEsU11o93eB0ojVR6RU2OG aiaIve20OuiM0jNI1cOmdA7dOEZSM8btjHTTdk4x/brsq+ue2PDRxl/WnavvbPjnp3/2OGK1APlR tKI+jtZWqjnX3GNYlpEWxgnEG0Kpih4nr7KPdh7jaDk+/YzHDl74OuiWCpLvXHPMmFgogjLb7DK7 lpVx/Bjw1FNFVE1PpCQ2TvQBMcE+6fZshtwyDX2cOAocL3zJ00jrY/DQpKnhKrLE9/M5FXVVPsUn uzHUlo/U+dxplNpwODaAs6hqnspOsGePT49VOKWmUWpdyDntclwcn2Z/cEamzN4bFTsDx7s6/6J7 F37fKyjXFaItdRcQJzEtjZMrHwZHcBHSqbrmAmI3OpUeM1K0YRubdKNbKaoN8HPIyOKoa3IBuIcz Rc9hB7juIeKgQ9hdjvQ9CuJnW0CzoDf4R8NOoZTT1+DYRSi2lVI4n3aqpO/B3MVRk28AYZXE+Hr5 6Ln0jUooBE8DT5L7M88RY+d88bNLfCTkieP87segje5zvcvvhdX0Jfx3YIQM/FnYf8Okg5s0hdld e/6nHvtlvi57SVd57Li65oSXvSnk8z/5zKCP9Qg4zv8cResmJagXPE5ZSpO0+0G0tvwPfkuVfPxy H9aS/+E+cV6b8z8KhdBymiZoiMboJDT3l/+pQ/uF/lwp/0MrgFvi/I+Xovao06Tavo9g9Cdsn7DE Ig3POmzvlv/Z5bZfnh//Ejj5n+K22V+3MFmc/8l/v1lt/fN3H/7ew3OX3wdKePihYCbL1juxU7x2 +Zw/oMVNI2OcsMRRw0yIXiOetY8efCsYiLIMIv4YSPzckte3tNOtzh+fplVxJ8dx51km57ic+/p3 5m8PJWveeKmS9nzuJ3/xQ/ZbKGpd/QVyYvlVctb/38mJ4VvkxHG14sTyVsWJ5x2KE9OtihPX/faZ mehpxfmG9JzixPh5xYnzVxUn1i+D8+3oh4r92ZN+Cv4I+K8Up/330OhnwA/Rg/qe4NSXPyLxM/dj 6TlmYNEG9S48ozQ/83jdC5xYufygXd67bOdd236URwc8UBhPtAawryuXnv8+Ee63/QeNh7n9wvVf 8QDXf8cK6/8sLV0vvEY5V02zBxRev7wmy1yb/P8Z5Hl1jSN/wOusjEoooYQSSiihhBJKKKGEEv5P wHeqgJtLYCq673Hu86imJ4zJjOhsowR1FZS1n8/vePeL268p9vPNWy9xfpcvVXy9Zz7rcv4ctNJl 6175H887v3/ntZbHar51sZL2NN3+Eed//kxOboP1XeTkZQ6Tc5fk/7vlfM+z5Nwbk+TkaybIyeuU 7p/L8W9QSwMEFAAAAAgA770mKYphIDF/HQYAAA4aAAsAAAAwNm4xNzA0LmRvY+xcW4wk11muTSzw YrfB2A4RCdJREGiXzIy7q+9jFGl2Znbd1u7sZntMIkiEqqvPdNdudVWnTvXMjoUQ4iHiOaD1AwgF FIMi5QEkLiZcYnNzQEbkgRfewlscRSgPPMCLl+8/l6pTPV3dvRfbL26ptneqzv+f//znP/+9+jv/ /vR3/+BPf/q/nLnPZ5yPOu/eO+/8iHXvE7j+9cf0Hz/hOG/j/x/Ff9+9d+8e3foz/P3nuP4C11/i eh3XX+H6Jq6/xvU3uP4W19/h+hauN3C9ievvcf0Drn/E9U+4/hnXW7i+jetfcP0Q1ytPYIInHefX cX0P170PP4/k84PX3nS+5Jx/zHEe/8lvZTuLD+4M3n7cecoZ3BrcSj+dfto58zn/2Mect+vPOR/b OSevT371cecXnnGcr8yN+9pj6vvevR/P7pX933y+KP/9+ONO9k3XV/H/1/E9xXf4pHpmfz/7kRzD bzxV/t2B2L7+tOP8Gr4bzznO7/1s/vzwj845XzvnOD/Ywf0fdZzf6jnOBdz/k556nn2/pL5/9/OO 8xTm/vrQcVLg+5kxJB3wO6+dc4icXXw79/H9v398zvkfmv/r55wDff9p9ajwMev+z+DsM/q89bLj /MdHFH32OPNt5vvE/6m/L5wvfpt1mg+t96eeUHyx4ea/Cf9/f07h+eWPaDzncnoN33ZeW7Ao5+x+ zdM1/23Ws2Ot54eP5fQ88a7j/P7PO86/ffmc8w2osN/EGr7v5PQ86MfMZ9bznY7jfBI0vfGN73/z yx9/49z8Ot56E7LVdpzTPzznfNuS0w/204tSnkReGsSRF55n5Z9e//rzvf3dSj/1oqGXDM8vGyw/ tWqz061U+tyPoyHbHwY0ScWtVqub1e5mtVbRn8dx9aKjOJlIMljK/XEUh/HolN1lhzwE/GQyiwJf PhYM87PAGs/v+GMvGnE24OkJ5xETpyLlEwFouboJHwZeyvVtlsYLbwdRmnibw3jiBRFL4lnKg2i0 eJ5pEqexH4cMz9hMcIxiWOOtWeTLgSdBOmbpeG4g/jgOhoSUHmF8xOXwkAuxOYmHnB2A/ji5zfo8 OQ58zi6A56zTaNcvgkOHhisBFwyDw6/YtN1luzaTaMAQM7yDsTxl72jChzYMnmDJav3fm3Bi1w1N Ly9wgxM24ognUcwiA0KjwMd3wMcAiL7Llj1KgzAQPJGMiunpBNMz75j7LMw5xcGqWRIFQnh4ij+F 5gWR8I7g3gxUM8ktjBCKjXdoxXPMmkzjxEtO2UGc8m3GDsHylN9JaavScSCYCyG6HEDm2e4ebvpx QgAp2KB4JUhOaKNq3a7LuBLeDZZwMQtT2sSjJJ4wb0q7yodKZsH8EBQlSTDiOCMbzMMah7ROsSGl FoOnscBwoInDmdoFzLPHjyAL7CYHDalg9SbbZI3GliJ7OksIiMVHiyiX8H7CSZI9JlJvEOqVnowD f8x8L8K5ICkdMk/IFQ08ATASyTgaxbQWkrotHMIUQoOVR3HK/FmSgPDwlJgTzsBvAgVeHglJdoxV EhUYkfAvzTgO0ZANTuWw3v7hZcYugNdKvUAE9xLvKBXbrPKLQ/rfZsDTo80AhGwOTyPwabPqbqV3 0s9ssDMDIIlHR4EPjSFHsIu05AkH0gw7UQA5k6wG2w60PmOX4uGp5PxVyKGAlMTJyIuCV9QhIb1C EMxLSGCPA1oCsVPdZ6SLiF9YGzvxTukRdnCEzZOMFDY/tkiRPbkbgyJgrDzDDq/vsi/E7FO1TfdT 7NnLccLB5eH5Z9iNnSv7N/cvs189jP1G16263WbdZV8Ys3PPHgfPVWqs78dTXjKwrgbWnqu4EG15 ko9xMiA/2C2fixKwRgZWJ2ELIinOZaObarSL0Vs1SKVGLo9diJO4Cr5lwbuZVgu9Uxx/L/HH4LOf zhK+Bqq2hao+j2o4pK0gAV6NqGMharCrMR1VbLvHIo1zNYquhaLJbhoTcZRAfNdD0ahaKFpsZ6jU ircGUxs1BVp/rtJg/dPJIA6VJfQGg4QfB94yWDeHxYbueakHVR2kZcPr1nA3MwpsuAquYcHVaXW0 PWUy2dBS1qDRDXYtED4PQy/i8awMopVBNNnh6RQn0ZuOtdKNjnHulrCgncG22PVjMir8RKnU3PiU gHZyUHCvr72I02npyroWgMv6s4GRsSVATS0aTQKqs0MYCmXrS4bXrOGNVbxuutboJrusHRUwTulD IaWnBFZLQ4tgW9AeIhhFbBR7Wv6iONqUf5WANyzwNtuHlk3iiNQrZrfVdgm4lpIOgXfKKKeNFDmb g2jIp7C8pMOhy6dxtGSCVjZB294qG8eRnrUMhZatWhU4ICGrNqNjD3fBUT8gE0JiCA1eBqWFqlYn qDp7eTokk78UpqVlqtYlmAaDETqB505Kazmc0TUNgrNUHY4ZPAxpMcmb8UjzwQKXoTFqB3vfsXm7 NmdbdQsDOHuNfK/NIexxEGkTHiT+DBqJbHWvD7rgUjLtxA/iGUUqpyW4GzZuqDlySjfTeHNK/7HE qYw2LZn1DsHXmXQ/3WpnDUijx+oE2WCXktgb+p5YZ1KjxkB0l/XTZKYMKW0HTHQs9xaH4cbey2UY tPQ14Qt0wdIrPOIJjlMGnczCMsltdW1YF4c5n9HsbcE0lyFqV21E9QKi/sGNnZXwNRu+Qctdplvb Rv25NLzJrvJj+DE1dnXnANsmA8I+G8P6xISpBEfdxtHSONz7w6FFrtkgHO15kVsbjZa8JgkBlKJZ ThhEtykCgFooh9Wy12wTbDdbxlqwWvhaVSk61Wxi0rEhp1CaAgHyFKPZZAC9sASXFsNWXeKqZYQ8 CC4tlq2mxOVmdEFBpQFke31UHS2YLcnaWj0j6wFQaRltgdPglXYbeG7/SsC0rLa6BJYdUBly3gpS aFsZlgSTUrXbqRcwuHDgTbApHZ5loI0CaB2guYE24RCCkySzuqT1yMEswdcs4Gush4+C+BJ8LQtf 5opNvMgb8SUs1XLbrhJUrvNKRnfy0ZubGO+yK3vXrlseegmclsJ2zcBhJkrKYGFzCEq4363OYYAP 3T+oUdhVrpO7WsxqVSgVyD4iUJnhgYyWALgGoEUAksgMxCSqUunwB3QUpatWvuxu3UKHnSRMJsfl KdtOORdzjj7nBVKU+1LVeL4fK38Eig9ezVatS/+AKPKLKC8Q+OR0rFiRiW6rbbki98yKcgkpJPTW Wl/TIIfM7VCyie2UjNTCWath/3bA116UJtg6fwnydgHEZTt2MCetupjCPSTFo0K+EjydAh44I/DT kplmP3FAq1WzM9PAF7TPTDKjDGu3gLXBeuSzBUc6x7gQqFU1PmetQUDNPHwUs8kE3ti2POMyN8xG Sw5iq2oku9YkTK2lmEKt8iW7QOEKz7JVNaeAfOMdssUrkbvrIzdnwq0amblUMtKIrgs7eCmPHWif aPdNHroEulmAdtnLJk3IVW5Du1HsKOAh5cwXJ7lLkBtxdptmEbslI40Uuzh/u5QxMvECZQwGXpkb 16p2CoD1dQOUVjULhmqGtr3FI2tGHOtg0Z5SdiOKH2T6jw5oifTVagVA1wb0juNgWKqPWjXXAlXU 7ZeMNIJSb5LK3ze2CSKmVNaQxYNblBr2Q0+IlSakVWvMIXTJhADtakgjS42GIfpyyUgjGI22GXml ZKQRjAZipCvraMRWrVMAced0jpHuNTR3q2aEpNElVPUSVIUCGDPVLTosKoFOY8rsh94Rvjit23Kr FgWKUy+WjDTS1oTIvLgWp1y3AOKu1PnXert9OlaSfp3LxgxUNqBHJbPUC7PUTepxI887cmWoqNxT Iltuo4Ckoay/SrEfFYy1rrks5ncJ8qaFXDG5VzLSCG4T29Fbj8ntAghO0/CW5yMAOJ07oCXgnQJ4 nf1SkKQzyjzfHxojyS2X0DQoCZdlQITtBC/HUzfySFFXD7bZxiMNxlpYjKxSvNWDXQagP6a6kzZe 7Fd+WxeLlf38nS+WIDISTNGW2rmXSkYaKSTX+KW1di4reSiQNY7HTft40AAqS7FBEBkH1TovN8vO i6md6GnrRVH3z4q6PUkJypaFshcN+Z2ScUZW29jd52Q5qmLKTpUKeTMXzuq763Y9jBZtFKC+d1Ge bdrKBcD7IYQEflNW+6RwJxBCwtFC5Qq1Bxu8ArnSwkoTgaxweBJQIbc4pV2/G8RDKnenY8rrJVAM nKJuEygCC1EmY3M/mFJEEaiYckgeWzw1fF+s4wkvfKDRuFC9xQoQZVPdXBZTAzHO65qQ7ikV7Y95 sZCIvRxyQMvCvyJnFnqJ8rsEUTCZyXMvq+JAjDVeB8JE3cgos5FCxY7iYzzUufI8157f3KD1hrq0 KScntugdg4oOBYTMu80lTYY3ptir/lKuISi0DVvegbFhY2RjDyu3+eIxWctfxEDTMMJeOoQewIJl Bbh0K7xhPLUqyOVoSQxk1jf0dLk2mpMWkq7jmA42Zr0xA63a4ntkqcoMvq5FCF3TJ3SnlE4OOWVm 282fKzxQR7c4L6VwpeNOs3PJ4oUzFZQjO/EoEuPYIbX6l+TKD4tnap6hNezLwv3CrFKTgpwduW37 6iB60vfnI0r1SmEw3QSLaQTjDJpLGwyitCeRXZbcJ/7a0hJHoT3vlS324hbrSYCXtrQXpSrsFgFi BQW6XQarttQyNkeI2A/kzkt5lwHNfNNOlsBY7Edsfdgf8mF/SPAB9Ifg86TUCpnvAklccgQCypHK jcXO8aWWTPsmkrwjzw/CQCbYZKxEIHm7GWGJp3mXnJYijV9kGH2yM0ogdA+WMDIqD5cwTJVzwgMM YHOZmPnj+RnpvFlVdhMzZUetfPWQa3muzGnX9pcmjKX5TLiyAjnZWsJkGUrYU5Edaze6HbkIPUpk BbS5gZ1WowPGwEbm1hzGNiWivHwlOoQ0bSlXaVLJz0Dkg6YIjKhC2bObDvu6RZGWhTm9XHlpZYYl Zv2G5DYGo5nOktt5oaLVPrP1hdS6dGAMnEQC5p1KVWXSWYsXNLd9MuqlJgC182oO1QMZkh460wlp agTKjdAJ/i2W3wdGqX9ozca5yBokcepONbkyzKD1nWatnvt4YHgp0S9iMoXqcLBhTsgHs4qs5JVQ U0tAxhtqGTTMRJYjzTKCKu1nSYei/1B6hEoAvXAEhZeOJ0pxSj4DZyjdFLNrtLHQB9L9J5Ui/TPw 0k+CAR9qPgd2iq7X3+z1Fxi2QMhDhmBAck3MpmQZIPXJiM+LkmyShJ5MdYEV2muggz7lmnrRqaqe FtsohJFkreDpOAZ2vZJqhjBcEzJ4hTuf30JQbiFSxm2wqMytFAYMj+RrpyoLqkK5p4hbcMRXLm9D uQqyhQLUTryhcVEWNfQC3cB47yRzUFuJ7EnzyVSR36On0YATj4QN7ukkAEBKxwmhxSmT4iRFgrQf ZJPYtQ8JNTEOdFVATAuocdjzyVKSMqehGJmlSI0C0AF4IFQzn1GrIitmmhXYwOYUyPlLYV0b1txa eFBucz5lWKN/O2uN8tKxUPFNMVUgMly1dXElc2vGvQA+xklkmIJolRhxQOV8NZ9eSaS0PQ2DLC2b F7YqGiqrJdGYKJt7FHZlmXwcKsqGkxeqpyfXbQQLQt3YRPAJhZypDCXnciSBNpmRNUuCwAgW8Tjw silsiVuEZwNTcPIrENmOpMY/g6S2FEmu+ra0X5GbgqxZfM0Wei2z63bSmx64eOHt3iKf/H1tpDfN KGJBI/2TpsO2sur9hQf7LPXojCkpeBHKETdGEK5JwfxSlz6cINLOU9MIsNo8MeNbzx9Lco3JDJVu DnE4LYYV8wcX3ij+Cs+oYhOQLKRsmasHK0oLnE21R50rdOn7LtriGWxfEkr3Re/yVu3icnc6Y/42 HHFZXxrOEp0voFkhtZHQ+SuTrVvD7TJnxQhdtl/SAqjRK5w/zc55fr5QqRBddmNXYefzhlwlOmUL 0cdkjcW8sJAxFLKS2y39+mnC08ynzEjRtbQCLppFreAob9u0IzFlpgulHEGVrkB2EJxJlpZnKzIP 1VDuFV16WZsAvYoauQzTm2B2r7BBWh0ezO9oli+kXTFKzGZDviMvFObyipN5RdTKv4XlKwp1cOxz kwZJSue2+l6Nupsm4CD5KcLaA9m7mdDRlw6x8lCH1L45MRZFKaLJDIaSfKQB4VMaiVzvhSw6ITso n44pO1NyQjzokUzLaW+UAuhMv0v7LmPkxa81qA0+isMwPiHsi+VA4paaLVMgIqviKe5lKDOVRLmQ DcWdIJ1xG3R1jky5CNRSJcUgzzVuqH1SaSEhww9fZa3I5h97YSDhw7B0KSTC2NtbOt6lWpuQiD3V eqsEEs7RKOH6OBGfhyorUa4FCS9pFKiCkXKvguiY3IqRiRqh9kWg4yzSv9OpEkl6NokFZVN82r1s dfHSSmoYqNQPx95hzde4apwzQPu7WVyYGyY+IiA1Ks80SbaVMWxL1TgoxN+udTuNYoZ0qtoJ5MnK fJrrlAbJnZZCluQuu+SJwLfefrlGb79Yszy/M8Qe1miy9nszGe5jDji0swnmoULpGTN4aKl6i7bN OpHVvT+yxH3QdYNyyPVtduBJXS31V9a6YhPSeD8IaWyza3mqN3shR9Ehc+bUmQ1KutWyxDlQyVTA btFRvquC2RsIY3iqHbIbtjMqgQ6VEg3ZPoybrDppFnTqjc66ArJ4+oM53Z43clhTSFFcWxKXT2Re Ps1fE1tDDNOzYpjR5RJdnZV0bW4+FGHudunbYYYguMXrkVLGohsPFYXY0ghSJG/WPqbvBUE2+3CU b9hON6E462JT+WU2US5BFmlQnriQ0lEWVzsuEtP1fk+5RqrN3OaHTLUuOJkPoiO0ZTBV7fzdIKJh PqeZ7UWn6m7i7Fws1Qyvmgh684HeQn91wduGdFdqLpwn8wZGz6oLGN4Qbe56MrJ0GpyOq/FI1p+u 0hbsKnd9ng319TZi6VSQpF2ZS00oFwPHT+UHQ9ntS8kV6fRBaEMlbOSCqg28sNu/tvP87t5FM3LC 03E8VA7P+FRI8tXhNp2Yai/ml9FcvptLiG9us8P4NjYvkVbt4choPTAZrW22R8nGYDAj1+mzMw7H dI+S15dmgl3Y++zepYdhUrdeW9Msv8ouB9RwYVMjVZE8akce5VYu7+31LmqBpXT+ujr2YX7Z4VWZ /RKL01D6dpYl/QDTTRbTD28yenVnuRPy6kNyhRRttu7LC/wgRUX7vaUiM0tBseNS5XyLr4pZtNWq 1XqXKCvtbqAVLjMBZYfqGiQDRm5HnRit/NiFazu7F0sdK01SrdVcZR1WkJS/pQdLZLmpNr67mTUo GWAFHxZhjUdHWEmL66uZg31lht2E/bbyQjnLcgymd1AUiG3X62tZ2AdVBqF5pah0IbJQJw9xLE9J MccqilGk1uEuzAEdlK3ymGGFR9K3VTBRp8KY7H3Hm/Rij+TnzoCyM4j1+6eIge9QX4oCuh5Boewc 9LdqtjbpthotyCWR13hw8nbtFBtXFUJlTxQC2oL85w2MkGYeC3D5fJqKjCxJlfuBUOXmHDykSk9/ FlCm1eb/HPfaks7m+0xnm/UKCc8ClqxZVMyf9NbDMnWNw77NCq/nEfmj4qEv5moLGVqR9blOS5u1 6NzlU1cqB9cP9yFOd9mcVNNKTVIov++q+2I25YngQ74AqlYCVbM6N2WR98X4hCNs2VD5y2XpMmrP k4GQ3VO6ob0EfhzEcMiyRFie3JOErOhuoZwnB6u4nbiTXUMa34bVPFfMop1RBLTIBxQO8fCKYHde Edi8f7/JsjQBwUBgSBOIoiYo/AzOqp+5WV5Wmni3uSzAmEgzT1Onsu6woAlpG8JvG6DsL5Pk0M69 bKtY+tDkObJBqqJQMV5gdt/4tNkN2f5z5nFewriPH+95tAySGYFKJf/BiIrl7FcWuPrWUOPO2be0 22e8UvvRXvZLFLv0CzLJSArAopE96/dAFo5d9/eJHjGv8iybzbFMKqxbSlwooZ+mnj+WKtgQvK/K UIdBGvI1fiDpEa8BwTKoP/vjHmYR5L57Rup95b1X8l/NmEjvfo0fZXqkZBeCukplp9AgxPZkATc7 hebvF+Np5VJIPTHjWHK67EegKvTqhrIyqg6/qhq1MUeyhUtVcEAjpoOio03dZjt5qU7MBrpbQxcA 8V8qw9CK8R3yksK3N8DdrIkmMMk3+Ys7QvdDy8IAtbnlSBfi0oaOqBfUEiMrXlRW1H2eZ2gVMCup qkyLaSx7flSLjGkOykZuqYW7jEGUg9EYVCdYf2Rewkrzji39HpNsD6VunER4oWpB+H/2/nW5jSRL EAbzH3vMCv0MYW32rRHdAFIkdUvl1JgxSaqSn+nCFphV3TM7uxYkgmRUggh0BCCKvbsPsSlZ5nPs r3mUeY3vEdbP1Y97eACgpLxUFqtnqkREhF+OHz/3C3vojbMVsgOg+gMPv+dzugC4EK9WVmp8nOJ1 WrFzJ9MQdHgXQbCjXYFuITsaYwLMmAyw+gJXxBkBStKCSnaIS4x3OZsvFzKRVh86IRsNynmwOlgn R39dec9zK+LDTeNoLpQCggBzTWsDPy8GnVNUAh6lXzogjyyUcERfosgnG3SyXY6KkUZEwcscYtWn cXxcod86nMhD+RvOwx0cRzivOQ70VcNplFA0Ch2sAln6CurTjChkmtDGCNNSVEw3h0HMDkPdQyIc ZAKHQpqhusxrfoSPn+HwgTqMR6Gar8NAD00IR4NTQNu6m+/9cv6B5NpwBIqnbkpEcBkIvNduMNhU w2t4zOG9eHjHY1pMysCG0H+x/0rEVA0MzjlOnstBAB1XErcEvzWIhDZPygGKSgFAfgUaqMdSigaD Fc6Kq3x6IaeHUy4Au8QoB0V4MPxg3hTLSTVzAhxv5on56Vn2F4y4y5OhqBjAMBP7XjFJbbkhKpv8 3NHBwq1RAhycxkBAgODRcF0AT/8DzouBsxj/jDSP9hkFpQDme0HIwfDIvAu1rygCQ5AVoMh33Ey2 7WB8hdEk+SybDXfSMxPRTQGgP2qdD5AWOb1J+7TM5Bx1f2jRa8QxxoA78/JcdRy4LBiwVGQ7Dmb/ 8A//iOf5NAl8vuFyFISOHDWMOV95fVYuMN+H6vbA4gwsSW1MbFcc24y+UyJs+Ry5BGyQ/J4Lzvti 2I8l9DQP6U7jx8UgB2BcTRHQmPGr/+d3r45PD/dP9yVtBmgsbF3LZbgP5qT//AIQGGRnS5P2I6HY GJT3tpiVQPau22XZAit5GJDGOQq3A7iyOHD6Qo56GUksDxLs/1mUEpM6N7s9oN1ih2AzdAOZt28i fsZC0o6v+eFnxI9oTocK6Uhqc7551+C7XMgJ93ANQznwuFeyt3ldMq1mX2DBAeYw9dt8uuRkIKzh hBS2Lt7qCYCPjZ4U7+YlRfrhSiblBeq2C10eJqedgcUVoXo7O3c8HgPi3SJX1BeN6of2eg7Rt9Tc jw++cw+2tsavxu6J0T7Ue+/fwVdi3dY+PzHP05OchJOkXuooYdrrHY2/BQK2JX4rE1CdfUsV2BLD HcdfBce/9vM3h+HXb9yHGFuZnOuY50pM0RF7nRrmxfhkyxLtNCS3xlLa7JWUNku8eABvHkiNto0+ OYFPTrh+2kZf9P4Q1I91ws3z46395eIKUmzI6vMcBTbQykG8qeqtrUO3S9Ky1OqL9iAHxsNjB8IS 5+c3pBRIUcPjk/gxfffq6FTRzyrIgJn7x23MNLV7jMUL8Hz/pIXnYpQApRzhvx8gsujq+6qrAyZH ZXJ7vcP9LS6Thcxpv6G8LAeNo8PgyVHjk7YR0oAQ7rXTo62OCKatraPxlr8SgPkpRNza+vbwxcHW t04YZYqow4ujDT49fIUfX5KQMJaEwsPysoTkdobO1hY4k7fW+ZwdSu9ssZ7n/r3L/951/95/tUWm i30wXeiwL/cPtsiKEPoA4ckr92QBibeQODeLPzwYbxmXXGDxpkJR7p3j8CWrTiRN5O6T1/qJL/HT 8eob8yp5sRwhvirnXR+8enFyfKj4FoWsWcQ/GZ++2qL8+GzsGOM5IAc44uZXkKmkMHg9Pj7aWule MFV93bAHx54lMJzDC/Gv1XjrX5e56LaMDXALzB2AP/fPT+ytCO/MP4xfHR4Ez1db8/CL4/CLdVY9 t4g3Lx1ldNdAmflLtwZ3GO4RrBcexUTNPfrzwZaCVIq+HJBO6OjbqvrVH2+k6hrxWa9XQrr7IseS CjWLR+K9A/NQAUoYJETlgAyQDEgapJFDLtgedVHWTkwDOYOSBTT+H3yo7DYyKrEvEmzmgdYN7tTL C54KnEMqwriDmTRZvYSE1ssCNBFSt2lieApCuNu0w2snMhYDH7dBr5xf5WD9JxkXBXA4ngUP7KR3 3KaTdewGqA4GZJqvWygqSrgMOxTsu9dDGY2ilgUgAwMCzfI3c+p0DoOmmPzv5n0/qZagYvzHsnIq 8QcnlHVXLW9VJf8I26GKzVBcA0qNUdpOUJ+xhW2YSGMScNFSYHQc8ByCaeoVqokLydm2IjpEkoO5 lF5BqTR4SbQP1D3QYUGvstbYcUm8toKCAEgMt9YIYdwJPvX5rLit0GcHSU+g5kwBAjbQkX2LKLi5 E1mV/dgFis32TG/pZoN3qmV97sdVoFrlSw0Ebg23kuiBUuYUaxTIx8k0TJ4dP1pUN5SK4PMmE2ag G0mFbK+B8pTd914DoVRPgV46DzWGHrjyTCZsp8LFJ4wK9Tmp5GgR4bWw2qfWbrTTaFq0Tw11kBv7 UeGbljLYAlA7uxNzWSPrteqB6Pl2c3FuFhsLHdl0fOLF7uvZ9BYCfgB8oHC6/bw/rZfFhwHdYmNc JAPTktzH7niBSstquS5GZk0+Z25FKVuqvAxp+bSo1mJY7dWK695SpvQ3pZFgHku8CTBYYWo13FI+ 3mnqeGkQMppZjMCbCnjLthDkeYF0BPOW0+kSXTJEVdme5C5vqi/Dx5BNE/V8d9KZTIgX3IfhyK7C fi87F9bDElMMYhCYpLyzwBQRzS4d9s3xV1Qliklw/73lCUjNgBPngXOdF+qcG+5JVv4KC1S4cnCh T8ndoIaaVPkANTtyNRrCqUZT5sE4rfQMsaAuGKXe4kouuV6mFjBILXGoa+z14nIFdtm0JDGOX0No Bt4aswpJ2wYJ2RO5HHPuwLpGvw0EQx1OwpUnK4vnsQ32RIP3tx3Am2n+tugHdFvHC+2NbCwIDft0 jrNbEQxk8LJg/hn9CDV/sISPjmL4Q35dkVH9uimmbws4dChgkqM3JHWCbfgRdi7c7fYkAuq3OeIB YmOTbS/JLOguwPfFDEnlYlmDa7W6uACWy4D1YmQ/wkwoylVAahlEJmGMbvkWtoELcEueGNXX1ivT JASIoj46bPrt1aM3zeg2VV2S94btlgjVYDGQIYRFLyBu1Wm6uCFQrjQE1a3ocP2KbCmmcialfwD3 bvJbQF1Q8hyqR6ewPcaf++w1AjCXYfU6zKtuwZTLc5MuMIUCCcxDVr0M6HqRl1NHR/sRnHM2PjjI 7q9bDMpA8wWb0IHxaI2Q5eUVSHw3M61zb8yZrJVMpgXdEilw7Gisr9YqsxJvtHOjl2GBpg4AvVk8 ilhWcWfOD5kMb+H2AnncBvfHq8od8o+2Kot6QYp3QwpRnfi04nFDfrLDfXVPZsz/94BsrLpbZH/N 0seOConDYZxZ8nJ4y/+xdNdh6kbFjPylQ1gRGfAr9UYQ3oGUAZF9txkx3ux9ONWHXg8SVZuIX+LE C3bysmunQ7X2UjaWGBNv8i0FzEXOAsNSBqYcz1o9P6hipEI7UWs3PmjttdTowsykuLCA3aHkKCGW Jaf2002qQXYlAYVSDkklXrpQvWgqVsD5p6ESGbP5UdQICj3txKuD3kcgRt1AxSS3NapKgzEZyYAU 8ibkxgekvvsoVEVULHAqnlNwgrttb51G6yhCQ74bqVyUiIgZZc+XNYidwESlchZ4h2tkZRcoHaN5 oV2iR/VjWGo5kasYFLPieoZ158fCp6m+kB+zeOdgwtGs1orlPlULRCSvo+RxbOoRRVW2UNXn0rJk cji/Ep+YFPOSQ+wqVgTjAAbUrI2kN2cIlPhNLclSfQW97pUpG/dGQ1ukRu9JXVyUUK5RYn6wzBEu wR1oUcLZwa1mKd6bNweZ5sTQvV97FBlX0gFaSLNhHVFmenVFkmoEdOnehNECJBDBgjPJpJeisE7s Afs6jAyKO/xbuYKDixN4qRoQf8779KE+UG0HyQu0HUJJyjMSmbIxkcwjDiJAvQA/Kq0qhLer7Q81 lGW7GF2OBlmSczpyPvC+0P7ArgKjqK5SJTAXLGhyNT4zl1EEDKKwbiqgRI0ZYIkaKIJnAsUnQOQB rgiD270EIN7GwJ13OTiEgIU7MWhndyc7dOzNn4IT6KrrgmQ/LCwB1MQOf3x4LMKrHb3PIn8baYH1 OE47mXrW06q7pCXZVPMHhy/UaczDe0NxbL7oEkY9GkexhDqRMYa1pkScIuEbTu2F8bksmcOAUBpw j1fYP9pzo2i48OHiVHfuFmQtYpDx5vsElRybSgGvYQMUiHhLDYOSjW0fLxjJSYiQ0lcKylaBQDY6 cdRgCZI9CGYQ64L1RSu1eOGZcjgEsCUDt1HfHS/dpk7SS2q8IdSFL9G3QjGHWSmMm6RpKqRZ2pr+ nr6osJacvFKzkarfga5KCJwwSY2yfW1BRwyvReM4WAiZB2Gy0/m+F4nHRIoNraMoJgA+2iyHvcDn UHcUgjGZ61sLUEkgm6oY+pA4CYELqYxUrFwkmFsLRkR3G6ioBfsBxXIK5Wf8zbQl9qBoMiehCJEK gqWZFmIJBawHp7SFg+kkgm1R+aW1IYskDkIjvH0j55prVRM2RxFBNoe0X6RIPmHZ2FHY+wzsKOy4 6VC4s4YnXCT20nFk5xqcFa9dQe7mBbibSZ5N2TyxUg8WujUMgJJ30B+IotOT0c7oIQbLlk14q3mV YWlD3entD42EKEkxGIgSmzVLsoosSM7hQcERg8GgoCjw8porUMQMTZAoMaRIF9TrhanqORXuQU3L cICCDLuenBLVbkxpMbHQayD8yGf3JLbrdtW1YbfgajkFm5UIvLjNaD1VGDfVAX73o1sqFqimE0CN XgRIrMl+sZxOvUjt19oo+8X7U/pSsgBgRjYWa4WO4OE6wupG1BsCJAf4brDcRUXCl0F+ET6IqrGv hbFWjJfYFDK1KxUEhWnceoig/UzMcQF4REHTM1M7VRMuF2QH+dR6cM6DamaWmbMGzHJsKcFTyfvD NrpbnIakEhjLQb8yRnuOYgVTj1juH0mdO6k3hrqGNAnY8H7xjOzegRA9KBY+rynYU8ihvp3YQfbq 6BRVapX9BGO6aEwYFhejNo5Exa0nawcj5rhcNKJwIgsYrWownCxwG5hSjKGgLsIaq2AHQ1t20+vK y5FpwzcOU8/dKsFrasJ3U+YKWvC62chbeIsXejhZOs7xTsuC+rBHrf3miNk8L2tigRIRb22/tyz0 +KnEsCtxTUbEd5jaqqxiKkVSLK37+HoACdTFHG8wHvOlOxYUNW6qthXd2vV7PcnzOxWbugeJJilK GXgIB4psVQP60VveCRFbRtphwkor9YGtkRU+RvsqvtPHH3omIWjF6sSlQQ4NEYEekwikCmsZllcW mw6L7snwb1ajHe0jhpike5zE6fD+8ehJzKfQUTAhq8yqe6eZjKg66uWNdkbtReDfg0xgCMFVA0Su Myi4+bbQAPWJW6Xb4RRM9qQmSIX0IIH9AhNOEvMkXVl+YnUkPc5e4orE9ZeeGzkJCBZOYxQV0LvP 1l5HvD0S5zRx6CumLTIktIiNtwk3dG8x7QXEd0y6KKUIPgf5VBdG37esJPQe5eKrPxqzHTco3juW jVE5bjfU97Pqxumzl+pptQJhXArWv5HkbKmy8kNROaTWupVzCjKMyQZz3HoQC3DVrceFYD2Xjuvo 9ElX1rziVhP+VNu9FZ/1Mug44VQZiOYhEKPyAhVII1H25OCYBEVcI9RJWAjf5jO98K0FbbZ1So+n z8n3wdKtRBRBuMC5asEAoxH4yzXGALzvQIjBRcKGfwKkk9AuSshSAz4/pXvN66fpcGcQ3Nh4d7oh Lylb+qLSWJKaO4NgTFc9IxsE27TY4gaYOTwHeXA5y9+69YFUPvBLRwEOXrvAlD/yytEiJIAKuIa7 obdsgMXhK+Fdsg1Wdq4Kb4Mv6hp5DibF2YunoSPmdPQheykpEIZPNvK8JUNPAMNn3sDn3tfXEBNu UMhHKXhWFBMlgk1xeU1GePHd4uu+ecn7WSUv4UwQlnXQaic5SrSYDJCpLoZEGfgmOrB3lVcdkaAS xCp0iilrsOU6b75fhczrZAo11pkXy9kwMdWIfarMcx0BHmaQ6h+2okiRBWtn0npSclNNvphfwsDq Vb2eUnIjWqV06u2GGpvZZvPbRdP/2g4Bk8YvwOrVEZFz9dZhbPnp9VrbRTmgwZok6xxZwsnIxxKm SkscGpDgXIv3BVAQwue2oodYUnw7y+Ful1fVHFg8/M9FnXucTlTzA2pEaSrX+bvy2s2HyR1ZU/6n FhhGl6t6WslhLG5luNTAZNc6wEF3eMzZYdlllXMCCjU9c3/BZYBYxz/RH6siADXzKWQylJ4YyGTE vHweMZ6AUmBaBdAcqF2i7MZbVyK3F8oejmphHk3Iu01I9LXjCWxTecaGmXP+cVr4nintoMNse1wU TvN+xBq0nbo/cFoPFmixGjSOr63NHAEz3avMawP3qEbh9qMDImVt0FE8vbqXYlez5RlphZz4DYBu m4JRegqVaDE+2tTkua1fyT7zlOcMCG7Cx8TL30stvtc7JHN2bk4N4rLmLJewtbtha5ZI5RPi0cKK DJeiz+oCS2WlvgreBdFQTBuGtw0gxzufL4JVwQ9kbDSRcXLqxrPQspiCBQYYLnzKkYP8maqO8wrK dpfstMp8VWuHFZQd/R9YqnBazC5RhD6GGNwp2pJ5yKlTFIAc6DH7YAWRu/kknnSgkbtI1/OFE9Yp 9AjIXVlhC0Pcu5qBUvsPvSrg84DjaRzxQIuZEF71j5DM7Ig7xm9DD0zwk3EasJBDmWRSsliSak7U 8ukQAzr0fHbuhBG/+4cduz8CKJZUZoBIB4Z0zn2FRRj2uriunJxW8MsLPAnfuw2DNvBQ3SdvDS7I KQEXuCryydrlvKnOlg0fxrFKiGzTQvsHZoiiBOib/UyhijjIl9yGr6Q2ctxmwEv1GOl9DCg55eRw R+BqqFhQ+Kh6MEuCWLkec8bBTWnoL7YxY7UMLuXukOf9ZVWx6tN8GHgz5wzdDm66JRR+SqFYVds3 kLthTQHY3XLO0s35+bKGBcXOdREYn7X97ugDNPLkbcpqBt5sDxi9vqQ6Ue80m41w7ujfQvMSaLcI cHTpOVQxgS0k6K0MDrvAvdMhQhI4VMeqhS05RPTsrlkKZrqTb4hrLcTxZC2u2WI5E6TmuDP3fUVx vsBT3E0CFdYeLB8W2OYBAmVDdm8qNDvgzwsJs0dbHJa1B8un2wXjKl51sFO4GyFuvkDHXTKpQfov x+yR8GkHEn4LsK/APCTrZfNSI4U8rst3sY8s9zZbNNENsjAEVKtqlXLcPuRklGUiZPhA0no5Q7jy lNiHF9KPC4ogDqw4JMe7tz2PEA/fonoWGoQGumWouI4raXcDk9jIIf8t+hbIWD57cCwhWAzQLrHi iHoshpwZjnJCFGMG5A6barbuywACSTG8z8mpUyhZHESqSfo+TPKW+3FacQUl7ukt0zm6AmjL18gD sLLoH8AC3BKy5mpJBQMwytHdauCptfCFAQgb+cSxU0gtLTiJS0qCtDRLb23hXHDHEJYQeubwnUZx A/4ZlPYX2NaMo7ueZeBICl2zAh+u2pOhqk/N0MQd0czzc3dzRPxyBwICi4gEy5ngBegGEs/Ksnjh mclux0nug1sWM4Vxi2/wbtKVNh5pdwxTU9tbQh+0UxlfafDxiqseM91Zg4TvQO1YIsUBmgJHIbEf HAMMZs71/OSQVUVHYZ5R/BwZH3MjSWBALZuLpDyzhKYPWL9BA7/TZhaOZ2NpFAqvuIF8NRI1MHRF I9qROudTiAoGPEDFUTx1+CZHfRFBH2QoM0mVbcTQl9BXlWTW22fizDozKQTXZcPPkfqy8QUr8Zjf Sy6Qg10oMBmBlWyWdG5qCCb3YtAAg4HfLUD3moLIeAOnTsYovr7g829FzXHNcLg7bmeXKL5wOIM7 TFBexMuvRc6EWSCs9OCtWLdeXGDLxwFkdRQsbYo55Jx+xLOl6w+AyW9BVp5D3fOdfiYspqHGk2QG iwDtlanaXJVAsanmrN4iIRYNp60nOa5el+cNgHTpvnMnQdxBD1idG4YRQN/LW9KQhrEXNWgqlQdj 4tJTlmdriBDSS4hZOJlHe3mi2DgEuREF91gb4QJLYhNWRg4QGjKIEMe6TQA+IheuoC+Fkt0U+fc+ QjLcFYUWzd3R8uUj1rRs2G5+sZz6PKu5v1TYwa9BzoOeB7cQd4NCLzXLFSguiCTOQ/jvnVgHnZ9A dFSAOVxwCI+EAc0ZS5AOiC6YtqMawXkFchPVX+JAZ6c2A+Ogul5NYtt4k5hcq6iLd05BodwLbKao KogtARcCllLfp6wWhVxibvnNa2gTPHM0Z0S2HGj2pMad08BUw4aUQG8i6w2FGjFNXeVM1vmDQOUV OPPMLYIVIK9KPgtUJwe4Cu4I2bGcjAHppRy2oX6Fy6m74tNA5QVygkbfICxUlhrO4S2QMvCt+JKA oxVA/AMHjBv8T0sn1rtNFWqLuA0HvZQX9DniwRRqrV2g1w2NEAOfmTnWZEdPPmvPkkVFYH7sC++1 GHEifVJHpCAvDIVRRYojst9yyBH4CK2/wjvf2uOWPhYChLb/WOIxuNuDagoG4bmZjsZx1zkikSYy wnGeqXUQqhX26ejh6BEGcy6vC9YSbMQK+hV09IIE2/Hy8pJ8CG7qg4AqnGKGC5F44QdkT9uf2QVJ dA4fp85A+MzfAw0A9gPZBIAtqmADr20kL91D11839QRKAIAKG6rXUr9UMvN4cX7U+wNUWTMVICKn N6VVilrY6kjt4/VlCYqpJExpbIs6IGgJhZ9RFQivPEiXF/Cz75B/UsZpfd4LZwSHcSH3bYqFo2C9 aLvQ0FhZLEh/YAOq5QszFhNUx5aNDtXrsW1mm7TlCYjTbtmc/4Sie9PnNoxo0PkaJJEi29kd7Y4e UlSX8EWrKONlMKFANLxWCIHsEagmkAPgeRqjhhu/QUJPckvg2hso7lFWlhvfYWJQ3V4XFudtsZtg n3WK6iYWg8Q6AhKAgwaf3G54csbzZMCMrDiVWkpneaJmYTw8tJbJ6aLltpU4jzoV1jdqFo5ODZdz d4wXEMyGXE67soP0CYacr0kT8CGy7oDNx1+31uDE1Wo6obwxjOVGJ65TuS7QnCWTln4lyTGorIJU oNPv88BTBoOFY1FoVRwPLuEN7ZlEkl74oO48GYoETiHkCkAcpwtRAgAXptAwuxHa42+/+do8LDlP nZJSS7GW8+Urm1C4PxP3Nwk9dMB0kox2b9Tz7KblOgp+Yh5MDPmXdT4hXBuapXFF9lEsprDKDSB9 n8LtDwONDMpnzC7srZUdOHqeU3A7V8yTMDCvLTkyXgzEGUoyNqq/DQ8LEe64HJjALXFZZ7dFXjfq vMCLZpIYoKz9gjgp2q+8hZKv396m18+H/9ibh/4eKsyq6emkQ7Lw6sOKNdyRLS4im7QDbcKkdbeZ r1cdyQangZDGexxaJQHcoDhgI3X2i9Ap2QNsHwhEYOAJgLjcAE4BxHs9p4X7ctBASMCvyZEVJdZC GkQvIMtmO4WelD8kRW6kHjWa8urlbCU8NkDRnwU7Z93Ymd0dPXnnoDuI6e2tTyN9q2gmKYAkQe0j xZaIGRubye4KQbFvkBIckLXT/TiEr7/x8ShrBsgO+Po8zMKDaKTqGdqIgoxdVC1EyOXqjOGdehaR sU6q1SZahOeeKL8S5IqiaWrBpAWGb+gM/I+O6LmG+QlHkcNlPke/AgwOLv2nXeHAyHbSEbhq1dw0 BBeDGrGcAFlVMWQYA9BbgWW5MZpqrArvgdXEMydAX0xvVV0EZnA+zaHsFrlSMqqMDv/i35+sLkm0 xPhqu4ZJYQqlk75phVxKx6kurDpr6ki7FfHEj5KGcTqscI6SVYcJaf5TMhnmi0QcwwAI7DnnedBS yiYM6BfTZRCOqnnMVBkHgx65hDxBV/WcMpn665FKXIU28KCVDIH3qwukcG5XgAtxPeE95uLWUHCu mUDPgF+GNdF7ve/m4Ezwf2PU8BM6cZizRjciih5weLbhyYG7/2Ilmk2CR1rhEP7wOJk4jxFqURIi p8tg2u9/cLcNCrTK+ufyu4Q3UweFfArCIVgW2MCw4PLPQRhdZCwlF1LxrjhfIj/mvPGprTkUlhQK /QnmA7bpmHrvMIQtQB3bNI1llAOTU9FysEa8aPDCC1/xFNTCM6oUJ5l7DWaBIx768/AaZo6dY8wQ vg5XQaxq0VEhW+CWY7oZGMnQVVgALtY4KtlHeC6gGGNyE02j+mhmoOzH7KsAgfF2RzuE3mKYgnfN PlEPrBB9ncreO8JzNJJ4qw8A8QsfMhF0incf/Q+t36+hdv8TExuabJviVcCD5lsQ9G03I3B1FJrZ bxNfDJrbq4Iu9B+znQfuvwCb0DTNuzOfCIq7qQnM+RQ8EJz1WUmcKReRA8X6LRIzMUb4YoVlHCWj jny1AbRAtpRkQlNkhNcY2puwLEcYIinBJL4yQ4BcsGdrZjJm0ePxDzhr/vUdRzEtBAQAx+NBVizO R+Azapg7TPj2qEEDnHsTe2jQUmsfE0c9/Jh+93qtq6x3nRGIpTk0GYClgWdxqLNEkxm+L1Ztm4zF LlHWaiG3ArbRDpxw+sQQ5Sp7vJpySGjIzHQHas33qNw80NJduTodlLTiDFQnSrH0RAIZgCa/zBPt DLhsf/irrCWVl47YM2G/GvlOAoBmvuYk3iXT9EMPlQ7SMedLuMDFJCaQEDPP7DQkFX5X5m1YRLuO sxJIGDtiTNlP2cOQfoFPd4rR7rPiJh2mF9/AVpeOn7LHMbCTLy+qbnINXcae4ChPMwCBtjZMB0lH 0CFxIWYTeW0bIuQUZIbCt7er2pAh9rdz5nVZTUiY4lwwDEGBZ2d2VAi9k4pd4QRt/M9ZpNJcKpwX 9YiZOlKS11Qzy/um3mVqu3oEE+FlK9NSpEYiKFji6DFDsEmKXxt5l8RmU68rzI/sjNyM6cNrLweT HGFJ+uEf8LYsA+oAZg1y22rhlfZp2PirArAUNcKZGwoUY4xIFTU6v0Y9yioBcYBe0DplRALgXoIj RoSLpWoiVjY5QSzDQcEkqTTI+RDTHB3GDG0bqIqFclRFdhuU6ioRPRh4t/cJ14Y9wySQISzbgfzH 7FFIL8KMntypr9X3YNZsCRA7fbt7kfxAdIBGk2xJ8fH9mi3tAAxdkSz5dC8DT4CLcOGHRAv4ZQm1 BawLzl2qimpGzjwRhh6HO7vZTwPT3oaiAHztFZxHweHef8hxA9gkZdqoRwgNUE2zBGhK0wAAnvtk L+Ojf6iQNufeJseSeVwuuBuUId3GXkFZKo6Fi4HaG2fgTSw0zjKG0+UOI13uR3cFzRkOjChgqXOQ 7A7ZcuDDFSXPL8tUjFOAyPYzFiEUiiis4VMoEkOUISBy6tkTbUK+1InZVe2G36PMpgUkESkGRlgn NFZNaTkYD95WUziJvNEiZieUQIdp+cSTdCVYF0gW2lb2YjSEGwJU+clGScwg7pCEI0YO3oKPH0Ae 5CuLeKnPitptRZ2ksOuw9zMNthhy/X6fxgKbSJBEqbdKsvPQeOu9XNbKA517rX1m1wuDcA1FNMWA XUKyWdeACrzRajYFMU3opWREkQIAGUSYcuNoufseJPlmIHmiUmFPeR4hBJTq+L4o5sR9eLFBHzFf VO/9i90P2faKmsuU8uze29H3kmWRsVzhglWW1VWcIRYepAxfBqlDuQWacQX4Syy8qbBulG5Pvjbn 4WMWZAH6cITeJjrGhOEl236xO8he7PQjA4z/PXFR9FlM9fRBT9gCzJkQa/xR6ycJCSR4q6/d9m49 09GvufJ/4onMPhbrwAmqrV0v7q560Y+W4IAggwNrAiEj1iBak6Q46MrP+z1ws5uaOIDXcXUJh7FY sMJcDsB27HoELJiyRrL/WOaS5mwL6CgNX1lIJE7ngmVCt5ZQ2wulDzbpBtbFH1ijoRo2S45hg2Je jn8DPXR8HxIsOOQJojU0znP/+TENusAK1eFiDscnbvfY4p0jtpBWMVO19k0AqQdq1mgD7wuUHxzL TYY9haUKsXU12PcnbeCBiEqtrXlvWJ9M7dk7UnMpkAWxAwG8j1t3K6fqe25JUoxEFxoVwWZB4KFU ZoSwtkJ7IADlp2LsS8wLfEbRwLz73vFhb3z0AkGySwf6E1nGxHOI4/R6+7PwZyBrXRh2K4ZAVIUu eFcYin1VXl4NCYjgTJenMDEmQ1EsB4kOh6QQH73gvdDB7dEqLSPoKBMV8mdqYUH8EgjtjU4cIZKD aOqCMXs7Mv2KghvnuN60ui24GWW0FDaLaEEystuCJylcSRmcMuAjLJ2ZrEdgAoTD4YMqLCKGg6Bo pwkOnnTIDEERwi5aEmCYph4YcoD0gF6dTVrD1KYaoZc1E4V4YIagBpgUi28KMx7pMRzrhP6jBZUr 8BKUCphCcTocRnT1ruEvCAvP2kX5pLyQVgiytbkg5b1gX54ihV4KsjrC1QByxBXciCgh4M/La8xn uywXFIA+e+bEr5LNSYd4PGp9fJ0dHhwAATga7TzGACUn2ZOHX0bisWEylBTAvOcQYTIxhkqa7eve BUePssnGTXbBNb/WjwgOZjtksBG+l5BNr6TU3GtOoo8fta63/QYRyB4yA8ULqVBuMj55E024OhjV zQ3/YYFZS5rUQPtaRI0a2CAO7wAiPs0qd4cd2LY5bPxt0WfjY4xCxTXQBCJohgMx82uKKYYoaw9k yO2QU3JLpInJhNVh92kZ0zmx0nLXstGd8Ngscx4far2T7vHIR8VnyH0hDyUPNfQeQQ3EwBqPTKL1 o9PnS4jvmAcVztz/g9rzFG1DHRl5MZSiAnPUGh4GWIlZwpD8cpq6vD6tuaoJk+0tRoCO9cJ2EG1A QimxJ5KKbh720RQzBqqmPoPvw6F0RhRxjEdcEWLtDBFx+FzZZ4NKXYN2rSG/K8fEpmntAbzwZUng Mai823i8LO8k0kUEmRIaR1S9gbrs9m09QzoPsJagG9qJMNtT90uf8N9eVynf9hTPQq806T6YTYPj 4fGeY1x+wPfFJV5wOTy23mmVReB0PsxaCHbtw2hm4CGZSDlkzKYMFkcl9WzhbnYaE9NGXdmw8rQw 4QFTh9UbY0PvuvJ04BSmHfJo7fKS6llfeAlGIiqC99HW70MxSMZwsy8asXVuoCysFF0GWuWl8XRH Cnd9BPmVotOrPhomiuI1Ji580QYE3FUMCAbTN3acriQYrYLgWEgnQJdWmdtCFNdaquyr7LTyLMfI Gq0zIhslHlFSkkddRrSqFt9D9haEnJA6AgcjfBS1Cvr+nJrJwdfUOCgQw40FiAfiiAZZfzsu3AZn 3OXcSPDwDDgAiYgK7gSSSPSMFrWe1Tzr/cM/9L65pTWVZACOvuooB0vVN/lwfEtfq7PAkc20bxAm 9LEfBDFg5wGEsrkbZAqSIUDMVokEoNHHl5+Q8U0pdPB0YNXqDFuk2VVU6oDpZLdavw6qfI0lvkjj RRemA7wbnQvAOIZUnH8vlnh39CUvH2Tuol5gy5u3JeZoa5omMwOTch6nV8EFQeHGW6pk+XjqBPcZ FL+6PnNfQYbV8eHXmVZ0mFW2zU+27TYEMu24HwzlYCYsFg/G8Vk8xFFY+paOkNUSOe0YH/y6iNLV MREkwVxELFZXLqBihkN4Yu8wry+LGiA78OcUR80nQ57gGYNshcOsU2vthiohNRopFo2uvg1ptUaO O+4LSFA4gULbClxl7SGzBgqM15atPoPwUVyGjaqITjqqlEvBcHhb4EXg6eyfV1FiBDFZMd9Df56d htTEMPrC2F3Hz9COYQI1VHLyVa2iT+AW5TNu4FNeQMtP4jb+QttuCP7DH6K38igwAoaBYB6HogMv 47G4hLnrw0WtCb/s+FrQwMQJwI6jlkHv/oQCcytWaVzTpAm6UbFY+91nUsK5w0GRQrNJuuAQoI8f n8oBIKZZWw+3gEHLQcgL6fyvIW17whY42K45TZGt2TMC67zIz2p0GcJ4tqj5SMIQiQOXUWMWjlSl aZD1kkywCeWIwjOfYbn+WfJZJkVv4E5FN5nMcE1D1U9tajM3su3iUQVbH3q9mc8RQMZ0q5wpFcMg 03JBb7qzdKpdzK2rUyNB7GVKpumu/C7yVnWxKLBUgyP/kmWlPjbTXw59xvYWUJbDTM9Xut7Zzj01 Fi4CLiEdRGABKwb19uaL5dSkpIUS00i67PHr0YBtc5h6On08n9bwR0Ar3qfliEF2WyxEQHXyQ2Fz 0rT2t29UhHu6kCAysyA9s/0FN5ortaNJJPmK6FAk2M7ZLRWexj0qkiyIW4B8W9Fh5M2Aiv1A/Va6 lf5w8Dl91rqspBQMA/EF7i+gKhfFnQCsJ0skHjMwf01by/QSc3lBZD+YyN+kghkg9tpSK4V2U7yo KJm82xQpxTcEGAupIW/bSN3OqtntNfD/8JKIUYZvulDbzvfZQkPipCnkkqQb8M/rRGhNil4zmfTv lOQBwXRQjmKmOpzjZAvCrwGbNE4v13hDEvu7dhP36oAVH48hXFKDTrsYDGu0Wh/YfO8+oPUdH1I9 ZycYlRM1phdB9wg11Y1VRjacZiIx6Hhd0pyOxQD1lI5P3ALgFe/xI/EH8AhgIMqXFfEc1nDdsTyT MP0igGIEunKGx6wCKAnRdIleFIHsCN0j3ZcOtRYlS+fRFIw8FQts7czxs1tDEEtJXnRCpnp+1+1a IYkjmAiXioRFpIzrsYM9UC1lCy4RhiNQxwFE14bLaAqpUhe0Zcb+sFVFzIxxCuRKa9QMiEeJ+AdV sXRE6rrrxk1hCsDaFHS683oDkRZNyoEcHC/fPIvlWNFqUa5T+bRTmIOFM6O9MB3rkF21zGhskDcR LIuwMwpxJrucVs8eIXFi2sXyHj5xd9AmQG3zcAKj+CodjcmE9sKcvUq0RiW10K41HJ0Zeb5C+CV4 MWmfsd0mcYmVxrWUK6g+WEz4rjI3nmCm6DmDGSW7mvitXPQrYaPH6uS2hvL8EnzK1awLNDT/QAk9 9lML+AbGz0d02JarPUu0xKPLqcac1CDkWdV+uxPfZ9duLY4+wMiEhiwmZFBJewcUsCl1WcxDXh9C 7gNfsoOHwztzY48SirCHFzcNlnzqW3nypyxtEV+9KdIdBEFgwVaQgPXPfXY5fJWEHbvpi1nQoDiF VOeUoxcGcUL+IvyvFkEGk8Xky6q2Ek27RBgGnV60MEkcbcxVU33gCNNskAlEz3iPyax4t/B0CXun UEECJfrMV1AAkMCMn0RA9l0kEGe8GhoALTYQkE9GxP0TKOe1SJVPZ7qjlUbqgjq8GAJKN3AM0eQc EUr+DVw+FYNlpikbYkXqsSPYUiNIFYOIXa4u7Hydf180Iv5hFrFWLPE8S8d6hpa1QWRXG0SUgePv RV5mzZMutdY0IpePColE16i7vTG0g6kBbHna+kqiZFrt4DtDiUxrq5KRyIczuOFDE+HPN5HuvkBk v7Y6s8BKZ9cgClCe6mo+FzxDZ9rx4QvyRf6LQ0X2SjNj6F4dvxCFcrndS/yQjuqwhUyivGN2fArr EQ91Mo5Vdcau7QZYkd6wLlk25F7cLt7N8YjUiJafNdjIgkMXIIRz46MamMR76zfkyS7cosKUsMMT LhcG3AMzHzm/0wREeKYTbk0xqUkcQFNcl+wfFm0evd0P3H+GOw8ekIOIHJ1D/EIzaQy6OA2qwIqQ RBaeOOagnTPD/qLWEOLpa90+Gigu09mlVCrxoG1xotXWuMvtJsNjOaa1b7GBFLovQq+PUrqPHY4d 1urusdY7nLJP4eEFLQwS2g1YYw31j5rEsGXjNLJf5hhfdy5QiTutNFhoYp2yPFjStrECtxu5phYP VwRK4iDvgaG7Vo8GCkENuamtQEu+qmG3GpL2deUm/xIamqBpC7wdxxftVW6z32W777X7iwJkF4/r uMBZ8G2ACzBGCOi+564198WkRY50FZ2zq/CVo+x9KySTL+T6mSUWJyS1m66cNIGwSEBMBtz6iEgn Zwg7BOsOBx4afGLcPuqmbIpBElRkt9/F6NooPsefOyxEAvURkaC8RHNBAcSRU5xlp/yseqvSKjAG 4vbfF7dcQbTUGxVNoNFmNzl54xwzQipS1VQlpgvSLUB3kAk4PJwE8YdJlLQvA/HjHf0zcYuS13CQ mTYiuG+muk+pE0VdNgxNESp6ve+I21RyOBzvMWCS0PrC37x5UWMZ0cInselLhrGI7xpRh5GI+Qky 30A0+QoKBtfuf/YwBMkHZxoJXcfW2fh4yAkD8rMEg4lxghLy6/hTQk8+IkbsKZbPHASfmddRP5kU 7PM+AwmkMSSDvobFhthukjbphilsBfuslCHnvWrp2+gFvO2zNanm4sb/WdSVQDkpI8n+ADS8DJ4J vTm4TL3u5vByaLXEhV8gJuUSsxrVlEWxzBqGhSKIRi1YoF0VVIHdBHEJofcH6lYu3ZvLxpuWACEo lbHWKCJxcA/S8dC0Udvap8Do0N11lTO0uIQksMC2TEpIlHWshTYEsSWpQj7fhqoIeGt9X2rzmkwL 4guUVMDnFCZBOiS27xGVBDufUWGIdkqLpnGUjS/rK+uTw16RPrLNbRbNe7sfOX4yvcSNj2QJuscc zzATczbhpEx3yV+dfHca5OqaxE48oYmZX5Nv71zbA4gY1a5IhrFuq4hdNmxIgm0y2NAbZITwlo3Z vr3bH7UXrnmWuti4cEfvVVRxEeyjWFWL4UDbx8zRrlEyDgyS6r2Y8wXQAGMYFkLDYm/VdUF6Fm9H NaXX353SaXRjy4pko15ve0W4SYOerP4qTPnkse0NaSWc2f51MlYEPq9X8r82CJ+B11AaQNoIpjFU i43jGx+4P6dqs6FSettwKHMIAqD89uxtWS8w/geOLExgoWaDmXWUtZCwvxmQjtlo2JEqCEO/95X6 qWcX2jVXjP0hk7ujVrZBAMDEaQzj49jpOI6wCoaTd3JgrRGCIAQdXfFn997XNp74TUzXbIJMQIsr Tg8qfeAiEwamZbvUFcAvoBHnOjArNF9FK1RRbRBJ3My38RuftF4vrqpLtJCBAUR7g0qRehH7WJf6 12rsNG1g1DOMLiW7SOWL0HN+ABd9yApwPlDHRm5RnUIH3+ZdOonnJgbMGvEJ5k2he/XW4evImI77 lNcAWIEed8jHSy88M6SPz5nT3qCHDxhosGRTEpUD2hbunvbFnm6qKvaWsj0uwYNNW9Q9k223bHgF 1iUg0VstF9At50vDuHHvKa2uBDFmZ7ccREL+flQZtDvxtdMVySdQBO4TMwquDlLhURzkGhLEjop3 OehVg4zaayDlAPYLLlH30xAEekoBG2XflpeA8nzVpPsXsA+09cvkI6w4mt+Gx8Mnw6ulKx10TpA1 Gzjx8iXaH2JQpBcCDafGiAt/Ekgl73KIKzeGdfODdbrt9Y6ox8P6HV47/F+AAeO8Ikc3VUsXiegX 3+uOkztWbBeavdR+0dzKwu34CKtWrN1uvbLXxc+7Y6iniprO2kOlXUaLM+VGuVMDK7CyTLFG7HEU YagpSJyGwoXnPdP+VjlH28l+SyjNvshnCzZ9XHAgDjt2Q4amFLOQhB61Hk8BI486SZw359mmH14w RwZkmhdY9im0bMwewopC7yoKkeelER+UBZaNnuIIWyN3MA3boFOXQ+QvXlGu6AA0Kiy5g8SVyj8b OIWZWS/GJz4Kpo1/X3s7B4kjx2MGGrm/orFBMcUoSAtErukn/I4BI9gc83ifHBlgEAZxcTeFhlbN 1Y5pO1rlWvYSSgiyPAf0Ga8CvZA/NLLThv3dyroCfpRauV3wLASMV27bGJQvDLDo1jxMJS0UbIgT e4c2o/ZysVQQClEyMw3k/bsYOmbREabn/oVOFgOw5VlUh1TymhNqNyU+NgYwVnSx9wVMt8XMG0LV 9RtLXJWU1z4yxS4DWcfH7gY2Snj1piJn5zO9VP6I2B0BvdDMr6P4NZKllr7HKM5FqsaXfI6LqPlo KUMsoiI6KjW9++Q5Kl9iKznFKcJeIQDv2cmwa4o4U8iARd1CuG8pjKnb4CWgUElh7N7vhu3winfB mxRrglhFnXDyWTRYZhtyYfjDlBkJOIbRJhcN6vVAyMCClhkoH6BXo2HlYS/7RktAm/Z5UN/B3ZGc nIAO+Tki/CzxMqVsQncVFCC5lLpvPwZwSX4HFxKGLiY0xLwplpNqht0qaOmonC64bmy+WOToWaPr O8r2wx/EQIwUzlPUsiYtVtyfOsmIWawqZIjGUZttrDYObSanF4I3dpk0o1YzaBl8fDt6+FL3I5F6 Xh3uhhJTZy90eGOczziOiP9On53Nfq3GLyop3qqyUWCI11cPI5jEICEdib43IpGfDPLZRZbiOVaM OcTTDJfrRigbDZtdzsr/oBytcKheYnlAjldvgK6lcd+tLzOMy6Nq9Fp2FpbyYv+VMfP4ScfejKlv 7EZvAFclvQzKMAIHwbY/sP79tDxDYgj2p3Lzd22SlV2UaTxGqbpNvp6zgqKY3C/gOwO2jabqFZjY hxM5QyyD5pIZlkCvYKghjWUKjqVWD3yQpOV5XVJMP0gKixzqqVdvJcpOdNRRhgJQh2hHYGjWwwGD LAn3KTQLpXN/uSaY/3KJXAGgYG5MeJm3mz7K2dQHmCnLmwJYB/z9orwopK8v3gZAAM5MVEWMa2QG qTNPIKX7sTt5J7t0oVPieHHRJlw6rjAJ3tlO5Fs3XqsIJkYmJE2PqDvBOdZSnD/nGuUvzDXacBF0 TnQe1GKFHb8gp6pM3IESTtR1SlfRcPo+eSRX0QFcGYXgunMAe1fRSOPDPIKAkEYMeSSigGUSTcmV 4i121FuzRRKrc38hxZ12F0TFAbZxJKem9ROYCgxV3bDQ0gleAcOgk246SSJK3N5jZnIHOTIIuQ7x NKJ/dNsB0iIYeUEZr7QXa91tAQrjjvE1UKYD7cQz1Hr+huttM52Kei65LUtrABEwyOOPYltyY+5o He+gfrYE3rzRRmS4LJ/vCGVH8YpelXOKi9ROcGwTs1G6gD5XhWOFdOWkZ9NklLmrfO0kBqZkcP0d vb92s9he1yyiiDJBFdrP6NBlQbgGt9ALiOnS7KURpOdzYvOCiyKQkVrbKF2ljAcQ4ctKEJXFB7RR hc+d4vvlHE3POVw4mKyp/HOH6HgnU1BepYULRoGIhzO+B87xwaM75oez2VHEpIwD2lp0qNdz6JNi T82gAxZBwM75wl9ZSx3GA0PK4GEdBuSD0GbRRuu/pFCO7ndOGRkmIFu4q2ls15JBx0oDKAJjgUpJ cpptjoJD/Gn6aokICVdpaveqUm+4nDvfGiO5hEulgMtk5FH2UhrCBvYO6geMywoKfAvmlUE3WJ/4 JrlkUqsasY7S2UzWl+TkkQtVduCTVlHjrzHyC1HnzMHF0Uu0fk9kDfB0u