From isis-wg-bounces@ietf.org Mon Aug 08 15:50:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Ddo-00045T-2V; Mon, 08 Aug 2005 15:50:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DdM-0003tG-DE; Mon, 08 Aug 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13728; Mon, 8 Aug 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2EB5-00029S-V1; Mon, 08 Aug 2005 16:24:56 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2DdJ-0003mV-Kc; Mon, 08 Aug 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 08 Aug 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ipv6-te-01.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@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 : IPv6 Traffic Engineering in IS-IS Author(s) : J. Harrison, et al. Filename : draft-ietf-isis-ipv6-te-01.txt Pages : 10 Date : 2005-8-8 This document specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. The described method uses three new TLVs, together with two new sub-TLVs of the Extended IS Reachability TLV. The information distributed allows a CSPF algorithm to calculate traffic engineered routes using IPv6 addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-te-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-ipv6-te-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-ipv6-te-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: <2005-8-8135119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ipv6-te-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ipv6-te-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-8135119.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Fri Aug 12 11:00:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3b1C-0008Hz-F3; Fri, 12 Aug 2005 11:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3b1A-0008Hr-IJ for isis-wg@megatron.ietf.org; Fri, 12 Aug 2005 11:00:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29604 for ; Fri, 12 Aug 2005 11:00:17 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3bZg-0003u4-Bn for isis-wg@ietf.org; Fri, 12 Aug 2005 11:36:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2005 08:00:09 -0700 X-IronPort-AV: i="3.96,103,1122879600"; d="scan'208"; a="654571689:sNHT34862940" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7CF05QM021683; Fri, 12 Aug 2005 08:00:05 -0700 (PDT) Received: from [10.83.142.178] (cfcentral.cisco.com [64.101.210.32]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA17855; Fri, 12 Aug 2005 09:59:50 -0500 (CDT) Mime-Version: 1.0 X-Sender: wardd@127.0.0.1 Message-Id: Date: Fri, 12 Aug 2005 09:59:55 -0500 To: isis-wg@ietf.org From: David Ward Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: chopps@rawdofmt.org Subject: [Isis-wg] Notes from IETF 63 ISIS WG meeting X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org ISIS WG meeting minutes from IETF 63 Thanks to Alia Atlas for taking the minutes. 0) Status & Admin: Admin-tags moving forward in process - cleared AD Last Call Please send in implementation info. I'll send out a last call for these. M-ISIS: cleared ADLC & LC for implementation reports MIB: Going to LC any day now Capability Advert: dependent on ISIS-TE one last revision needed BFD Bit: very little discussion on list... requested to be a WG item. If any comments, interesting to hear those. (No comments). Multi-instance ISIS: after presenation, see about WG item Traffic Engineering: Finally an informational RFC. Want to now submit it for standardization. Will allow others to become standard. Are going to take another run around this. I'd expect to see it for the first rev to be exactly the same as the Informational RFC. Reason it went informational, hadn't cleared up responsibility between ITU and IETF, but now is clear. V6: protocol analysis Experimental TLV: Need implementation report - know of none & can't move forward. Without any implementation, very hard to have become a standard. V6TE: dying & expired. Will contact the authors directly. When take the TE draft, may take the V6 in. (ADs indicate lack of caring about whether this is in separate draft or same.) In Editor queue: Alex: checking what the P2P over LAN is stuck on. It is in edit state, which means they are working on text. Dave: GMPLS is stuck on the TE drafts. Bill: (shows scary graph of dependencies for the GMPLS extensions. mpls-bundle was blocking everything. They're all clear now. MPLS-bundle was pulled from queue shortly after it was approved, b/c a fatal flaw was found, it's been reworked, and then got put back into the queue. So complicated, not sure RFC Editor has caught up. It's unclear, so I'm going to talk to RFC Editor this week to make sure. This group of 20 docs is going to pop out of the RFC Editor's queue some day when we're not looking. Bill: We're in a situation where even docs without any blocking references, etc, it's taking about 6 months for docs to get through the RFC Editor's queue. Alex: Doc can stay in edit state for few weeks to few months, depending on how complicated the doc is. Milestones: Dave: On track - completely amazing, but we are. In Vancouver, we're supposed to recharter, so bring items. TRILL related drafts to appear & need to see where work will be. Jumbo frames Alex: Had conversation with IEEE about jumbo frames & we came to pretty good agreement. No objections to an informational RFC on what people do & what to look out for. They agreed to provide us with a technical advisor to give us some guidance on jumbo frames. The thinking is that we need to decide where we want to scope this work; whether it should stay here or be a design team between here & INT, because they're interested also. Dave: ISIS-IP has come & gone & come & gone. Various meetings where people want to run IPSEC over ISIS. It might come back, but let's save discussion for Vancouver & list. ============ 1) Multi-Instance IS-IS: Stefano Prevardi draft will be released very very soon Stefano: Idea is to allow multiple instances of ISIS to run over the same links. Ships in the night approach. Similar approach for OSPFv3. Add an instance identifier via a new TLV and add to each ISIS packet. Mechanism intended just to distinguish multiple instances. How to forward is out of scope. Still need to submit draft. Just flushing out the details. We're still looking at the backwards compatibility because routers not supporting this extension will silently ignore the IID TLV. think it's similar to migration from narrow metric to wide metric, so not expecting any major issues. A special IID value of 0 may be used to indicate the default topology to ease transitions. Questions?: Radia Perlman: What kind of problems do you have in mind for this to address? Stefano: Personally no problems, but customers want ways of having separate topologies. Not sharing fate, flooding scope. Which topologies should converge first. What if topology 1 is having an SPF & topology 2 that is higher priority then needs one. Radia: Did you have in mind something like VLANs, where you want to have totally separate networks. Then you'd probably have to Dino: I think we're at a point where we're not sending ISH Tony Li: Real problem I see here is to resurrect QoS routing... Acee Lindem: Actually, in all 3 protocols, in BGP, you can mix address families. In OSPF, can have a single adjacency or have per address family/adjacency, can demux various packets. I don't think that there's a problem with being able to do this two different ways. Make it easier to debug if just want separate neighbor databases, topologies, etc. tony Li: Thanks, don't see how that's arguing against what I'm saying. There are multiple ways Dave Ward: Just use generic term "service separation". Acee: Could use this to separate IPv4 versus IPv6 or unicast versus multicast topology. Any way you want to slice & dice. Dave: Assume you want to take this to WG as an item. Stefano: First, we have to submit a draft. Dave: Details, details .... Alex: Just to be clear, we're not talking about adding the ID yet to be submitted as a WG item, but talking about adding a work item to the charter. Dave: yes Dino: Might want to consider having run on a different MAC address, so those not participating, won't have to hear. Stefano: Yeah, we thought about. I'm not sure that it brings that much other than another method of complexity. Would give two levels of complexity. We're talking about control packets so not flooding much. Dave: What it would allow is routers in an LAN where some don't support & some do. Might help with interop. Dino: Would help with densely meshed. This might be something to add in addition, so as not to bother the single instance box. Dave: Any comments on this. Should all welcome Hank Smith back. See you all on the list. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Aug 13 14:02:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E40Ks-0002Ne-50; Sat, 13 Aug 2005 14:02:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E40Kq-0002ML-UF for isis-wg@megatron.ietf.org; Sat, 13 Aug 2005 14:02:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02326 for ; Sat, 13 Aug 2005 14:02:19 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E40ta-0004Dr-Qy for isis-wg@ietf.org; Sat, 13 Aug 2005 14:38:16 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j7DI22o5025439 for ; Sat, 13 Aug 2005 11:02:02 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j7DI1tMe023351; Sat, 13 Aug 2005 11:01:55 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j7DI1t1c023348; Sat, 13 Aug 2005 11:01:55 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 13 Aug 2005 11:01:55 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ISIS WG In-Reply-To: <276a2ae2fe77d36dfec16c02c1420ad5@rawdofmt.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Isis-wg] Re: WG LC on draft-ietf-isis-wg-mib-22.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Tue, 12 Jul 2005, Christian Hopps wrote: > We are now in a "final final" WG LC on the MIB, please restrict any > requests for modifications to changes made in the last revision. Given > no more comments are received we will submit the MIB to the IESG > immediately following the Paris IETF meeting. Having seen no more comments on the list regarding this document, it seems to me that the time has come to submit it to the IESG. Thanks, //cmh _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg