From Internet-Drafts@ietf.org Wed May 1 12:25:49 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 01 May 2002 07:25:49 -0400 Subject: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt Message-ID: <200205011125.HAA20170@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Traffic restoration in link state protocols using neighbor's shortest path Author(s) : S. Kini, Y. Yang Filename : draft-kini-traf-restore-nsp-00.txt Pages : 8 Date : 30-Apr-02 Traffic recovery time when a link (or node) fails is typically in the order of tens of seconds for a link state IGP. The recovery time is governed by factors like the time it takes to detect an adjacency down, the time taken to propagate link state database changes throughout the network and the time it takes to run the SPF algorithm and install the new routes in the FIB. Till this entire process is complete, traffic in the network can be blackholed. This draft describes a technique to reduce the time for which traffic is blackholed by routing the traffic through a neighbor's shortest path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kini-traf-restore-nsp-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-kini-traf-restore-nsp-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: <20020430135733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kini-traf-restore-nsp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020430135733.I-D@ietf.org> --OtherAccess-- --NextPart-- From mshand@cisco.com Wed May 1 13:22:50 2002 From: mshand@cisco.com (mike shand) Date: Wed, 01 May 2002 13:22:50 +0100 Subject: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt In-Reply-To: <200205011125.HAA20170@ietf.org> Message-ID: <4.3.2.7.2.20020501131954.0426bb38@jaws.cisco.com> How does this differ from "downstream routes" as described in clause 7.2.6.2 (c) of ISO/IEC 10589? Mike At 07:25 01/05/2002 -0400, you wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Traffic restoration in link state protocols using > neighbor's shortest path > Author(s) : S. Kini, Y. Yang > Filename : draft-kini-traf-restore-nsp-00.txt > Pages : 8 > Date : 30-Apr-02 > >Traffic recovery time when a link (or node) fails is typically in the >order of tens of seconds for a link state IGP. The recovery time is >governed by factors like the time it takes to detect an adjacency >down, the time taken to propagate link state database changes >throughout the network and the time it takes to run the SPF algorithm >and install the new routes in the FIB. Till this entire process is >complete, traffic in the network can be blackholed. This draft >describes a technique to reduce the time for which traffic is >blackholed by routing the traffic through a neighbor's shortest path. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-kini-traf-restore-nsp-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-kini-traf-restore-nsp-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: <20020430135733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt > > From skini@mahinetworks.com Wed May 1 20:45:25 2002 From: skini@mahinetworks.com (Sriganesh Kini) Date: Wed, 1 May 2002 12:45:25 -0700 Subject: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt Message-ID: <9D6D37E97A57D411BB7C00508BAE29C903676A54@main.mahinetworks.com> At A for destination B, node C is not downstream. But there is NSP from A to B thru C. +---+ | C | +---+ 5 / \ 51 / \ +---+ +---+ | A |----------| B | +---+ 50 +---+ === Sriganesh Kini 707 283 1257 -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Wednesday, May 01, 2002 5:23 AM To: isis-wg@juniper.net Subject: Re: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt How does this differ from "downstream routes" as described in clause 7.2.6.2 (c) of ISO/IEC 10589? Mike At 07:25 01/05/2002 -0400, you wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Traffic restoration in link state protocols using > neighbor's shortest path > Author(s) : S. Kini, Y. Yang > Filename : draft-kini-traf-restore-nsp-00.txt > Pages : 8 > Date : 30-Apr-02 > >Traffic recovery time when a link (or node) fails is typically in the >order of tens of seconds for a link state IGP. The recovery time is >governed by factors like the time it takes to detect an adjacency >down, the time taken to propagate link state database changes >throughout the network and the time it takes to run the SPF algorithm >and install the new routes in the FIB. Till this entire process is >complete, traffic in the network can be blackholed. This draft >describes a technique to reduce the time for which traffic is >blackholed by routing the traffic through a neighbor's shortest path. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-kini-traf-restore-nsp-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-kini-traf-restore-nsp-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: <20020430135733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From azalani@opnet.com Wed May 1 23:50:49 2002 From: azalani@opnet.com (Ashish Zalani) Date: Wed, 01 May 2002 18:50:49 -0400 Subject: [Isis-wg] Cisco IS-IS Area == ISO10589 IS-IS Area ??? Message-ID: <4.2.1.20020501182236.00b73e60@mail.opnet.com> I suppose this is not the best place to ask a question about something that relates to a specific vendor's terminology, but I was hoping someone on this mailing list might be able to enlighten me on this issue: I am a bit confused about what Cisco calls an "Area" w.r.t. IS-IS. From the description of it, a "Cisco Area" seems to be what I would call an "IS-IS Routing domain" (or in terms of the Multi Topology draft, an MT). I understand from the Cisco documentation that one can configure no more than 30 "areas" on a (Cisco) router. But the Cisco documentation also says that you cannot configure more than 3 NETs on a router. I should have thought that I should be allowed to configure 3 NETs per "area" per router. Furthermore, it says: "If you are configuring multiarea IS-IS, the area ID must be unique, but the system ID portion of the NET must be the same for all IS-IS routing process instances". I don't understand: - why the area ID portion of the NET has to be unique between NETs for different "areas". - how I could configure 30 "areas" with just 3 NETs and unique area IDs. Can anyone kindly explain this to me? Regards, -Ashish. Ashish Zalani Modeling Engineer OPNET Technologies, Inc. From sprevidi@cisco.com Thu May 2 00:03:04 2002 From: sprevidi@cisco.com (stefano previdi) Date: Thu, 2 May 2002 01:03:04 +0200 Subject: [Isis-wg] Cisco IS-IS Area == ISO10589 IS-IS Area ??? In-Reply-To: <4.2.1.20020501182236.00b73e60@mail.opnet.com> References: <4.2.1.20020501182236.00b73e60@mail.opnet.com> Message-ID: <200205012303.BAA17287@strange-brew.cisco.com> this is cisco-configuration specific and will take this offline. s. On Thursday 02 May 2002 00:50, Ashish Zalani wrote: > I suppose this is not the best place to ask a question about something that > relates to a specific vendor's terminology, but I was hoping someone on > this mailing list might be able to enlighten me on this issue: > > I am a bit confused about what Cisco calls an "Area" w.r.t. IS-IS. > From the description of it, a "Cisco Area" seems to be what I would call > an "IS-IS Routing domain" (or in terms of the Multi Topology draft, an MT). > > I understand from the Cisco documentation that one can configure no more > than 30 "areas" on a (Cisco) router. But the Cisco documentation also says > that you cannot configure more than 3 NETs on a router. I should have > thought that I should be allowed to configure 3 NETs per "area" per router. > Furthermore, it says: "If you are configuring multiarea IS-IS, the area ID > must be unique, but the system ID portion of the NET must be the same for > all IS-IS routing process instances". > > I don't understand: > - why the area ID portion of the NET has to be unique between NETs for > different "areas". > - how I could configure 30 "areas" with just 3 NETs and unique area IDs. > > > Can anyone kindly explain this to me? > > Regards, > -Ashish. > Ashish Zalani > Modeling Engineer > OPNET Technologies, Inc. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From truskows@cisco.com Thu May 2 09:14:44 2002 From: truskows@cisco.com (Mike Truskowski) Date: Thu, 2 May 2002 01:14:44 -0700 (PDT) Subject: [Isis-wg] Cisco IS-IS Area == ISO10589 IS-IS Area ??? In-Reply-To: <4.2.1.20020501182236.00b73e60@mail.opnet.com> from Ashish Zalani at May "1," 2002 "06:50:49" pm Message-ID: <200205020814.BAA02502@wells.cisco.com> Since you are asking about a Cisco solution why ask this group. Ask your Cisco support person. Mike > I suppose this is not the best place to ask a question about something that > relates to a specific vendor's terminology, but I was hoping someone on > this mailing list might be able to enlighten me on this issue: > > I am a bit confused about what Cisco calls an "Area" w.r.t. IS-IS. > From the description of it, a "Cisco Area" seems to be what I would call > an "IS-IS Routing domain" (or in terms of the Multi Topology draft, an MT). > > I understand from the Cisco documentation that one can configure no more > than 30 "areas" on a (Cisco) router. But the Cisco documentation also says > that you cannot configure more than 3 NETs on a router. I should have > thought that I should be allowed to configure 3 NETs per "area" per router. > Furthermore, it says: "If you are configuring multiarea IS-IS, the area ID > must be unique, but the system ID portion of the NET must be the same for > all IS-IS routing process instances". > > I don't understand: > - why the area ID portion of the NET has to be unique between NETs for > different "areas". > - how I could configure 30 "areas" with just 3 NETs and unique area IDs. > > > Can anyone kindly explain this to me? > > Regards, > -Ashish. > Ashish Zalani > Modeling Engineer > OPNET Technologies, Inc. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From JRB@dataconnection.com Thu May 2 16:47:38 2002 From: JRB@dataconnection.com (Jon Berger) Date: Thu, 2 May 2002 16:47:38 +0100 Subject: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt Message-ID: <37701240971DD31193970000F6CCB9F7036D715F@duke.datcon.co.uk> But, if the BC cost is 60, don't you have a loop? Jon -----Original Message----- From: Sriganesh Kini [mailto:skini@mahinetworks.com] Sent: 01 May 2002 20:45 To: isis-wg@juniper.net Subject: RE: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt At A for destination B, node C is not downstream. But there is NSP from A to B thru C. +---+ | C | +---+ 5 / \ 51 / \ +---+ +---+ | A |----------| B | +---+ 50 +---+ === Sriganesh Kini 707 283 1257 -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Wednesday, May 01, 2002 5:23 AM To: isis-wg@juniper.net Subject: Re: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt How does this differ from "downstream routes" as described in clause 7.2.6.2 (c) of ISO/IEC 10589? Mike At 07:25 01/05/2002 -0400, you wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Traffic restoration in link state protocols using > neighbor's shortest path > Author(s) : S. Kini, Y. Yang > Filename : draft-kini-traf-restore-nsp-00.txt > Pages : 8 > Date : 30-Apr-02 > >Traffic recovery time when a link (or node) fails is typically in the >order of tens of seconds for a link state IGP. The recovery time is >governed by factors like the time it takes to detect an adjacency >down, the time taken to propagate link state database changes >throughout the network and the time it takes to run the SPF algorithm >and install the new routes in the FIB. Till this entire process is >complete, traffic in the network can be blackholed. This draft >describes a technique to reduce the time for which traffic is >blackholed by routing the traffic through a neighbor's shortest path. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-kini-traf-restore-nsp-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-kini-traf-restore-nsp-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: <20020430135733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From skini@mahinetworks.com Thu May 2 22:34:29 2002 From: skini@mahinetworks.com (Sriganesh Kini) Date: Thu, 2 May 2002 14:34:29 -0700 Subject: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt Message-ID: <9D6D37E97A57D411BB7C00508BAE29C903676A5C@main.mahinetworks.com> If the cost of BC is 60 then there is no NSP from A to B through C. === Sriganesh Kini 707 283 1257 > -----Original Message----- > From: Jon Berger [mailto:JRB@dataconnection.com] > Sent: Thursday, May 02, 2002 8:48 AM > To: Sriganesh Kini; isis-wg@juniper.net > Subject: RE: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt > > > But, if the BC cost is 60, don't you have a loop? > > Jon > > > -----Original Message----- > From: Sriganesh Kini [mailto:skini@mahinetworks.com] > Sent: 01 May 2002 20:45 > To: isis-wg@juniper.net > Subject: RE: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt > > > At A for destination B, node C is not downstream. But there > is NSP from A to > B thru C. > > > +---+ > | C | > +---+ > 5 / \ 51 > / \ > +---+ +---+ > | A |----------| B | > +---+ 50 +---+ > > > === > Sriganesh Kini > > 707 283 1257 > > > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Wednesday, May 01, 2002 5:23 AM > To: isis-wg@juniper.net > Subject: Re: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt > > > How does this differ from "downstream routes" as described in clause > 7.2.6.2 (c) of ISO/IEC 10589? > > Mike > > At 07:25 01/05/2002 -0400, you wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Traffic restoration in link state > protocols > using > > neighbor's shortest path > > Author(s) : S. Kini, Y. Yang > > Filename : draft-kini-traf-restore-nsp-00.txt > > Pages : 8 > > Date : 30-Apr-02 > > > >Traffic recovery time when a link (or node) fails is typically in the > >order of tens of seconds for a link state IGP. The recovery time is > >governed by factors like the time it takes to detect an adjacency > >down, the time taken to propagate link state database changes > >throughout the network and the time it takes to run the SPF algorithm > >and install the new routes in the FIB. Till this entire process is > >complete, traffic in the network can be blackholed. This draft > >describes a technique to reduce the time for which traffic is > >blackholed by routing the traffic through a neighbor's shortest path. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-kini-traf-restore-n sp-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-kini-traf-restore-nsp-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-kini-traf-restore-nsp-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: <20020430135733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From Internet-Drafts@ietf.org Fri May 3 12:28:47 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 03 May 2002 07:28:47 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-11.txt Message-ID: <200205031128.HAA09717@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter et al. Filename : draft-ietf-isis-gmpls-extensions-11.txt Pages : 11 Date : 02-May-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-11.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-11.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: <20020502145010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502145010.I-D@ietf.org> --OtherAccess-- --NextPart-- From aravindravikumar@yahoo.com Mon May 6 15:40:57 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Mon, 6 May 2002 07:40:57 -0700 (PDT) Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Message-ID: <20020506144057.96209.qmail@web11208.mail.yahoo.com> --0-765142342-1020696057=:92657 Content-Type: text/plain; charset=us-ascii Hi,All In the section 7.3.16.2 of the 2001 edition of ISO 10589, Checksums in LSP entries in SNP packets are also considered while dealing with LSP confusion. I have some doubts on that If a system has send a LSP on point to point link and is waiting for an acknowledgement and gets a PSNP,in which the LSPs sequence number is same,but checksum is different, Why should it try to purge or regenerate as we can be sure that its not a valid differentchecksum,but an incorrect checksum? The other system has send an acknowledgement, either because it has installed the received LSP,or is already having the same LSP (seqnum,checksum same remaining life time both zero or both non zero). if we have a different checksum for an LSP with same sequence number in a PSNP packet received on a point to point circuit,it can be because 1.The SNP packet itself is corrupted, 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. 3.Local systems memory got corrupted Here there is no LSP confusion as this is not describing copy of the same LSP with different data(with valid different checksums) .Can't we be sure that the checksum isincorrect. The last of the 3 cases can be verified and action should be taken in the same way an implementation handles memory corruption.For the first two cases,how will the purging of LSP(if the LSP is not in the set of LSP generated by the system) or regeneration(if its in the setof LSPs generated by the local system) help? or what does it achieve? I assume that in case of broadcast,while processing CSNPs,if we come across similar situation where sequence numbers are same and checksums are different, we cannot make out whether the LSP being described is a corrupted LSP,or its same LSP with different data or SNP itself is corrupted.In order to work in any case and get the database synchronized we are purging or regenerating according to the condition Am I right?? Aravind --------------------------------- Do You Yahoo!? Yahoo! Health - your guide to health and wellness --0-765142342-1020696057=:92657 Content-Type: text/html; charset=us-ascii
Hi,All
 
In the section 7.3.16.2 of the 2001 edition of ISO 10589,
Checksums in LSP entries in SNP packets are also considered while dealing with
LSP confusion. I have some doubts on that
 

If a system has send a LSP on point to point link and is waiting for an acknowledgement
and gets a PSNP,in which the LSPs sequence number is same,but checksum is different,
Why should it try to purge or regenerate as we can be sure that its not a valid different
checksum,but an incorrect checksum?
 
The other system has send an acknowledgement, either because it has installed
the received LSP,or is already having the same LSP
(seqnum,checksum same remaining life time both zero or both non zero).
if we have a different checksum for an LSP with same sequence number
in a PSNP packet received on a point to point circuit,it can be because
 
1.The SNP packet itself is corrupted,
2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
3.Local systems memory got corrupted
 
Here there is no LSP confusion as this is not describing copy of the same LSP
with different data(with valid different checksums) .Can't we be sure that the checksum is
incorrect. The last of the 3 cases can be verified and action should be taken in the same way
an implementation handles memory corruption.For the first two cases,how will
the purging of LSP(if the LSP is not in the set of LSP generated by the system)
or regeneration(if its in the setof LSPs generated by the local system)
help? or what does it achieve?
 
I assume that in case of broadcast,while processing CSNPs,if we come across
similar situation where sequence numbers are same and checksums are different,
we cannot make out whether the LSP being described is a corrupted LSP,or its
same LSP with different data or SNP itself is corrupted.In order to work in
any case and get the database synchronized we are purging or regenerating
according to the condition
 
Am I right??
 
Aravind


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness --0-765142342-1020696057=:92657-- From iesg@ietf.org Mon May 6 20:31:32 2002 From: iesg@ietf.org (The IESG) Date: Mon, 06 May 2002 15:31:32 -0400 Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational Message-ID: <200205061931.PAA03768@ietf.org> The IESG has received a request from the IS-IS for IP Internets Working Group to consider Three-Way Handshake for IS-IS Point-to-Point Adjacencies as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt From iesg@ietf.org Mon May 6 22:18:37 2002 From: iesg@ietf.org (The IESG) Date: Mon, 06 May 2002 17:18:37 -0400 Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational Message-ID: <200205062118.RAA07270@ietf.org> The IESG has received a request from the IS-IS for IP Internets Working Group to consider Three-Way Handshake for IS-IS Point-to-Point Adjacencies as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt From ginsberg@pluris.com Tue May 7 06:44:58 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Mon, 6 May 2002 22:44:58 -0700 Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F9DD@avalon.pluris.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F58A.52F34090 Content-Type: text/plain; charset="iso-8859-1" As you say, there are three possibilities: 1.The SNP packet itself is corrupted, Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP. NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB. So we are left with 2 and 3: 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. or 3.Local systems memory got corrupted (or perhaps both...) If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that. If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly. Les -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, May 06, 2002 7:41 AM To: isis-wg@juniper.net Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Hi,All In the section 7.3.16.2 of the 2001 edition of ISO 10589, Checksums in LSP entries in SNP packets are also considered while dealing with LSP confusion. I have some doubts on that If a system has send a LSP on point to point link and is waiting for an acknowledgement and gets a PSNP,in which the LSPs sequence number is same,but checksum is different, Why should it try to purge or regenerate as we can be sure that its not a valid different checksum,but an incorrect checksum? The other system has send an acknowledgement, either because it has installed the received LSP,or is already having the same LSP (seqnum,checksum same remaining life time both zero or both non zero). if we have a different checksum for an LSP with same sequence number in a PSNP packet received on a point to point circuit,it can be because 1.The SNP packet itself is corrupted, 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. 3.Local systems memory got corrupted Here there is no LSP confusion as this is not describing copy of the same LSP with different data(with valid different checksums) .Can't we be sure that the checksum is incorrect. The last of the 3 cases can be verified and action should be taken in the same way an implementation handles memory corruption.For the first two cases,how will the purging of LSP(if the LSP is not in the set of LSP generated by the system) or regeneration(if its in the setof LSPs generated by the local system) help? or what does it achieve? I assume that in case of broadcast,while processing CSNPs,if we come across similar situation where sequence numbers are same and checksums are different, we cannot make out whether the LSP being described is a corrupted LSP,or its same LSP with different data or SNP itself is corrupted.In order to work in any case and get the database synchronized we are purging or regenerating according to the condition Am I right?? Aravind _____ Do You Yahoo!? Yahoo! Health - your guide to health and wellness ------_=_NextPart_001_01C1F58A.52F34090 Content-Type: text/html; charset="iso-8859-1"
As you say, there are three possibilities:
 
1.The SNP packet itself is corrupted,
 
Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP.
NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB.
 
So we are left with 2 and 3:

2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
or
3.Local systems memory got corrupted
 
(or perhaps both...)
 
If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that.
 
If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly.
 
 
   Les
 
-----Original Message-----
From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com]
Sent: Monday, May 06, 2002 7:41 AM
To: isis-wg@juniper.net
Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP

Hi,All
 
In the section 7.3.16.2 of the 2001 edition of ISO 10589,
Checksums in LSP entries in SNP packets are also considered while dealing with
LSP confusion. I have some doubts on that
 

If a system has send a LSP on point to point link and is waiting for an acknowledgement
and gets a PSNP,in which the LSPs sequence number is same,but checksum is different,
Why should it try to purge or regenerate as we can be sure that its not a valid different
checksum,but an incorrect checksum?
 
The other system has send an acknowledgement, either because it has installed
the received LSP,or is already having the same LSP
(seqnum,checksum same remaining life time both zero or both non zero).
if we have a different checksum for an LSP with same sequence number
in a PSNP packet received on a point to point circuit,it can be because
 
1.The SNP packet itself is corrupted,
2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
3.Local systems memory got corrupted
 
Here there is no LSP confusion as this is not describing copy of the same LSP
with different data(with valid different checksums) .Can't we be sure that the checksum is
incorrect. The last of the 3 cases can be verified and action should be taken in the same way
an implementation handles memory corruption.For the first two cases,how will
the purging of LSP(if the LSP is not in the set of LSP generated by the system)
or regeneration(if its in the setof LSPs generated by the local system)
help? or what does it achieve?
 
I assume that in case of broadcast,while processing CSNPs,if we come across
similar situation where sequence numbers are same and checksums are different,
we cannot make out whether the LSP being described is a corrupted LSP,or its
same LSP with different data or SNP itself is corrupted.In order to work in
any case and get the database synchronized we are purging or regenerating
according to the condition
 
Am I right??
 
Aravind


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
------_=_NextPart_001_01C1F58A.52F34090-- From aravindravikumar@yahoo.com Tue May 7 07:45:47 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Mon, 6 May 2002 23:45:47 -0700 (PDT) Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F9DD@avalon.pluris.com> Message-ID: <20020507064547.16634.qmail@web11207.mail.yahoo.com> --0-909009487-1020753947=:16467 Content-Type: text/plain; charset=us-ascii Hi, Does this mean that if a system detects that its memory is corrupted (corrupted LSP in memory)it should purge the LSP ,causing a purge (area wide if its level1 LSP or domain wide in case of L2 LSP)and the regeneration by the originating system in case of non local LSP and regeneration in caser of local LSP? But the section 7.3.18 on database validation says that if a system detects failure the network entity should be disabled until the failure is corrected and also suggests that in the absence of implementation specific methods to deal with the situation, as a minimum we should take action to delete the databasea and reacquire the entire database Your answer seems to suggest that as an implementation specific way we can try to re-acquire the corrupted LSP by purging it.Are we justified in doing this .Won't it be better if we consider the memory corruption as an indication of more serious problems in our system(Atleast trying to find out whether the problem is transient or persistent) if its persistent problem we will keep on corrupting and purging,if we do like that I think dealing with memory corruption is an implemetation specific issue,but shouldn't it be fail stop-manner as suggested in the ISO 10589? Aravind Les Ginsberg wrote: As you say, there are three possibilities: 1.The SNP packet itself is corrupted, Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP.NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB. So we are left with 2 and 3: 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed.or 3.Local systems memory got corrupted (or perhaps both...) If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that. If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly. Les -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, May 06, 2002 7:41 AM To: isis-wg@juniper.net Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Hi,All In the section 7.3.16.2 of the 2001 edition of ISO 10589, Checksums in LSP entries in SNP packets are also considered while dealing with LSP confusion. I have some doubts on that If a system has send a LSP on point to point link and is waiting for an acknowledgement and gets a PSNP,in which the LSPs sequence number is same,but checksum is different, Why should it try to purge or regenerate as we can be sure that its not a valid differentchecksum,but an incorrect checksum? The other system has send an acknowledgement, either because it has installed the received LSP,or is already having the same LSP (seqnum,checksum same remaining life time both zero or both non zero). if we have a different checksum for an LSP with same sequence number in a PSNP packet received on a point to point circuit,it can be because 1.The SNP packet itself is corrupted, 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. 3.Local systems memory got corrupted Here there is no LSP confusion as this is not describing copy of the same LSP with different data(with valid different checksums) .Can't we be sure that the checksum isincorrect. The last of the 3 cases can be verified and action should be taken in the same way an implementation handles memory corruption.For the first two cases,how will the purging of LSP(if the LSP is not in the set of LSP generated by the system) or regeneration(if its in the setof LSPs generated by the local system) help? or what does it achieve? I assume that in case of broadcast,while processing CSNPs,if we come across similar situation where sequence numbers are same and checksums are different, we cannot make out whether the LSP being described is a corrupted LSP,or its same LSP with different data or SNP itself is corrupted.In order to work in any case and get the database synchronized we are purging or regenerating according to the condition Am I right?? Aravind --------------------------------- Do You Yahoo!? Yahoo! Health - your guide to health and wellness --------------------------------- Do You Yahoo!? Yahoo! Health - your guide to health and wellness --0-909009487-1020753947=:16467 Content-Type: text/html; charset=us-ascii

 Hi,

Does this mean that if a system detects that its memory is corrupted
(corrupted LSP in memory)it should purge the LSP ,causing a purge
(area wide if its level1 LSP or domain wide in case of L2 LSP)and
the regeneration by the originating system in case of non local LSP
and regeneration in caser of local LSP?


But the section 7.3.18 on database validation says that if a system detects failure
the network entity should be disabled until the failure is corrected and also suggests
that in the absence of implementation specific methods to deal with the situation, as a
minimum we should take action to delete the databasea and reacquire the entire database

Your answer seems to suggest that as an implementation specific way we can try to
re-acquire the corrupted LSP by purging it.Are we justified in doing this .Won't it
be better if we consider the memory corruption as an indication
of more serious problems in our system(Atleast trying to find out whether the problem
is transient or persistent)
if its persistent problem we will keep on corrupting and purging,if we do like that

I think dealing with memory corruption is an implemetation specific issue,but shouldn't it be fail stop-manner as suggested
in the ISO 10589?

Aravind

  Les Ginsberg <ginsberg@pluris.com> wrote:

As you say, there are three possibilities:
 
1.The SNP packet itself is corrupted,
 
Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP.
NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB.
 
So we are left with 2 and 3:

2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
or
3.Local systems memory got corrupted
 
(or perhaps both...)
 
If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that.
 
If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly.
 
 
   Les
 
-----Original Message-----
From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com]
Sent: Monday, May 06, 2002 7:41 AM
To: isis-wg@juniper.net
Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP

Hi,All
 
In the section 7.3.16.2 of the 2001 edition of ISO 10589,
Checksums in LSP entries in SNP packets are also considered while dealing with
LSP confusion. I have some doubts on that
 

If a system has send a LSP on point to point link and is waiting for an acknowledgement
and gets a PSNP,in which the LSPs sequence number is same,but checksum is different,
Why should it try to purge or regenerate as we can be sure that its not a valid different
checksum,but an incorrect checksum?
 
The other system has send an acknowledgement, either because it has installed
the received LSP,or is already having the same LSP
(seqnum,checksum same remaining life time both zero or both non zero).
if we have a different checksum for an LSP with same sequence number
in a PSNP packet received on a point to point circuit,it can be because
 
1.The SNP packet itself is corrupted,
2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
3.Local systems memory got corrupted
 
Here there is no LSP confusion as this is not describing copy of the same LSP
with different data(with valid different checksums) .Can't we be sure that the checksum is
incorrect. The last of the 3 cases can be verified and action should be taken in the same way
an implementation handles memory corruption.For the first two cases,how will
the purging of LSP(if the LSP is not in the set of LSP generated by the system)
or regeneration(if its in the setof LSPs generated by the local system)
help? or what does it achieve?
 
I assume that in case of broadcast,while processing CSNPs,if we come across
similar situation where sequence numbers are same and checksums are different,
we cannot make out whether the LSP being described is a corrupted LSP,or its
same LSP with different data or SNP itself is corrupted.In order to work in
any case and get the database synchronized we are purging or regenerating
according to the condition
 
Am I right??
 
Aravind


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness --0-909009487-1020753947=:16467-- From mshand@cisco.com Tue May 7 09:12:49 2002 From: mshand@cisco.com (mike shand) Date: Tue, 07 May 2002 09:12:49 +0100 Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP In-Reply-To: <20020507064547.16634.qmail@web11207.mail.yahoo.com> References: <17C81AD1F1FED411991E006008F6D1CA01B3F9DD@avalon.pluris.com> Message-ID: <4.3.2.7.2.20020507090327.042c5be8@jaws.cisco.com> Of course an alternative way to deal with "LSP confusion" is not to purge at all, but to treat an otherwise identical LSP which has a numerically HIGHER checksum as being newer. This resolves the situation just as well as a purge in the normal case (and arguably causes less disruption ( if the higher checksum really is the newer then is causes no disruption. If it should really have been the older, then the wrong LSP will be propagated back to the source and it will refresh it. So for this period of time we have the WRONG information, whereas in the 10589 case we have NO information. It is arguable which is better). I think in this case (a wrong xSNP checksum) it would resolve the situation rather more cleanly. This is of course what OSPF does. Note that this will interoperate with purging, and the choice of newer or older is arbitrary but it is CRITICAL that all systems make the same choice (i.e. HIGHER is NEWER - since that is what OSPF does). It will NOT interoperate with systems making the opposite choice. Mike At 23:45 06/05/2002 -0700, Aravind Ravikumar wrote: > Hi, > >Does this mean that if a system detects that its memory is corrupted >(corrupted LSP in memory)it should purge the LSP ,causing a purge >(area wide if its level1 LSP or domain wide in case of L2 LSP)and >the regeneration by the originating system in case of non local LSP >and regeneration in caser of local LSP? > > >But the section 7.3.18 on database validation says that if a system >detects failure >the network entity should be disabled until the failure is corrected and >also suggests >that in the absence of implementation specific methods to deal with the >situation, as a >minimum we should take action to delete the databasea and reacquire the >entire database > >Your answer seems to suggest that as an implementation specific way we can >try to >re-acquire the corrupted LSP by purging it.Are we justified in doing this >.Won't it >be better if we consider the memory corruption as an indication >of more serious problems in our system(Atleast trying to find out whether >the problem >is transient or persistent) >if its persistent problem we will keep on corrupting and purging,if we do >like that > >I think dealing with memory corruption is an implemetation specific >issue,but shouldn't it be fail stop-manner as suggested >in the ISO 10589? > >Aravind > > Les Ginsberg wrote: >>As you say, there are three possibilities: >> >>1.The SNP packet itself is corrupted, >> >>Without the optional SNP checksum and/or HMAC authentication, you will >>not know this is the case. If you do have optional checksum/HMAC and the >>validation fails, you will never process the SNP. >>NOT purging might help you if the checksum reported in the SNP is a >>transient error i.e. the neighbor really has the correct checksum but >>simply reported it incorrectly. The most likely reason for this is SNP >>corruption. The best way to address this is to use optional SNP checksums >>or HMAC authentication. Once you have decided to process the SNP you must >>assume its contents accurately reflect the neighbors DB. >> >>So we are left with 2 and 3: >> >>2.The LSP got corrupted in the other systems memory,before the PSNP was >>constructed. >>or >>3.Local systems memory got corrupted >> >>(or perhaps both...) >> >>If you were certain that neighbor's memory was corrupted you could simply >>keep the SRM flag set and try again. I suppose an implementation could >>recheck the checksum on the local copy of the LSP. If it failed, then we >>know local memory is corrupt and we need to make sure we get a new copy >>of the LSP. Purging it (if non-local) or regenerating it (if local) >>accomplishes that. >> >>If the recheck of the checksum succeeds then you could try resending the >>LSP (keep SRM flag set). However, when the neighbor receives this LSP for >>a second time and compares it to the local copy (sequence #'s match, >>lifetime both non-zero, but checksums don't match) then the neighbor must >>initiate the purge. So we have merely delayed the purge briefly. >> >> >> Les >> >>>-----Original Message----- >>>From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] >>>Sent: Monday, May 06, 2002 7:41 AM >>>To: isis-wg@juniper.net >>>Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP >>> >>>Hi,All >>> >>>In the section 7.3.16.2 of the 2001 edition of ISO 10589, >>>Checksums in LSP entries in SNP packets are also considered while >>>dealing with >>>LSP confusion. I have some doubts on that >>> >>> >>>If a system has send a LSP on point to point link and is waiting for an >>>acknowledgement >>>and gets a PSNP,in which the LSPs sequence number is same,but checksum >>>is different, >>>Why should it try to purge or regenerate as we can be sure that its not >>>a valid different >>>checksum,but an incorrect checksum? >>> >>>The other system has send an acknowledgement, either because it has >>>installed >>>the received LSP,or is already having the same LSP >>>(seqnum,checksum same remaining life time both zero or both non zero). >>>if we have a different checksum for an LSP with same sequence number >>>in a PSNP packet received on a point to point circuit,it can be because >>> >>>1.The SNP packet itself is corrupted, >>>2.The LSP got corrupted in the other systems memory,before the PSNP was >>>constructed. >>>3.Local systems memory got corrupted >>> >>>Here there is no LSP confusion as this is not describing copy of the >>>same LSP >>>with different data(with valid different checksums) .Can't we be sure >>>that the checksum is >>>incorrect. The last of the 3 cases can be verified and action should be >>>taken in the same way >>>an implementation handles memory corruption.For the first two cases,how >>>will >>>the purging of LSP(if the LSP is not in the set of LSP generated by the >>>system) >>>or regeneration(if its in the setof LSPs generated by the local system) >>>help? or what does it achieve? >>> >>>I assume that in case of broadcast,while processing CSNPs,if we come across >>>similar situation where sequence numbers are same and checksums are >>>different, >>>we cannot make out whether the LSP being described is a corrupted LSP,or its >>>same LSP with different data or SNP itself is corrupted.In order to work in >>>any case and get the database synchronized we are purging or regenerating >>>according to the condition >>> >>>Am I right?? >>> >>>Aravind >>> >>> >>> >>>Do You Yahoo!? >>>Yahoo! Health - >>>your guide to health and wellness > > > >Do You Yahoo!? >Yahoo! Health - your >guide to health and wellness From ginsberg@pluris.com Tue May 7 18:50:48 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Tue, 7 May 2002 10:50:48 -0700 Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F9DF@avalon.pluris.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F5EF.B8D15540 Content-Type: text/plain; charset="iso-8859-1" The notion that a system which detects internal DB corruption should recover by purging an LSP is, of course, wrong, and I apologize for unintentionally suggesting that. The point I was trying to make was that if you receive an SNP and have no reason to know that its contents are corrupt (i.e. no checksum/authentication failure) then you must treat its contents as valid. If you are truly worried about SNP corruption (and certainly that has been a real world problem) then use the optional checksum TLV or HMAC authentication. Don't just ignore information in the hope that the SNP might have been corrupted. Les -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, May 06, 2002 11:46 PM To: Les Ginsberg; isis-wg@juniper.net Subject: RE: [Isis-wg] Incorrect\Different LSP checksum in SNP Hi, Does this mean that if a system detects that its memory is corrupted (corrupted LSP in memory)it should purge the LSP ,causing a purge (area wide if its level1 LSP or domain wide in case of L2 LSP)and the regeneration by the originating system in case of non local LSP and regeneration in caser of local LSP? But the section 7.3.18 on database validation says that if a system detects failure the network entity should be disabled until the failure is corrected and also suggests that in the absence of implementation specific methods to deal with the situation, as a minimum we should take action to delete the databasea and reacquire the entire database Your answer seems to suggest that as an implementation specific way we can try to re-acquire the corrupted LSP by purging it.Are we justified in doing this .Won't it be better if we consider the memory corruption as an indication of more serious problems in our system(Atleast trying to find out whether the problem is transient or persistent) if its persistent problem we will keep on corrupting and purging,if we do like that I think dealing with memory corruption is an implemetation specific issue,but shouldn't it be fail stop-manner as suggested in the ISO 10589? Aravind Les Ginsberg wrote: As you say, there are three possibilities: 1.The SNP packet itself is corrupted, Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP. NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB. So we are left with 2 and 3: 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. or 3.Local systems memory got corrupted (or perhaps both...) If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that. If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly. Les -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, May 06, 2002 7:41 AM To: isis-wg@juniper.net Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Hi,All In the section 7.3.16.2 of the 2001 edition of ISO 10589, Checksums in LSP entries in SNP packets are also considered while dealing with LSP confusion. I have some doubts on that If a system has send a LSP on point to point link and is waiting for an acknowledgement and gets a PSNP,in which the LSPs sequence number is same,but checksum is different, Why should it try to purge or regenerate as we can be sure that its not a valid different checksum,but an incorrect checksum? The other system has send an acknowledgement, either because it has installed the received LSP,or is already having the same LSP (seqnum,checksum same remaining life time both zero or both non zero). if we have a different checksum for an LSP with same sequence number in a PSNP packet received on a point to point circuit,it can be because 1.The SNP packet itself is corrupted, 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. 3.Local systems memory got corrupted Here there is no LSP confusion as this is not describing copy of the same LSP with different data(with valid different checksums) .Can't we be sure that the checksum is incorrect. The last of the 3 cases can be verified and action should be taken in the same way an implementation handles memory corruption.For the first two cases,how will the purging of LSP(if the LSP is not in the set of LSP generated by the system) or regeneration(if its in the setof LSPs generated by the local system) help? or what does it achieve? I assume that in case of broadcast,while processing CSNPs,if we come across similar situation where sequence numbers are same and checksums are different, we cannot make out whether the LSP being described is a corrupted LSP,or its same LSP with different data or SNP itself is corrupted.In order to work in any case and get the database synchronized we are purging or regenerating according to the condition Am I right?? Aravind _____ Do You Yahoo!? Yahoo! Health - your guide to health and wellness _____ Do You Yahoo!? Yahoo! Health - your guide to health and wellness ------_=_NextPart_001_01C1F5EF.B8D15540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The=20 notion that a system which detects internal DB corruption should = recover by=20 purging an LSP is, of course, wrong, and I apologize for = unintentionally=20 suggesting that. The point I was trying to make was that if you receive = an SNP=20 and have no reason to know that its contents are corrupt (i.e. no=20 checksum/authentication failure) then you must treat its contents as = valid. If=20 you are truly worried about SNP corruption (and certainly that has been = a real=20 world problem) then use the optional checksum TLV or HMAC = authentication. Don't=20 just ignore information in the hope that the SNP might have been = corrupted.=20
 
   Les
 
-----Original Message-----
From: Aravind Ravikumar = [mailto:aravindravikumar@yahoo.com]
Sent: Monday, May 06, = 2002 11:46=20 PM
To: Les Ginsberg; isis-wg@juniper.net
Subject: = RE:=20 [Isis-wg] Incorrect\Different LSP checksum in = SNP

 Hi,

Does this mean that if a system detects that its memory is=20 corrupted
(corrupted LSP in memory)it should purge the LSP = ,causing a=20 purge
(area wide if its level1 LSP or domain wide in case of L2 = LSP)and=20
the regeneration by the originating system in case of non local = LSP
and=20 regeneration in caser of local LSP?


But the section 7.3.18 on database validation says that if a = system=20 detects failure
the network entity should be disabled until the = failure is=20 corrected and also suggests
that in the absence of implementation = specific=20 methods to deal with the situation, as a
minimum we should take = action to=20 delete the databasea and reacquire the entire database=20

Your answer seems to suggest that as an implementation specific = way we can=20 try to
re-acquire the corrupted LSP by purging it.Are we justified = in doing=20 this .Won't it
be better if we consider the memory corruption as = an=20 indication
of more serious problems in our system(Atleast trying = to find=20 out whether the problem
is transient or persistent)
if its = persistent=20 problem we will keep on corrupting and purging,if we do like that=20

I think dealing with memory corruption is an implemetation = specific=20 issue,but shouldn't it be fail stop-manner as suggested
in the = ISO 10589?=20

Aravind=20

  Les Ginsberg <ginsberg@pluris.com> = wrote:=20

As=20 you say, there are three possibilities:
 
1.The SNP packet = itself is=20 corrupted,
 
Without the optional SNP = checksum=20 and/or HMAC authentication, you will not know this is the case. If = you do=20 have optional checksum/HMAC and the validation fails, you will = never process=20 the SNP.
NOT purging might help you if the = checksum reported=20 in the SNP is a transient error i.e. the neighbor really has the = correct=20 checksum but simply reported it incorrectly. The most likely reason = for this=20 is SNP corruption. The best way to address this is to use optional = SNP=20 checksums or HMAC authentication. Once you have decided to = process the=20 SNP you must assume its contents accurately reflect the neighbors=20 DB.
 
So we are left with 2 and = 3:

2.The LSP got corrupted in=20 the other systems memory,before the PSNP was=20
constructed.
or
3.Local = systems memory=20 got corrupted
 
(or perhaps both...)
 
If=20 you were certain that neighbor's memory was corrupted you could = simply keep=20 the SRM flag set and try again. I suppose an implementation = could=20 recheck the checksum on the local copy of the LSP. If it failed, = then we=20 know local memory is corrupt and we need to make sure we get a new = copy of=20 the LSP. Purging it (if non-local) or regenerating it (if local)=20 accomplishes that.
 
If=20 the recheck of the checksum succeeds then you could try resending = the LSP=20 (keep SRM flag set). However, when the neighbor receives this LSP = for a=20 second time and compares it to the local copy (sequence #'s match, = lifetime=20 both non-zero, but checksums don't match) then the neighbor must = initiate=20 the purge. So we have merely delayed the purge = briefly.
 
 
   Les
 
-----Original Message-----
From: Aravind = Ravikumar=20 [mailto:aravindravikumar@yahoo.com]
Sent: Monday, May = 06, 2002=20 7:41 AM
To: isis-wg@juniper.net
Subject: = [Isis-wg]=20 Incorrect\Different LSP checksum in SNP

Hi,All
 
In the section 7.3.16.2 of the = 2001 edition=20 of ISO 10589,
Checksums in LSP entries in SNP = packets are=20 also considered while dealing with
LSP confusion. I have some = doubts=20 on that
 

If a system has send a LSP = on point to=20 point link and is waiting for an acknowledgement
and gets a = PSNP,in=20 which the LSPs sequence number is same,but checksum is = different,
Why=20 should it try to purge or regenerate as we can be sure that its = not a=20 valid different
checksum,but an incorrect=20 checksum?
 
The other system has send an = acknowledgement,=20 either because it has installed
the received LSP,or is = already having=20 the same LSP
(seqnum,checksum same remaining life time both = zero or=20 both non zero).
if we have a different checksum for an LSP = with same=20 sequence number
in a PSNP packet received on a point to = point=20 circuit,it can be because
 
1.The SNP packet itself is=20 corrupted,
2.The LSP got corrupted in the other=20 systems memory,before the PSNP was =
constructed.
3.Local=20 systems memory got corrupted
 
Here there is no LSP confusion as this is not describing = copy of the=20 same LSP
with different data(with valid different checksums) = .Can't we=20 be sure that the checksum is
incorrect. The last of the = 3 cases can=20 be verified and action should be taken in the same way
an=20 implementation handles memory corruption.For the first two = cases,how will=20
the purging of LSP(if the LSP is not in the set of LSP = generated by=20 the system)
or regeneration(if its in the setof LSPs generated = by the=20 local system)
help? or what does it achieve?
 
I assume that in case of = broadcast,while=20 processing CSNPs,if we come across
similar situation where = sequence=20 numbers are same and checksums are different,
we cannot make = out=20 whether the LSP being described is a corrupted LSP,or its
same = LSP with=20 different data or SNP itself is corrupted.In order to work in =
any case=20 and get the database synchronized we are purging or=20 regenerating
according to the condition
 
Am I right??
 
Aravind


Do You Yahoo!?
Yahoo!=20 Health - your guide to health and = wellness


Do You Yahoo!?
Yahoo! = Health=20 - your guide to health and wellness ------_=_NextPart_001_01C1F5EF.B8D15540-- From Internet-Drafts@ietf.org Wed May 8 12:27:50 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 08 May 2002 07:27:50 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-08.txt Message-ID: <200205081127.HAA00843@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Management Information Base for IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-wg-mib-08.txt Pages : 80 Date : 07-May-02 This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner [1]. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-mib-08.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: <20020507124241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507124241.I-D@ietf.org> --OtherAccess-- --NextPart-- From jparker@axiowave.com Wed May 8 14:39:26 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 8 May 2002 09:39:26 -0400 Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-08.txt Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1F695.C55E0DC0 Content-Type: text/plain; charset="iso-8859-1" > Title : Management Information Base for IS-IS > Author(s) : J. Parker > Filename : draft-ietf-isis-wg-mib-08.txt > Pages : 80 > Date : 07-May-02 >From the doc: -- Changes in version 08. -- Changed definiton of isisCircLevelDesIS to hold 7, not 6 bytes -- Moved isisCircLocalID to CircLevel rather than IsisCircEntry -- Remove isisCircIndex from isisIPRAEntry -- Edit description of isisISAdjNeighPriority -- Replace isisISAdjIPAddrAdjIndex with isisISAdjIndex -- Simplified the names of variables which include Adj twice -- isisISAdjAreaAddrAdjIndex, isisISAdjIPAddrAdjIndex, -- and isisISAdjProtSuppAdjIndex. -- Added isisSysMaxAge to control MaxAge for LSPs we generate -- Added isisSysReceiveLSPBufferSize to control LSPs buffers - jeff parker ------_=_NextPart_000_01C1F695.C55E0DC0 Content-Type: message/rfc822 To: Subject: Date: Wed, 8 May 2002 09:39:31 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1F695.C55E0DC0" ------_=_NextPart_002_01C1F695.C55E0DC0 Content-Type: text/plain ------_=_NextPart_002_01C1F695.C55E0DC0 Content-Type: application/octet-stream; name="ATT49495.txt" Content-Disposition: attachment; filename="ATT49495.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020507124241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-08.txt ------_=_NextPart_002_01C1F695.C55E0DC0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-isis-wg-mib-08.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1F695.C55E0DC0-- ------_=_NextPart_000_01C1F695.C55E0DC0-- From prz@redback.com Wed May 8 17:10:13 2002 From: prz@redback.com (Tony Przygienda) Date: Wed, 08 May 2002 09:10:13 -0700 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: <3CD94DE5.858BD755@redback.com> We are starting last call on draft-ietf-isis-ext-lsp-frags-00. The last call will end 5/22/02 thanks -- tony From prz@redback.com Thu May 9 22:53:25 2002 From: prz@redback.com (Tony Przygienda) Date: Thu, 09 May 2002 14:53:25 -0700 Subject: [Isis-wg] call for agenda items ... Message-ID: <3CDAEFD5.8FD48C74@redback.com> Given enough things on the agenda, we are planning to have a meeting in Japan for ISIS. Since neither Tony L. nor Tony P. will be there, we will have Tony Ward chair the group this time. Please forward requests for agenda slot to dward@cisco.com with cc: to the chairs. thanks -- tony From Internet-Drafts@ietf.org Fri May 10 12:34:38 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 10 May 2002 07:34:38 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-12.txt Message-ID: <200205101134.HAA14865@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-isis-gmpls-extensions-12.txt Pages : 11 Date : 09-May-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-12.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-12.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: <20020509124100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020509124100.I-D@ietf.org> --OtherAccess-- --NextPart-- From Norbert v. Bolhuis" Am I missing something here ? In my opinion the 3 problems described in this draft (draft-ietf-isis-3way-06.txt) hardly exist. Problem 1 --------- I do not know what exactly is meant with "a cut set of one through the link", but anyway, if a link comes back up a CSNP will be sent *AND* the SRM flag for all LSPs will be set for this link. This means all LSPs will be sent (and the SRM flag won't be reset until explicit acknowledgement). Problem 2 --------- A unidirectional link failure will not be detected by only one system. If a node stops receiving p2p IIHs the adjacency will be down *AND* the node should stop sending IIHs and continue (or restart) sending ISHs. This causes the adjacency to be down at the remote node also. ISO10589 may not be very clear about this, but IS-IS implementations are supposed to work this way. Problem 3 --------- This might be a problem indeed although I would like to see a more extended explanation. If a p2p link is connected to another node the adjacency will be down (because of the different SystemID) and be established with the new node shortly after. The same may apply for a p2p link connected to another link on the same system, the adjacency may go down because the IIH now has a different local circuit ID field (the 1 octet field), but I'm not sure what ISO10589 says about this. If the adjacency stays up (to another link on the same system) no problems will arise as long as the remote system takes into account the 'new' local circuit ID when running SPF. Norbert van Bolhuis -------------------- nvbolhuis@lucent.com > X-JNPR-Received-From: outside > To: IETF-Announce:;@spider.juniper.net@hzsms01.nl.lucent.com > Cc: isis-wg@juniper.net > From: The IESG > X-OriginalArrivalTime: 06 May 2002 21:17:34.0015 (UTC) FILETIME=[7061B4F0:01C1F543] > Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational > X-BeenThere: isis-wg@spider.juniper.net > X-Mailman-Version: 2.0rc1 > List-Help: > List-Post: > List-Subscribe: , > List-Id: IETF IS-IS working group > List-Unsubscribe: , > List-Archive: > > > The IESG has received a request from the IS-IS for IP Internets Working > Group to consider Three-Way Handshake for IS-IS Point-to-Point > Adjacencies as an Informational RFC. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg From jparker@axiowave.com Mon May 13 17:25:19 2002 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 13 May 2002 12:25:19 -0400 Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-P oint Adjacencies to Informational Message-ID: > Am I missing something here ? > > In my opinion the 3 problems described in this draft > (draft-ietf-isis-3way-06.txt) hardly exist. > > Problem 1 > --------- > I do not know what exactly is meant with "a cut set of one > through the link", > but anyway, if a link comes back up a CSNP will be sent *AND* the > SRM flag for all LSPs will be set for this link. This means > all LSPs will be > sent (and the SRM flag won't be reset until explicit acknowledgement). "Cut set" is a graph theory term for a set whose removal splits a connected graph into parts. > > Problem 2 > --------- > A unidirectional link failure will not be detected by only one system. > If a node stops receiving p2p IIHs the adjacency will be down > *AND* the > node should stop sending IIHs and continue (or restart) sending ISHs. > This causes the adjacency to be down at the remote node also. > ISO10589 may not be very clear about this, but IS-IS > implementations are > supposed to work this way. Not all link layers are created equal. Some point to point links don't have the smarts to reset. Note that the authors refer to this in their introduction (below). - jeff parker 1.0 Introduction The IS-IS protocol [1] assumes certain requirements stated in ISO 10589 (section 6.7.2) for the operation of IS-IS over point-to-point links and hence provides only a two-way handshake when establishing adjacencies on point-to-point links. The protocol does not operate correctly if these subnetwork requirements for point-to-point links are not met. The basic mechanism defined in the standard is that each From rsaluja@nortelnetworks.com Mon May 13 18:29:48 2002 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Mon, 13 May 2002 13:29:48 -0400 Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational References: <200205131539.RAA28676@hzsms01.nl.lucent.com> Message-ID: <3CDFF80C.B722E2AB@nortelnetworks.com> "Norbert v. Bolhuis" wrote: > Am I missing something here ? > > In my opinion the 3 problems described in this draft > (draft-ietf-isis-3way-06.txt) hardly exist. > > Problem 1 > --------- > I do not know what exactly is meant with "a cut set of one through the link", > but anyway, if a link comes back up a CSNP will be sent *AND* the > SRM flag for all LSPs will be set for this link. This means all LSPs will be > sent (and the SRM flag won't be reset until explicit acknowledgement). What about the other end which could not detect the link going down and hence will never send the full database. The databases will be unsynchronized. > > > Problem 2 > --------- > A unidirectional link failure will not be detected by only one system. > If a node stops receiving p2p IIHs the adjacency will be down *AND* the > node should stop sending IIHs and continue (or restart) sending ISHs. > This causes the adjacency to be down at the remote node also. > ISO10589 may not be very clear about this, but IS-IS implementations are > supposed to work this way. Here we are talking about unreliable point to point links and multiple parallel links between two systems. Please read it carefully. > > > Problem 3 > --------- > This might be a problem indeed although I would like to see a more extended > explanation. > If a p2p link is connected to another node the adjacency will be down (because > of the different SystemID) and be established with the new node shortly after. > The same may apply for a p2p link connected to another link on the same system, > the adjacency may go down because the IIH now has a different local circuit ID > field (the 1 octet field), but I'm not sure what ISO10589 says about this. > If the adjacency stays up (to another link on the same system) no problems > will arise as long as the remote system takes into account the 'new' local > circuit ID when running SPF. Let me just cut and paste from Dave's mail from archive. "several router vendors have implemented a scheme where two routers act together as a SONET ADM for the purposes of implementing Automatic Protection Switching (APS.) The idea is that the trunk circuit comes into a POP, hits an ADM, and out the other side come the APS Working and Protect circuits, which then go into different routers. This is primarily viewed as a way of protecting against router/interface failure or somebody tripping over the last 100 feet of fiber, while keeping the expensive trunk circuit operating. The routers coordinate via a back channel to instigate and react to APS signalling (via the K1/K2 overhead bytes.) In 1+1 Bidirectional mode, the ADM will send the same bit stream to both routers, but only listen to one of them. Without the addition of the ID stuff, it is theoretically possible that the router on the circuit not selected by the ADM can think that it has an adjacency to the guy at the far end of the trunk, which would cause traffic to be poured down a black hole." Hope it helps. Thanks, Rajesh > > > Norbert van Bolhuis > -------------------- > nvbolhuis@lucent.com > > > X-JNPR-Received-From: outside > > To: IETF-Announce:;@spider.juniper.net@hzsms01.nl.lucent.com > > Cc: isis-wg@juniper.net > > From: The IESG > > X-OriginalArrivalTime: 06 May 2002 21:17:34.0015 (UTC) FILETIME=[7061B4F0:01C1F543] > > Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies > to Informational > > X-BeenThere: isis-wg@spider.juniper.net > > X-Mailman-Version: 2.0rc1 > > List-Help: > > List-Post: > > List-Subscribe: , > > > List-Id: IETF IS-IS working group > > List-Unsubscribe: , > > > List-Archive: > > > > > > The IESG has received a request from the IS-IS for IP Internets Working > > Group to consider Three-Way Handshake for IS-IS Point-to-Point > > Adjacencies as an Informational RFC. > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. > > > > Files can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.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 iesg-secretary@ietf.org Mon May 13 21:16:56 2002 From: iesg-secretary@ietf.org (The IESG) Date: Mon, 13 May 2002 16:16:56 -0400 Subject: [Isis-wg] Document Action: Optional Checksums in ISIS to Informational Message-ID: <200205132016.QAA00707@ietf.org> The IESG has approved the Internet-Draft 'Optional Checksums in ISIS' as a Informational. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. From iesg-secretary@ietf.org Mon May 13 22:21:32 2002 From: iesg-secretary@ietf.org (The IESG) Date: Mon, 13 May 2002 17:21:32 -0400 Subject: [Isis-wg] Document Action: Reserved TLV Codepoints in ISIS to Informational Message-ID: <200205132121.RAA04319@ietf.org> The IESG has approved the Internet-Draft 'Reserved TLV Codepoints in ISIS' as a Informational. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. From sprevidi@cisco.com Wed May 15 16:18:22 2002 From: sprevidi@cisco.com (stefano previdi) Date: Wed, 15 May 2002 17:18:22 +0200 Subject: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.txt Message-ID: <200205151518.RAA18522@strange-brew.cisco.com> Naiming, in draft-ietf-isis-wg-multi-topology-03.txt I see: ------------------------------------------------------------------- 8.3. Multi-Topology Reachable IPv4 Prefixes TLV TLV number of this TLV is 235. It is aligned with extended IS reachability TLV type 135 beside an additional two bytes in front. 2 bytes of MT membership 4 bits (most significant) are reserved 12 least significant bits are the MT ID 0-251 octets of structures used in TLV type 135. This TLV can occur multiple times. A new sub-TLV for this MT Reachable IPv4 Prefixes TLV is proposed: Sub-TLV type 117 Length 4 octets Name MT IPv4 Prefix Color The value of 1 of this sub-TLV is reserved for MT Management Prefix color. If the MT Management Prefix color is present in this TLV, a MT based SPF computation MAY also need to install this prefix into the ``standard'' or ``management'' RIB. This MAY be necessary for example in the case of MT based network management. --------------------------------------------------------------------- In draft-martin-neal-policy-isis-admin-tags we specified admin tag sub-TLV for both TLV 135 and 235. Not sure about the real purpose of sub-TLV 117 but I believe we could just reserve an admin tag value of 1 of for "MT Management". s. From cmartin@gnilink.net Wed May 15 17:56:10 2002 From: cmartin@gnilink.net (Martin, Christian) Date: Wed, 15 May 2002 12:56:10 -0400 Subject: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.tx t Message-ID: <94B9091E1149D411A45C00508BACEB35015F2E6E@entmail.gnilink.com> Was this TLV designed to identify a particular MT? I suppose this may be used by an implementation to indicate which MT a prefix belongs to, but it must be consistent across the domain for it to be useful, which means, IMO, that it should be identified _not_ by prefix, but by MT itself. Unless I am reading this incorrectly. Otherwise, there appears to be some overlap between SubTLV 1 and 117 wrt a prefix. chris >-----Original Message----- >From: stefano previdi [mailto:sprevidi@cisco.com] >Sent: Wednesday, May 15, 2002 11:18 AM >To: naiming@redback.com >Cc: isis-wg@juniper.net >Subject: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.txt > > >Naiming, > >in draft-ietf-isis-wg-multi-topology-03.txt I see: > >------------------------------------------------------------------- >8.3. Multi-Topology Reachable IPv4 Prefixes TLV > > TLV number of this TLV is 235. It is aligned with extended IS > reachability TLV type 135 beside an additional two bytes in front. > > 2 bytes of MT membership > 4 bits (most significant) are reserved > 12 least significant bits are the MT ID > 0-251 octets of structures used in TLV type 135. > > This TLV can occur multiple times. > A new sub-TLV for this MT Reachable IPv4 Prefixes TLV is proposed: > > Sub-TLV type 117 > Length 4 octets > Name MT IPv4 Prefix Color > > The value of 1 of this sub-TLV is reserved for MT Management > Prefix color. > > If the MT Management Prefix color is present in this TLV, >a MT based > SPF computation MAY also need to install this prefix into the > ``standard'' or ``management'' RIB. This MAY be necessary for > example in the case of MT based network management. >--------------------------------------------------------------------- > >In draft-martin-neal-policy-isis-admin-tags we specified >admin tag sub-TLV for both TLV 135 and 235. Not sure about >the real purpose of sub-TLV 117 but I believe we could just >reserve an admin tag value of 1 of for "MT Management". > > > > > > >s. > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis>-wg > From naiming@redback.com Wed May 15 20:14:53 2002 From: naiming@redback.com (Naiming Shen) Date: Wed, 15 May 2002 12:14:53 -0700 Subject: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.tx t In-Reply-To: Mail from "Martin, Christian" dated Wed, 15 May 2002 12:56:10 EDT <94B9091E1149D411A45C00508BACEB35015F2E6E@entmail.gnilink.com> Message-ID: <20020515191454.0CC4639B5BA@prattle.redback.com> Stefano and Christian, ] Was this TLV designed to identify a particular MT? I suppose this may be ] used by an implementation to indicate which MT a prefix belongs to, but it ] must be consistent across the domain for it to be useful, which means, IMO, ] that it should be identified _not_ by prefix, but by MT itself. Unless I am ] reading this incorrectly. this should be per prefix based. imagine the network consists of multiple topologies using M-ISIS, and router connected to the management LAN may not be in all those topologies. this particular tlv 117 value of 1 indicate the option of installing this prefix into the "normal" unicast RIB, so the management traffic has a path to reach those routers. ] ] Otherwise, there appears to be some overlap between SubTLV 1 and 117 wrt a ] prefix. I would think there is no need to mention "MT Management" in subtlv 1. the subtlv 1 will be used for general ISIS prefix things. But the subtlv 117 can be used for MT related prefix things. thanks. ] ] chris ] ] >-----Original Message----- ] >From: stefano previdi [mailto:sprevidi@cisco.com] ] >Sent: Wednesday, May 15, 2002 11:18 AM ] >To: naiming@redback.com ] >Cc: isis-wg@juniper.net ] >Subject: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.txt ] > ] > ] >Naiming, ] > ] >in draft-ietf-isis-wg-multi-topology-03.txt I see: ] > ] >------------------------------------------------------------------- ] >8.3. Multi-Topology Reachable IPv4 Prefixes TLV ] > ] > TLV number of this TLV is 235. It is aligned with extended IS ] > reachability TLV type 135 beside an additional two bytes in front. ] > ] > 2 bytes of MT membership ] > 4 bits (most significant) are reserved ] > 12 least significant bits are the MT ID ] > 0-251 octets of structures used in TLV type 135. ] > ] > This TLV can occur multiple times. ] > A new sub-TLV for this MT Reachable IPv4 Prefixes TLV is proposed: ] > ] > Sub-TLV type 117 ] > Length 4 octets ] > Name MT IPv4 Prefix Color ] > ] > The value of 1 of this sub-TLV is reserved for MT Management ] > Prefix color. ] > ] > If the MT Management Prefix color is present in this TLV, ] >a MT based ] > SPF computation MAY also need to install this prefix into the ] > ``standard'' or ``management'' RIB. This MAY be necessary for ] > example in the case of MT based network management. ] >--------------------------------------------------------------------- ] > ] >In draft-martin-neal-policy-isis-admin-tags we specified ] >admin tag sub-TLV for both TLV 135 and 235. Not sure about ] >the real purpose of sub-TLV 117 but I believe we could just ] >reserve an admin tag value of 1 of for "MT Management". ] > ] > ] > ] > ] > ] > ] >s. ] > ] > ] >_______________________________________________ ] >Isis-wg mailing list - Isis-wg@spider.juniper.net ] >http://spider.juniper.net/mailman/listinfo/isis>-wg ] > ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming From tli@procket.com Wed May 15 22:50:28 2002 From: tli@procket.com (Tony Li) Date: Wed, 15 May 2002 14:50:28 -0700 Subject: [Isis-wg] Message from the ITU Message-ID: <15586.55332.355645.614362@alpha-tli.procket.com> Hi Folks, I'm forwarding the following message from the ITU. I've reformatted it to IETF-normal ASCII, so any subsequent noise is my fault. Tony ---------------------------------------------------------------------- ITU - Telecommunication Standardization Sector Annex S Geneva, 10th May 2002 QUESTIONS: Q.14/15 SOURCE: Rapporteur TITLE: Communication Statement to IETF IS-IS Working Group on work on Integrated IS-IS on the DCN in Q.14/15 _____________ COMMUNICATION STATEMENT TO: IETF IS-IS Working Group APPROVAL: Agreed to at 29 April - 10 May 2002 SG15 meeting FOR: Information DEADLINE: None CONTACT: Hing-Kam Lam Tel: +1-732-949-8338 101 Crawfords Corner Road Fax: +1-732-949-5055 Holmdel, NJ 07733, USA Email: hklam@lucent.com As requested by the chairman of the IETF IS-IS working group, Q.14/15 would like to inform the IETF of the current work that Q.14/15 is doing on recommendation G.7712 "Architecture and Specification of Data Communication Network". This contains the draft revision of G.7712 and is intended to be consented at the next SG15 plenary in January 2003. The particular sections that IS-IS WG may be interested for further developments on IS-IS are: - Section 7.1.8 Network Layer PDU Encapsulation Function as well as Annex B for the Description of the Automatic Encapsulation Procedures - Section 7.1.10.1.1 Network-layer Protocol Aware Adjacency Creation - Section 7.1.10.1 Integrated IS-IS requirements as well as Annex A on Requirements for Three-Way Handshaking - Appendix III Commissioning guide for SDH NEs in dual RFC 1195 environment and impact of automatic Encapsulation option - Appendix II Implementation Example of Automatic Encapsulation The document is available as version 1.1 of G.7712 at the ITU-T public ftp site for your information. The document may be obtained from ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html. From christi@nortelnetworks.com Thu May 16 17:03:40 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Thu, 16 May 2002 17:03:40 +0100 Subject: [Isis-wg] Message from the ITU Message-ID: <4103264BC8D3D51180B7002048400C454FB6B4@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FCF3.3EBA9AD6 Content-Type: text/plain; charset="iso-8859-1" Please note that there is now a version 1.2 also at the same URL. Version 1.1 is text that was agreed from the last ITU-T SG15 meeting, whilst version 1.2 has no official status. That said, I believe that version 1.2 is considerably easier to read. The technical content is exactly the same across the two versions. I would personally advice anyone interested in this work to head straight for v1.2. Philip -----Original Message----- From: Tony Li [mailto:tli@procket.com] Sent: Wednesday, May 15, 2002 10:50 PM To: isis-wg@spider.juniper.net Subject: [Isis-wg] Message from the ITU Hi Folks, I'm forwarding the following message from the ITU. I've reformatted it to IETF-normal ASCII, so any subsequent noise is my fault. Tony ---------------------------------------------------------------------- ITU - Telecommunication Standardization Sector Annex S Geneva, 10th May 2002 QUESTIONS: Q.14/15 SOURCE: Rapporteur TITLE: Communication Statement to IETF IS-IS Working Group on work on Integrated IS-IS on the DCN in Q.14/15 _____________ COMMUNICATION STATEMENT TO: IETF IS-IS Working Group APPROVAL: Agreed to at 29 April - 10 May 2002 SG15 meeting FOR: Information DEADLINE: None CONTACT: Hing-Kam Lam Tel: +1-732-949-8338 101 Crawfords Corner Road Fax: +1-732-949-5055 Holmdel, NJ 07733, USA Email: hklam@lucent.com As requested by the chairman of the IETF IS-IS working group, Q.14/15 would like to inform the IETF of the current work that Q.14/15 is doing on recommendation G.7712 "Architecture and Specification of Data Communication Network". This contains the draft revision of G.7712 and is intended to be consented at the next SG15 plenary in January 2003. The particular sections that IS-IS WG may be interested for further developments on IS-IS are: - Section 7.1.8 Network Layer PDU Encapsulation Function as well as Annex B for the Description of the Automatic Encapsulation Procedures - Section 7.1.10.1.1 Network-layer Protocol Aware Adjacency Creation - Section 7.1.10.1 Integrated IS-IS requirements as well as Annex A on Requirements for Three-Way Handshaking - Appendix III Commissioning guide for SDH NEs in dual RFC 1195 environment and impact of automatic Encapsulation option - Appendix II Implementation Example of Automatic Encapsulation The document is available as version 1.1 of G.7712 at the ITU-T public ftp site for your information. The document may be obtained from ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATION S/index.html. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1FCF3.3EBA9AD6 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Message from the ITU

Please note that there is now a version 1.2 also at the same URL.

Version 1.1 is text that was agreed from the last ITU-T SG15 meeting, whilst version 1.2 has no official status.
That said, I believe that version 1.2 is considerably easier to read.
The technical content is exactly the same across the two versions.

I would personally advice anyone interested in this work to head straight for v1.2.

Philip

-----Original Message-----
From: Tony Li [mailto:tli@procket.com]
Sent: Wednesday, May 15, 2002 10:50 PM
To: isis-wg@spider.juniper.net
Subject: [Isis-wg] Message from the ITU



Hi Folks,

I'm forwarding the following message from the ITU.  I've reformatted it to
IETF-normal ASCII, so any subsequent noise is my fault.

Tony

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

ITU - Telecommunication Standardization Sector  Annex S
Geneva, 10th May 2002

QUESTIONS:      Q.14/15
SOURCE: Rapporteur
TITLE:  Communication Statement to IETF IS-IS Working Group on work on
        Integrated IS-IS on the DCN in Q.14/15
_____________
COMMUNICATION STATEMENT
TO:     IETF IS-IS Working Group
APPROVAL:       Agreed to at 29 April - 10 May 2002 SG15 meeting
FOR:    Information
DEADLINE:       None

CONTACT:        Hing-Kam Lam    Tel:    +1-732-949-8338
101 Crawfords Corner Road       Fax:    +1-732-949-5055
Holmdel, NJ 07733, USA  Email:  hklam@lucent.com

As requested by the chairman of the IETF IS-IS working group, Q.14/15 would
like to inform the IETF of the current work that Q.14/15 is doing on
recommendation G.7712 "Architecture and Specification of Data Communication
Network".  This contains the draft revision of G.7712 and is intended to be
consented at the next SG15 plenary in January 2003.

The particular sections that IS-IS WG may be interested for further
developments on IS-IS are:

- Section 7.1.8 Network Layer PDU Encapsulation Function as well as Annex B
  for the Description of the Automatic Encapsulation Procedures
- Section 7.1.10.1.1 Network-layer Protocol Aware Adjacency Creation
- Section 7.1.10.1 Integrated IS-IS requirements as well as Annex A on
  Requirements for Three-Way Handshaking
- Appendix III Commissioning guide for SDH NEs in dual RFC 1195 environment
  and impact of automatic Encapsulation option
- Appendix II Implementation Example of Automatic Encapsulation

The document is available as version 1.1 of G.7712 at the ITU-T public ftp
site for your information. The document may be obtained from
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg

------_=_NextPart_001_01C1FCF3.3EBA9AD6-- From jparker@axiowave.com Thu May 16 21:25:59 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 16 May 2002 16:25:59 -0400 Subject: [Isis-wg] Message from the ITU Message-ID: > The document is available as version 1.1 of G.7712 at the > ITU-T public ftp site for your information. The document > may be obtained from ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATION S/index.html. I've had a brief look at Version 2. I've noted some minor typos below, and have a couple of comments. This is the wrong forum to reach the ITU, so perhaps these are misplaced. Appendix A includes a description of the 3-way handshake. The document refers to RFCs elsewhere, so I assume that when the 3way handshake is an RFC, this Appendix will be replaced with a reference. The ideas on auto-encapsulation of traffic to bridge between OSI and IP networks seems frightfully clever, and I'm happy to point all further discussion of this topic to the ITU. This looks like a fruitful source of future problems and networking PhDs. - jeff parker Nits: p 37/38 This describes generation a ProtocolSupportedMismatch if there -is- and adjacency, but there is no match, when a change in protocols supported forces a tear-down. This won't happen often. Should there also be provisions for an event if there isn't an adjacency yet? p. 38 'Manor' should be 'manner' in section 7.1.10.1.2.2. From jonathan.sadler@tellabs.com Thu May 16 21:55:01 2002 From: jonathan.sadler@tellabs.com (Jonathan Sadler) Date: Thu, 16 May 2002 15:55:01 -0500 Subject: [Isis-wg] Message from the ITU References: Message-ID: <3CE41CA5.74BBDEB0@tellabs.com> Hi Jeff - I'm a participant in the Q14/15 stuff, and can provide some insight on your first comment. > Appendix A includes a description of the 3-way handshake. > The document refers to RFCs elsewhere, so I > assume that when the 3way handshake is an RFC, this > Appendix will be replaced with a reference. Since the work in the IETF on IS-IS is limited to achiving Informational status, the ITU will never be able to use an IETF RFC as a normative reference. This is the reason why Sec. 7.1.10.1.2 goes into such excruciating detail describing how to do what is in RFC 2966. The mention of RFC 2966 in Sec 7.1.10.1.2 is purely informative, not normative. To be honest, I would prefer to see the ITU reference IETF RFCs instead of including reworded text that implements the same thing that is in an RFC. Not only does it keep from efforts to rewrite all of the RFC (to get past copyright issues), but it also makes certain that implementations will interoperate. Unfortunately, this issue will not go away until the IETF and JTC1 resolve how extensions to IS-IS should be progressed. Jonathan Sadler ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From tli@procket.com Thu May 16 23:05:34 2002 From: tli@procket.com (Tony Li) Date: Thu, 16 May 2002 15:05:34 -0700 Subject: [Isis-wg] Message from the ITU In-Reply-To: References: Message-ID: <15588.11566.114030.664703@alpha-tli.procket.com> Hi Jonathan, | Since the work in the IETF on IS-IS is limited to achiving Informational | status, the ITU will never be able to use an IETF RFC as a normative | reference. This comment struck me as curious. Are you saying that if IETF claimed to pass standards on IS-IS and put these RFCs on the standards track, that the ITU would be willing to reference them as Normative? What is the reason for not referencing Informational RFC's as normative? They are fixed, published documents. Would it help if the IETF (and the authors of the RFC's) granted ITU rights of replication? Tony From truskows@cisco.com Thu May 16 23:16:44 2002 From: truskows@cisco.com (Mike Truskowski) Date: Thu, 16 May 2002 15:16:44 -0700 (PDT) Subject: [Isis-wg] Message from the ITU In-Reply-To: <15588.11566.114030.664703@alpha-tli.procket.com> from Tony Li at May "16," 2002 "03:05:34" pm Message-ID: <200205162216.PAA03095@wells.cisco.com> Tony, This is why I requested Q14 to send a liaison to you. You have it correct.... In order to get the 3way handshake pointed at.. it must be on standard track or a STD. Same with everything else. I thought there was an agreement between the IETF and ITU so we didn't have to duplicate... but it seems it's only good at the STD level. Mike > > > Hi Jonathan, > > > | Since the work in the IETF on IS-IS is limited to achiving Informational > | status, the ITU will never be able to use an IETF RFC as a normative > | reference. > > > This comment struck me as curious. Are you saying that if IETF claimed to > pass standards on IS-IS and put these RFCs on the standards track, that the > ITU would be willing to reference them as Normative? > > What is the reason for not referencing Informational RFC's as normative? > They are fixed, published documents. > > Would it help if the IETF (and the authors of the RFC's) granted ITU > rights of replication? > > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From jonathan.sadler@tellabs.com Fri May 17 00:01:24 2002 From: jonathan.sadler@tellabs.com (Jonathan Sadler) Date: Thu, 16 May 2002 18:01:24 -0500 Subject: [Isis-wg] Message from the ITU References: Message-ID: <3CE43A44.C3123A0B@tellabs.com> Tony - > | Since the work in the IETF on IS-IS is limited to achiving Informational > | status, the ITU will never be able to use an IETF RFC as a normative > | reference. > > This comment struck me as curious. Are you saying that if IETF claimed to > pass standards on IS-IS and put these RFCs on the standards track, that the > ITU would be willing to reference them as Normative? Correct. Per RFC 2026, Informational documents are not considered normative in the IETF. Witness the following: "Specifications that are intended to become Internet Standards evolve through a set of maturity levels known as the 'standards track'. These maturity levels -- 'Proposed Standard', 'Draft Standard', and 'Standard' -- are defined and discussed in section 4.1." --- (RFC2026, sec. 4) "Specifications that are not on the standards track are labeled with one of three 'off-track' maturity levels: 'Experimental', 'Informational', or 'Historic'. The documents bearing these labels are not Internet Standards in any sense." --- (RFC2026, sec. 4.2) > What is the reason for not referencing Informational RFC's as normative? > They are fixed, published documents. This is the policy specified by the IESG. The ITU is only respecting it. This is why I wish that the IS-IS working group could have its drafts achive Standards track. Then they would be available as normative references to other bodies, such as the ITU. Unfortunately, as I understand it, the IETF is sensative to JTC1's "ownership" of IS-IS and therefore the RFCs are limited to Informational status at best. > Would it help if the IETF (and the authors of the RFC's) granted ITU > rights of replication? That question would be best answered by the governing bodies in the ITU, not by me. However, it may provide a short-term work around as the text of an RFC could possibly be incorporated into an ITU recommendation. Personally, I'd rather see the long term problem solved -- specifically that IETF and JTC1 (and maybe also the ITU given G.7712v1.2 Appendix I and II) reach agreement on how extensions to IS-IS should be progressed. Jonathan Sadler ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From rja@extremenetworks.com Fri May 17 00:32:03 2002 From: rja@extremenetworks.com (RJ Atkinson) Date: Thu, 16 May 2002 19:32:03 -0400 Subject: [Isis-wg] Message from the ITU In-Reply-To: <3CE43A44.C3123A0B@tellabs.com> Message-ID: <209AF4B2-6925-11D6-AF0A-00039357A82A@extremenetworks.com> On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: > This is why I wish that the IS-IS working group could have its drafts > achive Standards track. Then they would be available as normative > references to other bodies, such as the ITU. > > Unfortunately, as I understand it, the IETF is sensative to JTC1's > "ownership" of IS-IS and therefore the RFCs are limited to Informational > status at best. IETF has asked (formally) ANSI, who apparently really are the standards body for IS-IS under ISO (ANSI rather than JTC1) about handing over change control to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) reports that I hear are that ANSI either didn't respond or said "no we don't want to do that". IETF is not publishing IS-IS stuff as standards-track because change-control hasn't been handed over to IETF from ANSI. Consequently, I find this whole thread a bit confusing. Perhaps others also do. A fantasy that occurs to me right now would be to get the IETF IS-IS chairs, the applicable ANSI folks, the applicable JTC1 folks, and the applicable ITU-T folks all in the same room -- with a goal of trying to find some more productive process and path forwards for all of us. Ran rja@extremenetworks.com From ginsberg@pluris.com Fri May 17 02:34:30 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Thu, 16 May 2002 18:34:30 -0700 Subject: [Isis-wg] Message from the ITU Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3FA09@avalon.pluris.com> Having worked on the ISO 10589:2001 draft within ISO, I would be very surprised to learn that ANSI thinks it owns the IS-IS spec. As far as I know it is owned by JTC1/SC6/WG7. More importantly, your mail states that the reason IS-IS WG drafts are on the Informational track is because the IETF does not own the IS-IS specification and therefore does not feel it in its purview to define extensions to the protocol which are "standards". If true, this would suggest that it is necessary that either: a)ISO have procedures to incorporate IS-IS WG RFCs into ISO documents b)IETF be empowered to issue IS-IS extensions which are standards c)IETF take ownership of the IS-IS standard Having spoken to both IETF and ISO leadership on this issue, I have no reason to think that any solution to this impasse acceptable to both sides has been offered. Given that we have even more compelling reasons now to want to fix this, I would hope that leadership on "all sides of the aisle" would find a way to make Ran's fantasy come true. Les > > > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: > > This is why I wish that the IS-IS working group could have > its drafts > > achive Standards track. Then they would be available as normative > > references to other bodies, such as the ITU. > > > > Unfortunately, as I understand it, the IETF is sensative to JTC1's > > "ownership" of IS-IS and therefore the RFCs are limited to > Informational > > status at best. > > IETF has asked (formally) ANSI, who apparently really are the > standards > body for IS-IS under ISO (ANSI rather than JTC1) about handing over > change control > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) reports that I > hear are > that ANSI either didn't respond or said "no we don't want to do that". > > IETF is not publishing IS-IS stuff as standards-track because > change-control hasn't been handed over to IETF from ANSI. > > Consequently, I find this whole thread a bit confusing. > Perhaps others > also do. > > A fantasy that occurs to me right now would be to get the IETF IS-IS > chairs, the applicable ANSI folks, the applicable JTC1 folks, and > the applicable ITU-T folks all in the same room -- with a goal of > trying to find some more productive process and path forwards > for all of us. > > Ran > rja@extremenetworks.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From christi@nortelnetworks.com Fri May 17 11:08:00 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Fri, 17 May 2002 11:08:00 +0100 Subject: [Isis-wg] Message from the ITU Message-ID: <4103264BC8D3D51180B7002048400C454FB6B7@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FD8A.B9092CE8 Content-Type: text/plain; charset="iso-8859-1" Mike is quite right. In order to refer in a normative way to an RFC, it must be a standards track RFC. The ITU-T can make non-normative references to Informationals, such as "For more information see RFC..." But 3-way-handshake doesn't even have an RFC number. I don't think that an ITU-T document can refer to an Internet Draft at all, after all, six months later the the doc will deleted off of the server and it will be a dead URL. You cannot just take the text from an IETF doc and paste it in, as that would be against copyright laws. So that left me with just one option: I had to re-write the thing in my own words, and what a pain it was. That is the reason why I had to go through a major learning curve a few months back to understand extactly how the 3-way-handshake worked. Some of you will probably remember the stupid questions I kept asking about it :) I will certainly propose to put the RFC number in when 3-way gets one. In the mean time, yes, I suggest people have a good read of the 3-way-handshake and make sure I didn't mess up. Philip -----Original Message----- From: Mike Truskowski [mailto:truskows@cisco.com] Sent: Thursday, May 16, 2002 11:17 PM To: tli@procket.com Cc: jonathan.sadler@tellabs.com; jparker@axiowave.com; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Message from the ITU Tony, This is why I requested Q14 to send a liaison to you. You have it correct.... In order to get the 3way handshake pointed at.. it must be on standard track or a STD. Same with everything else. I thought there was an agreement between the IETF and ITU so we didn't have to duplicate... but it seems it's only good at the STD level. Mike > > > Hi Jonathan, > > > | Since the work in the IETF on IS-IS is limited to achiving Informational > | status, the ITU will never be able to use an IETF RFC as a normative > | reference. > > > This comment struck me as curious. Are you saying that if IETF claimed to > pass standards on IS-IS and put these RFCs on the standards track, that the > ITU would be willing to reference them as Normative? > > What is the reason for not referencing Informational RFC's as normative? > They are fixed, published documents. > > Would it help if the IETF (and the authors of the RFC's) granted ITU > rights of replication? > > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1FD8A.B9092CE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Message from the ITU

Mike is quite right.

In order to refer in a normative way to an RFC, it = must be a standards track RFC.
The ITU-T can make non-normative references to = Informationals, such as "For more information see = RFC..."
But 3-way-handshake doesn't even have an RFC = number.
I don't think that an ITU-T document can refer to an = Internet Draft at all, after all, six months later the the doc will = deleted off of the server and it will be a dead URL.

You cannot just take the text from an IETF doc and = paste it in, as that would be against copyright laws.

So that left me with just one option: I had to = re-write the thing in my own words, and what a pain it was.

That is the reason why I had to go through a major = learning curve a few months back to understand extactly how the = 3-way-handshake worked. Some of you will probably remember the stupid = questions I kept asking about it :)

I will certainly propose to put the RFC number in = when 3-way gets one.
In the mean time, yes, I suggest people have a good = read of the 3-way-handshake and make sure I didn't mess up.

Philip




-----Original Message-----
From: Mike Truskowski [mailto:truskows@cisco.com]=
Sent: Thursday, May 16, 2002 11:17 PM
To: tli@procket.com
Cc: jonathan.sadler@tellabs.com; = jparker@axiowave.com;
isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] Message from the ITU


Tony,
This is why I requested Q14 to send a liaison to = you. 

You have it correct....  In order to get the = 3way handshake
pointed at.. it must be on standard track or a = STD.  Same
with everything else.

I thought there was an agreement between the IETF and = ITU so
we didn't have to duplicate... but it seems it's = only good at
the STD level.

Mike

>
>
> Hi Jonathan,
>
>
>  | Since the work in the IETF on IS-IS is = limited to achiving Informational
>  | status, the ITU will never be able to = use an IETF RFC as a normative
>  | reference. 
>
>
> This comment struck me as curious.  Are = you saying that if IETF claimed to
> pass standards on IS-IS and put these RFCs on = the standards track, that the
> ITU would be willing to reference them as = Normative?
>
> What is the reason for not referencing = Informational RFC's as normative?
> They are fixed, published documents.
>
> Would it help if the IETF (and the authors of = the RFC's) granted ITU
> rights of replication?
>
> Tony
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg=
>

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

------_=_NextPart_001_01C1FD8A.B9092CE8-- From jparker@axiowave.com Fri May 17 14:52:31 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 17 May 2002 09:52:31 -0400 Subject: [Isis-wg] Message from the ITU Message-ID: Having had none of the experience that Les has had, and none of the insight that the Tony's have into the IETF inner workings, here is a proposal unencumbered by any information. 1) IETF 'owns' (we need a better term, but I think we know what this means) IP issues, such as 2966. 2) JTC1 'owns' all pure OSI issues, and some (most?) of the link layer. 3) Issues such as 3-way handshake need to be worked by both sides. This could involve working through the document in IETF (ITU) and then forwarding it -before- it is frozen, to the ITU (IETF) for further massaging. 4) Some rules on who is working on what, and some oversight is needed to bang the pipes when something gets wedged and cannot advance. Some method must be provided to fast track documents that all agree upon. - jeff parker > Having worked on the ISO 10589:2001 draft within ISO, I would be very > surprised to learn that ANSI thinks it owns the IS-IS spec. > As far as I know it is owned by JTC1/SC6/WG7. > ... > Les From truskows@cisco.com Fri May 17 15:44:14 2002 From: truskows@cisco.com (Mike Truskowski) Date: Fri, 17 May 2002 07:44:14 -0700 (PDT) Subject: [Isis-wg] Message from the ITU In-Reply-To: from Jeff Parker at May "17," 2002 "09:52:31" am Message-ID: <200205171444.HAA26414@wells.cisco.com> Jeff, It's a good "start". But it doesn't nail the door open. Mike > Having had none of the experience that Les has had, and > none of the insight that the Tony's have into the IETF > inner workings, here is a proposal unencumbered by > any information. > > 1) IETF 'owns' (we need a better term, but I think > we know what this means) IP issues, such as 2966. > > 2) JTC1 'owns' all pure OSI issues, and some (most?) > of the link layer. > > 3) Issues such as 3-way handshake need to be worked > by both sides. This could involve working through > the document in IETF (ITU) and then forwarding it > -before- it is frozen, to the ITU (IETF) for further > massaging. > > 4) Some rules on who is working on what, and some > oversight is needed to bang the pipes when something > gets wedged and cannot advance. Some method must be > provided to fast track documents that all agree upon. > > - jeff parker > > > Having worked on the ISO 10589:2001 draft within ISO, I would be very > > surprised to learn that ANSI thinks it owns the IS-IS spec. > > As far as I know it is owned by JTC1/SC6/WG7. > > ... > > Les > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From jonathan.sadler@tellabs.com Fri May 17 17:37:03 2002 From: jonathan.sadler@tellabs.com (Jonathan Sadler) Date: Fri, 17 May 2002 11:37:03 -0500 Subject: [Isis-wg] Message from the ITU References: Message-ID: <3CE531AF.990A3C9F@tellabs.com> Jeff - Comments inline... Jonathan Sadler Jeff Parker wrote: > > Having had none of the experience that Les has had, and > none of the insight that the Tony's have into the IETF > inner workings, here is a proposal unencumbered by > any information. > > 1) IETF 'owns' (we need a better term, but I think > we know what this means) IP issues, such as 2966. > > 2) JTC1 'owns' all pure OSI issues, and some (most?) > of the link layer. > > 3) Issues such as 3-way handshake need to be worked > by both sides. This could involve working through > the document in IETF (ITU) and then forwarding it > -before- it is frozen, to the ITU (IETF) for further > massaging. Actually, it is three-sides, not both sides. JTC1 and the ITU are not related, just as ITU and the IETF are not related. JTC1 is a joint committee of ISO and IEC. Even if the IETF and ITU work things out (which I think is quite possible -- there is enough open-minded thinking in both groups), we need JTC1 to also be a party to the agreement. > 4) Some rules on who is working on what, and some > oversight is needed to bang the pipes when something > gets wedged and cannot advance. Some method must be > provided to fast track documents that all agree upon. > > - jeff parker > > > Having worked on the ISO 10589:2001 draft within ISO, I would be very > > surprised to learn that ANSI thinks it owns the IS-IS spec. > > As far as I know it is owned by JTC1/SC6/WG7. > > ... > > Les > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From jharper@cisco.com Fri May 17 17:52:32 2002 From: jharper@cisco.com (John Harper) Date: Fri, 17 May 2002 09:52:32 -0700 Subject: [Isis-wg] Message from the ITU In-Reply-To: <3CE531AF.990A3C9F@tellabs.com> References: Message-ID: <4.3.2.7.2.20020517094705.03da18f8@jaws.cisco.com> I've been following this and trying to resist jumping in, but I guess I just failed... I don't understand why this matters. Regardless of what ITU or JTC1 think, the handful of vendors who are supplying this protocol all know where the action is. Maybe there are some marginal vendors or wannabes who believe they can influence things through the ITU, but I'd be pretty surprised if they were to succeed. I don't believe JTC1 will ever give this up, for the simple reason that it is just about the only thing that gives WG7 any reason to continue to exist. (When I quit as chair of WG2, the predecessor of WG7, in 1992, it was because I really didn't see that there was anything useful left to be done in that forum. 10 years later, I don't see any reason to believe I was wrong). John At 11:37 17/05/2002 -0500, Jonathan Sadler wrote: >Jeff - > >Comments inline... > >Jonathan Sadler > >Jeff Parker wrote: > > > > Having had none of the experience that Les has had, and > > none of the insight that the Tony's have into the IETF > > inner workings, here is a proposal unencumbered by > > any information. > > > > 1) IETF 'owns' (we need a better term, but I think > > we know what this means) IP issues, such as 2966. > > > > 2) JTC1 'owns' all pure OSI issues, and some (most?) > > of the link layer. > > > > 3) Issues such as 3-way handshake need to be worked > > by both sides. This could involve working through > > the document in IETF (ITU) and then forwarding it > > -before- it is frozen, to the ITU (IETF) for further > > massaging. > >Actually, it is three-sides, not both sides. JTC1 and the ITU are not >related, just as ITU and the IETF are not related. JTC1 is a joint >committee of ISO and IEC. > >Even if the IETF and ITU work things out (which I think is quite >possible -- there is enough open-minded thinking in both groups), we >need JTC1 to also be a party to the agreement. > > > 4) Some rules on who is working on what, and some > > oversight is needed to bang the pipes when something > > gets wedged and cannot advance. Some method must be > > provided to fast track documents that all agree upon. > > > > - jeff parker > > > > > Having worked on the ISO 10589:2001 draft within ISO, I would be very > > > surprised to learn that ANSI thinks it owns the IS-IS spec. > > > As far as I know it is owned by JTC1/SC6/WG7. > > > ... > > > Les > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.juniper.net/mailman/listinfo/isis-wg >============================================================ >The information contained in this message may be privileged >and confidential and protected from disclosure. If the >reader of this message is not the intended recipient, or an >employee or agent responsible for delivering this message to >the intended recipient, you are hereby notified that any >reproduction, dissemination or distribution of this >communication is strictly prohibited. If you have received >this communication in error, please notify us immediately by >replying to the message and deleting it from your computer. > >Thank you. >Tellabs >============================================================ >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From prz@redback.com Fri May 17 14:12:02 2002 From: prz@redback.com (Tony Przygienda) Date: Fri, 17 May 2002 06:12:02 -0700 Subject: [Isis-wg] Message from the ITU References: <4103264BC8D3D51180B7002048400C454FB6B7@zhard0jd.europe.nortel.com> Message-ID: <3CE501A2.4D6E656C@redback.com> Philip Christian wrote: > > > Mike is quite right. > > In order to refer in a normative way to an RFC, it must be a standards track RFC. > The ITU-T can make non-normative references to Informationals, such as "For more information > see RFC..." > But 3-way-handshake doesn't even have an RFC number. will have, things are on their way fine ... > The IESG has received a request from the IS-IS for IP Internets Working > Group to consider Three-Way Handshake for IS-IS Point-to-Point > Adjacencies as an Informational RFC. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. > > You cannot just take the text from an IETF doc and paste it in, as that would be against > copyright laws. touchy point thanks -- tony From prz@redback.com Fri May 17 14:22:43 2002 From: prz@redback.com (Tony Przygienda) Date: Fri, 17 May 2002 06:22:43 -0700 Subject: [Isis-wg] Message from the ITU References: <4.3.2.7.2.20020517094705.03da18f8@jaws.cisco.com> Message-ID: <3CE50423.9CC8DECB@redback.com> John Harper wrote: > I've been following this and trying to resist jumping in, but I guess > I just failed... > > I don't understand why this matters. Regardless of what ITU or JTC1 > think, the handful of vendors who are supplying this protocol all know > where the action is. Maybe there are some marginal vendors or > wannabes who believe they can influence things through the ITU, > but I'd be pretty surprised if they were to succeed. > > I don't believe JTC1 will ever give this up, for the simple reason > that it is just about the only thing that gives WG7 any reason to > continue to exist. (When I quit as chair of WG2, the predecessor > of WG7, in 1992, it was because I really didn't see that there > was anything useful left to be done in that forum. 10 years later, I don't see > any reason to believe I was wrong). All those are interesting points to be taken and I appreciate some of the light these mails shed on the history of things and inner clockworks. _Nevertheless_ 1) please this should not become any kind of flames & jell-o-throwing thread from hell. Any derogatory or pejorative comments vs. IETF workings, WG7, JTC1 or whatever other entity involved is probably uncalled for. I do not want to be 'soup-nazi' but airing dirty laundry on such lists never did anything good to anyone. This things are better solved in constructive ways behind and not in front of the peanut-gallery. That leads me to a more important reason 2) this is a _technical_ mailing list. We are here to get _work done_, not get sucked into petty politics. If ITU wants to reference those documents, some constructive way may or may not be found but these should not congest these mailing list with 99.9% political/subjective mails. this said, nose to the grindstone of technical issues or please constructive proposals as of how to accomodate all the parties involved (a la Jeff Parker) thanks -- tony From prz@net4u.ch Fri May 17 19:10:58 2002 From: prz@net4u.ch (Tony Przygienda) Date: Fri, 17 May 2002 11:10:58 -0700 Subject: [Isis-wg] Message from the ITU References: <4.3.2.7.2.20020517094705.03da18f8@jaws.cisco.com> <3CE50423.9CC8DECB@redback.com> Message-ID: <3CE547B2.3010401@net4u.ch> Tony Przygienda wrote: >John Harper wrote: > >>I've been following this and trying to resist jumping in, but I guess >>I just failed... >> >>I don't understand why this matters. Regardless of what ITU or JTC1 >>think, the handful of vendors who are supplying this protocol all know >>where the action is. Maybe there are some marginal vendors or >>wannabes who believe they can influence things through the ITU, >>but I'd be pretty surprised if they were to succeed. >> >>I don't believe JTC1 will ever give this up, for the simple reason >>that it is just about the only thing that gives WG7 any reason to >>continue to exist. (When I quit as chair of WG2, the predecessor >>of WG7, in 1992, it was because I really didn't see that there >>was anything useful left to be done in that forum. 10 years later, I don't see >>any reason to believe I was wrong). >> > >All those are interesting points to be taken and I appreciate some >of the light these mails shed on the history of things and inner >clockworks. _Nevertheless_ > >1) please this should not become any kind of flames & jell-o-throwing > thread from hell. Any derogatory or pejorative comments vs. IETF > workings, WG7, JTC1 or whatever other entity involved is probably > uncalled for. I do not want to be 'soup-nazi' but airing dirty laundry > on such lists never did anything good to anyone. This things are better > solved in constructive ways behind and not in front of the peanut-gallery. > That leads me to a more important reason >2) this is a _technical_ mailing list. We are here to get _work done_, not > get sucked into petty politics. If ITU wants to reference those documents, > some constructive way may or may not be found but these should not > congest these mailing list with 99.9% political/subjective mails. > >this said, nose to the grindstone of technical issues or please constructive >proposals as of how to accomodate all the parties involved (a la Jeff Parker) > On a lighter note and a 2nd reading of my answer: I have a bout with flu here and that seems to have affected my ability to distinguish 'this' and 'these' seriously beside hitting the area of the brain governing the use of prepositions sorry for that -- tony From jonathan.sadler@tellabs.com Fri May 17 18:31:32 2002 From: jonathan.sadler@tellabs.com (Jonathan Sadler) Date: Fri, 17 May 2002 12:31:32 -0500 Subject: [Isis-wg] Message from the ITU References: Message-ID: <3CE53E74.2ABF4DEF@tellabs.com> John - Let me step back and put this all into perspective. I agree that there is valuable work going on in the IETF IS-IS WG. And because of this valuable work, other standards bodies (such as ITU) want to be able to reference the work. However, because the policy of the IESG is that RFCs with Informational status are not normative, these other standards bodies are unable to reference them. So what can be done? I can see a few options, some of which Les already mentioned: 1) Make Informational status normative. This would allow the ITU to reference IS-IS WG RFCs. However, this is not likely to happen as it basically allows anyone to write an Internet Standard without the IETF development process being involved. (Informational status documents are not required to go through the same rigor as Standards track documents.) 2) Move for IS-IS WG RFCs to be Standards track without rectifying the situation with JTC1. This also would allow the ITU to reference IS-IS WG RFCs. However, this has thorny side effects due to the fact that in the eyes of the IESG, JTC1 owns IS-IS, not the IETF. 3) Reach agreement with JTC1 on how IETF developed IS-IS extensions are handled. This could be: a) JTC1 progresses them to standard b) JTC1 allows IETF to progess them to standard, but retains IS-IS ownership and therefore may have "veto power" c) JTC1 gets out of the IS-IS business allowing the IETF to progress them to standard. I understand your sentament about how JTC1 is only relevant in the area of IS-IS if we allow them to be relevant. However, that issue is one for the IESG to handle. If they determine that JTC1 is no longer relevant, then option 2 above would be possible. Jonathan Sadler John Harper wrote: > > I've been following this and trying to resist jumping in, but I guess > I just failed... > > I don't understand why this matters. Regardless of what ITU or JTC1 > think, the handful of vendors who are supplying this protocol all know > where the action is. Maybe there are some marginal vendors or > wannabes who believe they can influence things through the ITU, > but I'd be pretty surprised if they were to succeed. > > I don't believe JTC1 will ever give this up, for the simple reason > that it is just about the only thing that gives WG7 any reason to > continue to exist. (When I quit as chair of WG2, the predecessor > of WG7, in 1992, it was because I really didn't see that there > was anything useful left to be done in that forum. 10 years later, I don't see > any reason to believe I was wrong). > > John > > At 11:37 17/05/2002 -0500, Jonathan Sadler wrote: > >Jeff - > > > >Comments inline... > > > >Jonathan Sadler > > > >Jeff Parker wrote: > > > > > > Having had none of the experience that Les has had, and > > > none of the insight that the Tony's have into the IETF > > > inner workings, here is a proposal unencumbered by > > > any information. > > > > > > 1) IETF 'owns' (we need a better term, but I think > > > we know what this means) IP issues, such as 2966. > > > > > > 2) JTC1 'owns' all pure OSI issues, and some (most?) > > > of the link layer. > > > > > > 3) Issues such as 3-way handshake need to be worked > > > by both sides. This could involve working through > > > the document in IETF (ITU) and then forwarding it > > > -before- it is frozen, to the ITU (IETF) for further > > > massaging. > > > >Actually, it is three-sides, not both sides. JTC1 and the ITU are not > >related, just as ITU and the IETF are not related. JTC1 is a joint > >committee of ISO and IEC. > > > >Even if the IETF and ITU work things out (which I think is quite > >possible -- there is enough open-minded thinking in both groups), we > >need JTC1 to also be a party to the agreement. > > > > > 4) Some rules on who is working on what, and some > > > oversight is needed to bang the pipes when something > > > gets wedged and cannot advance. Some method must be > > > provided to fast track documents that all agree upon. > > > > > > - jeff parker > > > > > > > Having worked on the ISO 10589:2001 draft within ISO, I would be very > > > > surprised to learn that ANSI thinks it owns the IS-IS spec. > > > > As far as I know it is owned by JTC1/SC6/WG7. > > > > ... > > > > Les > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > > http://spider.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@spider.juniper.net > >http://spider.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From Alex Zinin Fri May 17 18:36:06 2002 From: Alex Zinin (Alex Zinin) Date: Fri, 17 May 2002 10:36:06 -0700 Subject: [Isis-wg] Message from the ITU In-Reply-To: <3CE531AF.990A3C9F@tellabs.com> References: <3CE531AF.990A3C9F@tellabs.com> Message-ID: <984354416.20020517103606@psg.com> Folks, Some clarifications on the formal version of the current situation here. Whether we like it or not: 1. ISO does own the IS-IS spec. 2. The IETF ISIS WG produces protocol mechanisms as recommendations to ISO that are also published in the IETF as informational to let the community know what has been recommended. 3. Other standards bodies cannot have a normative reference to IETF informational documents in their standards as this could easily be used to end-run around the standards process. The question of working out an agreement between IETF and ISO to have a clear and documented understanding on what IETF can and cannot do is on the plate that Bill and I share. Alex Zinin From tli@procket.com Fri May 17 19:15:20 2002 From: tli@procket.com (Tony Li) Date: Fri, 17 May 2002 11:15:20 -0700 Subject: [Isis-wg] A thought... Message-ID: <15589.18616.724037.654205@alpha-tli.procket.com> Would anyone object if we started simply moving documents forward as standards track? This would mean being 'rude' to ISO, but since being 'nice' seems to be backfiring... Tony From jharper@cisco.com Fri May 17 20:05:33 2002 From: jharper@cisco.com (John Harper) Date: Fri, 17 May 2002 12:05:33 -0700 Subject: [Isis-wg] A thought... In-Reply-To: <15589.18616.724037.654205@alpha-tli.procket.com> Message-ID: <4.3.2.7.2.20020517120524.03db8ee8@jaws.cisco.com> Sure makes sense to me... John At 11:15 17/05/2002 -0700, Tony Li wrote: >Would anyone object if we started simply moving documents forward as >standards track? This would mean being 'rude' to ISO, but since being >'nice' seems to be backfiring... > >Tony >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Fri May 17 21:06:30 2002 From: Alex Zinin (Alex Zinin) Date: Fri, 17 May 2002 13:06:30 -0700 Subject: [Isis-wg] A thought... In-Reply-To: <15589.18616.724037.654205@alpha-tli.procket.com> References: <15589.18616.724037.654205@alpha-tli.procket.com> Message-ID: <4713380106.20020517130630@psg.com> Tony, I have reasons to suspect that this will not fly by the IESG. As IETF wouldn't like any other standards body to modify IETF standards, the IESG would unlikely support putting a document affecting another body's standard on the IETF standards track. We could consider standardizing IP-specific extensions (as in the case of 1195), but I would suggest that we stick with the current scheme until we have had a conversation with ISO. After that we can reevaluate the WG documents (including Informational RFCs) and see if we want to push some of them to standards. -- Alex Friday, May 17, 2002, 11:15:20 AM, you wrote: > Would anyone object if we started simply moving documents forward as > standards track? This would mean being 'rude' to ISO, but since being > 'nice' seems to be backfiring... > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg From rja@extremenetworks.com Sat May 18 02:40:33 2002 From: rja@extremenetworks.com (RJ Atkinson) Date: Fri, 17 May 2002 21:40:33 -0400 Subject: [Isis-wg] Message from the ITU In-Reply-To: <3CE53E74.2ABF4DEF@tellabs.com> Message-ID: <3E4551DE-6A00-11D6-85CC-00039357A82A@extremenetworks.com> On Friday, May 17, 2002, at 01:31 , Jonathan Sadler wrote: > However, because the policy of the IESG is that RFCs with Informational > status are not normative, these other standards bodies are unable to > reference them. Actually, that puts the cart in front of the horse. Some standards bodies have no problem referencing Informational RFCs as normative (realising that they aren't IETF standards) in their own contexts. So it isn't IESG policy, but the policies of (ITU, JTC1, ISO, or whoever) about what they will adopt by reference that is the hindrance here. Ran From Internet-Drafts@ietf.org Tue May 21 12:31:36 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 21 May 2002 07:31:36 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt Message-ID: <200205211131.HAA05088@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Recommendations for Interoperable IP Networks using IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-interoperable-00.txt Pages : 19 Date : 20-May-02 'The difference between theory and practice is greater in practice than it is in theory.' (Author unknown) This document discusses a number of differences between the IS-IS protocol as described in ISO 10589 [1] and RFC 1195 [3] and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-interoperable-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-interoperable-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-interoperable-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: <20020520150743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-interoperable-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-interoperable-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520150743.I-D@ietf.org> --OtherAccess-- --NextPart-- From jparker@axiowave.com Tue May 21 15:02:48 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 21 May 2002 10:02:48 -0400 Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C200D0.30303B20 Content-Type: text/plain; charset="iso-8859-1" A small, but very active, subgroup of the WG has been working on this document for the last month. We considered a larger set of issues, and decided not to pursue some. A brief description of those issues is included in the attached document, remaining.dos. Suggestions and edits always welcome: we are still actively revising the last section, on checking the Source ID on point-to-point IIH packets. - jeff parker > 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 : Recommendations for Interoperable IP > Networks using > IS-IS > Author(s) : J. Parker > Filename : draft-ietf-isis-interoperable-00.txt > Pages : 19 > Date : 20-May-02 > > 'The difference between theory and practice is greater in > practice than it is in theory.' (Author unknown) > This document discusses a number of differences between the IS-IS > protocol as described in ISO 10589 [1] and RFC 1195 [3] and the > protocol as it is deployed today. These differences are discussed as > a service to those implementing, testing, and deploying the IS-IS > Protocol to route IP traffic. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-interoperable-00.txt ------_=_NextPart_000_01C200D0.30303B20 Content-Type: text/plain; name="remaining.dos.txt" Content-Disposition: attachment; filename="remaining.dos.txt" Remaining issues 1) 1195 says you set the aggregated metric to the max. metric of aggregated prefixes. There are different algorithms to decide the metric for a summary route. We could use the max, min, or a configured metric. As long as more specific routes are visible and everyone has the same information, the choice of policy will not affect network stability. 2) Documentation of "alternate forms" of route selection (?) The original topic was the "8 bit" metric. Discussion has suggested that this was a bug that has been fixed, and does not need to be further documented. Note that RFC 2966 has a good discussion about how to compare different metrics. 3) Rules for advertising reachability information Redistributed routes (deprecate external metric) Directly attached routes The redistibution of routes from one protocol to another is often controlled by policy. As long as routers don't originate routes that they don't use, the network should be able to produce consistent routing tables. 4) A description of flooding the new way (with per circuit flooding parameters, inter-LSP gaps, etc). Originally LSP transmission throttling was only defined for LAN circuits, but most implementation now provide it for pt-pt circuits as well. The throttling is to do with the total LSP transmission rate of all LSPs (new or re-transmissions) over a particular circuit. minLSPtransInt is to do with the re-transmission rate of a particular LSP. Mike [Shand] ------_=_NextPart_000_01C200D0.30303B20-- From joyal@lucent.com Thu May 23 19:04:08 2002 From: joyal@lucent.com (Joyal, Daniel R (Daniel)) Date: Thu, 23 May 2002 14:04:08 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: Hi Jeff, There's a couple things I couldn't find in the IS-IS MIB. I don't know if I overlooked them or whether they are defined in some other MIB. Specifically, I couldn't find a System ID to Hostname mapping table per RFC 2763 and I couldn't find tables for the L1 and L2 LSP databases (analagous to the OSPF LSDB tables). Can you point me in the right direction? Thanks. -Dan From jparker@axiowave.com Thu May 23 19:37:38 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 23 May 2002 14:37:38 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: > Hi Jeff, > > There's a couple things I couldn't find in the > IS-IS MIB. I don't know if I overlooked them or > whether they are defined in some other MIB. Specifically, > I couldn't find a System ID to Hostname mapping table > per RFC 2763 and I couldn't find tables for the L1 > and L2 LSP databases (analagous to the OSPF LSDB tables). > Can you point me in the right direction? > > Thanks. > -Dan Dan - Neither of those have been implemented in the ISIS mib as it exists today. I will put this on my mib to-do list. Any objectors, speak up now. The mib was recently rev'd, but there is other pending work to reorganize the system and circuit counters. In your work on the OSPF mib, did you find access to the LSAs to be useful? Those are big uninterpreted octet strings, much longer than the usual 255 bytes. It is good to have an SNMP maven looking things over. Please let me know about issues you see, and problems we might have moving through the official wickets. - jeff parker From joyal@lucent.com Thu May 23 21:04:20 2002 From: joyal@lucent.com (Joyal, Daniel R (Daniel)) Date: Thu, 23 May 2002 16:04:20 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Thursday, May 23, 2002 2:38 PM To: 'Joyal, Daniel R (Daniel)'; IS-IS-WG (E-mail) Subject: RE: [Isis-wg] IS-IS MIB >> Hi Jeff, >> >> There's a couple things I couldn't find in the >> IS-IS MIB. I don't know if I overlooked them or >> whether they are defined in some other MIB. Specifically, >> I couldn't find a System ID to Hostname mapping table >> per RFC 2763 and I couldn't find tables for the L1 >> and L2 LSP databases (analagous to the OSPF LSDB tables). >> Can you point me in the right direction? >> >> Thanks. >> -Dan > >Dan - > Neither of those have been implemented in >the ISIS mib as it exists today. I will put >this on my mib to-do list. Any objectors, >speak up now. > > The mib was recently rev'd, but there >is other pending work to reorganize the >system and circuit counters. > In your work on the OSPF mib, did you find >access to the LSAs to be useful? Those are >big uninterpreted octet strings, much longer >than the usual 255 bytes. The OSPF LSDB table structure has been around a long time. The tables break out the header information into separate objects and define a single object for the entire LSA (header and contents). If the LSA gets 'too big', an SNMP agent may not be able to satisfy a get/getnext request for the LSA object. It's probably reasonable to at least define L1 and L2 LSP Header tables. A more complex implementation could break out LSPs' TLVs into separate per LSP TLV tables to enable the entire LSP to be retrieved in pieces. -Dan > > It is good to have an SNMP maven looking >things over. Please let me know about issues >you see, and problems we might have moving through >the official wickets. > >- jeff parker From jparker@axiowave.com Thu May 23 21:16:31 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 23 May 2002 16:16:31 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: > > In your work on the OSPF mib, did you find > >access to the LSAs to be useful? Those are > >big uninterpreted octet strings, much longer > >than the usual 255 bytes. > > The OSPF LSDB table structure has been around a long time. > The tables break out the header information > into separate objects and define a single object > for the entire LSA (header and contents). If the > LSA gets 'too big', an SNMP agent may not be able to > satisfy a get/getnext request for the LSA object. > > It's probably reasonable to at least define L1 and L2 > LSP Header tables. A more complex implementation could > break out LSPs' TLVs into separate per LSP TLV tables > to enable the entire LSP to be retrieved in pieces. > > -Dan Dan - Can we rewind that, please? I think you are reminding me of why this was a problem in the first place. An agent may not be able to satisfy a get request for the LSA object? Is this due to a small SNMP buffer size and the lack of a defined way to fragment payload? If an IS has two non-pnode LSPs, one of them is bound to be over 1K. If this is too big, we have a problem. We could split this into globs in the mib, but there is no natural way to do this, other than "first glob, second glob" etc. I am uncomfortable with splitting this into tables based on the type, as I suspect this will mask issues that we might see. I admit that the order shouldn't matter, as long as we know which fragment a TLV sat in. - jeff parker From Yongjun Im" I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow routers or switches supporting an IS-IS over IPv4 encapsulation as well as a data link layer encapsulation ? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? 4. Is there any internet draft that defines the IS-IS over IPv4 encapsulation, or just a prorietary encapsulation? Any response will be greatly appreciated. Yongjun. --- Yongjun Im System Software Gr., Core Network Research Lab. LG Electronics, Inc. From VishwasM@netplane.com Mon May 27 08:03:18 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Mon, 27 May 2002 03:03:18 -0400 Subject: [Isis-wg] IS-IS over IPv4 encapsulation Message-ID: Hi Yogjun, A draft for ISIS over IPv4 exists at http://www.watersprings.org/pub/id/draft-ietf-isis-wg-over-ip-02.txt, it has long expired though. >From the archives it seems there wasn't much traction behind the draft, check the links http://external.juniper.net/pipermail/isis- wg/2000/000156.html http://external.juniper.net/pipermail/isis-wg/2000/000159.html Thanks, Vishwas -----Original Message----- From: Yongjun Im [mailto:yjim@lge.com] Sent: Monday, May 27, 2002 11:39 AM To: isis-wg@spider.juniper.net Subject: [Isis-wg] IS-IS over IPv4 encapsulation I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow routers or switches supporting an IS-IS over IPv4 encapsulation as well as a data link layer encapsulation ? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? 4. Is there any internet draft that defines the IS-IS over IPv4 encapsulation, or just a prorietary encapsulation? Any response will be greatly appreciated. Yongjun. --- Yongjun Im System Software Gr., Core Network Research Lab. LG Electronics, Inc. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Fri May 24 03:25:01 2002 From: Alex Zinin (Alex Zinin) Date: Thu, 23 May 2002 19:25:01 -0700 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: <7730861020.20020523192501@psg.com> Sorry I'm one day late with the comments. > Status ... > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [BCP14]. Pls, move this somewhere within the document (not the Abstract, though, probably the Intro). Also, please go through the text and make sure all occurrences of must/should/may/etc are capitalized when used to express the requirements level. > 1. Introduction > ... > A number of factors can contribute to exceeding this limit: ... > - The growing size of route tables and AS topologies. The size of the RT contributes to the LSP size in case of redistribution and inter-level propagation mentioned in the following item. Here you probably mean the increasing number of destinations (amount of reachability info) to be distributed. > 1.1 Definitions of Commonly Used Terms > > This section provides definitions for terms that are used throughout > the text. > > Originating System > A router running the IS-IS protocol. The term hints there should be some words about LSP origination here. > Original system-id > The system-id of an Originating System. Isn't this supposed to be the "normal" system-id (as opposed to the additional ones)? I mean you should explain what is "original" about it. > Extended system-id Sounds like we're stretching out the normal system-id. Maybe "Virtual system-id" would be a better choice? ... > > Extended LSP > An LSP using an extended system-id in its LSP ID. Same comment about "extended". > 1.2 Operation Modes > > Two administrative operation modes are provided: .. > > These modes may be configured per level. There is no restriction > that an L1/L2 IS operates in the same mode, for both L1 and L2. Shouldn't the modes be on a per-level & area basis. This text also sounds like all routers within a level (or an area if corrected) need to work in the same mode, which is not true, since modified SPF is a requirement regardless of the LSP origination mode. > 2.0 IS Alias ID TLV (IS-A) > > The proposed IS-A TLV allows extension-capable ISs to recognize all > LSPs of an Originating System, and combine the original and extended > LSPs for the purpose of SPF computation. > > The IS Alias ID TLV is type 24, and contains a new data structure, > consisting of: > 7 octets of system Id and pseudonode number > 1 octet of length of sub-TLVs > 0-247 octets of sub-TLVs, > where each sub-TLV consists of a sequence of > 1 octet of sub-type > 1 octet of length > 0-245 octets of value > > Without sub-TLVs, this structure consumes 8 octets per LSP set. This > TLV MUST be included in fragment 0 of every LSP set belonging to an > Originating System. Couldn't find any info on how to put S' and S'' in the TLV. Couldn't find description of any sub-TLVs that would be used to do the above. Couldn't find any rules about sub-TLV handling, i.e., padding and length calculation with it. The format description above should use the illustration style from 1195. > 3.1 Both Operation Modes > > Under both modes, the Originating System MUST include information > binding the Original LSP and the Extended ones. It can do this since > it is trivially an extension-capable IS. This is to ensure other > routers correctly process the extra information in their SPF ^ "implementing this specification" or something like this > 3.1.1 The Attached Bits ... > 3.1.2 The Partition Repair Bit What about the OL bit? > 3.2 Operation Mode 1 Additions ... > When an extended LSP belonging to extended system-id S' is first > created, the original LSP MUST specify S' as a neighbor, with metric > set to zero. This in order to satisfy the two-way connectivity check > on other routers, as well as to consider the cost of reaching the I thought that the S'->S link would be needed to satisfy the TWC check for the S->S' one, not the other way around... > 4. Purging Extended LSP Fragments ... > However, an extended LSP fragment zero should not > be purged until all of the fragments in its set (i.e. belonging to a > particular extended system-id), are empty as well. This is to ensure > implementations consider the fragments in their SPF computations, as > specified in section 7.2.5. Given what section 5 says about ignoring non-0 fragments when fragment zero is missing, what does the above rule give us? > 5. Modifications to LSP handling in SPF ... > If LSP fragment 0 of the original LSP set is missing, all of the LSPs > generated by that Originating System (extended as well) MUST NOT be > considered in the SPF. That is, the large logical LSP isn't > considered in the SPF. If an LSP fragment 0 of an extended LSP set > is missing, only that LSP set MUST NOT be considered in the SPF. This text should also say that fragment 0's RemainingLifetime should be > 0 > 7. Interoperating between extension-capable and non-extension-capable > ISs. ... > It is possible to transition a live network, using the following > steps: > - Upgrade the routers, one-by-one, to run this extension in > Operation Mode 1. The other non-extension-capable routers will > interoperate correctly. > - When all routers are extension-capable, configure them one-by-one > to run in Operation Mode 2. All extension-capable routers > interoperate correctly, regardless of what mode they're run in. We don't have to go through mode-1 to get to mode-2. An upgrade of SW does not necessarily mean changing the LSP origination process. In fact, I would argue that the default setting MUST be the standard one, i.e., neither mode 1 nor mode 2, and it would be really great if this was spelled out. > 9. Acknowledgments > > The author would like to thank Tony Li and Radia Perlman for helpful ^"s" > comments and suggestions on the subject. > 10. References ... > > [ISIS-CODES] Work in progress, "Reserved TLV Codepoints in ISIS", T. > Przygienda Unused ref. Check if you have others. > 11. Authors' Address ^"es" Alex From mshand@cisco.com Fri May 24 09:20:07 2002 From: mshand@cisco.com (mike shand) Date: Fri, 24 May 2002 09:20:07 +0100 Subject: [Isis-wg] draft-ietf-isis-restart-01.txt Message-ID: <4.3.2.7.2.20020524091256.04406478@jaws.cisco.com> Folks, I have submitted a revised version of the restart draft. It should be appearing in the usual place soon. I THINK I have addressed all the comments received on the list. I have retained the non-timer resetting behavior of the RR IIH because I think it is useful in some cases but have noted that if you want the resetting behavior you can easily get this by sending a normal IIH once you have acquired the necessary circuit IDs etc. So the way it would work is that you would re-start and get back the remaining time on each adjacency. If this is plenty of time you just carry on as normal. If you feel you need more time (and you are configured to allow that), then you send an IIH with the required holding time. Similarly, I have retained the retries, but said that you may configure a retry count of zero. Mike From joyal@lucent.com Fri May 24 16:48:56 2002 From: joyal@lucent.com (Joyal, Daniel R (Daniel)) Date: Fri, 24 May 2002 11:48:56 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Thursday, May 23, 2002 4:17 PM To: 'Joyal, Daniel R (Daniel)' Cc: IS-IS-WG (E-mail) Subject: RE: [Isis-wg] IS-IS MIB >> > In your work on the OSPF mib, did you find >> >access to the LSAs to be useful? Those are >> >big uninterpreted octet strings, much longer >> >than the usual 255 bytes. >> >> The OSPF LSDB table structure has been around a long time. >> The tables break out the header information >> into separate objects and define a single object >> for the entire LSA (header and contents). If the >> LSA gets 'too big', an SNMP agent may not be able to >> satisfy a get/getnext request for the LSA object. >> >> It's probably reasonable to at least define L1 and L2 >> LSP Header tables. A more complex implementation could >> break out LSPs' TLVs into separate per LSP TLV tables >> to enable the entire LSP to be retrieved in pieces. >> >> -Dan > >Dan - > Can we rewind that, please? I think you are >reminding me of why this was a problem in the first >place. > An agent may not be able to satisfy a get request >for the LSA object? Is this due to a small SNMP buffer >size and the lack of a defined way to fragment payload? Yes. > > If an IS has two non-pnode LSPs, one of them >is bound to be over 1K. If this is too big, we have >a problem. We could split this into globs in the mib, >but there is no natural way to do this, other than >"first glob, second glob" etc. One thought is to define L1 and L2 LSP Header tables indexed by LSPID. These tables would contain only LSP header information in small, fixed-sized objects and provide a summary of the LSP database. I think this, by itself, is useful. For viewing the contents of LSPs, a second set of tables is defined which contains, as row entries, the TLVs belonging to an LSP. If TLV order is not important, the table index could be LSPID, TLV Type, Index where Index is the instance of the TLV type in the LSP. TLV entries should be manageable by SNMP. The drawback is that you don't get a snapshot of the complete LSP contents in one SNMP request, so it is possible that the collection of TLVs returned reflect some transitional state between an old and new LSP instance. Does this scheme sound reasonable? -Dan > I am uncomfortable with splitting this into tables >based on the type, as I suspect this will mask issues >that we might see. I admit that the order shouldn't >matter, as long as we know which fragment a TLV sat in. > >- jeff parker From jparker@axiowave.com Fri May 24 18:59:56 2002 From: jparker@axiowave.com (Jeff Parker) Date: Fri, 24 May 2002 13:59:56 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: > > An agent may not be able to satisfy a get request > >for the LSA object? Is this due to a small SNMP buffer > >size and the lack of a defined way to fragment payload? > > Yes. > One thought is to define L1 and L2 LSP Header tables > indexed by LSPID. These tables would contain only LSP header > information in small, fixed-sized objects and provide a > summary of the LSP > database. I think this, by itself, is useful. An index of the 8 byte LSPID and the sequence number should do the trick. The sequence number addresses the issue you raise below in almost all cases. (the corner case is when a router reboots, and issues a new version of an LSP that is still in circulation. This is a transitory event) > For viewing the contents of LSPs, a second set of tables is > defined which > contains, as row entries, the TLVs belonging to an LSP. If TLV > order is not important, the table index could be LSPID, TLV > Type, Index > where Index is the instance of the TLV type in the LSP. > > TLV entries should be manageable by SNMP. The drawback is that > you don't get a snapshot of the complete LSP contents in one > SNMP request, > so it is possible that the collection of TLVs returned reflect some > transitional state between an old and new LSP instance. > Does this scheme sound reasonable? > > -Dan I'm uncomfortable with splitting an LSP into unordered components, though I don't have a compelling argument. - jeff From VishwasM@netplane.com Wed May 29 13:40:48 2002 From: VishwasM@netplane.com (Manral, Vishwas) Date: Wed, 29 May 2002 08:40:48 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: Jeff, A couple of comments inline prefixed by a "VM>". -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Friday, May 24, 2002 11:30 PM To: 'Joyal, Daniel R (Daniel)'; Jeff Parker Cc: IS-IS-WG (E-mail) Subject: RE: [Isis-wg] IS-IS MIB > > An agent may not be able to satisfy a get request > >for the LSA object? Is this due to a small SNMP buffer > >size and the lack of a defined way to fragment payload? > > Yes. > One thought is to define L1 and L2 LSP Header tables > indexed by LSPID. These tables would contain only LSP header > information in small, fixed-sized objects and provide a > summary of the LSP > database. I think this, by itself, is useful. An index of the 8 byte LSPID and the sequence number should do the trick. The sequence number addresses the issue you raise below in almost all cases. (the corner case is when a router reboots, and issues a new version of an LSP that is still in circulation. This is a transitory event) VM> Maybe the remaining lifetime could be given too. Remaining lifetime is used to identify an instance too, one with 0 Remaininglifetime and one without are different instances. > For viewing the contents of LSPs, a second set of tables is > defined which > contains, as row entries, the TLVs belonging to an LSP. If TLV > order is not important, the table index could be LSPID, TLV > Type, Index > where Index is the instance of the TLV type in the LSP. > > TLV entries should be manageable by SNMP. The drawback is that > you don't get a snapshot of the complete LSP contents in one > SNMP request, > so it is possible that the collection of TLVs returned reflect some > transitional state between an old and new LSP instance. > Does this scheme sound reasonable? > > -Dan I'm uncomfortable with splitting an LSP into unordered components, though I don't have a compelling argument. VM> May be we could have a count of individual TLV's too, which would be equivalent to the number of lsa's of each type. This could help in knowing how many prefixes etc have been injected from other domain/other areas etc. Thanks, Vishwas From satish@pluris.com Wed May 29 20:02:10 2002 From: satish@pluris.com (Satish Dattatri) Date: Wed, 29 May 2002 12:02:10 -0700 Subject: [Isis-wg] IS-IS MIB Message-ID: <17C81AD1F1FED411991E006008F6D1CA029E8300@avalon.pluris.com> Hi, Please see inline ... Thanks, Satish > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Friday, May 24, 2002 11:00 AM > To: 'Joyal, Daniel R (Daniel)'; Jeff Parker > Cc: IS-IS-WG (E-mail) > Subject: RE: [Isis-wg] IS-IS MIB > > > > > An agent may not be able to satisfy a get request > > >for the LSA object? Is this due to a small SNMP buffer > > >size and the lack of a defined way to fragment payload? > > > > Yes. > > > One thought is to define L1 and L2 LSP Header tables > > indexed by LSPID. These tables would contain only LSP header > > information in small, fixed-sized objects and provide a > > summary of the LSP > > database. I think this, by itself, is useful. > > An index of the 8 byte LSPID and the sequence number > should do the trick. The sequence number addresses > the issue you raise below in almost all cases. (the > corner case is when a router reboots, and issues > a new version of an LSP that is still in circulation. > This is a transitory event) > I am not sure why we need the sequence number to be in the index? As far as outside is concerned there is either LSPID A with seq s1 or s2 is part of the LSDB but not *both* s1 and s2. The table needs to have a level-index and the LSPID. The entry that we get will have the LSP header and for display/analysis purposes that can be used. > > For viewing the contents of LSPs, a second set of tables is > > defined which > > contains, as row entries, the TLVs belonging to an LSP. If TLV > > order is not important, the table index could be LSPID, TLV > > Type, Index > > where Index is the instance of the TLV type in the LSP. > > > > TLV entries should be manageable by SNMP. The drawback is that ^^^^^ Apart from being able to do a get is there something more this reqd ? > > you don't get a snapshot of the complete LSP contents in one > > SNMP request, > > so it is possible that the collection of TLVs returned reflect some > > transitional state between an old and new LSP instance. > > Does this scheme sound reasonable? > > > > -Dan > > I'm uncomfortable with splitting an LSP into unordered > components, though I don't have a compelling argument. > too much of housekeeping, depending on how an implementation stores an LSP. On the other hand most implementations have a way to display the LSP in detail, which needs the above table. Is there a way to specify in MIB terms saying optional so that an implementation can be conforming to standard yet not have this table implemented ;-). > - jeff > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From jparker@axiowave.com Wed May 29 20:07:53 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 29 May 2002 15:07:53 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: > > > One thought is to define L1 and L2 LSP Header tables > > > indexed by LSPID. These tables would contain only LSP header > > > information in small, fixed-sized objects and provide a > > > summary of the LSP > > > database. I think this, by itself, is useful. > > > > An index of the 8 byte LSPID and the sequence number > > should do the trick. The sequence number addresses > > the issue you raise below in almost all cases. (the > > corner case is when a router reboots, and issues > > a new version of an LSP that is still in circulation. > > This is a transitory event) > > I am not sure why we need the sequence number to be in the index? > As far as outside is concerned there is either LSPID A with seq > s1 or s2 is part of the LSDB but not *both* s1 and s2. The table > needs to have a level-index and the LSPID. The entry that we get > will have the LSP header and for display/analysis purposes that > can be used. Satish - You are right. There is no need for the sequence number to be in the index. If we return the seq #, we can avoid Dan's issue of mixing parts from different versions of LSP frag X. > > > TLV entries should be manageable by SNMP. The drawback is that > ^^^^^ > Apart from being able to do a get is there something more this reqd ? I agree that it wuold be a mistake for anything other than get. > > I'm uncomfortable with splitting an LSP into unordered > > components, though I don't have a compelling argument. > > too much of housekeeping, depending on how an implementation stores > an LSP. On the other hand most implementations have a way to display > the LSP in detail, which needs the above table. Is there a way to > specify in MIB terms saying optional so that an implementation can > be conforming to standard yet not have this table implemented ;-). Yes, there is a way to mark some things as optional. The MIB today has required tables and optional tables. - jeff parker From joyal@lucent.com Wed May 29 20:36:14 2002 From: joyal@lucent.com (Joyal, Daniel R (Daniel)) Date: Wed, 29 May 2002 15:36:14 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: >> > > One thought is to define L1 and L2 LSP Header tables >> > > indexed by LSPID. These tables would contain only LSP header >> > > information in small, fixed-sized objects and provide a >> > > summary of the LSP >> > > database. I think this, by itself, is useful. >> > >> > An index of the 8 byte LSPID and the sequence number >> > should do the trick. The sequence number addresses >> > the issue you raise below in almost all cases. (the >> > corner case is when a router reboots, and issues >> > a new version of an LSP that is still in circulation. >> > This is a transitory event) >> >> I am not sure why we need the sequence number to be in the index? >> As far as outside is concerned there is either LSPID A with seq >> s1 or s2 is part of the LSDB but not *both* s1 and s2. The table >> needs to have a level-index and the LSPID. The entry that we get >> will have the LSP header and for display/analysis purposes that >> can be used. > >Satish - > You are right. There is no need for the sequence number >to be in the index. If we return the seq #, we can avoid Dan's >issue of mixing parts from different versions of LSP frag X. > > >> > > TLV entries should be manageable by SNMP. The drawback is that >> ^^^^^ >> Apart from being able to do a get is there something more this reqd ? > >I agree that it wuold be a mistake for anything other than get. Bad word choice on my part. I meant the *size* of TLVs should be small enough to fit into SNMP buffers as opposed to the entire LSP fragment. These should be read-only tables. > > >> > I'm uncomfortable with splitting an LSP into unordered >> > components, though I don't have a compelling argument. >> >> too much of housekeeping, depending on how an implementation stores >> an LSP. On the other hand most implementations have a way to display >> the LSP in detail, which needs the above table. Is there a way to >> specify in MIB terms saying optional so that an implementation can >> be conforming to standard yet not have this table implemented ;-). > >Yes, there is a way to mark some things as optional. The MIB >today has required tables and optional tables. I agree that these tables should be optional. -Dan > >- jeff parker From dgoodspe@excite.com Wed May 29 23:24:05 2002 From: dgoodspe@excite.com (Don Goodspeed) Date: Wed, 29 May 2002 18:24:05 -0400 (EDT) Subject: [Isis-wg] IS-IS MIB Message-ID: <20020529222405.E0825B6D7@xmxpita.excite.com> --EXCITEBOUNDARY_000__3536ca3fc140443cd83c35edf41070cc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My 2 cents, Index by the level and the LSP ID. Have an attribute for each of the fixed fields. Have an OCTET-STRING defined attribute as the last entry in the table that contains either: a. The hex dump of the entire LSP, or b. The hex dump of just the variable length fields. The upper bound on the size probably needs to be 65535. Don't worry, SNMP can fragment SNMP replies for the large one. This is essentially how ospfLsdbAdvertisement is defined (it includes the entire header, incidentally). It is up to the management application to do the parsing of the TLVs to get out the needed info, so it's less work on the SNMP agent to track all this info. Cheers, Don --- On Wed 05/29, Joyal, Daniel R (Daniel) wrote: From: Joyal, Daniel R (Daniel) [mailto: joyal@lucent.com] To: jparker@axiowave.com,satish@pluris.com Cc: isis-wg@spider.juniper.net Date: Wed 05/29 Subject: RE: [Isis-wg] IS-IS MIB > > > > > >> > > One thought is to define L1 and L2 LSP Header tables > >> > > indexed by LSPID. These tables would contain only LSP > header > >> > > information in small, fixed-sized objects and provide a > > >> > > summary of the LSP > >> > > database. I think this, by itself, is useful. > >> > > >> > An index of the 8 byte LSPID and the sequence number > >> > should do the trick. The sequence number addresses > >> > the issue you raise below in almost all cases. (the > >> > corner case is when a router reboots, and issues > >> > a new version of an LSP that is still in circulation. > >> > This is a transitory event) > >> > >> I am not sure why we need the sequence number to be in the > index? > >> As far as outside is concerned there is either LSPID A with seq > >> s1 or s2 is part of the LSDB but not *both* s1 and s2. The table > >> needs to have a level-index and the LSPID. The entry that we get > >> will have the LSP header and for display/analysis purposes that > >> can be used. > > > >Satish - > > You are right. There is no need for the sequence number > >to be in the index. If we return the seq #, we can avoid Dan's > >issue of mixing parts from different versions of LSP frag X. > > > > > >> > > TLV entries should be manageable by SNMP. The drawback > is that > >> ^^^^^ > >> Apart from being able to do a get is there something more this > reqd ? > > > >I agree that it wuold be a mistake for anything other than get. > > Bad word choice on my part. I meant the *size* of TLVs should be small > enough to fit into SNMP buffers as opposed to the entire LSP fragment. > These should be read-only tables. > > > > > > >> > I'm uncomfortable with splitting an LSP into unordered > >> > components, though I don't have a compelling argument. > >> > >> too much of housekeeping, depending on how an implementation > stores > >> an LSP. On the other hand most implementations have a way to > display > >> the LSP in detail, which needs the above table. Is there a way > to > >> specify in MIB terms saying optional so that an implementation > can > >> be conforming to standard yet not have this table implemented > ;-). > > > >Yes, there is a way to mark some things as optional. The MIB > >today has required tables and optional tables. > > I agree that these tables should be optional. > > -Dan > > > >- jeff parker > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__3536ca3fc140443cd83c35edf41070cc Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit My 2 cents,

Index by the level and the LSP ID. Have an attribute for each
of the fixed fields. Have an OCTET-STRING defined attribute
as the last entry in the table that contains either:
a. The hex dump of the entire LSP, or
b. The hex dump of just the variable length fields.

The upper bound on the size probably needs to be 65535. Don't
worry, SNMP can fragment SNMP replies for the large one.

This is essentially how ospfLsdbAdvertisement is defined
(it includes the entire header, incidentally). It is up
to the management application to do the parsing of the
TLVs to get out the needed info, so it's less work on
the SNMP agent to track all this info.

Cheers,
Don

--- On Wed 05/29, Joyal, Daniel R (Daniel) < joyal@lucent.com > wrote:
From: Joyal, Daniel R (Daniel) [mailto: joyal@lucent.com]
To: jparker@axiowave.com,satish@pluris.com
Cc: isis-wg@spider.juniper.net
Date: Wed 05/29
Subject: RE: [Isis-wg] IS-IS MIB
>
>
>
>
> >> > > One thought is to define L1 and L2 LSP Header tables
> >> > > indexed by LSPID. These tables would contain only LSP
> header
> >> > > information in small, fixed-sized objects and provide a
>
> >> > > summary of the LSP
> >> > > database. I think this, by itself, is useful.
> >> >
> >> > An index of the 8 byte LSPID and the sequence number
> >> > should do the trick. The sequence number addresses
> >> > the issue you raise below in almost all cases. (the
> >> > corner case is when a router reboots, and issues
> >> > a new version of an LSP that is still in circulation.
> >> > This is a transitory event)
> >>
> >> I am not sure why we need the sequence number to be in the
> index?
> >> As far as outside is concerned there is either LSPID A with seq
> >> s1 or s2 is part of the LSDB but not *both* s1 and s2. The table
> >> needs to have a level-index and the LSPID. The entry that we get
> >> will have the LSP header and for display/analysis purposes that
> >> can be used.
> >
> >Satish -
> > You are right. There is no need for the sequence number
> >to be in the index. If we return the seq #, we can avoid Dan's
> >issue of mixing parts from different versions of LSP frag X.
> >
> >
> >> > > TLV entries should be manageable by SNMP. The drawback
> is that
> >> ^^^^^
> >> Apart from being able to do a get is there something more this
> reqd ?
> >
> >I agree that it wuold be a mistake for anything other than get.
>
> Bad word choice on my part. I meant the *size* of TLVs should be small
> enough to fit into SNMP buffers as opposed to the entire LSP fragment.
> These should be read-only tables.
>
> >
> >
> >> > I'm uncomfortable with splitting an LSP into unordered
> >> > components, though I don't have a compelling argument.
> >>
> >> too much of housekeeping, depending on how an implementation
> stores
> >> an LSP. On the other hand most implementations have a way to
> display
> >> the LSP in detail, which needs the above table. Is there a way
> to
> >> specify in MIB terms saying optional so that an implementation
> can
> >> be conforming to standard yet not have this table implemented
> ;-).
> >
> >Yes, there is a way to mark some things as optional. The MIB
> >today has required tables and optional tables.
>
> I agree that these tables should be optional.
>
> -Dan
> >
> >- jeff parker
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>

Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__3536ca3fc140443cd83c35edf41070cc-- From amir@cwnt.com Thu May 30 16:09:47 2002 From: amir@cwnt.com (Amir Hermelin) Date: Thu, 30 May 2002 18:09:47 +0300 Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: Alex, comments inline. Thanks very much for the helpful comments and suggestions. As always, other suggetions, especially for terminology, are more than welcomed. -- Amir Hermelin < mailto:amir@cwnt.com> Charlotte's Web Networks Inc. < http://www.cwnt.com> > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Friday, May 24, 2002 5:25 AM > To: isis-wg@juniper.net > Subject: Re: [Isis-wg] last call on draft > draft-ietf-isis-ext-lsp-frags-00 ... > > > Sorry I'm one day late with the comments. > > > Status > ... > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this > > document are to be interpreted as described in RFC 2119 [BCP14]. > > Pls, move this somewhere within the document (not the Abstract, > though, probably the Intro). > right. I'll put this into a subsection of the Introduction section. > Also, please go through the text and make sure all occurrences of > must/should/may/etc are capitalized when used to express the > requirements level. > > > 1. Introduction > > > ... > > A number of factors can contribute to exceeding this limit: > ... > > - The growing size of route tables and AS topologies. > > The size of the RT contributes to the LSP size in case > of redistribution and inter-level propagation mentioned > in the following item. Here you probably mean the increasing > number of destinations (amount of reachability info) to > be distributed. agreed. Will re-word. > > > 1.1 Definitions of Commonly Used Terms > > > > This section provides definitions for terms that are > used throughout > > the text. > > > > Originating System > > A router running the IS-IS protocol. > > The term hints there should be some words about LSP origination here. I agree it might be a little ambigous here, although when terming "LSP origination", it does appear to routers as if Extended (or Virtual) systems also originate LSPs. I'll think of an additional desciprtion here. > > > Original system-id > > The system-id of an Originating System. > > Isn't this supposed to be the "normal" system-id (as opposed > to the additional ones)? I mean you should explain what > is "original" about it. > probably bad naming on my behalf. I'll confer the other authors for a better term. I agree it's important, not only because of the document, but also because this will probably be the term presented to users of routers. > > Extended system-id > > Sounds like we're stretching out the normal system-id. > Maybe "Virtual system-id" would be a better choice? > again, could be bad naming. However, I originally thought "Virtual" to be a little confusing, as a "virtual link" term is already used in the IS-IS spec, for a completely different purpose. The draft uses "extended" for LSPs, since they really extend the original LS information an IS could advertise, as opposed to "Virtual System", which doesn't really add any additional info. Does that make sense? > ... > > > > Extended LSP > > An LSP using an extended system-id in its LSP ID. > > Same comment about "extended". > > > 1.2 Operation Modes > > > > Two administrative operation modes are provided: > .. > > > > These modes may be configured per level. There is no restriction > > that an L1/L2 IS operates in the same mode, for both L1 and L2. > > Shouldn't the modes be on a per-level & area basis. This > text also sounds like all routers within a level (or an area > if corrected) need to work in the same mode, which is not true, > since modified SPF is a requirement regardless of the LSP > origination mode. agreed, that's the original intent. I'll add "per area". The actual requirement is "per spf", but I think it will confuse more than it will clarify. > > > 2.0 IS Alias ID TLV (IS-A) > > > > The proposed IS-A TLV allows extension-capable ISs to > recognize all > > LSPs of an Originating System, and combine the original > and extended > > LSPs for the purpose of SPF computation. > > > > The IS Alias ID TLV is type 24, and contains a new data > structure, > > consisting of: > > 7 octets of system Id and pseudonode number > > 1 octet of length of sub-TLVs > > 0-247 octets of sub-TLVs, > > where each sub-TLV consists of a sequence of > > 1 octet of sub-type > > 1 octet of length > > 0-245 octets of value > > > > Without sub-TLVs, this structure consumes 8 octets per > LSP set. This > > TLV MUST be included in fragment 0 of every LSP set > belonging to an > > Originating System. > > Couldn't find any info on how to put S' and S'' in the TLV. > Actually, what you need to put here is S (or the is-alias-id, which could be different). The S' and S'' (and also S) appear in the LSP header. > Couldn't find description of any sub-TLVs that would be > used to do the above. It's just put there for future or proprietary use - doesn't take up any space, I think we should keep it. > > Couldn't find any rules about sub-TLV handling, i.e., padding > and length calculation with it. > > The format description above should use the illustration > style from 1195. I don't fully understand what's missing, but I will add an example. I've used the format from the TE-extensions draft, which I think to be clear and well-discussed. Please clarify what you'd like to see here. > > > 3.1 Both Operation Modes > > > > Under both modes, the Originating System MUST include information > > binding the Original LSP and the Extended ones. It can > do this since > > it is trivially an extension-capable IS. This is to ensure other > > routers correctly process the extra information in their SPF > ^ > "implementing this specification" or something like this added. > > > 3.1.1 The Attached Bits > ... > > 3.1.2 The Partition Repair Bit > > What about the OL bit? The 3.1.* sections are exceptions. The OL bit should be set/unset in original and extended LSPs the same as before. > > > 3.2 Operation Mode 1 Additions > ... > > When an extended LSP belonging to extended system-id S' is first > > created, the original LSP MUST specify S' as a neighbor, > with metric > > set to zero. This in order to satisfy the two-way > connectivity check > > on other routers, as well as to consider the cost of reaching the > > I thought that the S'->S link would be needed to satisfy > the TWC check for the S->S' one, not the other way around... > Depends on which node (S or S') was first considered in SPF. In Mode 1, it's true that always S will be reached first, but this isn't guaranteed in mode 2. > > > 4. Purging Extended LSP Fragments > ... > > However, an extended LSP fragment > zero should not > > be purged until all of the fragments in its set (i.e. > belonging to a > > particular extended system-id), are empty as well. This > is to ensure > > implementations consider the fragments in their SPF > computations, as > > specified in section 7.2.5. > > Given what section 5 says about ignoring non-0 fragments when > fragment zero is missing, what does the above rule give us? > the above rule is specifically to ensure section 5 works well: if we have info in other fragments, but the zero-fragment is empty (and we don't re-arrange information, as we shouldn't), we still need to keep that fragment so other fragments are considered. I guess this is true regardless of this draft or not - we just wanted to clarify it. > > 5. Modifications to LSP handling in SPF > ... > > If LSP fragment 0 of the original LSP set is missing, > all of the LSPs > > generated by that Originating System (extended as well) > MUST NOT be > > considered in the SPF. That is, the large logical LSP isn't > > considered in the SPF. If an LSP fragment 0 of an > extended LSP set > > is missing, only that LSP set MUST NOT be considered in the SPF. > > This text should also say that fragment 0's RemainingLifetime > should be > 0 > right you are! > > 7. Interoperating between extension-capable and > non-extension-capable > > ISs. > ... > > It is possible to transition a live network, using the following > > steps: > > - Upgrade the routers, one-by-one, to run this extension in > > Operation Mode 1. The other non-extension-capable routers will > > interoperate correctly. > > - When all routers are extension-capable, configure > them one-by-one > > to run in Operation Mode 2. All extension-capable routers > > interoperate correctly, regardless of what mode they're run in. > > We don't have to go through mode-1 to get to mode-2. An upgrade of > SW does not necessarily mean changing the LSP origination process. > In fact, I would argue that the default setting MUST be the standard > one, i.e., neither mode 1 nor mode 2, and it would be really great > if this was spelled out. > Your upgrade option is identical to what the draft suggests - since "standard one" is really Mode 1 (you can either have mode-1 or mode-2). The difference between mode-1 and the "standard" way, is that the standard way asserts when the maximum fragments are reached ;-) There's also the additional tlv, but there's no harm in advertising it. > > 9. Acknowledgments > > > > The author would like to thank Tony Li and Radia Perlman > for helpful > ^"s" > whoops... > > comments and suggestions on the subject. > > > > 10. References > ... > > > > [ISIS-CODES] Work in progress, "Reserved TLV Codepoints > in ISIS", T. > > Przygienda > > Unused ref. Check if you have others. > > > 11. Authors' Address > ^"es" > whoops again... > Alex > Thanks! very helpful comments! > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From jparker@axiowave.com Wed May 29 23:35:54 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 29 May 2002 18:35:54 -0400 Subject: [Isis-wg] IS-IS MIB Message-ID: > Index by the level and the LSP ID. Have an attribute for each > of the fixed fields. Have an OCTET-STRING defined attribute > as the last entry in the table that contains either: > a. The hex dump of the entire LSP, or > b. The hex dump of just the variable length fields. > The upper bound on the size probably needs to be 65535. Don't > worry, SNMP can fragment SNMP replies for the large one. > Don Don - I was under the impression that SNMP couldn't deal with 1492 byte or larger objects. If it can, I would be happy to package up the whole LSP and ship it over so that the clients can do what they like. But Dan suggested last week that this is not possible. Is there a MIB Doctor in the house? Can we get a ruling on shiping 1492 to 4K to larger yet blobs as one object? - jeff parker From dgoodspe@excite.com Wed May 29 23:59:43 2002 From: dgoodspe@excite.com (Don Goodspeed) Date: Wed, 29 May 2002 18:59:43 -0400 (EDT) Subject: [Isis-wg] IS-IS MIB Message-ID: <20020529225943.A75B0B703@xmxpita.excite.com> --EXCITEBOUNDARY_000__ca2f9217153105b14d6115f674a6d6c6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If supported, IP can fragment the SNMP Response PDU if it's larger than the MTU. I've tested this before with large OSPF router LSAs. (I test both IGP protocols and SNMP, btw). The only references to large PDUs in SMIv2 I can find are a warning on any octet string over 255 characters, and having the ability to give a "tooBig" error if a local constraint is exceeded on the agent. -don --- On Wed 05/29, Jeff Parker wrote: From: Jeff Parker [mailto: jparker@axiowave.com] To: dgoodspe@excite.com,joyal@lucent.com,jparker@axiowave.com,satish@pluris.com Cc: isis-wg@spider.juniper.net,jhalpin@charter.net,bwijnen@lucent.com Date: Wed 05/29 Subject: RE: [Isis-wg] IS-IS MIB > > Index by the level and the LSP ID. Have an attribute for each > > of the fixed fields. Have an OCTET-STRING defined attribute > > as the last entry in the table that contains either: > > a. The hex dump of the entire LSP, or > > b. The hex dump of just the variable length fields. > > > The upper bound on the size probably needs to be 65535. Don't > > worry, SNMP can fragment SNMP replies for the large one. > > > Don > > Don - > I was under the impression that SNMP couldn't deal with > 1492 byte or larger objects. If it can, I would be happy to > package up the whole LSP and ship it over so that the clients > can do what they like. > But Dan suggested last week that this is not possible. > > Is there a MIB Doctor in the house? Can we get a ruling > on shiping 1492 to 4K to larger yet blobs as one object? > > - jeff parker > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__ca2f9217153105b14d6115f674a6d6c6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit If supported, IP can fragment the SNMP Response PDU if it's
larger than the MTU. I've tested this before with large OSPF
router LSAs. (I test both IGP protocols and SNMP, btw).

The only references to large PDUs in SMIv2 I can find are a
warning on any octet string over 255 characters, and having the
ability to give a "tooBig" error if a local constraint is exceeded
on the agent.

-don

--- On Wed 05/29, Jeff Parker < jparker@axiowave.com > wrote:
From: Jeff Parker [mailto: jparker@axiowave.com]
To: dgoodspe@excite.com,joyal@lucent.com,jparker@axiowave.com,satish@pluris.com
Cc: isis-wg@spider.juniper.net,jhalpin@charter.net,bwijnen@lucent.com
Date: Wed 05/29
Subject: RE: [Isis-wg] IS-IS MIB
> > Index by the level and the LSP ID. Have an attribute for each
> > of the fixed fields. Have an OCTET-STRING defined attribute
> > as the last entry in the table that contains either:
> > a. The hex dump of the entire LSP, or
> > b. The hex dump of just the variable length fields.
>
> > The upper bound on the size probably needs to be 65535. Don't
> > worry, SNMP can fragment SNMP replies for the large one.
>
> > Don
>
> Don -
> I was under the impression that SNMP couldn't deal with
> 1492 byte or larger objects. If it can, I would be happy to
> package up the whole LSP and ship it over so that the clients
> can do what they like.
> But Dan suggested last week that this is not possible.
>
> Is there a MIB Doctor in the house? Can we get a ruling
> on shiping 1492 to 4K to larger yet blobs as one object?
>
> - jeff parker
>

Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__ca2f9217153105b14d6115f674a6d6c6-- From Alex Zinin Sat May 25 02:33:50 2002 From: Alex Zinin (Alex Zinin) Date: Fri, 24 May 2002 18:33:50 -0700 Subject: Fwd: Re: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: <4911805270.20020524183350@psg.com> Haven't seen this getting through to the list for some reason... This is a forwarded message From: Alex Zinin To: isis-wg@juniper.net Cc: Date: Thursday, May 23, 2002, 7:25:01 PM Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... ===8<==============Original message text=============== Sorry I'm one day late with the comments. > Status ... > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [BCP14]. Pls, move this somewhere within the document (not the Abstract, though, probably the Intro). Also, please go through the text and make sure all occurrences of must/should/may/etc are capitalized when used to express the requirements level. > 1. Introduction > ... > A number of factors can contribute to exceeding this limit: ... > - The growing size of route tables and AS topologies. The size of the RT contributes to the LSP size in case of redistribution and inter-level propagation mentioned in the following item. Here you probably mean the increasing number of destinations (amount of reachability info) to be distributed. > 1.1 Definitions of Commonly Used Terms > > This section provides definitions for terms that are used throughout > the text. > > Originating System > A router running the IS-IS protocol. The term hints there should be some words about LSP origination here. > Original system-id > The system-id of an Originating System. Isn't this supposed to be the "normal" system-id (as opposed to the additional ones)? I mean you should explain what is "original" about it. > Extended system-id Sounds like we're stretching out the normal system-id. Maybe "Virtual system-id" would be a better choice? ... > > Extended LSP > An LSP using an extended system-id in its LSP ID. Same comment about "extended". > 1.2 Operation Modes > > Two administrative operation modes are provided: .. > > These modes may be configured per level. There is no restriction > that an L1/L2 IS operates in the same mode, for both L1 and L2. Shouldn't the modes be on a per-level & area basis. This text also sounds like all routers within a level (or an area if corrected) need to work in the same mode, which is not true, since modified SPF is a requirement regardless of the LSP origination mode. > 2.0 IS Alias ID TLV (IS-A) > > The proposed IS-A TLV allows extension-capable ISs to recognize all > LSPs of an Originating System, and combine the original and extended > LSPs for the purpose of SPF computation. > > The IS Alias ID TLV is type 24, and contains a new data structure, > consisting of: > 7 octets of system Id and pseudonode number > 1 octet of length of sub-TLVs > 0-247 octets of sub-TLVs, > where each sub-TLV consists of a sequence of > 1 octet of sub-type > 1 octet of length > 0-245 octets of value > > Without sub-TLVs, this structure consumes 8 octets per LSP set. This > TLV MUST be included in fragment 0 of every LSP set belonging to an > Originating System. Couldn't find any info on how to put S' and S'' in the TLV. Couldn't find description of any sub-TLVs that would be used to do the above. Couldn't find any rules about sub-TLV handling, i.e., padding and length calculation with it. The format description above should use the illustration style from 1195. > 3.1 Both Operation Modes > > Under both modes, the Originating System MUST include information > binding the Original LSP and the Extended ones. It can do this since > it is trivially an extension-capable IS. This is to ensure other > routers correctly process the extra information in their SPF ^ "implementing this specification" or something like this > 3.1.1 The Attached Bits ... > 3.1.2 The Partition Repair Bit What about the OL bit? > 3.2 Operation Mode 1 Additions ... > When an extended LSP belonging to extended system-id S' is first > created, the original LSP MUST specify S' as a neighbor, with metric > set to zero. This in order to satisfy the two-way connectivity check > on other routers, as well as to consider the cost of reaching the I thought that the S'->S link would be needed to satisfy the TWC check for the S->S' one, not the other way around... > 4. Purging Extended LSP Fragments ... > However, an extended LSP fragment zero should not > be purged until all of the fragments in its set (i.e. belonging to a > particular extended system-id), are empty as well. This is to ensure > implementations consider the fragments in their SPF computations, as > specified in section 7.2.5. Given what section 5 says about ignoring non-0 fragments when fragment zero is missing, what does the above rule give us? > 5. Modifications to LSP handling in SPF ... > If LSP fragment 0 of the original LSP set is missing, all of the LSPs > generated by that Originating System (extended as well) MUST NOT be > considered in the SPF. That is, the large logical LSP isn't > considered in the SPF. If an LSP fragment 0 of an extended LSP set > is missing, only that LSP set MUST NOT be considered in the SPF. This text should also say that fragment 0's RemainingLifetime should be > 0 > 7. Interoperating between extension-capable and non-extension-capable > ISs. ... > It is possible to transition a live network, using the following > steps: > - Upgrade the routers, one-by-one, to run this extension in > Operation Mode 1. The other non-extension-capable routers will > interoperate correctly. > - When all routers are extension-capable, configure them one-by-one > to run in Operation Mode 2. All extension-capable routers > interoperate correctly, regardless of what mode they're run in. We don't have to go through mode-1 to get to mode-2. An upgrade of SW does not necessarily mean changing the LSP origination process. In fact, I would argue that the default setting MUST be the standard one, i.e., neither mode 1 nor mode 2, and it would be really great if this was spelled out. > 9. Acknowledgments > > The author would like to thank Tony Li and Radia Perlman for helpful ^"s" > comments and suggestions on the subject. > 10. References ... > > [ISIS-CODES] Work in progress, "Reserved TLV Codepoints in ISIS", T. > Przygienda Unused ref. Check if you have others. > 11. Authors' Address ^"es" Alex ===8<===========End of original message text=========== -- Alex From Yongjun Im" I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. From Yongjun Im" I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. From Yongjun Im" I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. From Yongjun Im" I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. From Yongjun Im" I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. From Yongjun Im" I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow a router or switch supporting IS-IS over IPv4 encapsulation? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? Any response will be greatly appreciated. Yongjun. From Tony.Li@procket.com Fri May 17 08:04:43 2002 From: Tony.Li@procket.com (Tony Li) Date: Fri, 17 May 2002 00:04:43 -0700 Subject: [Isis-wg] Message from the ITU Message-ID: An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.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 Tony.Li@procket.com Fri May 17 08:04:43 2002 From: Tony.Li@procket.com (Tony Li) Date: Fri, 17 May 2002 00:04:43 -0700 Subject: [Isis-wg] Message from the ITU Message-ID: An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.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 Tony.Li@procket.com Fri May 17 08:04:43 2002 From: Tony.Li@procket.com (Tony Li) Date: Fri, 17 May 2002 00:04:43 -0700 Subject: [Isis-wg] Message from the ITU Message-ID: An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.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 Tony.Li@procket.com Fri May 17 08:04:43 2002 From: Tony.Li@procket.com (Tony Li) Date: Fri, 17 May 2002 00:04:43 -0700 Subject: [Isis-wg] Message from the ITU Message-ID: An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.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 Tony.Li@procket.com Fri May 17 08:04:43 2002 From: Tony.Li@procket.com (Tony Li) Date: Fri, 17 May 2002 00:04:43 -0700 Subject: [Isis-wg] Message from the ITU Message-ID: An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.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 Tony.Li@procket.com Fri May 17 08:04:43 2002 From: Tony.Li@procket.com (Tony Li) Date: Fri, 17 May 2002 00:04:43 -0700 Subject: [Isis-wg] Message from the ITU Message-ID: An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.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 Tony.Li@procket.com Fri May 17 08:04:43 2002 From: Tony.Li@procket.com (Tony Li) Date: Fri, 17 May 2002 00:04:43 -0700 Subject: [Isis-wg] Message from the ITU Message-ID: An out of the box alternative is for the IS-IS WG to simply be 'rude' and put its documents on the standards track. Any objections? Tony | -----Original Message----- | From: Les Ginsberg [mailto:ginsberg@pluris.com] | Sent: Thursday, May 16, 2002 6:35 PM | To: 'RJ Atkinson'; jonathan.sadler@tellabs.com | Cc: isis-wg@spider.juniper.net | Subject: RE: [Isis-wg] Message from the ITU | | | Having worked on the ISO 10589:2001 draft within ISO, I | would be very | surprised to learn that ANSI thinks it owns the IS-IS | spec. As far as I | know it is owned by JTC1/SC6/WG7. | | More importantly, your mail states that the reason IS-IS WG | drafts are on | the Informational track is because the IETF does not own the IS-IS | specification and therefore does not feel it in its purview | to define | extensions to the protocol which are "standards". If true, | this would | suggest that it is necessary that either: | | a)ISO have procedures to incorporate IS-IS WG RFCs into ISO | documents | b)IETF be empowered to issue IS-IS extensions which are standards | c)IETF take ownership of the IS-IS standard | | Having spoken to both IETF and ISO leadership on this | issue, I have no | reason to think that any solution to this impasse | acceptable to both sides | has been offered. | | Given that we have even more compelling reasons now to want | to fix this, I | would hope that leadership on "all sides of the aisle" | would find a way to | make Ran's fantasy come true. | | Les | | | > | > | > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: | > > This is why I wish that the IS-IS working group could have | > its drafts | > > achive Standards track. Then they would be available | as normative | > > references to other bodies, such as the ITU. | > > | > > Unfortunately, as I understand it, the IETF is | sensative to JTC1's | > > "ownership" of IS-IS and therefore the RFCs are limited to | > Informational | > > status at best. | > | > IETF has asked (formally) ANSI, who apparently really are the | > standards | > body for IS-IS under ISO (ANSI rather than JTC1) about | handing over | > change control | > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) | reports that I | > hear are | > that ANSI either didn't respond or said "no we don't want | to do that". | > | > IETF is not publishing IS-IS stuff as standards-track because | > change-control hasn't been handed over to IETF from ANSI. | > | > Consequently, I find this whole thread a bit confusing. | > Perhaps others | > also do. | > | > A fantasy that occurs to me right now would be to get the | IETF IS-IS | > chairs, the applicable ANSI folks, the applicable JTC1 folks, and | > the applicable ITU-T folks all in the same room -- with a goal of | > trying to find some more productive process and path forwards | > for all of us. | > | > Ran | > rja@extremenetworks.com | > | > _______________________________________________ | > Isis-wg mailing list - Isis-wg@spider.juniper.net | > http://spider.juniper.net/mailman/listinfo/isis-wg | > | _______________________________________________ | Isis-wg mailing list - Isis-wg@spider.juniper.net | http://spider.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 Internet-Drafts@ietf.org Tue May 28 12:40:37 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 28 May 2002 07:40:37 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-restart-01.txt Message-ID: <200205281140.HAA13134@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Restart signaling for ISIS Author(s) : M. Shand Filename : draft-ietf-isis-restart-01.txt Pages : 10 Date : 24-May-02 The IS-IS routing protocol (RFC 1142 [2], ISO/IEC 10589 [3]) is a link state intra-domain routing protocol. Normally, when an IS-IS router is re-started, the neighboring routers detect the restart event and cycle their adjacencies with the restarting router through the down state. This is necessary in order to invoke the protocol mechanisms to ensure correct re-synchronization of the LSP database. However, the cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes temporary disruption of routes passing through the restarting router. In certain scenarios such temporary disruption of the routes is highly undesirable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-restart-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-restart-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-restart-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: <20020524143520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-restart-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-restart-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020524143520.I-D@ietf.org> --OtherAccess-- --NextPart-- From jparker@axiowave.com Tue May 28 15:43:00 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 28 May 2002 10:43:00 -0400 Subject: [Isis-wg] IS-IS over IPv4 encapsulation Message-ID: > I would like to ask a couple of questions regarding IS-IS > [IP] protocol encapsulation. Yongjun - As I recall, the main push for this was to avoid the 'cell tax' over ATM. The reasoning went something like the following. If you have OSI and IP traffic on a link, you will need to encapsulate them to distinguish them If you encapsulate, you will need extra bytes If you have extra bytes, the IP Ack, which is very common, takes 2 ATM cells rather than 1, which leads to a decrease in the amount of traffic your link can take. Henk Smit came up with a proposal to use the fact that the first nibble of the packet can distinguish IP v4, IP v6, and OSI. (0x4, 0x6, and 0x8). Thus people could use the null-encapsulation and avoid the cell tax. After Henk's proposal, I didn't hear much about IP encapsulation for IS-IS. Others may have a different memory. I think GateD did ship a version with IP encapsulation, but you should contact them directly to see if this is something they plan to support going forward. - jeff parker - axiowave networks From jparker@axiowave.com Thu May 30 19:21:13 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 30 May 2002 14:21:13 -0400 Subject: [Isis-wg] Limits on size of OctetString in SNMP Message-ID: We moved the discussion of SNMP limits over to the mibs mailing list for a bit. The ruling from Steve Moulton (below) is that the issue is the convention between manager and agent about max buffer size, rather than intrinsic SNMP limits. Assuming this, I'll adopt the proposal that several folks have floated Provide a (required) table indexed by level and 8-byte LSP-ID of header info. All agents and managers should be able to cope with this. Provide an optional table, indexed the same way, with an octet string pegged to the size of originate LX Buffer Size. - jeff parker - axiowave networks On Thursday, May 30 2002, Jeff Parker wrote: > Bert W. has suggested I take the following question to the mibs group. > > ISIS defines an object called a Link State PDU (Protocol Data Unit) or LSP. > Since ISIS does not fragment, the LSP is designed to be as big at the MTU > will allow. The max size of LSPs is often 1492, though there are provisions > to make the MTU large in networks with all point-2-point links, so the LSP > can be 4K or larger. > > The LSP is a fundamental object in the IS-IS world, and many systems provide > a command that shows the user the LSP broken down into components. Thus > there is interest in providing an SNMP get for the LSP. (Set is not > appropriate) The question before us is > > Can we in good conscience define an SNMP object that is bigger than > 1472 bytes? > > If so, and applying the salami principle, does 4K break things? 9K? > > > - jeff parker > - axiowave networks > - All those who believe in psychokinesis, raise my hand. Hello, Jeff, et al, There is no fundamental problem with having an object of the size you suggest in SNMP. There are some considerations to bear in mind. . If the object size plus packet overhead is larger than the MTU for the entire path from the agent to the manager, the packet will get fragmented at the IP level, and reassembled at the destination. This has no bearing directly on the SNMP implementation, but does increase the probability that the datagram cannot be reassembled due to one or more of the fragments getting lost. Datagrams that cannot be reassembled are silently dropped. The only action one might take here is to increase the number of times the manager retries sending the request before it decides that it cannot communicate with the agent. Note that NFS has been operated satisfactorily with datagram fragmentation for years, though generally on networks of fairly small radius. There is no problem peculiar to SNMP here. To quote rfc1270: Fragmentation and Reassembly does reduce the overall robustness of network management since, if any single fragment is lost along the way, the operation will fail. The worse the network operates, the higher the probability that a fragment will get lost or delayed. For monitoring and data gathering while the network is operating normally, Fragmentation and Reassembly is not a problem. When the network is operating poorly (and the network operators are typically trying to diagnose and repair a failure), small packets should to be used, preventing the packet from being fragmented. As this is a monitoring application, fragmentation is not an issue. . There is an implementation-specific issue. Agents and managers often have an implementation-defined limit on the size of the SNMP message they can deal with. While this is a simple issue of buffer sizes, it often requires a constant change and recompilation in the agent and manager code. If an object this size is specified in a MIB document, I recommend that a NOTE WELL be included regarding making sure the managers and agents utilizing the objects from this MIB document have an adequate snmpEngineMaxMessageSize [rfc2571]. Since there is some overhead in SNMP packets for the header and encoding, the maximum message size should be rather greater than the object size; I use two times the maximum object size as a rule of thumb. While rfc2571 describes snmpEngineMaxMessageSize as being the minimum of the maximum message sizes available to the agent (maximum size available to the transport layer, not the link layer), SNMP engines commonly use a smaller value to minimize allocated buffer size. . rfc2578 (the now-applicable SMIv2 document) suggests that some implementations restrict the maximum OCTET STRING size to 255. This, too, is often a recompilation issue. An implementation I am familiar with places the same size restriction on OCTET STRINGs as it does on messages. Display strings are still limited to 255 octets (rfc2579). Best Regards, Steve --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From rameshrr@future.futsoft.com Fri May 31 07:01:09 2002 From: rameshrr@future.futsoft.com (Rayapureddi Ramesh) Date: Fri, 31 May 2002 11:31:09 +0530 Subject: [Isis-wg] no of routers in an area In-Reply-To: Message-ID: <000401c20868$90a8d580$1305a8c0@future.futsoft.com> Hello, Is there any limitation on number of "Intermediate systems" can be configured in an ISIS area? If any one knows pl let me know. Thanks in advance, Ramesh *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ***************************************************************************