From isis-wg-admin@ietf.org Sun Aug 3 12:44:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21891 for ; Sun, 3 Aug 2003 12:44:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jLxh-0001hw-8r; Sun, 03 Aug 2003 12:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jLxC-0001hl-K7 for isis-wg@optimus.ietf.org; Sun, 03 Aug 2003 12:43:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21850 for ; Sun, 3 Aug 2003 12:43:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jLxA-0002gL-00 for isis-wg@ietf.org; Sun, 03 Aug 2003 12:43:28 -0400 Received: from smtp018.mail.yahoo.com ([216.136.174.115]) by ietf-mx with smtp (Exim 4.12) id 19jLxA-0002g9-00 for isis-wg@ietf.org; Sun, 03 Aug 2003 12:43:28 -0400 Received: from pc-80-194-90-59-hy.blueyonder.co.uk (HELO pchristi) (christian?tena@80.194.90.59 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Aug 2003 16:42:56 -0000 From: "Philip Christian" To: isis-wg@ietf.org MIME-Version: 1.0 Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational Reply-to: christian_tena@yahoo.co.uk Message-ID: <3F2D4B57.12936.834FD@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 03 Aug 2003 17:50:15 +0100 Content-Transfer-Encoding: 7BIT I have my own point of view, but I'm not seeing much support for it. I wouldn't want to be the one that holds this up, not unless some other folks around here want to support me on the auto-encap stuff. I don't see anything wrong with the draft as it stands. Philip At 0956 01/08/2003 -0700, Christian Hopps wrote Folks, Regarding all the proposals for making the IPv6 draft more complex to handle mixed sets of IPv4 and IPv6, has anyone queried operators on this issue? When I wrote this draft I had no intention of supporting disjoint sets of IPv4 and IPv6 routers within an area. I specifically reference RFC 1195 [1] to handle broad issues like this. "In [1] a method is described to route both OSI and IPv4. We utilize this same method with some minor changes to allow for IPv6." RFC 1195 was not designed to handle disjoint sets of OSI and IPv4 routers within an area either. The draft is for the most part unchanged from 3.5 *years* ago. It is currently implemented (and deployed) by at least 3 vendors, and has been for a while. Interop testing has occurred. Are we being academic here, or is there a real problem that needs solving? Thanks, Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Aug 3 13:38:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22678 for ; Sun, 3 Aug 2003 13:38:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jMnx-0003HH-85; Sun, 03 Aug 2003 13:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jFpZ-0003cN-9g for isis-wg@optimus.ietf.org; Sun, 03 Aug 2003 06:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13817 for ; Sun, 3 Aug 2003 06:11:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jFpV-0000S7-00 for isis-wg@ietf.org; Sun, 03 Aug 2003 06:11:09 -0400 Received: from [213.161.76.90] (helo=easily.co.uk) by ietf-mx with esmtp (Exim 4.12) id 19jFpT-0000S3-00 for isis-wg@ietf.org; Sun, 03 Aug 2003 06:11:08 -0400 Received: from [80.194.90.59] (account ee7a30ha8ykg HELO pchristi.christiantena.co.uk) by easily.co.uk (CommuniGate Pro SMTP 4.0.6) with ESMTP id 22663902; Sat, 02 Aug 2003 16:44:51 +0100 Message-Id: <5.2.1.1.1.20030802164255.00a9ec40@customermail.easily.co.uk> X-Sender: ee7a30ha8ykg@customermail.easily.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Christian Hopps , isis-wg@ietf.org From: Philip Christian Subject: Re: [Isis-wg] Autoencap and Re: Last Call: Routing IPv6 with IS-I S to Informational Cc: Jeff Learman , Jeff Parker , "'Naiming Shen'" , prz@net4u.ch In-Reply-To: <0A0B0645-C441-11D7-9D04-00039303E9E2@rawdofmt.org> References: <3EDD179C.5080407@net4u.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 02 Aug 2003 16:52:04 +0100 I have my own point of view, but I'm not seeing much support for it. I wouldn't want to be the one that holds this up, not unless some other folks around here want to support me on the auto-encap stuff. I don't see anything wrong with the draft as it stands. Philip At 09:56 01/08/2003 -0700, Christian Hopps wrote: >Folks, > >Regarding all the proposals for making the IPv6 draft more >complex to handle mixed sets of IPv4 and IPv6, has anyone >queried operators on this issue? > >When I wrote this draft I had no intention of supporting >disjoint sets of IPv4 and IPv6 routers within an area. I >specifically reference RFC 1195 [1] to handle broad issues >like this. > >"In [1] a method is described to route both OSI and IPv4. We utilize > this same method with some minor changes to allow for IPv6." > >RFC 1195 was not designed to handle disjoint sets of OSI and IPv4 >routers within an area either. > >The draft is for the most part unchanged from 3.5 *years* ago. >It is currently implemented (and deployed) by at least 3 vendors, >and has been for a while. Interop testing has occurred. Are we being >academic here, or is there a real problem that needs solving? > >Thanks, >Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Aug 4 05:22:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20453 for ; Mon, 4 Aug 2003 05:22:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jbXW-0008FS-1o; Mon, 04 Aug 2003 05:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jbFb-0007jJ-AD for isis-wg@optimus.ietf.org; Mon, 04 Aug 2003 05:03:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20060 for ; Mon, 4 Aug 2003 05:03:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jbFY-0007Ge-00 for isis-wg@ietf.org; Mon, 04 Aug 2003 05:03:28 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19jbFW-0007GU-00 for isis-wg@ietf.org; Mon, 04 Aug 2003 05:03:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7492lv13594; Mon, 4 Aug 2003 12:02:47 +0300 From: Pekka Savola To: christian_tena@yahoo.co.uk cc: isis-wg@ietf.org Subject: Re: [Isis-wg] Feedback on IS-IS Automatic Encapsulation In-Reply-To: <3F245BFB.18913.10EA90@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 4 Aug 2003 12:02:47 +0300 (EEST) Hi, On Sun, 27 Jul 2003 christian_tena@yahoo.co.uk wrote: > Do you accept what I said about the usefulness of autoencap in SONET/SDH DCN > networks ? I do not know those networks and environemtns in enough detail to comment for certainty, but their characteristics seemed to be slightly different than those of a typical Internet network. > On 20 Jul 2003 at 1:13, Philip Christian wrote: > > > I always felt that automatic encapsulation might be of > > less practical use in the Internet > > than in the context in which it was thought of, and > > that is in SDH/SONET DCN > > networks. > > > > Most Internet routers (more probably all) are > > reasonably easily upgradable, and > > operators probably don't mind taking a router out of > > service for a while in order to > > upgrade it to IPv6. The only slight problem that they > > have is that because of IS-IS > > topological restrictions they shouldn't really forward > > any IPv6 traffic in the level-1 area or > > level-2 subdomain until all of the routers have been > > upgraded, unless they use > > something like MT. > > > > One slight advantage might be to tunnel v6 over v4 to > > get past routers that have > > hardware forwarding of v4 but software forwarding for > > v6, another (compared with 6to4) > > is that there is no one explicit gateway. With > > automatic encap one can have as many > > tunnelling gateways as one wishes and let IS-IS choose > > one. > > > > SDH/SONET networks are different. Some SDH/SONET ADMs > > are twenty years old, > > and only forward CLNP, and will most likely never be > > able to forward IP. Moreover, > > restarting or rebooting one of these boxes that has > > live traffic on it is simply out of the > > question. > > > > One solution is to use manually configured RFC 3147 > > tunnels in order to run IP traffic > > through these old ADMs. Most likely many vendors will > > offer this option. The problem > > with manual tunnels is that in order to achieve any > > redundancy one has to run a routing > > protocol inside the tunnel. > > > > The D1-D3 overhead channel in SDH/SONET is only > > 192kbps. Moreover many of the > > older ADMs may not even be able to forward 192kbps. > > One popular ADM can only > > forward about 128kbps before it runs out of processing > > power. > > > > This means that if one runs more than about 10 or 12 > > tunnels, each with an adjacency > > maintained inside it, then one can very quickly run > > out of bandwidth just because of all > > the hellos and LSPs/LSAs. Each time the topology > > changes the LSPs/LSAs get flooded > > down all interfaces and all tunnels, and if there are > > 10 tunnels then that is a lot of > > packets (well more than 192kbps anyway). Pretty soon > > adjacencies in the tunnels fail > > causing more topology change and eventual complete > > instability. > > > > Automatic encapsulation solves this problem because > > there are no tunnel "interfaces" > > as such, and only one adjacency to maintain, which is > > the original IS-IS one. > > > > The other beauty of automatic encapsulation is that > > the tunnels don't need to be > > configured, and then configured again for redundancy. > > They just happen automatically. > > > > For this reason I expect automatic encapsulation to > > become quite popular amongst > > SHD/SONET vendors. It is really an answer to their > > backward compatibility and support > > issues, as they can provide IP management to their new > > ADMs without needing to > > upgrade the old ones, in a scalable and reliable way > > and without a lot of configuration > > needed. > > > > This stuff is already out there in ITU-T G.7712 and it > > will happen. The question may be > > simply whether and how to document it in the IETF. > > > > I accept many of the comments in your e-mail, however > > I feel that the comments on the > > pseudo code are not fair. Pseudo code of Dijkstra's > > algorithm already appears in ISO > > 10589 and in RFC 1195, and is already about four > > pages long in those documents. > > The changes made compared with the pseudo code in RFC > > 1195 really only amount to > > a few lines. > > > > Secondly I have not seen any OSPF or BGB proposal that > > has been progressed quite to > > this level of functionality or usefulness. I really > > don't believe that this can be done with > > OSPF as IPv4 is so imbedded in OSPFv2 and IPv6 so > > imbedded in OSPFv3. This > > approach works in IS-IS only because IS-IS all about > > discribing topology independantly > > of network layer protocols. I have little knowledge > > of BGP. > > > > Philip Christian > > > > On 19 Jul 2003 at 10:32, Pekka Savola wrote: > > > > > Hi, > > > > > > I was asked to review the IS-IS Automatic > > Encapsulation document. > > > > > > Overall, the specification is of very high quality > > one seldom gets to review > > > (thanks!), but I do not think this is > > architecturally or operationally the > > > right way to solve the problem. Therefore I do not > > recommend on continuing > > > with the work. > > > > > > subtantive comments > > > ------------------- > > > > > > 1) area of applicability. > > > > > > It is not clear what the real applicability of this > > technique is; or rather, > > > it is easy to guess one: being able to implement > > automatic IPv6-over-IPv4 > > > tunneling mechanism in a routing protocol (similar > > have been proposed for > > > OSPF, and for BGP multiple times) so that it would > > be possible to avoid > > > upgrading some of the routers to handle dual > > protocols. > > > > > > The operational community and v6ops working group > > has been very hesitant > > > about techniques like these, and as of yet, the > > v6ops working group has not > > > been able to determine any real use cases for > > techniques like this. If > > > asked at any point (with current knowledge), the > > v6ops working group would > > > not recommend specifying or publishing this > > mechanism. > > > > > > Instead of real deployment of dual-stack networks, > > > we add more code to the routers, and add > > hacks/features > > > which add significantly to the complexity of the > > code and the network. > > > > > > Note that the multiple topology IS-IS specification > > would probably satisfy > > > the requirements of partial IPv4/IPv6 deployment in > > a simpler manner, if > > > really necessary. As an aside, we run an IPv4/IPv6 > > backbone, use IS-IS as > > > our IPv6 routing protocol, and haven't had *any* > > need for even > > > multiple-topology IS-IS (and I'm not sure if even > > that is needed). > > > > > > In short, I do not believe this work should be > > continued. > > > > > > 2) operational requirements. > > > > > > There is always a desire to be able to manage > > > and maintain the interfaces of routers. In > > particular, it is a strict > > > requirement to know of things such as packet/byte > > counts, error counts, etc. > > > -- using a command-line interface as well as other > > management tools such as > > > SNMP. > > > > > > As far as I know, the document does not take stance > > on this at all. The > > > probable implementation technique is probably some > > kind of generic > > > tunneling mechanism pseudo-interface which includes > > all of this information. > > > In this particular case, it might also be desirable > > to be able to see > > > between which intermediate systems automatic tunnels > > have been built, how > > > much traffic has been passed through them etc. This > > is to be able to see > > > whether the implementation is working as expected, > > i.e. encapsulating > > > towards directions it should, and not encapsulating > > to those directions it > > > should not. > > > > > > It is worth considering whether this is something to > > mention in the > > > specification. > > > > > > 3) a doubt about specification. > > > > > > I note that the pseudocode for Dijkstra's new > > algorithm appears quite > > > complex and is 4 pages long. > > > > > > I note that there is a possibility of IPR claims on > > this subject. This may > > > or may not be a significant drawback for the > > specification and > > > implementation. > > > > > > 4) two significant technical worries about the > > specification. > > > > > > An IS that also supports manually configured > > tunnels will need to > > > check that a packet has not arrived over a manual > > tunnel in the > > > normal way before discarding it. > > > > > > ==> no way to check that for certain, because there > > could be a configured > > > (GRE) tunnel between the two systems (without IS-IS > > being run over one) as > > > it is. > > > > > > Encapsulated packets should never arrive from > > any source other > > > than another IS in the same level-1 area or > > level-2 subdomain, > > > and this MAY then be used as the basis of a > > security filter. > > > > > > ==> how do you know if the source address correspons > > to the address of > > > another IS? Note that nowhere does it specify which > > source address to use > > > when encapsulating a packet, only that it must equal > > to the identity of the > > > IS (whatever that means). > > > > > > ==> note that in general, automatic tunneling > > techniques have been > > > considered as a rather dubious area of work, > > security-wise. Luckily enough, > > > this specification luckily describes some mechanisms > > to mitigate this > > > threat. > > > > > > > > > > > > > > > editorial > > > --------- > > > > > > ==> as the length is more than 15 pages, a > > table-of-contents is required > > > > > > ==> the abstract has references (disallowed), and is > > too long; perhaps the > > > distinction between an abstract/introduction is not > > clear. > > > > > > The IETF is advised of potential intellectual > > property rights in > > > regard to some or all of the specification > > contained in this > > > document. For more information consult the online > > list for notices > > > and/or updates. > > > > > > ==> this should be removed and moved to a > > full-flegded IPR Statement at the > > > end, before the Copyright Notice section; like: > > > > > > Intellectual Property Statement > > > > > > The IETF takes no position regarding the validity > > or scope of any > > > intellectual property or other rights that might > > be claimed to > > > pertain to the implementation or use of the > > technology described in > > > this document or the extent to which any license > > under such rights > > > might or might not be available; neither does it > > represent that it > > > has made any effort to identify any such rights. > > Information on the > > > IETF's procedures with respect to rights in > > standards-track and > > > standards-related documentation can be found in > > BCP-11. Copies of > > > claims of rights made available for publication > > and any assurances of > > > licenses to be made available, or the result of > > an attempt made to > > > obtain a general license or permission for the > > use of such > > > proprietary rights by implementors or users of > > this specification can > > > be obtained from the IETF Secretariat. > > > > > > The IETF invites any interested party to bring to > > its attention any > > > copyrights, patents or patent applications, or > > other proprietary > > > rights which may cover technology that may be > > required to practice > > > this standard. Please address the information to > > the IETF Executive > > > Director. > > > > > > > > > 2.Introduction > > > > > > ==> s/2./2. / (and similar elsewhere) > > > > > > 3.The automatic encapsulation mechanism. > > > > > > ==> s/mechanism./mechanism/ (similar everywhere) > > > ==> the title should be written like: "The Automatic > > Encapsulation > > > Mechanism" > > > > > > 7.1 Injection of IP and CLNP packets into the > > network > > > > > > An IS that employs automatic encapsulation is > > required to > > > unencapsulate any incoming packet that is of a > > an advertised > > > encapsulation mode, and forward the contents. > > > > > > ==> s/of a/of/ > > > ==> still a bit unclear, maybe change s/that is > > of/that uses/ ? > > > > > > 8.References > > > > > > ==> references need to split to > > normative/informative > > > > > > -- > > > Pekka Savola "You each name > > yourselves king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: > > A Clash of Kings > > > > > > > > > > > > _______________________________________________ > > > Isis-wg mailing list > > > Isis-wg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > > > ________________________________________________________________________ > > Want to chat instantly with your online friends? Get the FREE Yahoo! > > Messenger http://uk.messenger.yahoo.com/ > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Aug 4 10:15:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27639 for ; Mon, 4 Aug 2003 10:15:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jg73-0007zt-ST; Mon, 04 Aug 2003 10:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jg72-0007zJ-B5 for isis-wg@optimus.ietf.org; Mon, 04 Aug 2003 10:15:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27494; Mon, 4 Aug 2003 10:14:54 -0400 (EDT) Message-Id: <200308041414.KAA27494@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-05.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 04 Aug 2003 10:14:54 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS extensions for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-traffic-05.txt Pages : 13 Date : 2003-8-4 This document describes extensions to the IS-IS protocol to support Traffic Engineering. This document extends the IS-IS protocol by specifying new information that an Intermediate System [router] can place in Link State Protocol Data Units. This information describes additional details of the state of the network that are useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-05.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-traffic-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-traffic-05.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: <2003-8-4094234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-traffic-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-traffic-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-4094234.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Aug 11 05:09:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10847 for ; Mon, 11 Aug 2003 05:09:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8fl-000373-2X; Mon, 11 Aug 2003 05:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m8fV-00036g-7f for isis-wg@optimus.ietf.org; Mon, 11 Aug 2003 05:08:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10806 for ; Mon, 11 Aug 2003 05:08:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m8fS-00047L-00 for isis-wg@ietf.org; Mon, 11 Aug 2003 05:08:42 -0400 Received: from gwnj8.utstar.com ([65.200.123.8] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19m8fR-00047A-00 for isis-wg@ietf.org; Mon, 11 Aug 2003 05:08:41 -0400 Received: (qmail 17079 invoked from network); 11 Aug 2003 09:08:12 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.101) by lxmail.nj.us.utstar.com with SMTP; 11 Aug 2003 09:08:12 -0000 Message-ID: <3F375959.20608@xebeo.com> From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: isis-wg@ietf.org X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] ISIS meeting minutes .. Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 11 Aug 2003 10:52:41 +0200 Content-Transfer-Encoding: 7bit Pls whoever took ISIS meeting minutes in Vienna, fwd to me for further processing ... thanks -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Aug 14 17:26:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27274 for ; Thu, 14 Aug 2003 17:26:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nPbd-0001Jf-7P; Thu, 14 Aug 2003 17:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nPbT-0001JN-GZ for isis-wg@optimus.ietf.org; Thu, 14 Aug 2003 17:25:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27245 for ; Thu, 14 Aug 2003 17:25:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nPbR-000646-00 for isis-wg@ietf.org; Thu, 14 Aug 2003 17:25:49 -0400 Received: from gwnj8.utstar.com ([65.200.123.8] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19nPbQ-000640-00 for isis-wg@ietf.org; Thu, 14 Aug 2003 17:25:48 -0400 Received: (qmail 20785 invoked from network); 14 Aug 2003 21:25:18 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.101) by lxmail.nj.us.utstar.com with SMTP; 14 Aug 2003 21:25:18 -0000 Message-ID: <3F3BFE09.8050701@xebeo.com> From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: isis-wg@ietf.org X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] interesting draft ... Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 14 Aug 2003 23:24:25 +0200 Content-Transfer-Encoding: 7bit Interesting for all the people looking for msec convergence -- tony ------------------------------------------------------------------------ This is a forwarded message From: Alex Zinin To: Routing Area Mailing List Cc: grow@lists.uoregon.edu Date: Wednesday, August 13, 2003, 5:17:55 PM Subject: Mailing list for BFD ===8<==============Original message text=============== Folks- In order to continue the discussion on draft-katz-ward-bfd in an organized fashion, the following mailing list has been established: List name : rtg-bfd@ietf.org List URL : https://www1.ietf.org/mailman/listinfo/rtg-bfd To subscribe : URL above or rtg-bfd-request@ietf.org Interested participants are encouraged to subscribed to the list. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Aug 26 18:13:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15473 for ; Tue, 26 Aug 2003 18:13:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rlzW-0002td-BN; Tue, 26 Aug 2003 18:08:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rl6z-0008To-Mh for isis-wg@optimus.ietf.org; Tue, 26 Aug 2003 17:12:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10337 for ; Tue, 26 Aug 2003 17:12:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rl6x-0001zB-00 for isis-wg@ietf.org; Tue, 26 Aug 2003 17:12:19 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19rl6w-0001z6-00 for isis-wg@ietf.org; Tue, 26 Aug 2003 17:12:18 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 1EBC320660E for ; Tue, 26 Aug 2003 17:09:08 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19rkrP-0004ur-K2 for ietf-announce-list@asgard.ietf.org; Tue, 26 Aug 2003 16:56:15 -0400 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19rkqw-0004pf-Ck; Tue, 26 Aug 2003 16:55:46 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce: ; Cc: Internet Architecture Board , RFC Editor , Message-Id: Precedence: bulk MIME-Version: 1.0 Subject: [Isis-wg] Document Action: 'IS-IS extensions for Traffic Engineering' to Informational RFC Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 26 Aug 2003 16:55:46 -0400 The IESG has approved the Internet-Draft 'IS-IS extensions for Traffic Engineering' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. RFC Editor's Note: Section 3.7 "Sub-TLV 18: Traffic Engineering Default metric" Second para: OLD: To preclude overflow within a SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). NEW: To preclude overflow within a a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25). Section 6.2.1 "Sub-TLVs for TLV 22" OLD: This registry contains codepoints for Sub-TLVs of TLV 22. The range of values is 0-255. Allocations within the registry require documentation of the use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]). NEW: This registry contains codepoints for Sub-TLVs of TLV 22. The range of values is 0-255. Allocations within the registry require documentation of the proposed use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]). Section 3.0 "The extended IS reachability TLV" OLD: To preclude overflow within a SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). NEW: To preclude overflow within a a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25). _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Aug 26 20:19:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25663 for ; Tue, 26 Aug 2003 20:19:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rlwl-0002Vg-C5; Tue, 26 Aug 2003 18:05:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rkrQ-0007jU-N0 for isis-wg@optimus.ietf.org; Tue, 26 Aug 2003 16:56:16 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08779 for ; Tue, 26 Aug 2003 16:56:10 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19rkqw-0004pf-Ck; Tue, 26 Aug 2003 16:55:46 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Subject: [Isis-wg] Document Action: 'IS-IS extensions for Traffic Engineering' to Informational RFC Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 26 Aug 2003 16:55:46 -0400 The IESG has approved the Internet-Draft 'IS-IS extensions for Traffic Engineering' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. RFC Editor's Note: Section 3.7 "Sub-TLV 18: Traffic Engineering Default metric" Second para: OLD: To preclude overflow within a SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). NEW: To preclude overflow within a a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25). Section 6.2.1 "Sub-TLVs for TLV 22" OLD: This registry contains codepoints for Sub-TLVs of TLV 22. The range of values is 0-255. Allocations within the registry require documentation of the use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]). NEW: This registry contains codepoints for Sub-TLVs of TLV 22. The range of values is 0-255. Allocations within the registry require documentation of the proposed use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]). Section 3.0 "The extended IS reachability TLV" OLD: To preclude overflow within a SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). NEW: To preclude overflow within a a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25). _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg