From isis-wg-bounces@ietf.org Mon Oct 03 15:50:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWKK-0002Of-G2; Mon, 03 Oct 2005 15:50:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWK3-0002Jg-MQ; Mon, 03 Oct 2005 15:50:03 -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 PAA27897; Mon, 3 Oct 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 1EMWSa-00022p-5G; Mon, 03 Oct 2005 15:58:53 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMWK2-0006KF-2A; Mon, 03 Oct 2005 15:50:02 -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, 03 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-23.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 : Management Information Base for IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-wg-mib-23.txt Pages : 101 Date : 2005-10-3 This document describes a management information base for the IS-IS Routing protocol when it is used to construct routing tables for IP networks. This memo defines a 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. 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-23.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-wg-mib-23.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-23.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-10-3115855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-23.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-3115855.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 Tue Oct 04 09:23:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmlJ-0002Pc-6r; Tue, 04 Oct 2005 09:23:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmlG-0002Nn-Qi for isis-wg@megatron.ietf.org; Tue, 04 Oct 2005 09:23:14 -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 JAA17857 for ; Tue, 4 Oct 2005 09:23:12 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMmtt-0000Vr-Ef for isis-wg@ietf.org; Tue, 04 Oct 2005 09:32:13 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.35 ; Tue, 4 Oct 2005 09:22:54 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Oct 2005 09:22:54 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.181 140.233.20.181 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Tue, 04 Oct 2005 09:22:52 -0400 Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-23.txt From: "Parker, Jeff" To: ISIS WG Message-ID: Thread-Topic: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-23.txt Thread-Index: AcXI5rjl9zlUsDTZEdqT9AANk6/xHg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3211262573_158439" X-OriginalArrivalTime: 04 Oct 2005 13:22:54.0218 (UTC) FILETIME=[BA37CEA0:01C5C8E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 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 > 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. --B_3211262573_158439 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I was remiss in not posting a note about the changes. I have included the diffs, but the changes were editorial, in response to a request from Bert Wijnen. Change Unsigned16TC to IsisUnsigned16TC and the like Beef up the Reference clauses in TCs Edits for Behaviors Describe how rest of System scalars behave after reboot The hope is that this version is closer to the final form. I did run across "Zeno's Body Shop" the other day, at the end of a scenic dirt road near a popular hiking trail. I did have a feeling of deja vu, and wondered if this version of the draft is halfway there. - jeff parker ------ Forwarded Message > Title : Management Information Base for IS-IS > Author(s) : J. Parker > Filename : draft-ietf-isis-wg-mib-23.txt > Pages : 101 > Date : 2005-10-3 --B_3211262573_158439 Content-type: application/octet-stream; name="diffs" Content-disposition: attachment; filename="diffs" Content-Transfer-Encoding: base64 MjBjMjAKPCAgICAgICAgIExBU1QtVVBEQVRFRCAiMjAwNTA3MDgxMjAwWiIgLS0gSnVseSA4 LCAyMDA1LCBub29uCi0tLQo+ICAgICAgICAgTEFTVC1VUERBVEVEICIyMDA1MDkyODEyMDBa IiAtLSBTZXB0ZW1iZXIgMjgsIDIwMDUsIG5vb24KNDljNDkKPCAgICAgICAgIFJFVklTSU9O ICIyMDA1MDcwODEyMDBaIiAtLSBKdWx5IDgsIDIwMDUsIG5vb24KLS0tCj4gICAgICAgICBS RVZJU0lPTiAiMjAwNTA5MjgxMjAwWiIgLS0gU2VwdGVtYmVyIDI4LCAyMDA1LCBub29uCjU2 YzU2CjwgLS0gUkZDIEVkaXRvciAtIHBsZWFzZSByZXBsYWNlIHdpdGggcHJvcGVyIElBTkEg VmFsdWUKLS0tCj4gLS0gUkZDIEVkaXRvciAtIHBsZWFzZSBSZXBsYWNlIHdpdGggcHJvcGVy IElBTkEgVmFsdWUKMTA5YzEwOSwxMTgKPCAgICAgICAgICAgICAiQSBzeXN0ZW0gSUQuIgot LS0KPiAgICAgICAgICAgICAiVGhlIElEIGZvciBhbiBJbnRlcm1lZGlhdGUgU3lzdGVtLiAg VGhpcyBzaG91bGQKPiAgICAgICAgICAgICAgYmUgdW5pcXVlIHdpdGhpbiBhIG5ldHdvcmss IGFuZCBpcyBpbmNsdWRlZAo+ICAgICAgICAgICAgICBpbiBhbGwgUERVcyBvcmlnaW5hdGVk IGJ5IGFuIEludGVybWVkaWF0ZSBTeXN0ZW0uCj4gICAgICAgICAgICAgIFNvbWUgaW1wbGVt ZW50YXRpb25zIG1heSBhdXRvbWF0aWNhbGx5IGFzc2lnbiAKPiAgICAgICAgICAgICAgdmFs dWVzIGFuZCBub3QgcGVybWl0IGFuIFNOTVAgd3JpdGUsIHdoaWxlIAo+ICAgICAgICAgICAg ICBvdGhlcnMgbWF5IHJlcXVpcmUgdGhlIHZhbHVlIHRvIGJlIHNldCBtYW51YWxseS4KPiAg ICAgICAgICAgICAgVGhlIHByb3RvY29sIGRvZXMgbm90IHBsYWNlIGFueSBtZWFuaW5ncyB1 cG9uCj4gICAgICAgICAgICAgIHRoZSBiaXRzLCBvdGhlciB0aGFuIHVzaW5nIG9yZGVyaW5n IHRvIGJyZWFrIAo+ICAgICAgICAgICAgICB0aWVzIGluIGVsZWN0aW5nIGEgRGVzaWduYXRl ZCBJUyBvbiBhIExBTi4iCj4gICAgICAgICBSRUZFUkVOQ0UgIntJU0lTLmFvaSBzeXN0ZW1J ZCAoMTE5KX0iCjExNWMxMjQsMTI3CjwgICAgICAgICAgICAgIkEgTGluayBTdGF0ZSBQRFUg SWRlbnRpZmllci4iCi0tLQo+ICAgICAgICAgICAgICJBIExpbmsgU3RhdGUgUERVIElkZW50 aWZpZXIgZm9ybWVkIGZyb20gdGhlCj4gICAgICAgICAgICAgIDYgYnl0ZSBTeXN0ZW0gSUQs IGEgb25lIGJ5dGUgUHNldWRvTm9kZSBJRCwKPiAgICAgICAgICAgICAgYW5kIGEgb25lIGJ5 dGUgTFNQIGZyYWdtZW50IG51bWJlci4iCj4gICAgICAgICBSRUZFUkVOQ0UgIntTZWUgc2Vj dGlvbiA5Ljggb2YgSVNPIDEwNTg5fSIKMTE4YzEzMAo8ICAgICBBZG1pblN0YXRlIDo6PSBU RVhUVUFMLUNPTlZFTlRJT04KLS0tCj4gICAgIElzaXNBZG1pblN0YXRlIDo6PSBURVhUVUFM LUNPTlZFTlRJT04KMTMyYzE0NAo8ICAgICAgICAgICAgICJJbnRlZ2VyIHN1YiByYW5nZSBm b3IgTFNQIHNpemUuIgotLS0KPiAgICAgICAgICAgICAiSW50ZWdlciBzdWIgcmFuZ2UgZm9y IG1heGltdW0gTFNQIHNpemUuIgoxNTJhMTY1Cj4gICAgICAgICBSRUZFUkVOQ0UgIntTZWUg c2VjdGlvbiA1LjMuMSBvZiBSRkMgMTE5NX0iCjE2NmExODAKPiAgICAgICAgIFJFRkVSRU5D RSAie1NlZSBzZWN0aW9uIDcuMi4yIG9mIElTTyAxMDU4OX0iCjE3NWExOTAKPiAgICAgICAg IFJFRkVSRU5DRSAie1NlZSBzZWN0aW9uIDMgb2YgUkZDIDM3ODR9IgoxODNhMTk5Cj4gICAg ICAgICBSRUZFUkVOQ0UgIntTZWUgc2VjdGlvbiA0IG9mIFJGQyAzNzg0fSIKMTg5YTIwNgo+ ICAgICAgICAgUkVGRVJFTkNFICJ7U2VlIHNlY3Rpb24gNy4yLjIgb2YgSVNPIDEwNTg5fSIK MTk5YzIxNiwyMTcKPCAgICAgICAgICAgICAiRG8gd2UgdXNlIDExOTUgc3R5bGUgTWV0cmlj cyBvciB3aWRlIG1ldHJpY3MuIgotLS0KPiAgICAgICAgICAgICAiRG8gd2UgdXNlIFJGQyAx MTk1IHN0eWxlIG1ldHJpY3Mgb3Igd2lkZSBtZXRyaWNzPyIKPiAgICAgICAgIFJFRkVSRU5D RSAie1NlZSBzZWN0aW9uIDUgb2YgUkZDIDM3ODd9IgoyMTBhMjI5Cj4gICAgICAgICBSRUZF UkVOQ0UgIntTZWUgZGVmaW5pdGlvbnMgMy42LjEgYW5kIDMuNi4xMSBvZiBJU08gMTA1ODl9 IgoyMjBhMjQwCj4gICAgICAgICBSRUZFUkVOQ0UgIntTZWUgZGVmaW5pdGlvbnMgMy42LjEg YW5kIDMuNi4xMSBvZiBJU08gMTA1ODl9IgoyMzdhMjU4Cj4gICAgICAgICBSRUZFUkVOQ0Ug IntTZWUgc2VjdGlvbiA3LjIuNyBvZiBJU08gMTA1ODl9IgoyNDRhMjY2Cj4gICAgICAgICBS RUZFUkVOQ0UgIntTZWUgc2VjdGlvbiA5LjUgb2YgSVNPIDEwNTg5fSIKMjQ3YzI2OQo8ICAg ICBVbnNpZ25lZDE2VEMgOjo9IFRFWFRVQUwtQ09OVkVOVElPTgotLS0KPiAgICAgSXNpc1Vu c2lnbmVkMTZUQyA6Oj0gVEVYVFVBTC1DT05WRU5USU9OCjI1NmMyNzgKPCAgICAgVW5zaWdu ZWQ4VEMgOjo9IFRFWFRVQUwtQ09OVkVOVElPTgotLS0KPiAgICAgSXNpc1Vuc2lnbmVkOFRD IDo6PSBURVhUVUFMLUNPTlZFTlRJT04KMjY4LDI3OGMyOTAsMzAyCjwgLS0gIlRoaXMgb2Jq ZWN0IHNwZWNpZmllcyB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBjZXJ0YWluIGV2ZW50cyBpbgo8 IC0tIHRoZSBvcGVyYXRpb24gb2YgdGhlIHByb3RvY29sIHN0YXRlIG1hY2hpbmUuIElmIHRo ZSB2YWx1ZSBvZgo8IC0tIHRoaXMgb2JqZWN0IGlzIHNldCB0byBhIG5ldyB2YWx1ZSB3aGls ZSB0aGUgcHJvdG9jb2wgc3RhdGUKPCAtLSBtYWNoaW5lIGlzIGluIG9wZXJhdGlvbiwgdGhl IGltcGxlbWVudGF0aW9uIHNoYWxsIHRha2UgdGhlCjwgLS0gbmVjZXNzYXJ5IHN0ZXBzIHRv IGVuc3VyZSB0aGF0IGZvciBhbnkgdGltZSBpbnRlcnZhbCB3aGljaAo8IC0tIHdhcyBpbiBw cm9ncmVzcyB3aGVuIHRoZSB2YWx1ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBvYmplY3QKPCAt LSB3YXMgY2hhbmdlZCwgdGhlIG5leHQgZXhwaXJhdGlvbiBvZiB0aGF0IGludGVydmFsIHRh a2VzIHBsYWNlCjwgLS0gdGhlIHNwZWNpZmllZCB0aW1lIGFmdGVyIHRoZSBvcmlnaW5hbCBz dGFydCBvZiB0aGF0IGludGVydmFsLAo8IC0tIG9yIGltbWVkaWF0ZWx5LCB3aGljaGV2ZXIg aXMgbGF0ZXIuIFRoZSBwcmVjaXNpb24gd2l0aCB3aGljaAo8IC0tIHRoaXMgdGltZSBzaGFs bCBiZSBpbXBsZW1lbnRlZCBzaGFsbCBiZSB0aGUgc2FtZSBhcyB0aGF0CjwgLS0gYXNzb2Np YXRlZCB3aXRoIHRoZSBiYXNpYyBvcGVyYXRpb24gb2YgdGhlIHRpbWVyIG9iamVjdC4iCi0t LQo+IC0tCj4gLS0gIlRoaXMgYmVoYXZpb3IgYXBwbGllcyB0byBvYmplY3RzIHRoYXQgc3Bl Y2lmeSB0aGUgaW50ZXJ2YWwgIAo+IC0tIGJldHdlZW4gZXZlbnRzIGluIHRoZSBvcGVyYXRp b24gb2YgdGhlIHByb3RvY29sIHN0YXRlIG1hY2hpbmUuIAo+IC0tIElmIHRoZSB2YWx1ZSBv ZiBzdWNoIGFuIG9iamVjdCBpcyBzZXQgdG8gYSBuZXcgdmFsdWUgd2hpbGUgCj4gLS0gdGhl IHByb3RvY29sIHN0YXRlIG1hY2hpbmUgaXMgaW4gb3BlcmF0aW9uLCB0aGUgaW1wbGVtZW50 YXRpb24gCj4gLS0gc2hhbGwgdGFrZSB0aGUgbmVjZXNzYXJ5IHN0ZXBzIHRvIGVuc3VyZSB0 aGF0IGZvciBhbnkgdGltZSAKPiAtLSBpbnRlcnZhbCB3aGljaCB3YXMgaW4gcHJvZ3Jlc3Mg d2hlbiB0aGUgdmFsdWUgb2YgdGhlIAo+IC0tIGNvcnJlc3BvbmRpbmcgb2JqZWN0IHdhcyBj aGFuZ2VkLCB0aGUgbmV4dCBleHBpcmF0aW9uIG9mIHRoYXQgCj4gLS0gaW50ZXJ2YWwgdGFr ZXMgcGxhY2UgdGhlIHNwZWNpZmllZCB0aW1lIGFmdGVyIHRoZSBvcmlnaW5hbCAKPiAtLSBz dGFydCBvZiB0aGF0IGludGVydmFsLCBvciBpbW1lZGlhdGVseSwgd2hpY2hldmVyIGlzIGxh dGVyLiAKPiAtLSBUaGUgcHJlY2lzaW9uIHdpdGggd2hpY2ggdGhpcyB0aW1lIHNoYWxsIGJl IGltcGxlbWVudGVkIHNoYWxsIAo+IC0tIGJlIHRoZSBzYW1lIGFzIHRoYXQgYXNzb2NpYXRl ZCB3aXRoIHRoZSBiYXNpYyBvcGVyYXRpb24gb2YgCj4gLS0gdGhlIHRpbWVyIG9iamVjdC4i CjI4MSwyODJjMzA1LDMwNwo8IC0tICJUaGlzIG9iamVjdCBtYXkgbm90IGJlIG1vZGlmaWVk IHdoaWxlIHRoZSBjb3JyZXNwb25kaW5nCjwgLS0gdGFibGUgcm93J3MgdmFyaWFibGUgb2Yg dHlwZSBBZG1pblN0YXRlIGlzIGluIHN0YXRlIG9uLiIKLS0tCj4gLS0gIlRoaXMgYmVoYXZp b3IgYXBwbGllcyB0byBvYmplY3RzIHRoYXQgbWF5IG5vdCBiZSBtb2RpZmllZCAKPiAtLSB3 aGlsZSB0aGUgY29ycmVzcG9uZGluZyB0YWJsZSByb3cncyB2YXJpYWJsZSBvZiB0eXBlIAo+ IC0tIElzaXNBZG1pblN0YXRlIGlzIGluIHN0YXRlIG9uLiIKMjg1LDI4N2MzMTAsMzEzCjwg LS0gIlRoZSBhY2Nlc3Mgb2YgdGhpcyBvYmplY3QgaXMgcmVhZC13cml0ZSBpZiB0aGUgcm93 IHRvIHdoaWNoCjwgLS0gaXQgYmVsb25ncyBpcyBtYW51YWwgKGkuZS4gaXMgYmVpbmcgb3Ig d2FzIGNyZWF0ZWQgbWFudWFsbHkpCjwgLS0gb3RoZXJ3aXNlIChpLmUuIHdhcyBjcmVhdGVk IGF1dG9tYXRpY2FsbHkpIGl0IGlzIHJlYWQtb25seS4iCi0tLQo+IC0tICJUaGlzIGJlaGF2 aW9yIGFwcGxpZXMgdG8gb2JqZWN0cyB0aGF0IGFyZSByZWFkLXdyaXRlIAo+IC0tIGlmIHRo ZSBvYmplY3Qgd2FzIGNyZWF0ZWQgbWFudWFsbHkuICBPYmplY3RzIHRoYXQgd2VyZQo+IC0t IGNyZWF0ZWQgYXV0b21hdGljYWxseSB0aGF0IGhhdmUgdGhpcyBiZWhhdmlvciBhcmUKPiAt LSByZWFkLW9ubHkuCjMxNGMzNDAsMzQyCjwgICAgICAgICAgICAgIGZvciB0aGlzIEludGVy bWVkaWF0ZSBTeXN0ZW0uIgotLS0KPiAgICAgICAgICAgICAgZm9yIHRoaXMgSW50ZXJtZWRp YXRlIFN5c3RlbS4KPiAKPiAgICAgICAgICAgICAgQ29uZmlndXJlZCB2YWx1ZXMgd2lsbCBz dXJ2aXZlIGFuIGFnZW50IHJlYm9vdC4iCjMyNmMzNTQKPCAgICAgICAgICAgICAgYXJlYSBh ZGRyZXNzZXMgdG8gZm9ybSB0aGUgTmV0d29yayBFbnRpdHkgVGl0bGVzLgotLS0KPiAgICAg ICAgICAgICAgYXJlYSBhZGRyZXNzZXMgdG8gZm9ybSB0aGUgTmV0d29yayBFbnRpdHkgVGl0 bGVzLiAgCjMzMWMzNTksMzYxCjwgICAgICAgICAgICAgIHRvIGJlIHNldCBtYW51YWxseS4i Ci0tLQo+ICAgICAgICAgICAgICB0byBiZSBzZXQgbWFudWFsbHkuCj4gCj4gICAgICAgICAg ICAgIENvbmZpZ3VyZWQgdmFsdWVzIHdpbGwgc3Vydml2ZSBhbiBhZ2VudCByZWJvb3QuIgoz NDNjMzczLDM3NQo8ICAgICAgICAgICAgICBpcyBpbiBzdGF0ZSAnb24nIGZvciB0aGlzIElu dGVybWVkaWF0ZSBTeXN0ZW0uIgotLS0KPiAgICAgICAgICAgICAgaXMgaW4gc3RhdGUgJ29u JyBmb3IgdGhpcyBJbnRlcm1lZGlhdGUgU3lzdGVtLgo+IAo+ICAgICAgICAgICAgICBDb25m aWd1cmVkIHZhbHVlcyB3aWxsIHN1cnZpdmUgYW4gYWdlbnQgcmVib290LiIKMzU2YzM4OAo8 ICAgICAgICAgICAgICB0aGUgcmVzZXR0aW5nVGltZXIgYmVoYXZpb3IuICBUaGUgdmFsdWUg bXVzdCBiZQotLS0KPiAgICAgICAgICAgICAgdGhlIFJlc2V0dGluZ1RpbWVyIGJlaGF2aW9y LiAgVGhlIHZhbHVlIG11c3QgYmUKMzU5YzM5MSwzOTMKPCAgICAgICAgICAgICAgc2Vjb25k cyBsZXNzIHRoYW4gaXNpc1N5c01heEFnZS4iCi0tLQo+ICAgICAgICAgICAgICBzZWNvbmRz IGxlc3MgdGhhbiBpc2lzU3lzTWF4QWdlLgo+IAo+ICAgICAgICAgICAgICBDb25maWd1cmVk IHZhbHVlcyB3aWxsIHN1cnZpdmUgYW4gYWdlbnQgcmVib290LiIKMzY1YzM5OQo8ICAgICAg ICAgU1lOVEFYIFVuc2lnbmVkMTZUQyAoMS4uNjU1MzUpCi0tLQo+ICAgICAgICAgU1lOVEFY IElzaXNVbnNpZ25lZDE2VEMgKDEuLjY1NTM1KQozNzJjNDA2LDQwOAo8ICAgICAgICAgICAg ICBjb25maWd1cmF0aW9uLiIKLS0tCj4gICAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24uCj4g Cj4gICAgICAgICAgICAgIENvbmZpZ3VyZWQgdmFsdWVzIHdpbGwgc3Vydml2ZSBhbiBhZ2Vu dCByZWJvb3QuIgozNzhjNDE0CjwgICAgICAgICBTWU5UQVggVW5zaWduZWQxNlRDICgxLi42 NTUzNSkKLS0tCj4gICAgICAgICBTWU5UQVggSXNpc1Vuc2lnbmVkMTZUQyAoMS4uNjU1MzUp CjM4MywzODVjNDE5LDQyMwo8ICAgICAgICAgICAgICJOdW1iZXIgb2Ygc2Vjb25kcyB0byBk ZWxheSBpbiB3YWl0aW5nIHN0YXRlIGJlZm9yZQo8ICAgICAgICAgICAgICBlbnRlcmluZyBv biBzdGF0ZS4gVGhpcyBvYmplY3QgZm9sbG93cyB0aGUgcmVzZXR0aW5nVGltZXIKPCAgICAg ICAgICAgICAgYmVoYXZpb3IuIgotLS0KPiAgICAgICAgICAgICAiTnVtYmVyIG9mIHNlY29u ZHMgdG8gZGVsYXkgaW4gc3RhdGUgJ3dhaXRpbmcnIGJlZm9yZQo+ICAgICAgICAgICAgICBl bnRlcmluZyB0aGUgc3RhdGUgJ29uJy4gVGhpcyBvYmplY3QgZm9sbG93cyB0aGUgCj4gICAg ICAgICAgICAgIFJlc2V0dGluZ1RpbWVyIGJlaGF2aW9yLgo+IAo+ICAgICAgICAgICAgICBD b25maWd1cmVkIHZhbHVlcyB3aWxsIHN1cnZpdmUgYW4gYWdlbnQgcmVib290LiIKMzkxYzQy OQo8ICAgICAgICAgU1lOVEFYIEFkbWluU3RhdGUKLS0tCj4gICAgICAgICBTWU5UQVggSXNp c0FkbWluU3RhdGUKMzk4YzQzNiw0MzgKPCAgICAgICAgICAgICAgdGhlIEludGVybWVkaWF0 ZSBTeXN0ZW0uIgotLS0KPiAgICAgICAgICAgICAgdGhlIEludGVybWVkaWF0ZSBTeXN0ZW0u Cj4gCj4gICAgICAgICAgICAgIENvbmZpZ3VyZWQgdmFsdWVzIHdpbGwgc3Vydml2ZSBhbiBh Z2VudCByZWJvb3QuIgo0MDdjNDQ3LDQ0OQo8ICAgICAgICAgICAgICJJZiB0cnVlLCBhbGxv dyB0aGUgcm91dGVyIHRvIGxlYWsgTDIgcm91dGVzIGludG8gTDEuIgotLS0KPiAgICAgICAg ICAgICAiSWYgdHJ1ZSwgYWxsb3cgdGhlIHJvdXRlciB0byBsZWFrIEwyIHJvdXRlcyBpbnRv IEwxLgo+IAo+ICAgICAgICAgICAgICBDb25maWd1cmVkIHZhbHVlcyB3aWxsIHN1cnZpdmUg YW4gYWdlbnQgcmVib290LiIKNDEyYzQ1NAo8ICAgICAgICAgU1lOVEFYIFVuc2lnbmVkMTZU QyAoMzUwLi42NTUzNSkKLS0tCj4gICAgICAgICBTWU5UQVggSXNpc1Vuc2lnbmVkMTZUQyAo MzUwLi42NTUzNSkKNDIwYzQ2Miw0NjQKPCAgICAgICAgICAgICAgaXNpc1N5c01heExTUEdl bkludC4iCi0tLQo+ICAgICAgICAgICAgICBpc2lzU3lzTWF4TFNQR2VuSW50Lgo+IAo+ICAg ICAgICAgICAgICBDb25maWd1cmVkIHZhbHVlcyB3aWxsIHN1cnZpdmUgYW4gYWdlbnQgcmVi b290LiIKNDI1YzQ2OQo8ICAgICAgICAgU1lOVEFYIFVuc2lnbmVkMTZUQyAoMTQ5Mi4uMTYw MDApCi0tLQo+ICAgICAgICAgU1lOVEFYIElzaXNVbnNpZ25lZDE2VEMgKDE0OTIuLjE2MDAw KQo0MzhjNDgyLDQ4NAo8ICAgICAgICAgICAgICB2YWx1ZXMgZm9yIGlzaXNTeXNMZXZlbE9y aWdMU1BCdWZmU2l6ZS4iCi0tLQo+ICAgICAgICAgICAgICB2YWx1ZXMgZm9yIGlzaXNTeXNM ZXZlbE9yaWdMU1BCdWZmU2l6ZS4KPiAKPiAgICAgICAgICAgICAgQ29uZmlndXJlZCB2YWx1 ZXMgd2lsbCBzdXJ2aXZlIGFuIGFnZW50IHJlYm9vdC4iCjQ2MmM1MDgsNTEwCjwgICAgICAg ICAgICAgIHNldCB0byBmYWxzZSgyKSwgdGhlc2Ugbm90aWZpY2F0aW9ucyBhcmUgbm90IHNl bnQuIgotLS0KPiAgICAgICAgICAgICAgc2V0IHRvIGZhbHNlKDIpLCB0aGVzZSBub3RpZmlj YXRpb25zIGFyZSBub3Qgc2VudC4KPiAKPiAgICAgICAgICAgICAgQ29uZmlndXJlZCB2YWx1 ZXMgd2lsbCBzdXJ2aXZlIGFuIGFnZW50IHJlYm9vdC4iCjQ2Nyw0NzVkNTE0CjwgLS0gY29u dGFpbnMgdGhlIHNldCBvZiBhcmVhIGFkZHJlc3NlcyBtYW51YWxseSBjb25maWd1cmVkCjwg LS0gZm9yIHRoaXMgSW50ZXJtZWRpYXRlIFN5c3RlbS4KPCAtLSBBdCBsZWFzdCBvbmUgcm93 IGluIHdoaWNoIHRoZSB2YWx1ZSBvZiBpc2lzTWFuQXJlYUFkZHJFeGlzdFN0YXRlCjwgLS0g aXMgYWN0aXZlIG11c3QgYmUgcHJlc2VudC4gVGhlIG1heGltdW0gbnVtYmVyIG9mIHJvd3MK PCAtLSBpbiB0aGlzIHRhYmxlIGZvciBmb3Igd2hpY2ggdGhlIG9iamVjdAo8IC0tIGlzaXNN YW5BcmVhQWRkckV4aXN0U3RhdGUgaGFzIHRoZSB2YWx1ZSBhY3RpdmUgaXMgMy4KPCAtLSAg ICAgQW4gYXR0ZW1wdCB0byBjcmVhdGUgbW9yZSAzIHJvd3Mgb2YgaXNpc01hbkFyZWFBZGRy RW50cnkKPCAtLSB3aXRoIHN0YXRlICdhY3RpdmUnIGluIG9uZSBpbnN0YW5jZSBvZiB0aGUg SVMtSVMgcHJvdG9jb2wKPCAtLSBzaG91bGQgcmV0dXJuIGluY29uc2lzdGVudFZhbHVlLgo0 ODNjNTIyLDUzMgo8ICAgICAgICAgICAgICBJbnRlcm1lZGlhdGUgU3lzdGVtLiIKLS0tCj4g ICAgICAgICAgICAgIEludGVybWVkaWF0ZSBTeXN0ZW0uCj4gCj4gICAgICAgICAgICAgIEF0 IGxlYXN0IG9uZSByb3cgaW4gd2hpY2ggdGhlIHZhbHVlIG9mIAo+ICAgICAgICAgICAgICBp c2lzTWFuQXJlYUFkZHJFeGlzdFN0YXRlIGlzIGFjdGl2ZSBtdXN0IGJlIHByZXNlbnQuIAo+ ICAgICAgICAgICAgICBUaGUgbWF4aW11bSBudW1iZXIgb2Ygcm93cyBpbiB0aGlzIHRhYmxl IGZvciBmb3IgCj4gICAgICAgICAgICAgIHdoaWNoIHRoZSBvYmplY3QgaXNpc01hbkFyZWFB ZGRyRXhpc3RTdGF0ZSBoYXMgdGhlIAo+ICAgICAgICAgICAgICB2YWx1ZSBhY3RpdmUgaXMg My4KPiAKPiAgICAgICAgICAgICAgQW4gYXR0ZW1wdCB0byBjcmVhdGUgbW9yZSAzIHJvd3Mg b2YgaXNpc01hbkFyZWFBZGRyRW50cnkKPiAgICAgICAgICAgICAgd2l0aCBzdGF0ZSAnYWN0 aXZlJyBpbiBvbmUgaW5zdGFuY2Ugb2YgdGhlIElTLUlTIHByb3RvY29sCj4gICAgICAgICAg ICAgIHNob3VsZCByZXR1cm4gaW5jb25zaXN0ZW50VmFsdWUuIgo5MjBjOTY5CjwgICAgICAg ICAgICAgICAgIFVuc2lnbmVkMTZUQywKLS0tCj4gICAgICAgICAgICAgICAgIElzaXNVbnNp Z25lZDE2VEMsCjk1N2MxMDA2CjwgICAgICAgICBTWU5UQVggVW5zaWduZWQxNlRDICgxLi42 NTUzNSkKLS0tCj4gICAgICAgICBTWU5UQVggSXNpc1Vuc2lnbmVkMTZUQyAoMS4uNjU1MzUp CjExMTFjMTE2MAo8ICAgICAgICAgICAgICAgICBBZG1pblN0YXRlLAotLS0KPiAgICAgICAg ICAgICAgICAgSXNpc0FkbWluU3RhdGUsCjExNjFjMTIxMAo8ICAgICAgICAgU1lOVEFYIEFk bWluU3RhdGUKLS0tCj4gICAgICAgICBTWU5UQVggSXNpc0FkbWluU3RhdGUKMTE5OGMxMjQ3 CjwgICAgICAgICAgICAgIHJlcGxhY2VPbmx5V2hpbGVEaXNhYmxlZCBiZWhhdmlvci4gVGhl IHR5cGUgc3BlY2lmaWVkCi0tLQo+ICAgICAgICAgICAgICBSZXBsYWNlT25seVdoaWxlRGlz YWJsZWQgYmVoYXZpb3IuIFRoZSB0eXBlIHNwZWNpZmllZAoxMjI4YzEyNzcKPCAgICAgICAg ICAgICAgcmVwbGFjZU9ubHlXaGlsZURpc2FibGVkIGJlaGF2aW9yLiIKLS0tCj4gICAgICAg ICAgICAgIFJlcGxhY2VPbmx5V2hpbGVEaXNhYmxlZCBiZWhhdmlvci4iCjEzNjZjMTQxNQo8 ICAgICAgICAgICAgICAgICBVbnNpZ25lZDE2VEMsCi0tLQo+ICAgICAgICAgICAgICAgICBJ c2lzVW5zaWduZWQxNlRDLAoxNDkwYzE1MzkKPCAgICAgICAgICAgICAgVGhpcyBvYmplY3Qg Zm9sbG93cyB0aGUgcmVzZXR0aW5nVGltZXIgYmVoYXZpb3IuIgotLS0KPiAgICAgICAgICAg ICAgVGhpcyBvYmplY3QgZm9sbG93cyB0aGUgUmVzZXR0aW5nVGltZXIgYmVoYXZpb3IuIgox NTA0YzE1NTMKPCAgICAgICAgICAgICAgcmVzZXR0aW5nVGltZXIgYmVoYXZpb3IuIgotLS0K PiAgICAgICAgICAgICAgUmVzZXR0aW5nVGltZXIgYmVoYXZpb3IuIgoxNTEwYzE1NTkKPCAg ICAgICAgIFNZTlRBWCBVbnNpZ25lZDE2VEMgKDEuLjY1NTM1KQotLS0KPiAgICAgICAgIFNZ TlRBWCBJc2lzVW5zaWduZWQxNlRDICgxLi42NTUzNSkKMTUzMGMxNTc5CjwgICAgICAgICAg ICAgIHJlc2V0dGluZ1RpbWVyIGJlaGF2aW9yLgotLS0KPiAgICAgICAgICAgICAgUmVzZXR0 aW5nVGltZXIgYmVoYXZpb3IuCjE1NDljMTU5OAo8ICAgICAgICAgICAgICBUaGlzIG9iamVj dCBmb2xsb3dzIHRoZSByZXNldHRpbmdUaW1lciBiZWhhdmlvci4iIAotLS0KPiAgICAgICAg ICAgICAgVGhpcyBvYmplY3QgZm9sbG93cyB0aGUgUmVzZXR0aW5nVGltZXIgYmVoYXZpb3Iu IiAKMTU2MmMxNjExCjwgICAgICAgICAgICAgIGZvbGxvd3MgdGhlIHJlc2V0dGluZ1RpbWVy IGJlaGF2aW9yLiIKLS0tCj4gICAgICAgICAgICAgIGZvbGxvd3MgdGhlIFJlc2V0dGluZ1Rp bWVyIGJlaGF2aW9yLiIKMjEwNGMyMTUzCjwgICAgICAgICAgICAgICAgIFVuc2lnbmVkMTZU QywKLS0tCj4gICAgICAgICAgICAgICAgIElzaXNVbnNpZ25lZDE2VEMsCjIyMTFjMjI2MAo8 ICAgICAgICAgU1lOVEFYIFVuc2lnbmVkMTZUQyAoMS4uNjU1MzUpCi0tLQo+ICAgICAgICAg U1lOVEFYIElzaXNVbnNpZ25lZDE2VEMgKDEuLjY1NTM1KQoyNDUzYzI1MDIKPCAgICAgICAg ICAgICAgICAgQWRtaW5TdGF0ZSwKLS0tCj4gICAgICAgICAgICAgICAgIElzaXNBZG1pblN0 YXRlLAoyNDk2YzI1NDUKPCAgICAgICAgIFNZTlRBWCBBZG1pblN0YXRlCi0tLQo+ICAgICAg ICAgU1lOVEFYIElzaXNBZG1pblN0YXRlCjI1MTJjMjU2MQo8ICAgICAgICAgICAgICByZXBs YWNlT25seVdoaWxlRGlzYWJsZWQgYW5kIE1hbnVhbE9yQXV0b21hdGljCi0tLQo+ICAgICAg ICAgICAgICBSZXBsYWNlT25seVdoaWxlRGlzYWJsZWQgYW5kIE1hbnVhbE9yQXV0b21hdGlj CjI3MTljMjc2OAo8ICAgICAgICAgICAgICAgICBBZG1pblN0YXRlLAotLS0KPiAgICAgICAg ICAgICAgICAgSXNpc0FkbWluU3RhdGUsCjI4MzFjMjg4MAo8ICAgICAgICAgU1lOVEFYIEFk bWluU3RhdGUKLS0tCj4gICAgICAgICBTWU5UQVggSXNpc0FkbWluU3RhdGUKMjgzNmMyODg1 CjwgICAgICAgICAgICAgIG9iamVjdCBmb2xsb3dzIHRoZSBBZG1pblN0YXRlIGFuZCBNYW51 YWxPckF1dG9tYXRpYwotLS0KPiAgICAgICAgICAgICAgb2JqZWN0IGZvbGxvd3MgdGhlIElz aXNBZG1pblN0YXRlIGFuZCBNYW51YWxPckF1dG9tYXRpYwoyOTQ0YzI5OTMKPCAgICAgICAg ICAgICAgICAgVW5zaWduZWQxNlRDLAotLS0KPiAgICAgICAgICAgICAgICAgSXNpc1Vuc2ln bmVkMTZUQywKMjk0NmMyOTk1CjwgICAgICAgICAgICAgICAgIFVuc2lnbmVkMTZUQywKLS0t Cj4gICAgICAgICAgICAgICAgIElzaXNVbnNpZ25lZDE2VEMsCjI5NDhjMjk5Nwo8ICAgICAg ICAgICAgICAgICBVbnNpZ25lZDE2VEMsCi0tLQo+ICAgICAgICAgICAgICAgICBJc2lzVW5z aWduZWQxNlRDLAoyOTUwYzI5OTkKPCAgICAgICAgICAgICAgICAgVW5zaWduZWQ4VEMKLS0t Cj4gICAgICAgICAgICAgICAgIElzaXNVbnNpZ25lZDhUQwoyOTY2LDI5NjdjMzAxNSwzMDE3 CjwgICAgICAgICAgICAgIlRoZSA4IGJ5dGUgTFNQIElELCBjb25zaXN0aW5nIG9mIHRoZSBT eXN0ZW1JRCwKPCAgICAgICAgICAgICAgQ2lyY3VpdCBJRCwgYW5kIEZyYWdtZW50IE51bWJl ci4iCi0tLQo+ICAgICAgICAgICAgICJUaGUgOCBieXRlIExTUCBJRCwgY29uc2lzdGluZyBv ZiB0aGUgNiBieXRlCj4gICAgICAgICAgICAgIFN5c3RlbUlELCBhIG9uZSBieXRlIFBzZXVk b05vZGUgSUQsIGFuZCBhIAo+ICAgICAgICAgICAgICBvbmUgYnl0ZSBMU1AgZnJhZ21lbnQg bnVtYmVyLiIgCjI5ODdjMzAzNwo8ICAgICAgICAgU1lOVEFYIFVuc2lnbmVkMTZUQwotLS0K PiAgICAgICAgIFNZTlRBWCBJc2lzVW5zaWduZWQxNlRDCjI5OTVjMzA0NQo8ICAgICAgICAg U1lOVEFYIFVuc2lnbmVkMTZUQwotLS0KPiAgICAgICAgIFNZTlRBWCBJc2lzVW5zaWduZWQx NlRDCjMwMDRjMzA1NAo8ICAgICAgICAgU1lOVEFYIFVuc2lnbmVkMTZUQwotLS0KPiAgICAg ICAgIFNZTlRBWCBJc2lzVW5zaWduZWQxNlRDCjMwMTJjMzA2Mgo8ICAgICAgICAgU1lOVEFY IFVuc2lnbmVkOFRDCi0tLQo+ICAgICAgICAgU1lOVEFYIElzaXNVbnNpZ25lZDhUQwozMDU3 YzMxMDcKPCAgICAgICAgICAgICAgICAgVW5zaWduZWQxNlRDLAotLS0KPiAgICAgICAgICAg ICAgICAgSXNpc1Vuc2lnbmVkMTZUQywKMzA1OWMzMTA5CjwgICAgICAgICAgICAgICAgIFVu c2lnbmVkOFRDLAotLS0KPiAgICAgICAgICAgICAgICAgSXNpc1Vuc2lnbmVkOFRDLAozMDYx YzMxMTEKPCAgICAgICAgICAgICAgICAgVW5zaWduZWQ4VEMsCi0tLQo+ICAgICAgICAgICAg ICAgICBJc2lzVW5zaWduZWQ4VEMsCjMwODRjMzEzNAo8ICAgICAgICAgU1lOVEFYIFVuc2ln bmVkMTZUQwotLS0KPiAgICAgICAgIFNZTlRBWCBJc2lzVW5zaWduZWQxNlRDCjMwOTJjMzE0 Mgo8ICAgICAgICAgU1lOVEFYIFVuc2lnbmVkOFRDCi0tLQo+ICAgICAgICAgU1lOVEFYIElz aXNVbnNpZ25lZDhUQwozMTAwYzMxNTAKPCAgICAgICAgIFNZTlRBWCBVbnNpZ25lZDhUQwot LS0KPiAgICAgICAgIFNZTlRBWCBJc2lzVW5zaWduZWQ4VEMKMzE2MGMzMjEwCjwgICAgICAg ICBTWU5UQVggVW5zaWduZWQ4VEMKLS0tCj4gICAgICAgICBTWU5UQVggSXNpc1Vuc2lnbmVk OFRDCjMxNjhjMzIxOAo8ICAgICAgICAgU1lOVEFYIFVuc2lnbmVkOFRDCi0tLQo+ICAgICAg ICAgU1lOVEFYIElzaXNVbnNpZ25lZDhUQwozMTc3YzMyMjcKPCAgICAgICAgIFNZTlRBWCBV bnNpZ25lZDhUQwotLS0KPiAgICAgICAgIFNZTlRBWCBJc2lzVW5zaWduZWQ4VEMKMzE5NWMz MjQ1CjwgICAgICAgICBTWU5UQVggVW5zaWduZWQxNlRDICgwLi4xNjAwMCkKLS0tCj4gICAg ICAgICBTWU5UQVggSXNpc1Vuc2lnbmVkMTZUQyAoMC4uMTYwMDApCjMyMDZjMzI1Ngo8ICAg ICAgICAgU1lOVEFYIFVuc2lnbmVkMTZUQyAoMC4uMTYwMDApCi0tLQo+ICAgICAgICAgU1lO VEFYIElzaXNVbnNpZ25lZDE2VEMgKDAuLjE2MDAwKQo= --B_3211262573_158439 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 --B_3211262573_158439-- From isis-wg-bounces@ietf.org Thu Oct 06 14:14:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaFm-0002hL-LW; Thu, 06 Oct 2005 14:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaFi-0002gi-UT for isis-wg@megatron.ietf.org; Thu, 06 Oct 2005 14:14:00 -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 OAA19978 for ; Thu, 6 Oct 2005 14:13:57 -0400 (EDT) Received: from mx4.tellabs.com ([204.154.129.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENaOq-0003eg-C3 for isis-wg@ietf.org; Thu, 06 Oct 2005 14:23:24 -0400 Received: from usnvwwms2d.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.107]) by mx4.tellabs.com with ESMTP; 06 Oct 2005 18:29:51 +0000 X-SBRS: None X-IronPort-AV: i="3.97,183,1125878400"; d="scan'208,217"; a="30487305:sNHT34155232" Received: from USSJEX1.tellabs-west.tellabsinc.net ([172.25.6.7]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Oct 2005 13:13:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Oct 2005 11:13:09 -0700 Message-ID: <4B731D5A5B73494493A5F41ABF854C750376549A@USSJEX1.tellabs-west.tellabsinc.net> Thread-Topic: Computation of areas in MT-ISIS thread-index: AcXKoR9zVWR6T+bUTYSlUu2w1CX44gAAGk+A From: "Pudiyapura, Ajeer" To: X-OriginalArrivalTime: 06 Oct 2005 18:13:11.0009 (UTC) FILETIME=[9C42B510:01C5CAA1] X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Subject: [Isis-wg] Computation of areas in MT-ISIS 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: , Content-Type: multipart/mixed; boundary="===============0990180568==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============0990180568== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CAA1.9BAE9406" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CAA1.9BAE9406 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi. I have the following questions: 1) How is Area Address Computation (section 7.2.11 of ISO/IEC 10589) done in Multi Topology IS-IS? Are they computed separately for each topology? 2) If so, how is the resulting set advertised in L2 LSPs since there is no mechanism to do this per topology? Thanks -Ajeer Pudiyapura ============================================================ 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 ============================================================ ------_=_NextPart_001_01C5CAA1.9BAE9406 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

Hi.

 

  I have the following questions:

 

1)       How is Area Address Computation (section 7.2.11 of ISO/IEC 10589) done in Multi Topology IS-IS? Are they computed separately for each topology?

2)       If so, how is the resulting set advertised in L2 LSPs since there is no mechanism to do this per topology?

 

Thanks

-Ajeer Pudiyapura

 

============================================================
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
============================================================
------_=_NextPart_001_01C5CAA1.9BAE9406-- --===============0990180568== 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 --===============0990180568==-- From isis-wg-bounces@ietf.org Fri Oct 07 09:02:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENrrf-0007FR-7x; Fri, 07 Oct 2005 09:02:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENaCG-00013E-4C for isis-wg@megatron.ietf.org; Thu, 06 Oct 2005 14:10:24 -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 OAA19765 for ; Thu, 6 Oct 2005 14:10:22 -0400 (EDT) Received: from mx4.tellabs.com ([204.154.129.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENaLN-0003Ua-9s for isis-wg@ietf.org; Thu, 06 Oct 2005 14:19:50 -0400 Received: from usnvwwms2d.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.107]) by mx4.tellabs.com with ESMTP; 06 Oct 2005 18:26:16 +0000 X-SBRS: None X-IronPort-AV: i="3.97,183,1125878400"; d="scan'208,217"; a="30486917:sNHT32651952" Received: from USSJEX1.tellabs-west.tellabsinc.net ([172.25.6.7]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 Oct 2005 13:09:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Oct 2005 11:09:41 -0700 Message-ID: <4B731D5A5B73494493A5F41ABF854C750376548D@USSJEX1.tellabs-west.tellabsinc.net> Thread-Topic: Computation of areas in MT-ISIS thread-index: AcXKoR9zVWR6T+bUTYSlUu2w1CX44g== From: "Pudiyapura, Ajeer" To: X-OriginalArrivalTime: 06 Oct 2005 18:09:43.0133 (UTC) FILETIME=[205B58D0:01C5CAA1] X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-Mailman-Approved-At: Fri, 07 Oct 2005 09:02:18 -0400 Subject: [Isis-wg] Computation of areas in MT-ISIS 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: , Content-Type: multipart/mixed; boundary="===============0062241786==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============0062241786== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CAA1.1FC59867" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CAA1.1FC59867 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi. I have the following questions: 1) How is Area Address Computation (section 7.2.11 of ISO/IEC 10589) done in Multi Topology IS-IS? Are they computed separately for each topology? 2) If so, how is the resulting set advertised in L2 LSPs since there is no mechanism to do this per topology? Thanks -Ajeer Pudiyapura ============================================================ 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 ============================================================ ------_=_NextPart_001_01C5CAA1.1FC59867 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

Hi.

 

  I have the following questions:

 

1)       How is Area Address Computation (section 7.2.11 of ISO/IEC 10589) done in Multi Topology IS-IS? Are they computed separately for each topology?

2)       If so, how is the resulting set advertised in L2 LSPs since there is no mechanism to do this per topology?

 

Thanks

-Ajeer Pudiyapura

 

============================================================
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
============================================================
------_=_NextPart_001_01C5CAA1.1FC59867-- --===============0062241786== 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 --===============0062241786==-- From isis-wg-bounces@ietf.org Fri Oct 07 09:11:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENs0f-0002yA-Ei; Fri, 07 Oct 2005 09:11:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENs0d-0002s1-Rx for isis-wg@megatron.ietf.org; Fri, 07 Oct 2005 09:11:36 -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 JAA16997 for ; Fri, 7 Oct 2005 09:11:33 -0400 (EDT) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENs9v-0005e0-2u for isis-wg@ietf.org; Fri, 07 Oct 2005 09:21:12 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 8C9923DCC8B; Fri, 7 Oct 2005 06:11:12 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Christian Hopps Date: Fri, 7 Oct 2005 06:11:25 -0700 To: Jeff Parker X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ISIS WG Subject: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.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 This draft has been in Final Final WG LC. The only changes allowed at this point are changes to the changes from the previous. This revision was requested by the MIB area director so the revision was made. :) Please review these changes for anything glaringly wrong as I plan to send this MIB to the Alex and Bill next Friday (2005/10/14). I'd like for this to be in the queue to become an RFC *before* the next IETF. Chris. On Oct 4, 2005, at 6:22 AM, Parker, Jeff wrote: > I was remiss in not posting a note about the changes. > > I have included the diffs, but the changes were editorial, in > response to a > request from Bert Wijnen. > > Change Unsigned16TC to IsisUnsigned16TC and the like > Beef up the Reference clauses in TCs > Edits for Behaviors > Describe how rest of System scalars behave after reboot > > The hope is that this version is closer to the final form. > > I did run across "Zeno's Body Shop" the other day, at the end of a > scenic > dirt road near a popular hiking trail. I did have a feeling of > deja vu, and > wondered if this version of the draft is halfway there. > > - jeff parker > > ------ Forwarded Message > > >> Title : Management Information Base for IS-IS >> Author(s) : J. Parker >> Filename : draft-ietf-isis-wg-mib-23.txt >> Pages : 101 >> Date : 2005-10-3 >> > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Oct 08 01:00:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO6ot-0000hm-JN; Sat, 08 Oct 2005 01:00:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO6or-0000gP-3n for isis-wg@megatron.ietf.org; Sat, 08 Oct 2005 01:00:25 -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 BAA17698 for ; Sat, 8 Oct 2005 01:00:23 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO6yD-0003Hx-Ok for isis-wg@ietf.org; Sat, 08 Oct 2005 01:10:09 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 07 Oct 2005 22:00:12 -0700 Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j98509uk014815; Fri, 7 Oct 2005 22:00:09 -0700 (PDT) Message-ID: <4347527B.4080304@cisco.com> Date: Fri, 07 Oct 2005 22:00:43 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pudiyapura, Ajeer" Subject: Re: [Isis-wg] Computation of areas in MT-ISIS References: <4B731D5A5B73494493A5F41ABF854C750376548D@USSJEX1.tellabs-west.tellabsinc.net> In-Reply-To: <4B731D5A5B73494493A5F41ABF854C750376548D@USSJEX1.tellabs-west.tellabsinc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org 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 Pudiyapura, Ajeer said the following on 10/06/2005 11:09 AM: > Hi. > > > > I have the following questions: > > > > 1) How is Area Address Computation (section 7.2.11 of ISO/IEC > 10589) done in Multi Topology IS-IS? Are they computed separately for > each topology? > No. MT-ISIS node keeps the same system-id, areas, levels, hostname, etc. there is no change to any of that. thanks. - Naiming > 2) If so, how is the resulting set advertised in L2 LSPs since > there is no mechanism to do this per topology? > > > > Thanks > > -Ajeer Pudiyapura > > > > ============================================================ > 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@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Oct 09 13:27:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOexS-00044c-Oc; Sun, 09 Oct 2005 13:27:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOexR-00044U-22 for isis-wg@megatron.ietf.org; Sun, 09 Oct 2005 13:27:33 -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 NAA28545 for ; Sun, 9 Oct 2005 13:27:30 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOf7A-0000yc-4q for isis-wg@ietf.org; Sun, 09 Oct 2005 13:37:37 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2005 19:27:23 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j99HRKOk003533; Sun, 9 Oct 2005 19:27:21 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 9 Oct 2005 19:27:20 +0200 Received: from [192.168.50.240] ([10.61.80.74]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 9 Oct 2005 10:27:20 -0700 User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Sun, 09 Oct 2005 12:27:30 -0500 From: David Ward To: ISIS , Chris Hopps , David Ward Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Oct 2005 17:27:20.0324 (UTC) FILETIME=[B3F6BC40:01C5CCF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Cc: Subject: [Isis-wg] ISIS-WG Request for slot at IETF 64 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 It's that season again. Please let us know if you would like an agenda slot at IETF 64 in Vancouver. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 10 12:21:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0PW-0007Ao-GN; Mon, 10 Oct 2005 12:21:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0PV-0007Aj-La for isis-wg@megatron.ietf.org; Mon, 10 Oct 2005 12:21:57 -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 MAA04065 for ; Mon, 10 Oct 2005 12:21:54 -0400 (EDT) Received: from rchss002.chiaro.com ([63.88.196.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP0ZQ-0000iA-OI for isis-wg@ietf.org; Mon, 10 Oct 2005 12:32:14 -0400 Received: from rchst007.cus.chiaro.com ([192.168.8.120]) by rchss002.chiaro.com (8.12.11/8.12.11) with SMTP id j9AGGcaj015604; Mon, 10 Oct 2005 11:16:38 -0500 (CDT) (envelope-from mlu@chiaro.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Computation of areas in MT-ISIS Date: Mon, 10 Oct 2005 11:20:34 -0500 Message-ID: <34B6386F843340459B22F59DFF7B12FF0295032F@192-168-240-22.chiaro.com> Thread-Topic: [Isis-wg] Computation of areas in MT-ISIS Thread-Index: AcXLxXO1x4FO1QcoS2OUiWr7hb9V9AB5WaGw From: "May Lu" To: "Naiming Shen" , "Pudiyapura, Ajeer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: isis-wg@ietf.org 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 If a MT-ISIS node runs different protocols on its interfaces, how does = the node broadcast its union address in L2 LSP? See configuration below: Node1(area 01, 04) ---- Node2 (area 01, 02) --- Node3 (area 02, = 05) IP = Ipv6 All three nodes are MT-ISIS nodes. Node2 is connected to Node1 = with IP protocol. Node2 and Node3 are connected with IPV6 protocol. = Node2 IP union addresses should be 01, 02 and 04. Node2 Ipv6 union = addresses should be 01, 02 and 05. Is this correct? If the union address does not consider the protocol, in the = following case, there is a problem: Node1 (area 01) ------ Node2 (area 01) ----- Node3 (area = 01, 02) IP = Ipv6 All three nodes are MT-ISIS nodes. Node1 and Node2 are connected = via IP protocol. Node2 and Node3 are connected via Ipv6 protocol. Node1 = is a level1 only node. Node2's union addresses are 01 and 02. Node2 will = set attached bit on IP protocol and Node1 will set the IP default route = towards Node2. Actually Node1 and Node2 are using the same area address = in IP network and Node1 shouldn't set default route to Node2. Thanks, - Xiaomei Lu =20 -----Original Message----- From: Naiming Shen [mailto:naiming@cisco.com]=20 Sent: Saturday, October 08, 2005 12:01 AM To: Pudiyapura, Ajeer Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] Computation of areas in MT-ISIS Pudiyapura, Ajeer said the following on 10/06/2005 11:09 AM: > Hi. >=20 > =20 >=20 > I have the following questions: >=20 > =20 >=20 > 1) How is Area Address Computation (section 7.2.11 of ISO/IEC=20 > 10589) done in Multi Topology IS-IS? Are they computed separately for=20 > each topology? >=20 No. MT-ISIS node keeps the same system-id, areas, levels, hostname, etc. there is no change to any of that. thanks. - Naiming > 2) If so, how is the resulting set advertised in L2 LSPs since=20 > there is no mechanism to do this per topology? >=20 > =20 >=20 > Thanks >=20 > -Ajeer Pudiyapura >=20 > =20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 10 14:33:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2TB-0003hD-02; Mon, 10 Oct 2005 14:33:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2T9-0003gK-Ky for isis-wg@megatron.ietf.org; Mon, 10 Oct 2005 14:33:51 -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 OAA11353 for ; Mon, 10 Oct 2005 14:33:50 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP2d5-0004Rq-Gb for isis-wg@ietf.org; Mon, 10 Oct 2005 14:44:09 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Oct 2005 11:33:32 -0700 X-IronPort-AV: i="3.97,195,1125903600"; d="scan'208"; a="218741290:sNHT1022437476" Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9AIXUVt026925; Mon, 10 Oct 2005 11:33:30 -0700 (PDT) Message-ID: <434AB41E.3050606@cisco.com> Date: Mon, 10 Oct 2005 11:34:06 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: May Lu Subject: Re: [Isis-wg] Computation of areas in MT-ISIS References: <34B6386F843340459B22F59DFF7B12FF0295032F@192-168-240-22.chiaro.com> In-Reply-To: <34B6386F843340459B22F59DFF7B12FF0295032F@192-168-240-22.chiaro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org 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 May, May Lu said the following on 10/10/2005 09:20 AM: > If a MT-ISIS node runs different protocols on its interfaces, how > does the node broadcast its union address in L2 LSP? > > See configuration below: > > Node1(area 01, 04) ---- Node2 (area 01, 02) --- Node3 (area 02, 05) > IP Ipv6 > > All three nodes are MT-ISIS nodes. Node2 is connected to Node1 with > IP protocol. Node2 and Node3 are connected with IPV6 protocol. Node2 > IP union addresses should be 01, 02 and 04. Node2 Ipv6 union > addresses should be 01, 02 and 05. Is this correct? > > If the union address does not consider the protocol, in the following > case, there is a problem: > > Node1 (area 01) ------ Node2 (area 01) ----- Node3 (area 01, 02) IP > Ipv6 All three nodes are MT-ISIS nodes. Node1 and Node2 are connected > via IP protocol. Node2 and Node3 are connected via Ipv6 protocol. > Node1 is a level1 only node. Node2's union addresses are 01 and 02. > Node2 will set attached bit on IP protocol and Node1 will set the IP > default route towards Node2. Actually Node1 and Node2 are using the > same area address in IP network and Node1 shouldn't set default route > to Node2. > But don't you already have problem even if Node3 is IP(not IPv6) ? or do we already have problem if they are not MT-ISIS nodes? If we are playing with IP/IPv6, why should we assigning different areas to those nodes ? thanks. - Naiming > Thanks, - Xiaomei Lu > > > -----Original Message----- From: Naiming Shen > [mailto:naiming@cisco.com] Sent: Saturday, October 08, 2005 12:01 AM > To: Pudiyapura, Ajeer Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] > Computation of areas in MT-ISIS > > > > Pudiyapura, Ajeer said the following on 10/06/2005 11:09 AM: > >> Hi. >> >> >> >> I have the following questions: >> >> >> >> 1) How is Area Address Computation (section 7.2.11 of ISO/IEC >> 10589) done in Multi Topology IS-IS? Are they computed separately >> for each topology? >> > > > No. MT-ISIS node keeps the same system-id, areas, levels, hostname, > etc. there is no change to any of that. > > thanks. - Naiming > > >> 2) If so, how is the resulting set advertised in L2 LSPs >> since there is no mechanism to do this per topology? >> >> >> >> Thanks >> >> -Ajeer Pudiyapura >> >> >> >> ============================================================ 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@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg > > > _______________________________________________ Isis-wg mailing list > Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Oct 11 15:07:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPT1-0005nQ-Ou; Tue, 11 Oct 2005 15:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPSz-0005lM-OR for isis-wg@megatron.ietf.org; Tue, 11 Oct 2005 15:07:13 -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 PAA22722 for ; Tue, 11 Oct 2005 15:07:11 -0400 (EDT) Received: from mx4.tellabs.com ([204.154.129.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPPd9-0004xy-Pl for isis-wg@ietf.org; Tue, 11 Oct 2005 15:17:44 -0400 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 11 Oct 2005 19:23:50 +0000 X-SBRS: None X-IronPort-AV: i="3.97,199,1125878400"; d="scan'208"; a="30960153:sNHT31682328" Received: from USSJEX1.tellabs-west.tellabsinc.net ([172.25.6.7]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 Oct 2005 14:06:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isis-wg] Computation of areas in MT-ISIS Date: Tue, 11 Oct 2005 12:06:52 -0700 Message-ID: <4B731D5A5B73494493A5F41ABF854C7503825FA8@USSJEX1.tellabs-west.tellabsinc.net> Thread-Topic: [Isis-wg] Computation of areas in MT-ISIS thread-index: AcXNySRdtoHPsFKHTDOzkII1dbtXfAAzaWbw From: "Pudiyapura, Ajeer" To: "Naiming Shen" , "May Lu" X-OriginalArrivalTime: 11 Oct 2005 19:06:54.0041 (UTC) FILETIME=[F1671C90:01C5CE96] Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org 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 Naiming, Please consider the following MT-ISIS network example: N3(L2-only) / \ / \ V6/ \V6 / \ / \ (L1L2)N2 -------- N4(L1L2) | V4 | | | V4/V6| | V4/V6 | | N1(L1) N5(L1) Area Configurations: N1: A1 N2: A1, A2 N4: A2, A3 N5: A3 The default (IPv4) Topology of the above network would be: (L1L2)N2 -------- N4(L1L2) | | | | | | | | N1(L1) N5(L1) Here: 1. Each adjacent router is configured with at least one common area id, hence forming an L1 adjacency. 2. Both N2 and N4 computes Union Area Address set, which would be {A1,A2,A3} 3. Neither N2 nor N4 would set the attached bit in L1 LSP since the entire network acts as an L1 cloud. 4. Neither N1 nor N5 would install a default route. 5. Since N1 would get L1 LSP from N5 and vice versa, routing between them would work fine, as expected. Now please consider the IPv6 Topology of the above network: N3(L2-only) / \ / \ / \ / \ / \ (L1L2)N2 N4(L1L2) | | | | | | | | N1(L1) N5(L1) 6. Since both N2 and N4 would use the Union Area Address set from Default topology, it will be {A1,A2,A3} as in step 2 above. 7. Neither N2 nor N4 would set the attached bit in their L1 LSPs because no more Areas are reachable through L2 routing than the Union Area Address set. 8. Neither N1 nor N5 would install a default route. 9. Since N1 in this case would not get L1 LSPs from N5 (and vice versa) routing will not be available between N1 and N5, even though there is a path between them that uses the L2 connectivity. Please correct me if I am wrong. Thanks -Ajeer Pudiyapura -----Original Message----- From: Naiming Shen [mailto:naiming@cisco.com] Sent: Monday, October 10, 2005 11:34 AM To: May Lu Cc: Pudiyapura, Ajeer; isis-wg@ietf.org Subject: Re: [Isis-wg] Computation of areas in MT-ISIS May, May Lu said the following on 10/10/2005 09:20 AM: > If a MT-ISIS node runs different protocols on its interfaces, how > does the node broadcast its union address in L2 LSP? > > See configuration below: > > Node1(area 01, 04) ---- Node2 (area 01, 02) --- Node3 (area 02, 05) > IP Ipv6 > > All three nodes are MT-ISIS nodes. Node2 is connected to Node1 with > IP protocol. Node2 and Node3 are connected with IPV6 protocol. Node2 > IP union addresses should be 01, 02 and 04. Node2 Ipv6 union > addresses should be 01, 02 and 05. Is this correct? > > If the union address does not consider the protocol, in the following > case, there is a problem: > > Node1 (area 01) ------ Node2 (area 01) ----- Node3 (area 01, 02) IP > Ipv6 All three nodes are MT-ISIS nodes. Node1 and Node2 are connected > via IP protocol. Node2 and Node3 are connected via Ipv6 protocol. > Node1 is a level1 only node. Node2's union addresses are 01 and 02. > Node2 will set attached bit on IP protocol and Node1 will set the IP > default route towards Node2. Actually Node1 and Node2 are using the > same area address in IP network and Node1 shouldn't set default route > to Node2. > But don't you already have problem even if Node3 is IP(not IPv6) ? or do we already have problem if they are not MT-ISIS nodes? If we are playing with IP/IPv6, why should we assigning different areas to those nodes ? thanks. - Naiming > Thanks, - Xiaomei Lu > > > -----Original Message----- From: Naiming Shen > [mailto:naiming@cisco.com] Sent: Saturday, October 08, 2005 12:01 AM > To: Pudiyapura, Ajeer Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] > Computation of areas in MT-ISIS > > > > Pudiyapura, Ajeer said the following on 10/06/2005 11:09 AM: > >> Hi. >> >> >> >> I have the following questions: >> >> >> >> 1) How is Area Address Computation (section 7.2.11 of ISO/IEC >> 10589) done in Multi Topology IS-IS? Are they computed separately >> for each topology? >> > > > No. MT-ISIS node keeps the same system-id, areas, levels, hostname, > etc. there is no change to any of that. > > thanks. - Naiming > > >> 2) If so, how is the resulting set advertised in L2 LSPs >> since there is no mechanism to do this per topology? >> >> >> >> Thanks >> >> -Ajeer Pudiyapura >> >> >> >> ============================================================ 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@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg > > > _______________________________________________ Isis-wg mailing list > Isis-wg@ietf.org https://www1.ietf.org/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@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 02:45:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaMZ-0003TG-Fj; Wed, 12 Oct 2005 02:45:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPaMU-0003Sx-Pw for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 02:45:17 -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 CAA00314 for ; Wed, 12 Oct 2005 02:45:12 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPaWk-0007wI-NT for isis-wg@ietf.org; Wed, 12 Oct 2005 02:55:51 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2005 23:45:05 -0700 X-IronPort-AV: i="3.97,205,1125903600"; d="scan'208"; a="351043684:sNHT30397424" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9C6ir9C009215; Tue, 11 Oct 2005 23:45:02 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 23:45:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Computation of areas in MT-ISIS Date: Tue, 11 Oct 2005 23:44:59 -0700 Message-ID: Thread-Topic: [Isis-wg] Computation of areas in MT-ISIS Thread-Index: AcXNySRdtoHPsFKHTDOzkII1dbtXfAAzaWbwABcp1OA= From: "Les Ginsberg \(ginsberg\)" To: "Pudiyapura, Ajeer" , "Naiming Shen \(naiming\)" , "May Lu" X-OriginalArrivalTime: 12 Oct 2005 06:45:02.0018 (UTC) FILETIME=[78952A20:01C5CEF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Content-Transfer-Encoding: quoted-printable Cc: isis-wg@ietf.org 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 Ajeer - > -----Original Message----- > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf > Of Pudiyapura, Ajeer > Sent: Tuesday, October 11, 2005 12:07 PM > To: Naiming Shen (naiming); May Lu > Cc: isis-wg@ietf.org > Subject: RE: [Isis-wg] Computation of areas in MT-ISIS >=20 > Naiming, >=20 > Please consider the following MT-ISIS network example: >=20 >=20 > N3(L2-only) > / \ > / \ > V6/ \V6 > / \ > / \ > (L1L2)N2 -------- N4(L1L2) > | V4 | > | | > V4/V6| | V4/V6 > | | > N1(L1) N5(L1) >=20 > Area Configurations: >=20 > N1: A1 > N2: A1, A2 > N4: A2, A3 > N5: A3 >=20 You don't specify the area address(es) for N3, which make it a bit difficult to follow your example, but I am assuming it is in the set of (A1,A2,A3). If not, please explain where I have marked "**N3**" below. As this does not seem to be key to your question, I continue to comment below. > The default (IPv4) Topology of the above network would be: >=20 >=20 > (L1L2)N2 -------- N4(L1L2) > | | > | | > | | > | | > N1(L1) N5(L1) >=20 >=20 > Here: > 1. Each adjacent router is configured with at least one common area id, > hence forming an L1 adjacency. > 2. Both N2 and N4 computes Union Area Address set, which would be > {A1,A2,A3} > 3. Neither N2 nor N4 would set the attached bit in L1 LSP since the > entire network acts as an L1 cloud. > 4. Neither N1 nor N5 would install a default route. > 5. Since N1 would get L1 LSP from N5 and vice versa, routing between > them would work fine, as expected. >=20 >=20 > Now please consider the IPv6 Topology of the above network: >=20 >=20 > N3(L2-only) > / \ > / \ > / \ > / \ > / \ > (L1L2)N2 N4(L1L2) > | | > | | > | | > | | > N1(L1) N5(L1) >=20 >=20 > 6. Since both N2 and N4 would use the Union Area Address set from > Default topology, it will be {A1,A2,A3} as in step 2 above. > 7. Neither N2 nor N4 would set the attached bit in their L1 LSPs because > no more Areas are reachable through L2 routing than the Union Area > Address set. **N3** I therefore conclude N3 has area addresses in the set of (A1,A2,A3). Which means there is no reason to set ATT bit. > 8. Neither N1 nor N5 would install a default route. > 9. Since N1 in this case would not get L1 LSPs from N5 (and vice versa) > routing will not be available between N1 and N5, even though there is a > path between them that uses the L2 connectivity. > How do you conclude that N1 would get no L1 LSPs from N5 (and vice versa)?? Even if you were to use the optimized flooding rules described in Section 10 of the draft, in your example the only LSPs N4 could choose to "not flood" to N2 would be an LSP from N5 which only had V6 TLVs in it. It would still be obligated to flood any LSPs from N5 with any V4 info in them. Of course if there is no link between N2 and N4 in any topology, then the IPv4 topology is partitioned - and no attempt to support partition repair is defined in the draft (See Section 7). That said, I think the optimized flooding rules are not worth the trouble - and require additional logic than what is specified in the draft e.g. special CSNPs to be generated for neighbors on which optimized flooding is attempted and LSP #0 must always be flooded (at least to L1L2 neighbors). I have suggested to Naiming that Section 10 be removed. Les =20 > Please correct me if I am wrong. > Thanks > -Ajeer Pudiyapura >=20 >=20 > -----Original Message----- > From: Naiming Shen [mailto:naiming@cisco.com] > Sent: Monday, October 10, 2005 11:34 AM > To: May Lu > Cc: Pudiyapura, Ajeer; isis-wg@ietf.org > Subject: Re: [Isis-wg] Computation of areas in MT-ISIS >=20 > May, >=20 > May Lu said the following on 10/10/2005 09:20 AM: > > If a MT-ISIS node runs different protocols on its interfaces, how > > does the node broadcast its union address in L2 LSP? > > > > See configuration below: > > > > Node1(area 01, 04) ---- Node2 (area 01, 02) --- Node3 (area 02, 05) > > IP Ipv6 > > > > All three nodes are MT-ISIS nodes. Node2 is connected to Node1 with > > IP protocol. Node2 and Node3 are connected with IPV6 protocol. Node2 > > IP union addresses should be 01, 02 and 04. Node2 Ipv6 union > > addresses should be 01, 02 and 05. Is this correct? > > > > If the union address does not consider the protocol, in the following > > case, there is a problem: > > > > Node1 (area 01) ------ Node2 (area 01) ----- Node3 (area 01, 02) IP > > Ipv6 All three nodes are MT-ISIS nodes. Node1 and Node2 are connected > > via IP protocol. Node2 and Node3 are connected via Ipv6 protocol. > > Node1 is a level1 only node. Node2's union addresses are 01 and 02. > > Node2 will set attached bit on IP protocol and Node1 will set the IP > > default route towards Node2. Actually Node1 and Node2 are using the > > same area address in IP network and Node1 shouldn't set default route > > to Node2. > > >=20 > But don't you already have problem even if Node3 is IP(not IPv6) ? > or do we already have problem if they are not MT-ISIS nodes? If we > are playing with IP/IPv6, why should we assigning different areas to > those nodes ? >=20 > thanks. > - Naiming >=20 > > Thanks, - Xiaomei Lu > > > > > > -----Original Message----- From: Naiming Shen > > [mailto:naiming@cisco.com] Sent: Saturday, October 08, 2005 12:01 > AM > > To: Pudiyapura, Ajeer Cc: isis-wg@ietf.org Subject: Re: > [Isis-wg] > > Computation of areas in MT-ISIS > > > > > > > > Pudiyapura, Ajeer said the following on 10/06/2005 11:09 AM: > > > >> Hi. > >> > >> > >> > >> I have the following questions: > >> > >> > >> > >> 1) How is Area Address Computation (section 7.2.11 of ISO/IEC > >> 10589) done in Multi Topology IS-IS? Are they computed separately > >> for each topology? > >> > > > > > > No. MT-ISIS node keeps the same system-id, areas, levels, hostname, > > etc. there is no change to any of that. > > > > thanks. - Naiming > > > > > >> 2) If so, how is the resulting set advertised in L2 LSPs > >> since there is no mechanism to do this per topology? > >> > >> > >> > >> Thanks > >> > >> -Ajeer Pudiyapura > >> > >> > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> > >> _______________________________________________ Isis-wg mailing > >> list Isis-wg@ietf.org > >> https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > _______________________________________________ Isis-wg mailing list > > Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 03:28:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPb27-0007Bh-I1; Wed, 12 Oct 2005 03:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPb25-0007BX-Nr for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 03:28:13 -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 DAA02583 for ; Wed, 12 Oct 2005 03:28:11 -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 1EPbCM-0000gF-0q for isis-wg@ietf.org; Wed, 12 Oct 2005 03:38:50 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2005 00:28:02 -0700 X-IronPort-AV: i="3.97,205,1125903600"; d="scan'208"; a="665355701:sNHT31241032" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9C7RsJl004248; Wed, 12 Oct 2005 00:27:59 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 00:27:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Computation of areas in MT-ISIS Date: Wed, 12 Oct 2005 00:27:55 -0700 Message-ID: Thread-Topic: [Isis-wg] Computation of areas in MT-ISIS Thread-Index: AcXNySRdtoHPsFKHTDOzkII1dbtXfAAzaWbwABcp1OAAAoEKoA== From: "Les Ginsberg \(ginsberg\)" To: "Les Ginsberg \(ginsberg\)" , "Pudiyapura, Ajeer" , "Naiming Shen \(naiming\)" , "May Lu" X-OriginalArrivalTime: 12 Oct 2005 07:27:56.0843 (UTC) FILETIME=[774C47B0:01C5CEFE] X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Content-Transfer-Encoding: quoted-printable Cc: isis-wg@ietf.org 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 One addition below. > -----Original Message----- > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf > Of Les Ginsberg (ginsberg) > Sent: Tuesday, October 11, 2005 11:45 PM > To: Pudiyapura, Ajeer; Naiming Shen (naiming); May Lu > Cc: isis-wg@ietf.org > Subject: RE: [Isis-wg] Computation of areas in MT-ISIS >=20 > Ajeer - >=20 > > -----Original Message----- > > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On > Behalf > > Of Pudiyapura, Ajeer > > Sent: Tuesday, October 11, 2005 12:07 PM > > To: Naiming Shen (naiming); May Lu > > Cc: isis-wg@ietf.org > > Subject: RE: [Isis-wg] Computation of areas in MT-ISIS > > > > Naiming, > > > > Please consider the following MT-ISIS network example: > > > > > > N3(L2-only) > > / \ > > / \ > > V6/ \V6 > > / \ > > / \ > > (L1L2)N2 -------- N4(L1L2) > > | V4 | > > | | > > V4/V6| | V4/V6 > > | | > > N1(L1) N5(L1) > > > > Area Configurations: > > > > N1: A1 > > N2: A1, A2 > > N4: A2, A3 > > N5: A3 > > >=20 > You don't specify the area address(es) for N3, which make it a bit > difficult to follow your example, but I am assuming it is in the set of > (A1,A2,A3). If not, please explain where I have marked "**N3**" below. >=20 > As this does not seem to be key to your question, I continue to comment > below. >=20 >=20 > > The default (IPv4) Topology of the above network would be: > > > > > > (L1L2)N2 -------- N4(L1L2) > > | | > > | | > > | | > > | | > > N1(L1) N5(L1) > > > > > > Here: > > 1. Each adjacent router is configured with at least one common area > id, > > hence forming an L1 adjacency. > > 2. Both N2 and N4 computes Union Area Address set, which would be > > {A1,A2,A3} > > 3. Neither N2 nor N4 would set the attached bit in L1 LSP since the > > entire network acts as an L1 cloud. > > 4. Neither N1 nor N5 would install a default route. > > 5. Since N1 would get L1 LSP from N5 and vice versa, routing between > > them would work fine, as expected. > > > > > > Now please consider the IPv6 Topology of the above network: > > > > > > N3(L2-only) > > / \ > > / \ > > / \ > > / \ > > / \ > > (L1L2)N2 N4(L1L2) > > | | > > | | > > | | > > | | > > N1(L1) N5(L1) > > > > > > 6. Since both N2 and N4 would use the Union Area Address set from > > Default topology, it will be {A1,A2,A3} as in step 2 above. > > 7. Neither N2 nor N4 would set the attached bit in their L1 LSPs > because > > no more Areas are reachable through L2 routing than the Union Area > > Address set. >=20 > **N3** > I therefore conclude N3 has area addresses in the set of (A1,A2,A3). > Which means there is no reason to set ATT bit. >=20 > > 8. Neither N1 nor N5 would install a default route. > > 9. Since N1 in this case would not get L1 LSPs from N5 (and vice > versa) > > routing will not be available between N1 and N5, even though there is > a > > path between them that uses the L2 connectivity. > > >=20 > How do you conclude that N1 would get no L1 LSPs from N5 (and vice > versa)?? >=20 > Even if you were to use the optimized flooding rules described in > Section 10 of the draft, in your example the only LSPs N4 could choose > to "not flood" to N2 would be an LSP from N5 which only had V6 TLVs in > it. It would still be obligated to flood any LSPs from N5 with any V4 > info in them. >=20 > Of course if there is no link between N2 and N4 in any topology, then > the IPv4 topology is partitioned - and no attempt to support partition > repair is defined in the draft (See Section 7). It should also be noted that the IPv6 (not v4) topology is partitioned at L1 as currently defined, regardless of the presence or absence of a V4 enabled link between N2 and N4. Les >=20 > That said, I think the optimized flooding rules are not worth the > trouble - and require additional logic than what is specified in the > draft e.g. special CSNPs to be generated for neighbors on which > optimized flooding is attempted and LSP #0 must always be flooded (at > least to L1L2 neighbors). I have suggested to Naiming that Section 10 be > removed. >=20 > Les >=20 >=20 > > Please correct me if I am wrong. > > Thanks > > -Ajeer Pudiyapura > > > > > > -----Original Message----- > > From: Naiming Shen [mailto:naiming@cisco.com] > > Sent: Monday, October 10, 2005 11:34 AM > > To: May Lu > > Cc: Pudiyapura, Ajeer; isis-wg@ietf.org > > Subject: Re: [Isis-wg] Computation of areas in MT-ISIS > > > > May, > > > > May Lu said the following on 10/10/2005 09:20 AM: > > > If a MT-ISIS node runs different protocols on its interfaces, how > > > does the node broadcast its union address in L2 LSP? > > > > > > See configuration below: > > > > > > Node1(area 01, 04) ---- Node2 (area 01, 02) --- Node3 (area 02, 05) > > > IP Ipv6 > > > > > > All three nodes are MT-ISIS nodes. Node2 is connected to Node1 with > > > IP protocol. Node2 and Node3 are connected with IPV6 protocol. Node2 > > > IP union addresses should be 01, 02 and 04. Node2 Ipv6 union > > > addresses should be 01, 02 and 05. Is this correct? > > > > > > If the union address does not consider the protocol, in the > following > > > case, there is a problem: > > > > > > Node1 (area 01) ------ Node2 (area 01) ----- Node3 (area 01, 02) IP > > > Ipv6 All three nodes are MT-ISIS nodes. Node1 and Node2 are > connected > > > via IP protocol. Node2 and Node3 are connected via Ipv6 protocol. > > > Node1 is a level1 only node. Node2's union addresses are 01 and 02. > > > Node2 will set attached bit on IP protocol and Node1 will set the IP > > > default route towards Node2. Actually Node1 and Node2 are using the > > > same area address in IP network and Node1 shouldn't set default > route > > > to Node2. > > > > > > > But don't you already have problem even if Node3 is IP(not IPv6) ? > > or do we already have problem if they are not MT-ISIS nodes? If we > > are playing with IP/IPv6, why should we assigning different areas to > > those nodes ? > > > > thanks. > > - Naiming > > > > > Thanks, - Xiaomei Lu > > > > > > > > > -----Original Message----- From: Naiming Shen > > > [mailto:naiming@cisco.com] Sent: Saturday, October 08, 2005 12:01 > > AM > > > To: Pudiyapura, Ajeer Cc: isis-wg@ietf.org Subject: Re: > > [Isis-wg] > > > Computation of areas in MT-ISIS > > > > > > > > > > > > Pudiyapura, Ajeer said the following on 10/06/2005 11:09 AM: > > > > > >> Hi. > > >> > > >> > > >> > > >> I have the following questions: > > >> > > >> > > >> > > >> 1) How is Area Address Computation (section 7.2.11 of ISO/IEC > > >> 10589) done in Multi Topology IS-IS? Are they computed separately > > >> for each topology? > > >> > > > > > > > > > No. MT-ISIS node keeps the same system-id, areas, levels, hostname, > > > etc. there is no change to any of that. > > > > > > thanks. - Naiming > > > > > > > > >> 2) If so, how is the resulting set advertised in L2 LSPs > > >> since there is no mechanism to do this per topology? > > >> > > >> > > >> > > >> Thanks > > >> > > >> -Ajeer Pudiyapura > > >> > > >> > > >> > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> > > >> > > >> > > > ------------------------------------------------------------------------ > > >> > > >> > > >> _______________________________________________ Isis-wg mailing > > >> list Isis-wg@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > _______________________________________________ Isis-wg mailing list > > > Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 03:51:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPbOP-0005gm-99; Wed, 12 Oct 2005 03:51:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPbOM-0005ge-Pw for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 03:51:15 -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 DAA03809 for ; Wed, 12 Oct 2005 03:51:12 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPbYY-0001Jw-8e for isis-wg@ietf.org; Wed, 12 Oct 2005 04:01:49 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2005 09:51:00 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9C7ouHH011186; Wed, 12 Oct 2005 09:50:57 +0200 (MEST) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp333.cisco.com [10.61.65.77]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA03464; Wed, 12 Oct 2005 08:50:55 +0100 (BST) Message-Id: <4.3.2.7.2.20051012083258.02e0b4a8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Oct 2005 08:50:54 +0100 To: "Les Ginsberg \(ginsberg\)" From: mike shand Subject: RE: [Isis-wg] Computation of areas in MT-ISIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Cc: "Les Ginsberg \(ginsberg\)" , isis-wg@ietf.org 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 A few comments inline below. At 08:27 12/10/2005, Les Ginsberg \(ginsberg\) wrote: >One addition below. > > > -----Original Message----- > > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On >Behalf > > Of Les Ginsberg (ginsberg) > > Sent: Tuesday, October 11, 2005 11:45 PM > > To: Pudiyapura, Ajeer; Naiming Shen (naiming); May Lu > > Cc: isis-wg@ietf.org > > Subject: RE: [Isis-wg] Computation of areas in MT-ISIS > > > > Ajeer - > > > > > -----Original Message----- > > > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On > > Behalf > > > Of Pudiyapura, Ajeer > > > Sent: Tuesday, October 11, 2005 12:07 PM > > > To: Naiming Shen (naiming); May Lu > > > Cc: isis-wg@ietf.org > > > Subject: RE: [Isis-wg] Computation of areas in MT-ISIS > > > > > > Naiming, > > > > > > Please consider the following MT-ISIS network example: > > > > > > > > > N3(L2-only) > > > / \ > > > / \ > > > V6/ \V6 > > > / \ > > > / \ > > > (L1L2)N2 -------- N4(L1L2) > > > | V4 | > > > | | > > > V4/V6| | V4/V6 > > > | | > > > N1(L1) N5(L1) > > > > > > Area Configurations: > > > > > > N1: A1 > > > N2: A1, A2 > > > N4: A2, A3 > > > N5: A3 > > > > > > > You don't specify the area address(es) for N3, which make it a bit > > difficult to follow your example, but I am assuming it is in the set >of > > (A1,A2,A3). If not, please explain where I have marked "**N3**" below. > > > > As this does not seem to be key to your question, I continue to >comment > > below. > > > > > > > The default (IPv4) Topology of the above network would be: > > > > > > > > > (L1L2)N2 -------- N4(L1L2) > > > | | > > > | | > > > | | > > > | | > > > N1(L1) N5(L1) > > > > > > > > > Here: > > > 1. Each adjacent router is configured with at least one common area > > id, > > > hence forming an L1 adjacency. While such "pairwise" assignment of area addresses is technically possible, it is strongly deprecated because it can lead to unexpected area configurations during failure conditions even in standard ISO/IEC 10589. The original design of allowing multiple area addresses per area was to allow for area splitting and merging (and decnet PhaseIV addressing). It was expected that ALL routers within an area would have the same set of area addresses, except during split/merge operations, and even then that only one area address would be added or deleted at a time, so preserving the transitive property." > > > 2. Both N2 and N4 computes Union Area Address set, which would be > > > {A1,A2,A3} > > > 3. Neither N2 nor N4 would set the attached bit in L1 LSP since the > > > entire network acts as an L1 cloud. > > > 4. Neither N1 nor N5 would install a default route. > > > 5. Since N1 would get L1 LSP from N5 and vice versa, routing between > > > them would work fine, as expected. > > > > > > > > > Now please consider the IPv6 Topology of the above network: > > > > > > > > > N3(L2-only) > > > / \ > > > / \ > > > / \ > > > / \ > > > / \ > > > (L1L2)N2 N4(L1L2) > > > | | > > > | | > > > | | > > > | | > > > N1(L1) N5(L1) > > > > > > > > > 6. Since both N2 and N4 would use the Union Area Address set from > > > Default topology, it will be {A1,A2,A3} as in step 2 above. > > > 7. Neither N2 nor N4 would set the attached bit in their L1 LSPs > > because > > > no more Areas are reachable through L2 routing than the Union Area > > > Address set. > > > > **N3** > > I therefore conclude N3 has area addresses in the set of (A1,A2,A3). > > Which means there is no reason to set ATT bit. Agreed. > > > > > 8. Neither N1 nor N5 would install a default route. > > > 9. Since N1 in this case would not get L1 LSPs from N5 (and vice > > versa) > > > routing will not be available between N1 and N5, even though there >is > > a > > > path between them that uses the L2 connectivity. > > > > > > > How do you conclude that N1 would get no L1 LSPs from N5 (and vice > > versa)?? > > > > Even if you were to use the optimized flooding rules described in > > Section 10 of the draft, in your example the only LSPs N4 could choose > > to "not flood" to N2 would be an LSP from N5 which only had V6 TLVs in > > it. It would still be obligated to flood any LSPs from N5 with any V4 > > info in them. > > > > Of course if there is no link between N2 and N4 in any topology, then > > the IPv4 topology is partitioned - and no attempt to support partition > > repair is defined in the draft (See Section 7). > >It should also be noted that the IPv6 (not v4) topology is partitioned >at L1 as currently defined, regardless of the presence or absence of a >V4 enabled link between N2 and N4. Exactly. Mike > Les > > > > > That said, I think the optimized flooding rules are not worth the > > trouble - and require additional logic than what is specified in the > > draft e.g. special CSNPs to be generated for neighbors on which > > optimized flooding is attempted and LSP #0 must always be flooded (at > > least to L1L2 neighbors). I have suggested to Naiming that Section 10 >be > > removed. > > > > Les > > > > > > > Please correct me if I am wrong. > > > Thanks > > > -Ajeer Pudiyapura > > > > > > > > > -----Original Message----- > > > From: Naiming Shen [mailto:naiming@cisco.com] > > > Sent: Monday, October 10, 2005 11:34 AM > > > To: May Lu > > > Cc: Pudiyapura, Ajeer; isis-wg@ietf.org > > > Subject: Re: [Isis-wg] Computation of areas in MT-ISIS > > > > > > May, > > > > > > May Lu said the following on 10/10/2005 09:20 AM: > > > > If a MT-ISIS node runs different protocols on its interfaces, how > > > > does the node broadcast its union address in L2 LSP? > > > > > > > > See configuration below: > > > > > > > > Node1(area 01, 04) ---- Node2 (area 01, 02) --- Node3 (area 02, >05) > > > > IP Ipv6 > > > > > > > > All three nodes are MT-ISIS nodes. Node2 is connected to Node1 >with > > > > IP protocol. Node2 and Node3 are connected with IPV6 protocol. >Node2 > > > > IP union addresses should be 01, 02 and 04. Node2 Ipv6 union > > > > addresses should be 01, 02 and 05. Is this correct? > > > > > > > > If the union address does not consider the protocol, in the > > following > > > > case, there is a problem: > > > > > > > > Node1 (area 01) ------ Node2 (area 01) ----- Node3 (area 01, 02) >IP > > > > Ipv6 All three nodes are MT-ISIS nodes. Node1 and Node2 are > > connected > > > > via IP protocol. Node2 and Node3 are connected via Ipv6 protocol. > > > > Node1 is a level1 only node. Node2's union addresses are 01 and >02. > > > > Node2 will set attached bit on IP protocol and Node1 will set the >IP > > > > default route towards Node2. Actually Node1 and Node2 are using >the > > > > same area address in IP network and Node1 shouldn't set default > > route > > > > to Node2. > > > > > > > > > > But don't you already have problem even if Node3 is IP(not IPv6) ? > > > or do we already have problem if they are not MT-ISIS nodes? If we > > > are playing with IP/IPv6, why should we assigning different areas to > > > those nodes ? > > > > > > thanks. > > > - Naiming > > > > > > > Thanks, - Xiaomei Lu > > > > > > > > > > > > -----Original Message----- From: Naiming Shen > > > > [mailto:naiming@cisco.com] Sent: Saturday, October 08, 2005 12:01 > > > AM > > > > To: Pudiyapura, Ajeer Cc: isis-wg@ietf.org Subject: >Re: > > > [Isis-wg] > > > > Computation of areas in MT-ISIS > > > > > > > > > > > > > > > > Pudiyapura, Ajeer said the following on 10/06/2005 11:09 AM: > > > > > > > >> Hi. > > > >> > > > >> > > > >> > > > >> I have the following questions: > > > >> > > > >> > > > >> > > > >> 1) How is Area Address Computation (section 7.2.11 of >ISO/IEC > > > >> 10589) done in Multi Topology IS-IS? Are they computed >separately > > > >> for each topology? > > > >> > > > > > > > > > > > > No. MT-ISIS node keeps the same system-id, areas, levels, >hostname, > > > > etc. there is no change to any of that. > > > > > > > > thanks. - Naiming > > > > > > > > > > > >> 2) If so, how is the resulting set advertised in L2 LSPs > > > >> since there is no mechanism to do this per topology? > > > >> > > > >> > > > >> > > > >> Thanks > > > >> > > > >> -Ajeer Pudiyapura > > > >> > > > >> > > > >> > > > >> ============================================================ 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@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > > > > _______________________________________________ Isis-wg mailing >list > > > > Isis-wg@ietf.org https://www1.ietf.org/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@ietf.org > > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 09:53:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPh3A-0003X4-Ek; Wed, 12 Oct 2005 09:53:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPSUD-0006wG-6i for isis-wg@megatron.ietf.org; Tue, 11 Oct 2005 18:20:41 -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 SAA07215 for ; Tue, 11 Oct 2005 18:20:37 -0400 (EDT) From: rup@sce.carleton.ca Received: from sangam.sce.carleton.ca ([134.117.56.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPSeO-0003Tu-2T for isis-wg@ietf.org; Tue, 11 Oct 2005 18:31:13 -0400 Received: from webmail.sce.carleton.ca (webmail.sce.carleton.ca [134.117.56.46]) by sangam.sce.carleton.ca (8.13.5/8.13.1) with ESMTP id j9BMKDPR013429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 11 Oct 2005 18:20:15 -0400 Received: from webmail.sce.carleton.ca (webmail.sce.carleton.ca [127.0.0.1]) by webmail.sce.carleton.ca (8.13.1/8.12.5) with ESMTP id j9BMKDUJ012366 for ; Tue, 11 Oct 2005 18:20:13 -0400 Received: (from apache@localhost) by webmail.sce.carleton.ca (8.13.1/8.13.1/Submit) id j9BMKB38012365 for isis-wg@ietf.org; Tue, 11 Oct 2005 18:20:11 -0400 X-Authentication-Warning: webmail.sce.carleton.ca: apache set sender to rup@sce.carleton.ca using -f Received: from ottawa-hs-206-191-33-74.d-ip.magma.ca (ottawa-hs-206-191-33-74.d-ip.magma.ca [206.191.33.74]) by webmail.sce.carleton.ca (Horde MIME library) with HTTP for ; Tue, 11 Oct 2005 18:20:10 -0400 Message-ID: <20051011182010.ajw7ta440cs4ggkc@webmail.sce.carleton.ca> Date: Tue, 11 Oct 2005 18:20:10 -0400 To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 12 Oct 2005 09:53:43 -0400 Subject: [Isis-wg] Interface IP addresses from IS-IS 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 Hi guys, Does any of the IS-IS packets contains the IP addresses of all the interfaces of router runnning IS-IS? I looked at TLV type 132, but it requires at least one interface IP address only, rest are optional. The TLV type 128 can give you the prefix and netmask but not the exact IP address. Any info will be appreciated. rupinder makkar _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 10:16:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhPV-0002es-M5; Wed, 12 Oct 2005 10:16:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhPT-0002eh-66 for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 10:16:47 -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 KAA23167 for ; Wed, 12 Oct 2005 10:16:44 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPhZm-0003OU-0N for isis-wg@ietf.org; Wed, 12 Oct 2005 10:27:27 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.35 ; Wed, 12 Oct 2005 10:16:29 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 Oct 2005 10:16:28 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.127 140.233.20.127 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Wed, 12 Oct 2005 10:16:28 -0400 Subject: Re: [Isis-wg] Interface IP addresses from IS-IS From: "Parker, Jeff" To: , Message-ID: Thread-Topic: [Isis-wg] Interface IP addresses from IS-IS Thread-Index: AcXPN4kWx6VYqDsqEdqBfAANk6/xHg== In-Reply-To: <20051011182010.ajw7ta440cs4ggkc@webmail.sce.carleton.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Oct 2005 14:16:28.0968 (UTC) FILETIME=[89A9BA80:01C5CF37] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: 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 The router may be advertising some of the networks reachable from some interfaces, and may be advertising the router ID (aka loopback address) with a TE TLV. - jeff parker On 10/11/05 6:20 PM, "rup@sce.carleton.ca" wrote: > Hi guys, > > Does any of the IS-IS packets contains the IP addresses of all the interfaces > of > router runnning IS-IS? > > I looked at TLV type 132, but it requires at least one interface IP address > only, rest are optional. The TLV type 128 can give you the prefix and netmask > but not the exact IP address. > > Any info will be appreciated. > > rupinder makkar > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 10:37:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhjs-00016O-2u; Wed, 12 Oct 2005 10:37:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhjq-00015c-IT for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 10:37:50 -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 KAA24170 for ; Wed, 12 Oct 2005 10:37:47 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPhuA-0003wP-WF for isis-wg@ietf.org; Wed, 12 Oct 2005 10:48:31 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9CEbVGS027410; Wed, 12 Oct 2005 09:37:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Oct 2005 16:37:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508490027@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jeffp@middlebury.edu Subject: RE: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt (fwd) Date: Wed, 12 Oct 2005 16:37:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: "C. M. Heard" , isis-wg@ietf.org 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 In rev 23 I am happy to see THis: IsisSystemID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A system ID." SYNTAX OCTET STRING (SIZE(6)) changed into this: IsisSystemID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The ID for an Intermediate System. This should be unique within a network, and is included in all PDUs originated by an Intermediate System. > Some implementations may automatically assign > values and not permit an SNMP write, while > others may require the value to be set manually. The protocol does not place any meanings upon the bits, other than using ordering to break ties in electing a Designated IS on a LAN." REFERENCE "{ISIS.aoi systemId (119)}" SYNTAX OCTET STRING (SIZE(6)) But the 3 lines marked with > seem not part of the TC. It depends on where /how the TC is used. Some may use it for a read-only object and then those 3 lines mean nothing or may be confusing. The 3 lines belong in a DESCRIPTION clause where the TC is used as a SYNTAX in an OBJECT-TYPE and whihc has possibly a MAX-ACCESS of read-write or read-create. I am not hung up on this though. When I see this IsisLinkStatePDUID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A Link State PDU Identifier." SYNTAX OCTET STRING (SIZE(8)) changed into: IsisLinkStatePDUID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A Link State PDU Identifier formed from the 6 byte System ID, a one byte PseudoNode ID, and a one byte LSP fragment number." REFERENCE "{See section 9.8 of ISO 10589}" SYNTAX OCTET STRING (SIZE(8)) Then I like that. But it would have been even more helpful if you had been more explicit on the sequence of th 6, 1 nad 1 byte. Maybe you imply that that is the sequence, but that is not very clear. Again, I can live with it. When I see: Configured values will survive an agent reboot." I am happy. Better/clearer might have been: Configured values MUST survive an agent reboot." assuming that is what the WG wants. I am not hung up on it. Besides, I see that Mike suggested the "will survive" so I should not keep nitpicking further. Ready to go, as far as I am concerned! Thanks Jeff! Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Friday, October 07, 2005 21:02 > To: Wijnen, Bert (Bert) > Subject: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt (fwd) > > > Bert, > > FYI. It might be good to let the author & WG chairs know whether or > not you are satisfied with this version of the MIB module. > > Regards, > > Mike > > ---------- Forwarded message ---------- > Date: Fri, 7 Oct 2005 06:11:25 -0700 > From: Christian Hopps > To: Jeff Parker > Cc: ISIS WG > Subject: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt > > This draft has been in Final Final WG LC. The only changes > allowed at > this point are changes to the changes from the previous. This > revision was requested by the MIB area director so the revision was > made. :) > > Please review these changes for anything glaringly wrong as I > plan to > send this MIB to the Alex and Bill next Friday (2005/10/14). > I'd like > for this to be in the queue to become an RFC *before* the next IETF. > > Chris. > > On Oct 4, 2005, at 6:22 AM, Parker, Jeff wrote: > > > I was remiss in not posting a note about the changes. > > > > I have included the diffs, but the changes were editorial, in > > response to a > > request from Bert Wijnen. > > > > Change Unsigned16TC to IsisUnsigned16TC and the like > > Beef up the Reference clauses in TCs > > Edits for Behaviors > > Describe how rest of System scalars behave after reboot > > > > The hope is that this version is closer to the final form. > > > > I did run across "Zeno's Body Shop" the other day, at the end of a > > scenic > > dirt road near a popular hiking trail. I did have a feeling of > > deja vu, and > > wondered if this version of the draft is halfway there. > > > > - jeff parker > > > > ------ Forwarded Message > > > > > >> Title : Management Information Base for IS-IS > >> Author(s) : J. Parker > >> Filename : draft-ietf-isis-wg-mib-23.txt > >> Pages : 101 > >> Date : 2005-10-3 > >> > > > > > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 11:00:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPi5d-0000qS-IY; Wed, 12 Oct 2005 11:00:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPi5b-0000oj-5H for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 11:00:19 -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 LAA26464 for ; Wed, 12 Oct 2005 11:00:16 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPiFu-0004y3-K6 for isis-wg@ietf.org; Wed, 12 Oct 2005 11:11:00 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.35 ; Wed, 12 Oct 2005 11:00:07 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 Oct 2005 11:00:06 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.127 140.233.20.127 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Wed, 12 Oct 2005 10:59:54 -0400 Subject: Re: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt From: "Parker, Jeff" To: "Wijnen, Bert (Bert)" Message-ID: Thread-Topic: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt Thread-Index: AcXPPZpi2PYnqjswEdqBfAANk6/xHg== In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508490027@nl0006exch001u.nl.lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Oct 2005 15:00:06.0859 (UTC) FILETIME=[A20C31B0:01C5CF3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , isis-wg@ietf.org 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 10/12/05 10:37 AM, "Wijnen, Bert (Bert)" wrote: > In rev 23 I am happy to see THis: > > IsisSystemID ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A system ID." > SYNTAX OCTET STRING (SIZE(6)) > > changed into this: > > IsisSystemID ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The ID for an Intermediate System. This should > be unique within a network, and is included > in all PDUs originated by an Intermediate System. >> Some implementations may automatically assign >> values and not permit an SNMP write, while >> others may require the value to be set manually. > The protocol does not place any meanings upon > the bits, other than using ordering to break > ties in electing a Designated IS on a LAN." > REFERENCE "{ISIS.aoi systemId (119)}" > SYNTAX OCTET STRING (SIZE(6)) > > But the 3 lines marked with > seem not part of the TC. > It depends on where /how the TC is used. Some may use it > for a read-only object and then those 3 lines mean nothing > or may be confusing. The 3 lines belong in a DESCRIPTION clause > where the TC is used as a SYNTAX in an OBJECT-TYPE and whihc > has possibly a MAX-ACCESS of read-write or read-create. > I am not hung up on this though. Removed > When I see this > IsisLinkStatePDUID ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A Link State PDU Identifier." > SYNTAX OCTET STRING (SIZE(8)) > > changed into: > IsisLinkStatePDUID ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A Link State PDU Identifier formed from the > 6 byte System ID, a one byte PseudoNode ID, > and a one byte LSP fragment number." > REFERENCE "{See section 9.8 of ISO 10589}" > SYNTAX OCTET STRING (SIZE(8)) > Then I like that. But it would have been even more helpful > if you had been more explicit on the sequence of th 6, 1 nad 1 byte. > Maybe you imply that that is the sequence, but that is not very clear. > Again, I can live with it. "The 8 byte Link State PDU (LSP) ID, consisting of the 6 byte SystemID of the originating IS, a one byte PseudoNode ID which is 0 unless the LSP represents the topology of a LAN, and one byte LSP fragment number that are issued in sequence, starting with 0. Non zero PseudoNode IDs need to be unique to the IS, but need not match the IfIndex." This probably says too much about the PseudoNode ID. I believe it be wordsmithed further: the byte really only needs to be unique at that -level-. > When I see: > Configured values will survive an agent reboot." > I am happy. Better/clearer might have been: > Configured values MUST survive an agent reboot." > assuming that is what the WG wants. > I am not hung up on it. Besides, I see that Mike suggested the > "will survive" so I should not keep nitpicking further. > > Ready to go, as far as I am concerned! > Thanks Jeff! > > Bert myrmidon:~/MIB jeff$ grep survive mib Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Configured values MUST survive an agent reboot." Dynamically created rows MUST survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically created rows MUST survive an agent reboot. Dynamically created rows MUST survive an agent reboot. Dynamically learned rows do not survive an agent reboot." Configured values MUST survive an agent reboot." Dynamically created rows MUST survive an agent reboot." Configured values MUST survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically created rows MUST survive an agent reboot." Dynamically created rows MUST survive an agent reboot. Dynamically learned rows will not survive an Dynamically learned rows will not survive an myrmidon:~/MIB jeff$ grep survive mib | grep -v MUST Dynamically learned rows do not survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically learned rows do not survive an agent reboot." Dynamically learned rows will not survive an Dynamically learned rows will not survive an Other issues? - jdp _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 11:03:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPi8o-0002Tj-C5; Wed, 12 Oct 2005 11:03:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPi8n-0002TS-0s for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 11:03:37 -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 LAA26746 for ; Wed, 12 Oct 2005 11:03:33 -0400 (EDT) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPiJ6-00055I-O4 for isis-wg@ietf.org; Wed, 12 Oct 2005 11:14:18 -0400 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 12 Oct 2005 08:03:26 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,207,1125903600"; d="scan'208"; a="504211949:sNHT98325278" Received: from [172.26.200.92] ([172.26.200.92]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 08:03:25 -0700 Message-ID: <434D25BC.3010406@juniper.net> Date: Wed, 12 Oct 2005 17:03:24 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rup@sce.carleton.ca Subject: Re: [Isis-wg] Interface IP addresses from IS-IS References: <20051011182010.ajw7ta440cs4ggkc@webmail.sce.carleton.ca> In-Reply-To: <20051011182010.ajw7ta440cs4ggkc@webmail.sce.carleton.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2005 15:03:26.0021 (UTC) FILETIME=[18C1E750:01C5CF3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org 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 rup@sce.carleton.ca wrote: > Hi guys, > > Does any of the IS-IS packets contains the IP addresses of all the interfaces of > router runnning IS-IS? LSPs (if traffic-engineering is enabled on a link) may contain subTLV 6,8 to the extended IS reach TLV 22. i.e. see below a tcpdump output of an IS-IS LSP: 18:28:54.259841 IS-IS, length 333 L2 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) lsp-id: 0102.5500.6110.00-00, seq: 0x00000005, lifetime: 1198s chksum: 0x59e3 (correct), PDU length: 333, Flags: [ L1L2 IS ] Area address(es) TLV #1, length: 14 Area address (length: 13): 47.0005.80ff.f800.0000.0108.0001 Protocols supported TLV #129, length: 2 NLPID(s): IPv4 (0xcc), IPv6 (0x8e) Traffic Engineering Router ID TLV #134, length: 4 Traffic Engineering Router ID: 10.255.6.110 IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 10.255.6.110 Hostname TLV #137, length: 8 Hostname: schnapps IS Reachability TLV #2, length: 12 IsNotVirtual IS Neighbor: 0102.5507.0001.00, Default Metric: 10, Internal Extended IS Reachability TLV #22, length: 94 IS Neighbor: 0102.5507.0001.00, Metric: 10, sub-TLVs present (83) IPv4 interface address subTLV #6, length: 4, 10.40.2.1 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ IPv4 neighbor address subTLV #8, length: 4, 10.40.2.2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Unreserved bandwidth subTLV #11, length: 32 TE-Class 0: 154.520 Mbps TE-Class 1: 116.640 Mbps TE-Class 2: 77.760 Mbps TE-Class 3: 38.880 Mbps TE-Class 4: 155.520 Mbps TE-Class 5: 116.640 Mbps TE-Class 6: 77.760 Mbps TE-Class 7: 38.880 Mbps Reservable link bandwidth subTLV #10, length: 4, 155.520 Mbps Maximum link bandwidth subTLV #9, length: 4, 155.520 Mbps Administrative groups subTLV #3, length: 4, 0x00000000 Bandwidth Constraints (old) subTLV #12, length: 17 Bandwidth Constraints Model ID: Russian dolls (0) Bandwidth constraint CT0: 155.520 Mbps Bandwidth constraint CT1: 116.640 Mbps Bandwidth constraint CT2: 77.760 Mbps Bandwidth constraint CT3: 38.880 Mbps IPv4 Internal Reachability TLV #128, length: 72 IPv4 prefix: 10.255.6.110/32, Distribution: up, Metric: 0, Internal IPv4 prefix: 10.40.2.0/30, Distribution: up, Metric: 10, Internal IPv4 prefix: 10.40.1.0/30, Distribution: up, Metric: 20, Internal IPv4 prefix: 10.40.3.0/30, Distribution: up, Metric: 20, Internal IPv4 prefix: 10.255.70.1/32, Distribution: up, Metric: 10, Internal IPv4 prefix: 10.255.71.212/32, Distribution: up, Metric: 20, Internal Extended IPv4 Reachability TLV #135, length: 54 IPv4 prefix: 10.255.6.110/32, Distribution: up, Metric: 0 IPv4 prefix: 10.40.2.0/30, Distribution: up, Metric: 10 IPv4 prefix: 10.40.1.0/30, Distribution: up, Metric: 20 IPv4 prefix: 10.40.3.0/30, Distribution: up, Metric: 20 IPv4 prefix: 10.255.70.1/32, Distribution: up, Metric: 10 IPv4 prefix: 10.255.71.212/32, Distribution: up, Metric: 20 IPv6 reachability TLV #236, length: 22 IPv6 prefix: abcd::10:255:6:110/128, Distribution: up, Metric: 0, Internal > I looked at TLV type 132, but it requires at least one interface IP address > only, rest are optional. The TLV type 128 can give you the prefix and netmask > but not the exact IP address. TLV 132 is typically used in IIHs - some implementations add also the IP address of the loopback IP adress packeged in TLV 132 in LSPs. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 11:15:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPiK3-0005PI-EJ; Wed, 12 Oct 2005 11:15:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPiK1-0005PC-Ug for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 11:15:14 -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 LAA27442 for ; Wed, 12 Oct 2005 11:15:10 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPiUK-0005RZ-Ez for isis-wg@ietf.org; Wed, 12 Oct 2005 11:25:55 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9CFExWs022197; Wed, 12 Oct 2005 10:15:00 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Oct 2005 17:14:58 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508490042@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Parker, Jeff" Subject: RE: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt Date: Wed, 12 Oct 2005 17:14:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: "C. M. Heard" , isis-wg@ietf.org 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 I was already happy Jeff. This makes it even better. Thanks Bert > -----Original Message----- > From: Parker, Jeff [mailto:jeffp@middlebury.edu] > Sent: Wednesday, October 12, 2005 17:00 > To: Wijnen, Bert (Bert) > Cc: C. M. Heard; isis-wg@ietf.org > Subject: Re: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt > > > On 10/12/05 10:37 AM, "Wijnen, Bert (Bert)" > wrote: > > > In rev 23 I am happy to see THis: > > > > IsisSystemID ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "A system ID." > > SYNTAX OCTET STRING (SIZE(6)) > > > > changed into this: > > > > IsisSystemID ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The ID for an Intermediate System. This should > > be unique within a network, and is included > > in all PDUs originated by an Intermediate System. > >> Some implementations may automatically assign > >> values and not permit an SNMP write, while > >> others may require the value to be set manually. > > The protocol does not place any meanings upon > > the bits, other than using ordering to break > > ties in electing a Designated IS on a LAN." > > REFERENCE "{ISIS.aoi systemId (119)}" > > SYNTAX OCTET STRING (SIZE(6)) > > > > But the 3 lines marked with > seem not part of the TC. > > It depends on where /how the TC is used. Some may use it > > for a read-only object and then those 3 lines mean nothing > > or may be confusing. The 3 lines belong in a DESCRIPTION clause > > where the TC is used as a SYNTAX in an OBJECT-TYPE and whihc > > has possibly a MAX-ACCESS of read-write or read-create. > > I am not hung up on this though. > > Removed > > > When I see this > > IsisLinkStatePDUID ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "A Link State PDU Identifier." > > SYNTAX OCTET STRING (SIZE(8)) > > > > changed into: > > IsisLinkStatePDUID ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "A Link State PDU Identifier formed from the > > 6 byte System ID, a one byte PseudoNode ID, > > and a one byte LSP fragment number." > > REFERENCE "{See section 9.8 of ISO 10589}" > > SYNTAX OCTET STRING (SIZE(8)) > > Then I like that. But it would have been even more helpful > > if you had been more explicit on the sequence of th 6, 1 nad 1 byte. > > Maybe you imply that that is the sequence, but that is not > very clear. > > Again, I can live with it. > > "The 8 byte Link State PDU (LSP) ID, > consisting of the 6 byte SystemID of the > originating IS, a one byte PseudoNode ID > which is 0 unless the LSP represents the > topology of a LAN, and one byte LSP > fragment number that are issued in sequence, > starting with 0. Non zero PseudoNode IDs > need to be unique to the IS, but need not > match the IfIndex." > > This probably says too much about the PseudoNode ID. I believe it be > wordsmithed further: the byte really only needs to be unique at that > -level-. > > > When I see: > > Configured values will survive an agent reboot." > > I am happy. Better/clearer might have been: > > Configured values MUST survive an agent reboot." > > assuming that is what the WG wants. > > I am not hung up on it. Besides, I see that Mike suggested the > > "will survive" so I should not keep nitpicking further. > > > > Ready to go, as far as I am concerned! > > Thanks Jeff! > > > > Bert > > myrmidon:~/MIB jeff$ grep survive mib > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Dynamically created rows MUST survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically created rows MUST survive an agent reboot. > Dynamically created rows MUST survive an agent reboot. > Dynamically learned rows do not survive an agent reboot." > Configured values MUST survive an agent reboot." > Dynamically created rows MUST survive an agent reboot." > Configured values MUST survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically created rows MUST survive an agent reboot." > Dynamically created rows MUST survive an agent reboot. > Dynamically learned rows will not survive an > Dynamically learned rows will not survive an > > myrmidon:~/MIB jeff$ grep survive mib | grep -v MUST > Dynamically learned rows do not survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically learned rows do not survive an agent reboot." > Dynamically learned rows will not survive an > Dynamically learned rows will not survive an > > > Other issues? > > - jdp > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 16:29:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnEV-0000vR-0S; Wed, 12 Oct 2005 16:29:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnET-0000vD-Ni for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 16:29:49 -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 QAA00090 for ; Wed, 12 Oct 2005 16:29:46 -0400 (EDT) From: rup@sce.carleton.ca Received: from sangam.sce.carleton.ca ([134.117.56.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnOp-0002zT-Dr for isis-wg@ietf.org; Wed, 12 Oct 2005 16:40:32 -0400 Received: from webmail.sce.carleton.ca (webmail.sce.carleton.ca [134.117.56.46]) by sangam.sce.carleton.ca (8.13.5/8.13.1) with ESMTP id j9CKTXaK004244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Oct 2005 16:29:33 -0400 Received: from webmail.sce.carleton.ca (webmail.sce.carleton.ca [127.0.0.1]) by webmail.sce.carleton.ca (8.13.1/8.12.5) with ESMTP id j9CKTXsP023558 for ; Wed, 12 Oct 2005 16:29:33 -0400 Received: (from apache@localhost) by webmail.sce.carleton.ca (8.13.1/8.13.1/Submit) id j9CKTWfo023557 for isis-wg@ietf.org; Wed, 12 Oct 2005 16:29:32 -0400 X-Authentication-Warning: webmail.sce.carleton.ca: apache set sender to rup@sce.carleton.ca using -f Received: from ottawa-hs-64-26-167-52.d-ip.magma.ca (ottawa-hs-64-26-167-52.d-ip.magma.ca [64.26.167.52]) by webmail.sce.carleton.ca (Horde MIME library) with HTTP for ; Wed, 12 Oct 2005 16:29:32 -0400 Message-ID: <20051012162932.pg9694kdkw4ss0w4@webmail.sce.carleton.ca> Date: Wed, 12 Oct 2005 16:29:32 -0400 To: isis-wg@ietf.org Subject: Re: [Isis-wg] Interface IP addresses from IS-IS References: <20051011182010.ajw7ta440cs4ggkc@webmail.sce.carleton.ca> <434D25BC.3010406@juniper.net> In-Reply-To: <434D25BC.3010406@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Spam-Score: 0.3 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit 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 Hi guys, Thanks for the response. The TE TLV was only defined in RFC 3784 and may not be present in most deployed systems. Further, I am seeing older Cisco boxes running IS-IS that only seem to advertise the IP for one interface. Does this mean that there are many deployed IS-IS systems which do not advertise their interface IP addresses? rgds, rupinder makkar > > > rup@sce.carleton.ca wrote: >> Hi guys, >> >> Does any of the IS-IS packets contains the IP addresses of all the >> interfaces of >> router runnning IS-IS? > > LSPs (if traffic-engineering is enabled on a link) may contain subTLV 6,8 > to the extended IS reach TLV 22. > > i.e. see below a tcpdump output of an IS-IS LSP: > > 18:28:54.259841 IS-IS, length 333 > L2 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) > lsp-id: 0102.5500.6110.00-00, seq: 0x00000005, lifetime: 1198s > chksum: 0x59e3 (correct), PDU length: 333, Flags: [ L1L2 IS ] > Area address(es) TLV #1, length: 14 > Area address (length: 13): 47.0005.80ff.f800.0000.0108.0001 > Protocols supported TLV #129, length: 2 > NLPID(s): IPv4 (0xcc), IPv6 (0x8e) > Traffic Engineering Router ID TLV #134, length: 4 > Traffic Engineering Router ID: 10.255.6.110 > IPv4 Interface address(es) TLV #132, length: 4 > IPv4 interface address: 10.255.6.110 > Hostname TLV #137, length: 8 > Hostname: schnapps > IS Reachability TLV #2, length: 12 > IsNotVirtual > IS Neighbor: 0102.5507.0001.00, Default Metric: 10, Internal > Extended IS Reachability TLV #22, length: 94 > IS Neighbor: 0102.5507.0001.00, Metric: 10, sub-TLVs > present (83) > IPv4 interface address subTLV #6, length: 4, 10.40.2.1 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > IPv4 neighbor address subTLV #8, length: 4, 10.40.2.2 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Unreserved bandwidth subTLV #11, length: 32 > TE-Class 0: 154.520 Mbps > TE-Class 1: 116.640 Mbps > TE-Class 2: 77.760 Mbps > TE-Class 3: 38.880 Mbps > TE-Class 4: 155.520 Mbps > TE-Class 5: 116.640 Mbps > TE-Class 6: 77.760 Mbps > TE-Class 7: 38.880 Mbps > Reservable link bandwidth subTLV #10, length: 4, 155.520 Mbps > Maximum link bandwidth subTLV #9, length: 4, 155.520 Mbps > Administrative groups subTLV #3, length: 4, 0x00000000 > Bandwidth Constraints (old) subTLV #12, length: 17 > Bandwidth Constraints Model ID: Russian dolls (0) > Bandwidth constraint CT0: 155.520 Mbps > Bandwidth constraint CT1: 116.640 Mbps > Bandwidth constraint CT2: 77.760 Mbps > Bandwidth constraint CT3: 38.880 Mbps > IPv4 Internal Reachability TLV #128, length: 72 > IPv4 prefix: 10.255.6.110/32, Distribution: up, > Metric: 0, Internal > IPv4 prefix: 10.40.2.0/30, Distribution: up, > Metric: 10, Internal > IPv4 prefix: 10.40.1.0/30, Distribution: up, > Metric: 20, Internal > IPv4 prefix: 10.40.3.0/30, Distribution: up, > Metric: 20, Internal > IPv4 prefix: 10.255.70.1/32, Distribution: up, > Metric: 10, Internal > IPv4 prefix: 10.255.71.212/32, Distribution: up, > Metric: 20, Internal > Extended IPv4 Reachability TLV #135, length: 54 > IPv4 prefix: 10.255.6.110/32, Distribution: up, Metric: 0 > IPv4 prefix: 10.40.2.0/30, Distribution: up, Metric: 10 > IPv4 prefix: 10.40.1.0/30, Distribution: up, Metric: 20 > IPv4 prefix: 10.40.3.0/30, Distribution: up, Metric: 20 > IPv4 prefix: 10.255.70.1/32, Distribution: up, Metric: 10 > IPv4 prefix: 10.255.71.212/32, Distribution: up, Metric: 20 > IPv6 reachability TLV #236, length: 22 > IPv6 prefix: abcd::10:255:6:110/128, Distribution: up, > Metric: 0, Internal > >> I looked at TLV type 132, but it requires at least one interface IP address >> only, rest are optional. The TLV type 128 can give you the prefix >> and netmask >> but not the exact IP address. > > TLV 132 is typically used in IIHs - some implementations add also the > IP address of the > loopback IP adress packeged in TLV 132 in LSPs. > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 16:41:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnPo-0003b6-Dn; Wed, 12 Oct 2005 16:41:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnPn-0003aw-Ao for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 16:41:31 -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 QAA03990 for ; Wed, 12 Oct 2005 16:41:28 -0400 (EDT) Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnaA-0004T4-U3 for isis-wg@ietf.org; Wed, 12 Oct 2005 16:52:15 -0400 Received: from mvrelay.mv.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j9CKfKgJ010354; Wed, 12 Oct 2005 15:41:21 -0500 (CDT) Received: from SPEEDY1PC (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j9CKfNn7027401; Wed, 12 Oct 2005 13:41:24 -0700 (PDT) Message-Id: <200510122041.j9CKfNn7027401@mvrelay.mv.usa.alcatel.com> From: "Don Goodspeed" To: , Subject: RE: [Isis-wg] Interface IP addresses from IS-IS Date: Wed, 12 Oct 2005 13:41:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <20051012162932.pg9694kdkw4ss0w4@webmail.sce.carleton.ca> Thread-Index: AcXPbKwOGrKTOSBUSk+5fJchOOsH7QAAEurg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: 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 Correct. For TE TLVs, some implementations advertise all router interfaces while others like the one below only advertise one reachable IP address unless there is an active nbr on that interface. Note that the subnets for all active ISIS interfaces should be included in the TE IP reachability TLVs though. Think OSPF stub interfaces (those w/out nbrs), only the subnet is advertised in the router LSA, not the specific IP address. -don -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of rup@sce.carleton.ca Sent: Wednesday, October 12, 2005 1:30 PM To: isis-wg@ietf.org Subject: Re: [Isis-wg] Interface IP addresses from IS-IS Hi guys, Thanks for the response. The TE TLV was only defined in RFC 3784 and may not be present in most deployed systems. Further, I am seeing older Cisco boxes running IS-IS that only seem to advertise the IP for one interface. Does this mean that there are many deployed IS-IS systems which do not advertise their interface IP addresses? rgds, rupinder makkar > > > rup@sce.carleton.ca wrote: >> Hi guys, >> >> Does any of the IS-IS packets contains the IP addresses of all the >> interfaces of >> router runnning IS-IS? > > LSPs (if traffic-engineering is enabled on a link) may contain subTLV 6,8 > to the extended IS reach TLV 22. > > i.e. see below a tcpdump output of an IS-IS LSP: > > 18:28:54.259841 IS-IS, length 333 > L2 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0) > lsp-id: 0102.5500.6110.00-00, seq: 0x00000005, lifetime: 1198s > chksum: 0x59e3 (correct), PDU length: 333, Flags: [ L1L2 IS ] > Area address(es) TLV #1, length: 14 > Area address (length: 13): 47.0005.80ff.f800.0000.0108.0001 > Protocols supported TLV #129, length: 2 > NLPID(s): IPv4 (0xcc), IPv6 (0x8e) > Traffic Engineering Router ID TLV #134, length: 4 > Traffic Engineering Router ID: 10.255.6.110 > IPv4 Interface address(es) TLV #132, length: 4 > IPv4 interface address: 10.255.6.110 > Hostname TLV #137, length: 8 > Hostname: schnapps > IS Reachability TLV #2, length: 12 > IsNotVirtual > IS Neighbor: 0102.5507.0001.00, Default Metric: 10, Internal > Extended IS Reachability TLV #22, length: 94 > IS Neighbor: 0102.5507.0001.00, Metric: 10, sub-TLVs > present (83) > IPv4 interface address subTLV #6, length: 4, 10.40.2.1 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > IPv4 neighbor address subTLV #8, length: 4, 10.40.2.2 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Unreserved bandwidth subTLV #11, length: 32 > TE-Class 0: 154.520 Mbps > TE-Class 1: 116.640 Mbps > TE-Class 2: 77.760 Mbps > TE-Class 3: 38.880 Mbps > TE-Class 4: 155.520 Mbps > TE-Class 5: 116.640 Mbps > TE-Class 6: 77.760 Mbps > TE-Class 7: 38.880 Mbps > Reservable link bandwidth subTLV #10, length: 4, 155.520 Mbps > Maximum link bandwidth subTLV #9, length: 4, 155.520 Mbps > Administrative groups subTLV #3, length: 4, 0x00000000 > Bandwidth Constraints (old) subTLV #12, length: 17 > Bandwidth Constraints Model ID: Russian dolls (0) > Bandwidth constraint CT0: 155.520 Mbps > Bandwidth constraint CT1: 116.640 Mbps > Bandwidth constraint CT2: 77.760 Mbps > Bandwidth constraint CT3: 38.880 Mbps > IPv4 Internal Reachability TLV #128, length: 72 > IPv4 prefix: 10.255.6.110/32, Distribution: up, > Metric: 0, Internal > IPv4 prefix: 10.40.2.0/30, Distribution: up, > Metric: 10, Internal > IPv4 prefix: 10.40.1.0/30, Distribution: up, > Metric: 20, Internal > IPv4 prefix: 10.40.3.0/30, Distribution: up, > Metric: 20, Internal > IPv4 prefix: 10.255.70.1/32, Distribution: up, > Metric: 10, Internal > IPv4 prefix: 10.255.71.212/32, Distribution: up, > Metric: 20, Internal > Extended IPv4 Reachability TLV #135, length: 54 > IPv4 prefix: 10.255.6.110/32, Distribution: up, Metric: 0 > IPv4 prefix: 10.40.2.0/30, Distribution: up, Metric: 10 > IPv4 prefix: 10.40.1.0/30, Distribution: up, Metric: 20 > IPv4 prefix: 10.40.3.0/30, Distribution: up, Metric: 20 > IPv4 prefix: 10.255.70.1/32, Distribution: up, Metric: 10 > IPv4 prefix: 10.255.71.212/32, Distribution: up, Metric: 20 > IPv6 reachability TLV #236, length: 22 > IPv6 prefix: abcd::10:255:6:110/128, Distribution: up, > Metric: 0, Internal > >> I looked at TLV type 132, but it requires at least one interface IP address >> only, rest are optional. The TLV type 128 can give you the prefix >> and netmask >> but not the exact IP address. > > TLV 132 is typically used in IIHs - some implementations add also the > IP address of the > loopback IP adress packeged in TLV 132 in LSPs. > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 18:29:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPp5z-0004eV-4M; Wed, 12 Oct 2005 18:29:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPp5w-0004eQ-MJ for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 18:29:09 -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 SAA09261 for ; Wed, 12 Oct 2005 18:29:04 -0400 (EDT) Received: from mx4.tellabs.com ([204.154.129.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPpGJ-0007C6-MG for isis-wg@ietf.org; Wed, 12 Oct 2005 18:39:52 -0400 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 12 Oct 2005 22:45:59 +0000 X-SBRS: None X-IronPort-AV: i="3.97,207,1125878400"; d="scan'208"; a="31106185:sNHT34342936" Received: from USSJEX1.tellabs-west.tellabsinc.net ([172.25.6.7]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Oct 2005 17:28:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isis-wg] Computation of areas in MT-ISIS Date: Wed, 12 Oct 2005 15:28:48 -0700 Message-ID: <4B731D5A5B73494493A5F41ABF854C750382673E@USSJEX1.tellabs-west.tellabsinc.net> Thread-Topic: [Isis-wg] Computation of areas in MT-ISIS thread-index: AcXPAbE0mlhGmiv9SReAhV3BvJAf7AAdfSAA From: "Pudiyapura, Ajeer" To: "mike shand" , "Les Ginsberg \(ginsberg\)" X-OriginalArrivalTime: 12 Oct 2005 22:28:50.0410 (UTC) FILETIME=[51BC0CA0:01C5CF7C] Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org 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 Mike, Les. Thanks for the clarification. I agree that there is no routing between N1 and N5 in the IPv6 topology because L1 routing is partitioned in area A2. This would be the expected behavior in the absence of partition repair. N3(L2-only) / \ / \ / \ / \ / \ (L1L2)N2 N4(L1L2) | | | | | | | | N1(L1) N5(L1) Area Configurations: N1: A1 N2: A1, A2 N3: Any subset of {A1,A2,A3} N4: A2, A3 N5: A3 But if you consider the same topology for IPv4 topology, without partition repair, routing will work between N1 and N5 for the following reason. 1. N2 will compute Union Area Address set = {A1, A2} 2. N4 will compute Union Area Address set = {A2, A3} 3. Both N2 and N4 will set attached bit set in their L1 LSPs. 4. Both N1 and N5 will install default routes. 5. Routing will work smoothly between N1 and N5 using the backbone. Is there any mechanism to prevent this? So apparently, there is some discrepancy in the behavior between default routing and MT routing for the same topology. Is this true? And is this documented? Thanks -Ajeer Pudiyapura -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Wednesday, October 12, 2005 12:51 AM To: Les Ginsberg (ginsberg) Cc: Les Ginsberg (ginsberg); Pudiyapura, Ajeer; Naiming Shen (naiming); May Lu; isis-wg@ietf.org Subject: RE: [Isis-wg] Computation of areas in MT-ISIS A few comments inline below. At 08:27 12/10/2005, Les Ginsberg \(ginsberg\) wrote: >One addition below. > > > -----Original Message----- > > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On >Behalf > > Of Les Ginsberg (ginsberg) > > Sent: Tuesday, October 11, 2005 11:45 PM > > To: Pudiyapura, Ajeer; Naiming Shen (naiming); May Lu > > Cc: isis-wg@ietf.org > > Subject: RE: [Isis-wg] Computation of areas in MT-ISIS > > > > Ajeer - > > > > > -----Original Message----- > > > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On > > Behalf > > > Of Pudiyapura, Ajeer > > > Sent: Tuesday, October 11, 2005 12:07 PM > > > To: Naiming Shen (naiming); May Lu > > > Cc: isis-wg@ietf.org > > > Subject: RE: [Isis-wg] Computation of areas in MT-ISIS > > > > > > Naiming, > > > > > > Please consider the following MT-ISIS network example: > > > > > > > > > N3(L2-only) > > > / \ > > > / \ > > > V6/ \V6 > > > / \ > > > / \ > > > (L1L2)N2 -------- N4(L1L2) > > > | V4 | > > > | | > > > V4/V6| | V4/V6 > > > | | > > > N1(L1) N5(L1) > > > > > > Area Configurations: > > > > > > N1: A1 > > > N2: A1, A2 > > > N4: A2, A3 > > > N5: A3 > > > > > > > You don't specify the area address(es) for N3, which make it a bit > > difficult to follow your example, but I am assuming it is in the set >of > > (A1,A2,A3). If not, please explain where I have marked "**N3**" below. > > > > As this does not seem to be key to your question, I continue to >comment > > below. > > > > > > > The default (IPv4) Topology of the above network would be: > > > > > > > > > (L1L2)N2 -------- N4(L1L2) > > > | | > > > | | > > > | | > > > | | > > > N1(L1) N5(L1) > > > > > > > > > Here: > > > 1. Each adjacent router is configured with at least one common area > > id, > > > hence forming an L1 adjacency. While such "pairwise" assignment of area addresses is technically possible, it is strongly deprecated because it can lead to unexpected area configurations during failure conditions even in standard ISO/IEC 10589. The original design of allowing multiple area addresses per area was to allow for area splitting and merging (and decnet PhaseIV addressing). It was expected that ALL routers within an area would have the same set of area addresses, except during split/merge operations, and even then that only one area address would be added or deleted at a time, so preserving the transitive property." > > > 2. Both N2 and N4 computes Union Area Address set, which would be > > > {A1,A2,A3} > > > 3. Neither N2 nor N4 would set the attached bit in L1 LSP since the > > > entire network acts as an L1 cloud. > > > 4. Neither N1 nor N5 would install a default route. > > > 5. Since N1 would get L1 LSP from N5 and vice versa, routing between > > > them would work fine, as expected. > > > > > > > > > Now please consider the IPv6 Topology of the above network: > > > > > > > > > N3(L2-only) > > > / \ > > > / \ > > > / \ > > > / \ > > > / \ > > > (L1L2)N2 N4(L1L2) > > > | | > > > | | > > > | | > > > | | > > > N1(L1) N5(L1) > > > > > > > > > 6. Since both N2 and N4 would use the Union Area Address set from > > > Default topology, it will be {A1,A2,A3} as in step 2 above. > > > 7. Neither N2 nor N4 would set the attached bit in their L1 LSPs > > because > > > no more Areas are reachable through L2 routing than the Union Area > > > Address set. > > > > **N3** > > I therefore conclude N3 has area addresses in the set of (A1,A2,A3). > > Which means there is no reason to set ATT bit. Agreed. > > > > > 8. Neither N1 nor N5 would install a default route. > > > 9. Since N1 in this case would not get L1 LSPs from N5 (and vice > > versa) > > > routing will not be available between N1 and N5, even though there >is > > a > > > path between them that uses the L2 connectivity. > > > > > > > How do you conclude that N1 would get no L1 LSPs from N5 (and vice > > versa)?? > > > > Even if you were to use the optimized flooding rules described in > > Section 10 of the draft, in your example the only LSPs N4 could choose > > to "not flood" to N2 would be an LSP from N5 which only had V6 TLVs in > > it. It would still be obligated to flood any LSPs from N5 with any V4 > > info in them. > > > > Of course if there is no link between N2 and N4 in any topology, then > > the IPv4 topology is partitioned - and no attempt to support partition > > repair is defined in the draft (See Section 7). > >It should also be noted that the IPv6 (not v4) topology is partitioned >at L1 as currently defined, regardless of the presence or absence of a >V4 enabled link between N2 and N4. Exactly. Mike > Les > > > > > That said, I think the optimized flooding rules are not worth the > > trouble - and require additional logic than what is specified in the > > draft e.g. special CSNPs to be generated for neighbors on which > > optimized flooding is attempted and LSP #0 must always be flooded (at > > least to L1L2 neighbors). I have suggested to Naiming that Section 10 >be > > removed. > > > > Les > > > > > > > Please correct me if I am wrong. > > > Thanks > > > -Ajeer Pudiyapura > > > > > > > > > -----Original Message----- > > > From: Naiming Shen [mailto:naiming@cisco.com] > > > Sent: Monday, October 10, 2005 11:34 AM > > > To: May Lu > > > Cc: Pudiyapura, Ajeer; isis-wg@ietf.org > > > Subject: Re: [Isis-wg] Computation of areas in MT-ISIS > > > > > > May, > > > > > > May Lu said the following on 10/10/2005 09:20 AM: > > > > If a MT-ISIS node runs different protocols on its interfaces, how > > > > does the node broadcast its union address in L2 LSP? > > > > > > > > See configuration below: > > > > > > > > Node1(area 01, 04) ---- Node2 (area 01, 02) --- Node3 (area 02, >05) > > > > IP Ipv6 > > > > > > > > All three nodes are MT-ISIS nodes. Node2 is connected to Node1 >with > > > > IP protocol. Node2 and Node3 are connected with IPV6 protocol. >Node2 > > > > IP union addresses should be 01, 02 and 04. Node2 Ipv6 union > > > > addresses should be 01, 02 and 05. Is this correct? > > > > > > > > If the union address does not consider the protocol, in the > > following > > > > case, there is a problem: > > > > > > > > Node1 (area 01) ------ Node2 (area 01) ----- Node3 (area 01, 02) >IP > > > > Ipv6 All three nodes are MT-ISIS nodes. Node1 and Node2 are > > connected > > > > via IP protocol. Node2 and Node3 are connected via Ipv6 protocol. > > > > Node1 is a level1 only node. Node2's union addresses are 01 and >02. > > > > Node2 will set attached bit on IP protocol and Node1 will set the >IP > > > > default route towards Node2. Actually Node1 and Node2 are using >the > > > > same area address in IP network and Node1 shouldn't set default > > route > > > > to Node2. > > > > > > > > > > But don't you already have problem even if Node3 is IP(not IPv6) ? > > > or do we already have problem if they are not MT-ISIS nodes? If we > > > are playing with IP/IPv6, why should we assigning different areas to > > > those nodes ? > > > > > > thanks. > > > - Naiming > > > > > > > Thanks, - Xiaomei Lu > > > > > > > > > > > > -----Original Message----- From: Naiming Shen > > > > [mailto:naiming@cisco.com] Sent: Saturday, October 08, 2005 12:01 > > > AM > > > > To: Pudiyapura, Ajeer Cc: isis-wg@ietf.org Subject: >Re: > > > [Isis-wg] > > > > Computation of areas in MT-ISIS > > > > > > > > > > > > > > > > Pudiyapura, Ajeer said the following on 10/06/2005 11:09 AM: > > > > > > > >> Hi. > > > >> > > > >> > > > >> > > > >> I have the following questions: > > > >> > > > >> > > > >> > > > >> 1) How is Area Address Computation (section 7.2.11 of >ISO/IEC > > > >> 10589) done in Multi Topology IS-IS? Are they computed >separately > > > >> for each topology? > > > >> > > > > > > > > > > > > No. MT-ISIS node keeps the same system-id, areas, levels, >hostname, > > > > etc. there is no change to any of that. > > > > > > > > thanks. - Naiming > > > > > > > > > > > >> 2) If so, how is the resulting set advertised in L2 LSPs > > > >> since there is no mechanism to do this per topology? > > > >> > > > >> > > > >> > > > >> Thanks > > > >> > > > >> -Ajeer Pudiyapura > > > >> > > > >> > > > >> > > > >> ============================================================ 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@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > > > > > > > > _______________________________________________ Isis-wg mailing >list > > > > Isis-wg@ietf.org https://www1.ietf.org/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@ietf.org > > > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/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@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 19:08:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPpho-0000uJ-NZ; Wed, 12 Oct 2005 19:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPphn-0000uE-VG for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 19:08:16 -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 TAA10904 for ; Wed, 12 Oct 2005 19:08:12 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPpsC-00083b-Cj for isis-wg@ietf.org; Wed, 12 Oct 2005 19:19:01 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Oct 2005 16:08:06 -0700 X-IronPort-AV: i="3.97,207,1125903600"; d="scan'208"; a="219593415:sNHT30518430" Received: from [128.107.134.5] (naiming-linux.cisco.com [128.107.134.5]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9CN808k001183; Wed, 12 Oct 2005 16:08:01 -0700 (PDT) Message-ID: <434D9752.7050308@cisco.com> Date: Wed, 12 Oct 2005 16:08:02 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pudiyapura, Ajeer" Subject: Re: [Isis-wg] Computation of areas in MT-ISIS References: <4B731D5A5B73494493A5F41ABF854C750382673E@USSJEX1.tellabs-west.tellabsinc.net> In-Reply-To: <4B731D5A5B73494493A5F41ABF854C750382673E@USSJEX1.tellabs-west.tellabsinc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 78a8240bd7a9c0d7033035fffd7b84c6 Content-Transfer-Encoding: 7bit Cc: "Les Ginsberg \(ginsberg\)" , isis-wg@ietf.org, mike shand 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 Ajeer, Pudiyapura, Ajeer said the following on 10/12/2005 03:28 PM: > Mike, Les. > > Thanks for the clarification. I agree that there is no routing between > N1 and N5 in the IPv6 topology because L1 routing is partitioned in area > A2. This would be the expected behavior in the absence of partition > repair. > > > N3(L2-only) > / \ > / \ > / \ > / \ > / \ > (L1L2)N2 N4(L1L2) > | | > | | > | | > | | > N1(L1) N5(L1) > > Area Configurations: > > N1: A1 > N2: A1, A2 > N3: Any subset of {A1,A2,A3} > N4: A2, A3 > N5: A3 > > > But if you consider the same topology for IPv4 topology, without > partition repair, routing will work between N1 and N5 for the following > reason. > > 1. N2 will compute Union Area Address set = {A1, A2} > 2. N4 will compute Union Area Address set = {A2, A3} > 3. Both N2 and N4 will set attached bit set in their L1 LSPs. > 4. Both N1 and N5 will install default routes. > 5. Routing will work smoothly between N1 and N5 using the backbone. Is > there any mechanism to prevent this? > > So apparently, there is some discrepancy in the behavior between > default routing and MT routing for the same topology. Is this true? Not really. The MT TLV has the A bit. For the most simple approach, the IPv6 topology just set the ATT bit as it would for the default topology(if the default and IPv6 topology has the same links and adjacencies), unless there is some other reasons not to do so. An implementation can also configure routemaps, ACLs to match and set the ATT bit for diff topologies or unconditaionally set or unset ATT bit. thanks. - Naiming > And is this documented? > > Thanks > -Ajeer Pudiyapura > > > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Wednesday, October 12, 2005 12:51 AM > To: Les Ginsberg (ginsberg) > Cc: Les Ginsberg (ginsberg); Pudiyapura, Ajeer; Naiming Shen (naiming); > May Lu; isis-wg@ietf.org > Subject: RE: [Isis-wg] Computation of areas in MT-ISIS > > A few comments inline below. > > At 08:27 12/10/2005, Les Ginsberg \(ginsberg\) wrote: > >>One addition below. >> >> >>>-----Original Message----- >>>From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On >> >>Behalf >> >>>Of Les Ginsberg (ginsberg) >>>Sent: Tuesday, October 11, 2005 11:45 PM >>>To: Pudiyapura, Ajeer; Naiming Shen (naiming); May Lu >>>Cc: isis-wg@ietf.org >>>Subject: RE: [Isis-wg] Computation of areas in MT-ISIS >>> >>>Ajeer - >>> >>> >>>>-----Original Message----- >>>>From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] > > On > >>>Behalf >>> >>>>Of Pudiyapura, Ajeer >>>>Sent: Tuesday, October 11, 2005 12:07 PM >>>>To: Naiming Shen (naiming); May Lu >>>>Cc: isis-wg@ietf.org >>>>Subject: RE: [Isis-wg] Computation of areas in MT-ISIS >>>> >>>>Naiming, >>>> >>>> Please consider the following MT-ISIS network example: >>>> >>>> >>>> N3(L2-only) >>>> / \ >>>> / \ >>>> V6/ \V6 >>>> / \ >>>> / \ >>>> (L1L2)N2 -------- N4(L1L2) >>>> | V4 | >>>> | | >>>> V4/V6| | V4/V6 >>>> | | >>>> N1(L1) N5(L1) >>>> >>>>Area Configurations: >>>> >>>> N1: A1 >>>> N2: A1, A2 >>>> N4: A2, A3 >>>> N5: A3 >>>> >>> >>>You don't specify the area address(es) for N3, which make it a bit >>>difficult to follow your example, but I am assuming it is in the set >> >>of >> >>>(A1,A2,A3). If not, please explain where I have marked "**N3**" > > below. > >>>As this does not seem to be key to your question, I continue to >> >>comment >> >>>below. >>> >>> >>> >>>>The default (IPv4) Topology of the above network would be: >>>> >>>> >>>> (L1L2)N2 -------- N4(L1L2) >>>> | | >>>> | | >>>> | | >>>> | | >>>> N1(L1) N5(L1) >>>> >>>> >>>>Here: >>>>1. Each adjacent router is configured with at least one common > > area > >>>id, >>> >>>>hence forming an L1 adjacency. > > > While such "pairwise" assignment of area addresses is technically > possible, > it is strongly deprecated because it can lead to unexpected area > configurations during failure conditions even in standard ISO/IEC 10589. > > The original design of allowing multiple area addresses per area was to > allow for area splitting and merging (and decnet PhaseIV addressing). > It > was expected that ALL routers within an area would have the same set of > area addresses, except during split/merge operations, and even then that > > only one area address would be added or deleted at a time, so preserving > > the transitive property." > > >>>>2. Both N2 and N4 computes Union Area Address set, which would be >>>>{A1,A2,A3} >>>>3. Neither N2 nor N4 would set the attached bit in L1 LSP since > > the > >>>>entire network acts as an L1 cloud. >>>>4. Neither N1 nor N5 would install a default route. >>>>5. Since N1 would get L1 LSP from N5 and vice versa, routing > > between > >>>>them would work fine, as expected. >>>> >>>> >>>> Now please consider the IPv6 Topology of the above network: >>>> >>>> >>>> N3(L2-only) >>>> / \ >>>> / \ >>>> / \ >>>> / \ >>>> / \ >>>> (L1L2)N2 N4(L1L2) >>>> | | >>>> | | >>>> | | >>>> | | >>>> N1(L1) N5(L1) >>>> >>>> >>>>6. Since both N2 and N4 would use the Union Area Address set from >>>>Default topology, it will be {A1,A2,A3} as in step 2 above. >>>>7. Neither N2 nor N4 would set the attached bit in their L1 LSPs >>> >>>because >>> >>>>no more Areas are reachable through L2 routing than the Union Area >>>>Address set. >>> >>>**N3** >>>I therefore conclude N3 has area addresses in the set of (A1,A2,A3). >>>Which means there is no reason to set ATT bit. > > > Agreed. > > >>>>8. Neither N1 nor N5 would install a default route. >>>>9. Since N1 in this case would not get L1 LSPs from N5 (and vice >>> >>>versa) >>> >>>>routing will not be available between N1 and N5, even though there >> >>is >> >>>a >>> >>>>path between them that uses the L2 connectivity. >>>> >>> >>>How do you conclude that N1 would get no L1 LSPs from N5 (and vice >>>versa)?? >>> >>>Even if you were to use the optimized flooding rules described in >>>Section 10 of the draft, in your example the only LSPs N4 could > > choose > >>>to "not flood" to N2 would be an LSP from N5 which only had V6 TLVs > > in > >>>it. It would still be obligated to flood any LSPs from N5 with any > > V4 > >>>info in them. >>> >>>Of course if there is no link between N2 and N4 in any topology, > > then > >>>the IPv4 topology is partitioned - and no attempt to support > > partition > >>>repair is defined in the draft (See Section 7). >> >>It should also be noted that the IPv6 (not v4) topology is partitioned >>at L1 as currently defined, regardless of the presence or absence of a >>V4 enabled link between N2 and N4. > > > Exactly. > > Mike > > > > >> Les >> >> >>>That said, I think the optimized flooding rules are not worth the >>>trouble - and require additional logic than what is specified in the >>>draft e.g. special CSNPs to be generated for neighbors on which >>>optimized flooding is attempted and LSP #0 must always be flooded > > (at > >>>least to L1L2 neighbors). I have suggested to Naiming that Section > > 10 > >>be >> >>>removed. >>> >>> Les >>> >>> >>> >>>>Please correct me if I am wrong. >>>>Thanks >>>>-Ajeer Pudiyapura >>>> >>>> >>>>-----Original Message----- >>>>From: Naiming Shen [mailto:naiming@cisco.com] >>>>Sent: Monday, October 10, 2005 11:34 AM >>>>To: May Lu >>>>Cc: Pudiyapura, Ajeer; isis-wg@ietf.org >>>>Subject: Re: [Isis-wg] Computation of areas in MT-ISIS >>>> >>>>May, >>>> >>>>May Lu said the following on 10/10/2005 09:20 AM: >>>> >>>>>If a MT-ISIS node runs different protocols on its interfaces, > > how > >>>>>does the node broadcast its union address in L2 LSP? >>>>> >>>>>See configuration below: >>>>> >>>>>Node1(area 01, 04) ---- Node2 (area 01, 02) --- Node3 (area 02, >> >>05) >> >>>>>IP Ipv6 >>>>> >>>>>All three nodes are MT-ISIS nodes. Node2 is connected to Node1 >> >>with >> >>>>>IP protocol. Node2 and Node3 are connected with IPV6 protocol. >> >>Node2 >> >>>>>IP union addresses should be 01, 02 and 04. Node2 Ipv6 union >>>>>addresses should be 01, 02 and 05. Is this correct? >>>>> >>>>>If the union address does not consider the protocol, in the >>> >>>following >>> >>>>>case, there is a problem: >>>>> >>>>>Node1 (area 01) ------ Node2 (area 01) ----- Node3 (area 01, > > 02) > >>IP >> >>>>>Ipv6 All three nodes are MT-ISIS nodes. Node1 and Node2 are >>> >>>connected >>> >>>>>via IP protocol. Node2 and Node3 are connected via Ipv6 > > protocol. > >>>>>Node1 is a level1 only node. Node2's union addresses are 01 and >> >>02. >> >>>>>Node2 will set attached bit on IP protocol and Node1 will set > > the > >>IP >> >>>>>default route towards Node2. Actually Node1 and Node2 are using >> >>the >> >>>>>same area address in IP network and Node1 shouldn't set default >>> >>>route >>> >>>>>to Node2. >>>>> >>>> >>>>But don't you already have problem even if Node3 is IP(not IPv6) ? >>>>or do we already have problem if they are not MT-ISIS nodes? If > > we > >>>>are playing with IP/IPv6, why should we assigning different areas > > to > >>>>those nodes ? >>>> >>>>thanks. >>>>- Naiming >>>> >>>> >>>>>Thanks, - Xiaomei Lu >>>>> >>>>> >>>>>-----Original Message----- From: Naiming Shen >>>>>[mailto:naiming@cisco.com] Sent: Saturday, October 08, 2005 > > 12:01 > >>>>AM >>>> >>>>>To: Pudiyapura, Ajeer Cc: isis-wg@ietf.org Subject: >> >>Re: >> >>>>[Isis-wg] >>>> >>>>>Computation of areas in MT-ISIS >>>>> >>>>> >>>>> >>>>>Pudiyapura, Ajeer said the following on 10/06/2005 11:09 AM: >>>>> >>>>> >>>>>>Hi. >>>>>> >>>>>> >>>>>> >>>>>>I have the following questions: >>>>>> >>>>>> >>>>>> >>>>>>1) How is Area Address Computation (section 7.2.11 of >> >>ISO/IEC >> >>>>>> 10589) done in Multi Topology IS-IS? Are they computed >> >>separately >> >>>>>>for each topology? >>>>>> >>>>> >>>>> >>>>>No. MT-ISIS node keeps the same system-id, areas, levels, >> >>hostname, >> >>>>>etc. there is no change to any of that. >>>>> >>>>>thanks. - Naiming >>>>> >>>>> >>>>> >>>>>>2) If so, how is the resulting set advertised in L2 LSPs >>>>>>since there is no mechanism to do this per topology? >>>>>> >>>>>> >>>>>> >>>>>>Thanks >>>>>> >>>>>>-Ajeer Pudiyapura >>>>>> >>>>>> >>>>>> >>>>>>============================================================ > > 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@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/isis-wg >>>>> >>>>> >>>>>_______________________________________________ Isis-wg mailing >> >>list >> >>>>>Isis-wg@ietf.org https://www1.ietf.org/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@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/isis-wg >>> >>>_______________________________________________ >>>Isis-wg mailing list >>>Isis-wg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/isis-wg >> >>_______________________________________________ >>Isis-wg mailing list >>Isis-wg@ietf.org >>https://www1.ietf.org/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@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 19:14:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPpnc-0001lQ-JF; Wed, 12 Oct 2005 19:14:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPpnb-0001lH-6w for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 19:14:15 -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 TAA11168 for ; Wed, 12 Oct 2005 19:14:11 -0400 (EDT) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPpxz-0008BS-LF for isis-wg@ietf.org; Wed, 12 Oct 2005 19:25:00 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 2B88C3DCC8B; Wed, 12 Oct 2005 16:13:50 -0700 (PDT) In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508490042@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15508490042@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: Re: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt Date: Wed, 12 Oct 2005 16:14:03 -0700 To: Jeff Parker X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , "Wijnen, Bert \(Bert\)" , ISIS WG 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 Jeff, I suggest that we make these changes if necessary (sounds like not) as editorial in the RFC process. I *really* don't want to publish a new draft and then go through *another* WG LC. Thanks, Chris. On Oct 12, 2005, at 8:14 AM, Wijnen, Bert (Bert) wrote: > I was already happy Jeff. > This makes it even better. > > Thanks > > Bert > > >> -----Original Message----- >> From: Parker, Jeff [mailto:jeffp@middlebury.edu] >> Sent: Wednesday, October 12, 2005 17:00 >> To: Wijnen, Bert (Bert) >> Cc: C. M. Heard; isis-wg@ietf.org >> Subject: Re: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt >> >> >> On 10/12/05 10:37 AM, "Wijnen, Bert (Bert)" >> wrote: >> >> >>> In rev 23 I am happy to see THis: >>> >>> IsisSystemID ::= TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "A system ID." >>> SYNTAX OCTET STRING (SIZE(6)) >>> >>> changed into this: >>> >>> IsisSystemID ::= TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "The ID for an Intermediate System. This should >>> be unique within a network, and is included >>> in all PDUs originated by an Intermediate System. >>> >>>> Some implementations may automatically assign >>>> values and not permit an SNMP write, while >>>> others may require the value to be set manually. >>>> >>> The protocol does not place any meanings upon >>> the bits, other than using ordering to break >>> ties in electing a Designated IS on a LAN." >>> REFERENCE "{ISIS.aoi systemId (119)}" >>> SYNTAX OCTET STRING (SIZE(6)) >>> >>> But the 3 lines marked with > seem not part of the TC. >>> It depends on where /how the TC is used. Some may use it >>> for a read-only object and then those 3 lines mean nothing >>> or may be confusing. The 3 lines belong in a DESCRIPTION clause >>> where the TC is used as a SYNTAX in an OBJECT-TYPE and whihc >>> has possibly a MAX-ACCESS of read-write or read-create. >>> I am not hung up on this though. >>> >> >> Removed >> >> >>> When I see this >>> IsisLinkStatePDUID ::= TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "A Link State PDU Identifier." >>> SYNTAX OCTET STRING (SIZE(8)) >>> >>> changed into: >>> IsisLinkStatePDUID ::= TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "A Link State PDU Identifier formed from the >>> 6 byte System ID, a one byte PseudoNode ID, >>> and a one byte LSP fragment number." >>> REFERENCE "{See section 9.8 of ISO 10589}" >>> SYNTAX OCTET STRING (SIZE(8)) >>> Then I like that. But it would have been even more helpful >>> if you had been more explicit on the sequence of th 6, 1 nad 1 byte. >>> Maybe you imply that that is the sequence, but that is not >>> >> very clear. >> >>> Again, I can live with it. >>> >> >> "The 8 byte Link State PDU (LSP) ID, >> consisting of the 6 byte SystemID of the >> originating IS, a one byte PseudoNode ID >> which is 0 unless the LSP represents the >> topology of a LAN, and one byte LSP >> fragment number that are issued in sequence, >> starting with 0. Non zero PseudoNode IDs >> need to be unique to the IS, but need not >> match the IfIndex." >> >> This probably says too much about the PseudoNode ID. I believe it be >> wordsmithed further: the byte really only needs to be unique at that >> -level-. >> >> >>> When I see: >>> Configured values will survive an agent reboot." >>> I am happy. Better/clearer might have been: >>> Configured values MUST survive an agent reboot." >>> assuming that is what the WG wants. >>> I am not hung up on it. Besides, I see that Mike suggested the >>> "will survive" so I should not keep nitpicking further. >>> >>> Ready to go, as far as I am concerned! >>> Thanks Jeff! >>> >>> Bert >>> >> >> myrmidon:~/MIB jeff$ grep survive mib >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Dynamically created rows MUST survive an agent reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically created rows MUST survive an agent reboot. >> Dynamically created rows MUST survive an agent reboot. >> Dynamically learned rows do not survive an agent >> reboot." >> Configured values MUST survive an agent reboot." >> Dynamically created rows MUST survive an agent reboot." >> Configured values MUST survive an agent reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically created rows MUST survive an agent reboot." >> Dynamically created rows MUST survive an agent reboot. >> Dynamically learned rows will not survive an >> Dynamically learned rows will not survive an >> >> myrmidon:~/MIB jeff$ grep survive mib | grep -v MUST >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically learned rows do not survive an agent >> reboot." >> Dynamically learned rows will not survive an >> Dynamically learned rows will not survive an >> >> >> Other issues? >> >> - jdp >> >> > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Oct 12 19:58:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPqUn-0007Fu-N2; Wed, 12 Oct 2005 19:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPqUm-0007FA-7t for isis-wg@megatron.ietf.org; Wed, 12 Oct 2005 19:58:52 -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 TAA12869 for ; Wed, 12 Oct 2005 19:58:47 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPqfB-0000fE-5m for isis-wg@ietf.org; Wed, 12 Oct 2005 20:09:37 -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 j9CNwZBT001721; Wed, 12 Oct 2005 16:58:35 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9CNwRph002782; Wed, 12 Oct 2005 16:58:27 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9CNwQ1E002776; Wed, 12 Oct 2005 16:58:27 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 12 Oct 2005 16:58:26 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Christian Hopps Subject: Re: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Wijnen, Bert \(Bert\)" , ISIS WG 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 Wed, 12 Oct 2005, Christian Hopps wrote: > Jeff, > > I suggest that we make these changes if necessary (sounds like not) > as editorial in the RFC process. I *really* don't want to publish a > new draft and then go through *another* WG LC. > > Thanks, > Chris. I am not sure that the proposed changes -- especially the relatively important one shown below, deleting the inappropriate text from the IsisSystemID DESCRIPTION clause -- would be allowed by the RFC Editor without consultation with the IESG/cognizant ADs. It's possible to put this is in as an IESG note, but it's really better to have the I-D that is sent to the RFC Editor be as close as possible to what you want to publish. In any case it does not seem like full 2-week WG last call should be needed for these changes ... seems to me it should suffice to have a short (e.g. 48-hour) "does anybody object to these changes" last call. The document will after all still be going through IETF last call before it gets to the IESG. //cmh > IsisSystemID ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The ID for an Intermediate System. This should > be unique within a network, and is included > in all PDUs originated by an Intermediate System. > > > Some implementations may automatically assign > > values and not permit an SNMP write, while > > others may require the value to be set manually. > > > The protocol does not place any meanings upon > the bits, other than using ordering to break > ties in electing a Designated IS on a LAN." > REFERENCE "{ISIS.aoi systemId (119)}" > SYNTAX OCTET STRING (SIZE(6)) > > But the 3 lines marked with > seem not part of the TC. > It depends on where /how the TC is used. Some may use it > for a read-only object and then those 3 lines mean nothing > or may be confusing. The 3 lines belong in a DESCRIPTION clause > where the TC is used as a SYNTAX in an OBJECT-TYPE and whihc > has possibly a MAX-ACCESS of read-write or read-create. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 13 05:00:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPywg-0003EJ-M1; Thu, 13 Oct 2005 05:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPywe-0003E9-OW for isis-wg@megatron.ietf.org; Thu, 13 Oct 2005 05:00:13 -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 FAA03886 for ; Thu, 13 Oct 2005 05:00:09 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPz75-0004YT-NK for isis-wg@ietf.org; Thu, 13 Oct 2005 05:11:03 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9D8xu2e026143; Thu, 13 Oct 2005 03:59:57 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Oct 2005 10:59:56 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508490182@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Christian Hopps Subject: RE: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt Date: Thu, 13 Oct 2005 10:59:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "C. M. Heard" , ISIS WG 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 As Mike said. I think you can consider my comments purely editorial, even though one of them may sound technical (the removal of write-semantic from the TC). Again (as Mike said), we CAN deal with them as editorial comments from AD/IESG to RFC-Editor. But experience shows things go smoother if we have an I-D that is clean. So if you can respind an I-D real quick, then I would go for it. If not, then go ahead as is (actually, your own AD better says so instead of me). I do not see a need for another WG Last Call if you were to make those changes. You can (in my view) just say: WG, these few (editorial) changes were made after additonal MIB review. We (WG chair(s) believe they do not warrant a new WGLC, so we're handing this doc to AD for publication. You can always comment during IETF LC if you think this is inappropriate. Or speak up RIGHT NOW! Oh well.. trying to help. Betr > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Thursday, October 13, 2005 01:58 > To: Christian Hopps > Cc: Jeff Parker; ISIS WG; Wijnen, Bert (Bert) > Subject: Re: [Isis-wg] Final WG LC draft-ietf-isis-wg-mib-23.txt > > > On Wed, 12 Oct 2005, Christian Hopps wrote: > > Jeff, > > > > I suggest that we make these changes if necessary (sounds > like not) > > as editorial in the RFC process. I *really* don't want to > publish a > > new draft and then go through *another* WG LC. > > > > Thanks, > > Chris. > > I am not sure that the proposed changes -- especially the relatively > important one shown below, deleting the inappropriate text from the > IsisSystemID DESCRIPTION clause -- would be allowed by the RFC > Editor without consultation with the IESG/cognizant ADs. It's > possible to put this is in as an IESG note, but it's really better > to have the I-D that is sent to the RFC Editor be as close as > possible to what you want to publish. > > In any case it does not seem like full 2-week WG last call should be > needed for these changes ... seems to me it should suffice to have a > short (e.g. 48-hour) "does anybody object to these changes" last > call. The document will after all still be going through IETF last > call before it gets to the IESG. > > //cmh > > > IsisSystemID ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The ID for an Intermediate System. This should > > be unique within a network, and is included > > in all PDUs originated by an Intermediate System. > > > > > Some implementations may automatically assign > > > values and not permit an SNMP write, while > > > others may require the value to be set manually. > > > > > The protocol does not place any meanings upon > > the bits, other than using ordering to break > > ties in electing a Designated IS on a LAN." > > REFERENCE "{ISIS.aoi systemId (119)}" > > SYNTAX OCTET STRING (SIZE(6)) > > > > But the 3 lines marked with > seem not part of the TC. > > It depends on where /how the TC is used. Some may use it > > for a read-only object and then those 3 lines mean nothing > > or may be confusing. The 3 lines belong in a DESCRIPTION clause > > where the TC is used as a SYNTAX in an OBJECT-TYPE and whihc > > has possibly a MAX-ACCESS of read-write or read-create. > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 20 11:46:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EScce-0005iw-1I; Thu, 20 Oct 2005 11:46:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESccc-0005ir-Es for isis-wg@megatron.ietf.org; Thu, 20 Oct 2005 11:46:26 -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 LAA24519 for ; Thu, 20 Oct 2005 11:46:17 -0400 (EDT) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EScoa-0006OY-3j for isis-wg@ietf.org; Thu, 20 Oct 2005 11:58:48 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOO00K6O0Z2FJ@usaga01-in.huawei.com> for isis-wg@ietf.org; Thu, 20 Oct 2005 08:42:38 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOO006T60Z02P@usaga01-in.huawei.com> for isis-wg@ietf.org; Thu, 20 Oct 2005 08:42:38 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [10.110.102.91]) by szxmc02-in.huawei.com (mshttpd); Thu, 20 Oct 2005 23:45:51 +0800 Date: Thu, 20 Oct 2005 23:45:51 +0800 From: heqian 24209 Subject: [Isis-wg] New draft draft-heqian-isis-link-overload-00.txt is provided. To: isis-wg@ietf.org Message-id: <27bd1727c681.27c68127bd17@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_BW++SGdyG5Fs6qXvbNA/mw)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: 77cronux.leed0621@huawei.com 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 This is a multi-part message in MIME format. --Boundary_(ID_BW++SGdyG5Fs6qXvbNA/mw) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT Hi guys, I have just written one draft. It is about avoiding packet lost when IS-IS is using with LDP (Label Distrute Protocol) in MPLS network. Details are in the document. It is in attachment. Please refer. Any question and suggestion are warmly welcome. Regards, Heqian --Boundary_(ID_BW++SGdyG5Fs6qXvbNA/mw) Content-type: text/plain; NAME=draft-heqian-isis-link-overload-00.txt Content-disposition: attachment; filename=draft-heqian-isis-link-overload-00.txt Content-Transfer-Encoding: 7BIT Internet Engineering Task Force HeQian INTERNET-DRAFT XiongYi Expires Apr 2006 Huawei Technologies October 2005 Link Overload Attribute in IS-IS Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society 2005. All Rights Reserved. Abstract This document describes a mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with Label Distribution Protocol (LDP) during transient network conditions. 1. Introduction In many networks, the ISP uses MPLS to carry the data in PEs between CEs and LDP is used to create LSP (Label Switch Path). When IS-IS work with LDP, IS-IS always convergence faster than LDP, which can cause data losing when the data is transfering by LSP (Label Switch Path) in some cases. This document tries to find out a method to solve this interactional problem. 2. Discussion This document describes a mechanism that can be employed in IS-IS [1, 2] networks in order to avoid transition to a newly available path until other associated protocols such as LDP have been established its session. The benefits of such a mechanism can be realized when considering the following scenario depicted in Figure 1. +-----+ +-----------| RTB |-----------+ | +-----+ | | | +-----+ +-----+ CE.Src---| RTA | | RTD |---CE.Dst +-----+ +-----+ | | | +-----+ | +-----------| RTC |-----------+ +-----+ Figure 1: Example Network Topology IS-IS is running on all the routers as IGP. The path of RTA->RTB->RTD has more priority than RTA->RTC->RTD. CE.Src and CE.Dst are in same VPN. LDP sessions are created between each two routers and one LSP of RTA->RTB->RTD is created. The data are transmitted between two CEs by using the LSP created by LDP. If the state of the link between RTB and RTD changes to DOWN, the next hop of the routes to RTD on RTA will change from RTB to RTC. According to this change, LDP will remove the LSP (RTA->RTB->RTD) and try to create the LSP of RTA->RTC->RTD. Since the LDP sessions are already created between RTA and RTC, RTC and RTD, the LSP (RTA->RTC->RTD) can be created very quikly (about 10's of milli seconds). In this case, the data flow between CE.Src and CE.Dst will be lost only in the period IS-IS updating the network and LDP creating the LSP. Then, assume the state of the link between RTB and RTD changes to UP, the next hop of the routes to RTD on RTA will change back from RTC to RTB. According to this change, LDP will remove the LSP (RTA->RTC->RTD) and try to create the LSP of RTA->RTB->RTD. But at this time, the LDP session between RTB and RTD has not been established, the LSP (RTA->RTB->RTD) can be created till the LDP session between RTB and RTD established. The LDP session establishes slow (about 10's of seconds), this will delay the creation of LSP (RTA->RTB->RTD). In this case, the data flow between CE.Src and CE.Dst will be lost for a long time (at least the time of establishing LDP session). 3. Approach Now we introduce one method to solve the problem. 3.1. Link-Overload property One link property called link overload is required. This property can be carried by any type of IS-IS TLV descripting adjacency. For TLV 2 (IS Neighbor TLV)[1], we can use the eighth bit of default metric, this bit is already sighned to up/down bit, but it is never used for TLV 2. So we can use this bit to carry the Link-Overload property. For TLV 22 (Extended IS Reachability TLV)[3], we can define a new sub tlv named Link-Overload, sub-type is 3 (to be assigned by IANA) and has a length of 1 octets. For MT TLV 222 (MT Intermediate Systems TLV)[4], since this TLV only adds 2 octects (for reserved bits and MT ID) before TLV 22, we can use same method as what we extended for TLV 22. For convernions, we call all these three TLV as Neighbor TLV. This sub-TLV is OPTIONAL and MAY appear at most once for a single IS Neighbor TLV. 3.2. When to start sending the Link-Overload property When the adjacency established on a link, the implementation should check if LDP is enabled on the link and check the LDP's session status. If the LDP session is not established, then the Link-Overload property SHOULD be set in the Neighbor TLV. 3.3. How to use the Link-Overload property on the non-connected routers RTA and RTC are non-connected to the link RTB<->RTD routers. RTB and RTD establish new adjancency and send out the new LSPs with Link-Overload property. When RTA and RTC receive the new LSPs, RTA and RTC will signal a new SPF accroding to the changes. When the SPF is scheduled, the link with Link-Overload property should be ignored. The routes, used by LDP to create LSP (Label Switch Path), will not change during this time. Then the LSP (Label Switch Path) will not change. 3.4. How to use the Link-Overload property on the connected routers RTB and RTD are connected to the link RTB<->RTD routers. When these two routers generate and receive the new LSPs, SPF will be scheduled. When the SPF run, the link with Link-Overload property should be used only when the router is calculating the routes advertised by the other router. For example, when RTB calculates the routes advertised by RTD, the link RTB<->RTD SHOULD be used. And RTB SHOULD NOT calculates other routes via the link. RTB and RTD calculate the routes advertised by each other. These routes can be used for LDP to establish session. According to the algrithm above, only the routes for establishing LDP session will change back at this moment. The other routes, used by LDP to create LSP (Label Switch Path), will not change. So the LSP (Label Switch Path) will not change, and data transmission between RTA and RTD will still use the LSP (Label Switch Path) through RTA->RTC->RTD. 3.5. When to stop sending the Link-Overload property When the LDP session created, LDP SHOULD give a message to IS-IS. Based on this message, IS-IS SHOULD remove the Link-Overload property from the Neighbor TLV and generate new LSP. After the database synchronised, all the routers schedule a normal SPF calculation once. All the routes will change back to the path RTA->RTB->RTD. LDP will remove the LSP (RTA->RTC->RTD) and create the new LSP (RTA->RTB->RTD). Since the LDP session is already established on the link RTB<->RTD, the creation of LSP (RTA->RTB->RTD) will be very fast (about 10's milli seconds). According to this method, the data losting could be reduced much during the link RTB<->RTD changes back to UP status. If there is problem for LDP to send a message to IS-IS, IS-IS could not recover to the normal state. To avoid this, IS-IS can start a timer when the adjacency created, and when the timer expires, stop sending the Link-Overload property. 4. Deployment Considerations A router not supporting the Link-Overload sub-TLV MUST just silently ignore this sub-TLV. Since the Link-Overload property is used in IS-IS SPF calculation, some routers in the routing domain don't support the Link-Overload property can cause loops or black holes. 5. Potential Alternatives This extention needs all routers to support in the routing domain. When there are some routers who do not support the Link-Overload property, the way described below can be used. The connected routers don't send the Neighbor TLV when adjacency comes to UP if LDP session is not established. The non-connected routers will not know the adjacency, then, all the routes in non-connected routers will not change. The connected routers SHOULD start a SPF calculation. During the calculation, the adjacency SHOULD be used this adjacency SHOULD be used in it's calculation but ignore the two way check. The routes for establishing the LDP session can be calculated by this way. So, this method can compatible with the routers who do not support the Link-Overload property. The only constriction is that the connected router have to support this method both. 6. Security Considerations The Link-Overload property defined within this document describes an addition to the IS-IS Neighbor TLV and does not impact the security mechanism of the IS-IS protocol. 7. Acknowledgements The authors would like to thank Lixia Zhang, XiongYi, ZhangRenhai and LiDefeng for their useful comments. 8. References [1] ISO, "Intermediate system to Intermediate system routing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992. [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. [3] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering" RFC 3906, October 2004. [4] Tony Przygienda, Naiming Shen and Nischal Sheth, "M-ISIS: Multi Topology (MT) Routing in IS-IS" Draft draft-ietf-isis-wg-multi- topology-10, May 2005. 9. Author's Address HeQian Beijing Institution of Huawei Technologies, China. Phone: 86-010-82882012 EMail: heqian@huawei.com --Boundary_(ID_BW++SGdyG5Fs6qXvbNA/mw) 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 --Boundary_(ID_BW++SGdyG5Fs6qXvbNA/mw)-- From isis-wg-bounces@ietf.org Thu Oct 20 12:12:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESd1z-0007ev-S6; Thu, 20 Oct 2005 12:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESd1y-0007ek-AX for isis-wg@megatron.ietf.org; Thu, 20 Oct 2005 12:12:38 -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 MAA26162 for ; Thu, 20 Oct 2005 12:12:29 -0400 (EDT) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESdDw-0007Ir-57 for isis-wg@ietf.org; Thu, 20 Oct 2005 12:25:00 -0400 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by borg.juniper.net with ESMTP; 20 Oct 2005 09:12:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="505315702:sNHT27471328" Received: from [172.26.124.103] ([172.26.124.103]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 09:12:16 -0700 Message-ID: <4357C1DE.1000702@juniper.net> Date: Thu, 20 Oct 2005 18:12:14 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: heqian 24209 Subject: Re: [Isis-wg] New draft draft-heqian-isis-link-overload-00.txt is provided. References: <27bd1727c681.27c68127bd17@huawei.com> In-Reply-To: <27bd1727c681.27c68127bd17@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2005 16:12:16.0750 (UTC) FILETIME=[0A2B20E0:01C5D591] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Content-Transfer-Encoding: 7bit Cc: 77cronux.leed0621@huawei.com, isis-wg@ietf.org 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 heqian, there are already implementations out that fix the IGP/LDP desync problem by advertising the link with MAX_METRIC until LDP startup is complete; doing so, has the nice property that it is downwards compatible; /hannes heqian 24209 wrote: > Hi guys, > > I have just written one draft. It is about avoiding packet lost when IS-IS is using with LDP (Label Distrute Protocol) in MPLS network. > > Details are in the document. It is in attachment. Please refer. > > Any question and suggestion are warmly welcome. > > Regards, > Heqian > > > ------------------------------------------------------------------------ > > > Internet Engineering Task Force HeQian > INTERNET-DRAFT XiongYi > Expires Apr 2006 Huawei Technologies > October 2005 > > > Link Overload Attribute in IS-IS > > > > Status of this Memo > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > > Copyright Notice > > Copyright (C) The Internet Society 2005. All Rights Reserved. > > > Abstract > > This document describes a mechanism that can be employed in > Intermediate System to Intermediate System (IS-IS) networks > in order to decrease the data loss associated with Label > Distribution Protocol (LDP) during transient network conditions. > > > 1. Introduction > > In many networks, the ISP uses MPLS to carry the data in PEs between > CEs and LDP is used to create LSP (Label Switch Path). When IS-IS > work with LDP, IS-IS always convergence faster than LDP, which can > cause data losing when the data is transfering by LSP (Label Switch > Path) in some cases. This document tries to find out a method to > solve this interactional problem. > > > 2. Discussion > > This document describes a mechanism that can be employed in IS-IS [1, > 2] networks in order to avoid transition to a newly available path > until other associated protocols such as LDP have been established > its session. > > The benefits of such a mechanism can be realized when considering the > following scenario depicted in Figure 1. > > > +-----+ > +-----------| RTB |-----------+ > | +-----+ | > | | > +-----+ +-----+ > CE.Src---| RTA | | RTD |---CE.Dst > +-----+ +-----+ > | | > | +-----+ | > +-----------| RTC |-----------+ > +-----+ > > Figure 1: Example Network Topology > > IS-IS is running on all the routers as IGP. The path of RTA->RTB->RTD > has more priority than RTA->RTC->RTD. > > CE.Src and CE.Dst are in same VPN. LDP sessions are created between > each two routers and one LSP of RTA->RTB->RTD is created. The data are > transmitted between two CEs by using the LSP created by LDP. > > If the state of the link between RTB and RTD changes to DOWN, the next > hop of the routes to RTD on RTA will change from RTB to RTC. According > to this change, LDP will remove the LSP (RTA->RTB->RTD) and try to > create the LSP of RTA->RTC->RTD. Since the LDP sessions are already > created between RTA and RTC, RTC and RTD, the LSP (RTA->RTC->RTD) can > be created very quikly (about 10's of milli seconds). In this case, > the data flow between CE.Src and CE.Dst will be lost only in the > period IS-IS updating the network and LDP creating the LSP. > > Then, assume the state of the link between RTB and RTD changes to UP, > the next hop of the routes to RTD on RTA will change back from RTC to > RTB. According to this change, LDP will remove the LSP (RTA->RTC->RTD) > and try to create the LSP of RTA->RTB->RTD. But at this time, the LDP > session between RTB and RTD has not been established, the LSP > (RTA->RTB->RTD) can be created till the LDP session between RTB and > RTD established. The LDP session establishes slow (about 10's of > seconds), this will delay the creation of LSP (RTA->RTB->RTD). In this > case, the data flow between CE.Src and CE.Dst will be lost for a long > time (at least the time of establishing LDP session). > > 3. Approach > > Now we introduce one method to solve the problem. > > 3.1. Link-Overload property > > One link property called link overload is required. This property can > be carried by any type of IS-IS TLV descripting adjacency. > > For TLV 2 (IS Neighbor TLV)[1], we can use the eighth bit of default > metric, this bit is already sighned to up/down bit, but it is never > used for TLV 2. So we can use this bit to carry the Link-Overload > property. > > For TLV 22 (Extended IS Reachability TLV)[3], we can define a new sub > tlv named Link-Overload, sub-type is 3 (to be assigned by IANA) and > has a length of 1 octets. > > For MT TLV 222 (MT Intermediate Systems TLV)[4], since this TLV only > adds 2 octects (for reserved bits and MT ID) before TLV 22, we can use > same method as what we extended for TLV 22. > > For convernions, we call all these three TLV as Neighbor TLV. > > This sub-TLV is OPTIONAL and MAY appear at most once for a single IS > Neighbor TLV. > > 3.2. When to start sending the Link-Overload property > > When the adjacency established on a link, the implementation should > check if LDP is enabled on the link and check the LDP's session status. > If the LDP session is not established, then the Link-Overload property > SHOULD be set in the Neighbor TLV. > > 3.3. How to use the Link-Overload property on the non-connected routers > > RTA and RTC are non-connected to the link RTB<->RTD routers. RTB and > RTD establish new adjancency and send out the new LSPs with > Link-Overload property. When RTA and RTC receive the new LSPs, RTA and > RTC will signal a new SPF accroding to the changes. When the SPF is > scheduled, the link with Link-Overload property should be ignored. > > The routes, used by LDP to create LSP (Label Switch Path), will not > change during this time. Then the LSP (Label Switch Path) will not > change. > > 3.4. How to use the Link-Overload property on the connected routers > > RTB and RTD are connected to the link RTB<->RTD routers. When these > two routers generate and receive the new LSPs, SPF will be scheduled. > When the SPF run, the link with Link-Overload property should be used > only when the router is calculating the routes advertised by the other > router. For example, when RTB calculates the routes advertised by RTD, > the link RTB<->RTD SHOULD be used. And RTB SHOULD NOT calculates other > routes via the link. > > RTB and RTD calculate the routes advertised by each other. These > routes can be used for LDP to establish session. > > According to the algrithm above, only the routes for establishing LDP > session will change back at this moment. The other routes, used by LDP > to create LSP (Label Switch Path), will not change. So the LSP (Label > Switch Path) will not change, and data transmission between RTA and > RTD will still use the LSP (Label Switch Path) through RTA->RTC->RTD. > > 3.5. When to stop sending the Link-Overload property > > When the LDP session created, LDP SHOULD give a message to IS-IS. > Based on this message, IS-IS SHOULD remove the Link-Overload property > from the Neighbor TLV and generate new LSP. After the database > synchronised, all the routers schedule a normal SPF calculation once. > All the routes will change back to the path RTA->RTB->RTD. LDP will > remove the LSP (RTA->RTC->RTD) and create the new LSP (RTA->RTB->RTD). > Since the LDP session is already established on the link RTB<->RTD, > the creation of LSP (RTA->RTB->RTD) will be very fast (about 10's > milli seconds). According to this method, the data losting could be > reduced much during the link RTB<->RTD changes back to UP status. > > If there is problem for LDP to send a message to IS-IS, IS-IS could > not recover to the normal state. To avoid this, IS-IS can start a > timer when the adjacency created, and when the timer expires, stop > sending the Link-Overload property. > > > 4. Deployment Considerations > > A router not supporting the Link-Overload sub-TLV MUST just silently > ignore this sub-TLV. > > Since the Link-Overload property is used in IS-IS SPF calculation, > some routers in the routing domain don't support the Link-Overload > property can cause loops or black holes. > > > 5. Potential Alternatives > > This extention needs all routers to support in the routing domain. > When there are some routers who do not support the Link-Overload > property, the way described below can be used. > > The connected routers don't send the Neighbor TLV when adjacency comes > to UP if LDP session is not established. The non-connected routers will > not know the adjacency, then, all the routes in non-connected routers > will not change. The connected routers SHOULD start a SPF calculation. > During the calculation, the adjacency SHOULD be used this adjacency > SHOULD be used in it's calculation but ignore the two way check. The > routes for establishing the LDP session can be calculated by this way. > > So, this method can compatible with the routers who do not support the > Link-Overload property. The only constriction is that the connected > router have to support this method both. > > > 6. Security Considerations > > The Link-Overload property defined within this document describes an > addition to the IS-IS Neighbor TLV and does not impact the security > mechanism of the IS-IS protocol. > > > 7. Acknowledgements > > The authors would like to thank Lixia Zhang, XiongYi, ZhangRenhai and > LiDefeng for their useful comments. > > > 8. References > > [1] ISO, "Intermediate system to Intermediate system routing > information exchange protocol for use in conjunction with the > Protocol for providing the Connectionless-mode Network Service > (ISO 8473)," ISO/IEC 10589:1992. > > [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, > December 1990. > > [3] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering" > RFC 3906, October 2004. > > [4] Tony Przygienda, Naiming Shen and Nischal Sheth, "M-ISIS: Multi > Topology (MT) Routing in IS-IS" Draft draft-ietf-isis-wg-multi- > topology-10, May 2005. > > > 9. Author's Address > > HeQian > Beijing Institution of Huawei Technologies, China. > Phone: 86-010-82882012 > EMail: heqian@huawei.com > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 20 17:25:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EShuM-0005Jq-3B; Thu, 20 Oct 2005 17:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EShuJ-0005IL-SU for isis-wg@megatron.ietf.org; Thu, 20 Oct 2005 17:25: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 RAA12877 for ; Thu, 20 Oct 2005 17:24:50 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EShPG-0006bc-HJ for isis-wg@ietf.org; Thu, 20 Oct 2005 16:52:59 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.35 ; Thu, 20 Oct 2005 16:40:23 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Oct 2005 16:40:23 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.127 140.233.20.127 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.2.0.050811 Date: Thu, 20 Oct 2005 16:40:23 -0400 From: "Parker, Jeff" To: ISIS WG Message-ID: Thread-Topic: draft-ietf-isis-wg-mib-24.txt Thread-Index: AcXVtn5SvKJphEGpEdqpVAANk6/xHg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Oct 2005 20:40:23.0656 (UTC) FILETIME=[7EB62E80:01C5D5B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Isis-wg] draft-ietf-isis-wg-mib-24.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 I have just forwarded a new mib draft to the IETF. The changes were editorial, and include suggestions from Bert Moving text describing things into TC where possible More description of makeup of LSP ID Additional References Configured values MUST, rather than will, survive reboot Capitalized RessettingTimer Chris is eager to pull the trigger on this and move to last call. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Oct 21 06:21:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESu1G-00027S-0O; Fri, 21 Oct 2005 06:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESu19-000277-9A for isis-wg@megatron.ietf.org; Fri, 21 Oct 2005 06:21:00 -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 GAA11888 for ; Fri, 21 Oct 2005 06:20:43 -0400 (EDT) Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESuDD-0002qk-Ox for isis-wg@ietf.org; Fri, 21 Oct 2005 06:33:24 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9LAJuJ09145; Fri, 21 Oct 2005 12:19:56 +0200 (CEST) Received: from [144.254.191.157] (dhcp-144-254-191-157.cisco.com [144.254.191.157]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9LAJsC29468; Fri, 21 Oct 2005 12:19:55 +0200 (CEST) In-Reply-To: <4357C1DE.1000702@juniper.net> References: <27bd1727c681.27c68127bd17@huawei.com> <4357C1DE.1000702@juniper.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: stefano previdi Subject: Re: [Isis-wg] New draft draft-heqian-isis-link-overload-00.txt is provided. Date: Fri, 21 Oct 2005 12:20:01 +0200 To: Hannes Gredler X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Content-Transfer-Encoding: 7bit Cc: heqian 24209 , 77cronux.leed0621@huawei.com, isis-wg@ietf.org 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 Oct 20, 2005, at 6:12 PM, Hannes Gredler wrote: > heqian, > > there are already implementations out that fix the IGP/LDP desync > problem > by advertising the link with MAX_METRIC until LDP startup is complete; > doing so, has the nice property that it is downwards compatible; ... and need not any extension... s. > > /hannes > > heqian 24209 wrote: >> Hi guys, >> I have just written one draft. It is about avoiding packet lost when >> IS-IS is using with LDP (Label Distrute Protocol) in MPLS network. >> Details are in the document. It is in attachment. Please refer. >> Any question and suggestion are warmly welcome. >> Regards, >> Heqian >> ---------------------------------------------------------------------- >> -- >> Internet Engineering Task Force >> HeQian >> INTERNET-DRAFT >> XiongYi >> Expires Apr 2006 Huawei >> Technologies >> October >> 2005 >> Link Overload Attribute in IS-IS >> >> Status of this Memo >> This memo provides information for the Internet community. It does >> not specify an Internet standard of any kind. Distribution of this >> memo is unlimited. >> Copyright Notice >> Copyright (C) The Internet Society 2005. All Rights Reserved. >> Abstract >> This document describes a mechanism that can be employed in >> Intermediate System to Intermediate System (IS-IS) networks >> in order to decrease the data loss associated with Label >> Distribution Protocol (LDP) during transient network conditions. >> 1. Introduction >> In many networks, the ISP uses MPLS to carry the data in PEs >> between >> CEs and LDP is used to create LSP (Label Switch Path). When IS-IS >> work with LDP, IS-IS always convergence faster than LDP, which can >> cause data losing when the data is transfering by LSP (Label Switch >> Path) in some cases. This document tries to find out a method to >> solve this interactional problem. >> 2. Discussion >> This document describes a mechanism that can be employed in IS-IS >> [1, >> 2] networks in order to avoid transition to a newly available path >> until other associated protocols such as LDP have been established >> its session. >> The benefits of such a mechanism can be realized when considering >> the >> following scenario depicted in Figure 1. >> +-----+ >> +-----------| RTB |-----------+ >> | +-----+ | >> | | >> +-----+ +-----+ >> CE.Src---| RTA | | RTD |---CE.Dst >> +-----+ +-----+ >> | | >> | +-----+ | >> +-----------| RTC |-----------+ >> +-----+ >> Figure 1: Example Network Topology >> IS-IS is running on all the routers as IGP. The path of >> RTA->RTB->RTD >> has more priority than RTA->RTC->RTD. >> CE.Src and CE.Dst are in same VPN. LDP sessions are created >> between >> each two routers and one LSP of RTA->RTB->RTD is created. The data >> are >> transmitted between two CEs by using the LSP created by LDP. >> If the state of the link between RTB and RTD changes to DOWN, >> the next >> hop of the routes to RTD on RTA will change from RTB to RTC. >> According >> to this change, LDP will remove the LSP (RTA->RTB->RTD) and try to >> create the LSP of RTA->RTC->RTD. Since the LDP sessions are already >> created between RTA and RTC, RTC and RTD, the LSP (RTA->RTC->RTD) >> can >> be created very quikly (about 10's of milli seconds). In this case, >> the data flow between CE.Src and CE.Dst will be lost only in the >> period IS-IS updating the network and LDP creating the LSP. >> Then, assume the state of the link between RTB and RTD changes >> to UP, >> the next hop of the routes to RTD on RTA will change back from RTC >> to >> RTB. According to this change, LDP will remove the LSP >> (RTA->RTC->RTD) >> and try to create the LSP of RTA->RTB->RTD. But at this time, the >> LDP >> session between RTB and RTD has not been established, the LSP >> (RTA->RTB->RTD) can be created till the LDP session between RTB and >> RTD established. The LDP session establishes slow (about 10's of >> seconds), this will delay the creation of LSP (RTA->RTB->RTD). In >> this >> case, the data flow between CE.Src and CE.Dst will be lost for a >> long >> time (at least the time of establishing LDP session). >> 3. Approach >> Now we introduce one method to solve the problem. >> 3.1. Link-Overload property >> One link property called link overload is required. This property >> can >> be carried by any type of IS-IS TLV descripting adjacency. >> For TLV 2 (IS Neighbor TLV)[1], we can use the eighth bit of >> default >> metric, this bit is already sighned to up/down bit, but it is never >> used for TLV 2. So we can use this bit to carry the Link-Overload >> property. >> For TLV 22 (Extended IS Reachability TLV)[3], we can define a >> new sub >> tlv named Link-Overload, sub-type is 3 (to be assigned by IANA) and >> has a length of 1 octets. >> For MT TLV 222 (MT Intermediate Systems TLV)[4], since this TLV >> only >> adds 2 octects (for reserved bits and MT ID) before TLV 22, we can >> use >> same method as what we extended for TLV 22. >> For convernions, we call all these three TLV as Neighbor TLV. >> This sub-TLV is OPTIONAL and MAY appear at most once for a >> single IS >> Neighbor TLV. >> 3.2. When to start sending the Link-Overload property >> When the adjacency established on a link, the implementation should >> check if LDP is enabled on the link and check the LDP's session >> status. >> If the LDP session is not established, then the Link-Overload >> property >> SHOULD be set in the Neighbor TLV. >> 3.3. How to use the Link-Overload property on the non-connected >> routers >> RTA and RTC are non-connected to the link RTB<->RTD routers. RTB >> and >> RTD establish new adjancency and send out the new LSPs with >> Link-Overload property. When RTA and RTC receive the new LSPs, RTA >> and >> RTC will signal a new SPF accroding to the changes. When the SPF is >> scheduled, the link with Link-Overload property should be ignored. >> The routes, used by LDP to create LSP (Label Switch Path), will >> not >> change during this time. Then the LSP (Label Switch Path) will not >> change. >> 3.4. How to use the Link-Overload property on the connected routers >> RTB and RTD are connected to the link RTB<->RTD routers. When these >> two routers generate and receive the new LSPs, SPF will be >> scheduled. >> When the SPF run, the link with Link-Overload property should be >> used >> only when the router is calculating the routes advertised by the >> other >> router. For example, when RTB calculates the routes advertised by >> RTD, >> the link RTB<->RTD SHOULD be used. And RTB SHOULD NOT calculates >> other >> routes via the link. >> RTB and RTD calculate the routes advertised by each other. These >> routes can be used for LDP to establish session. >> According to the algrithm above, only the routes for >> establishing LDP >> session will change back at this moment. The other routes, used by >> LDP >> to create LSP (Label Switch Path), will not change. So the LSP >> (Label >> Switch Path) will not change, and data transmission between RTA and >> RTD will still use the LSP (Label Switch Path) through >> RTA->RTC->RTD. >> 3.5. When to stop sending the Link-Overload property >> When the LDP session created, LDP SHOULD give a message to IS-IS. >> Based on this message, IS-IS SHOULD remove the Link-Overload >> property >> from the Neighbor TLV and generate new LSP. After the database >> synchronised, all the routers schedule a normal SPF calculation >> once. >> All the routes will change back to the path RTA->RTB->RTD. LDP will >> remove the LSP (RTA->RTC->RTD) and create the new LSP >> (RTA->RTB->RTD). >> Since the LDP session is already established on the link RTB<->RTD, >> the creation of LSP (RTA->RTB->RTD) will be very fast (about 10's >> milli seconds). According to this method, the data losting could be >> reduced much during the link RTB<->RTD changes back to UP status. >> If there is problem for LDP to send a message to IS-IS, IS-IS >> could >> not recover to the normal state. To avoid this, IS-IS can start a >> timer when the adjacency created, and when the timer expires, stop >> sending the Link-Overload property. >> 4. Deployment Considerations >> A router not supporting the Link-Overload sub-TLV MUST just >> silently >> ignore this sub-TLV. >> Since the Link-Overload property is used in IS-IS SPF calculation, >> some routers in the routing domain don't support the Link-Overload >> property can cause loops or black holes. 5. Potential Alternatives >> This extention needs all routers to support in the routing domain. >> When there are some routers who do not support the Link-Overload >> property, the way described below can be used. >> The connected routers don't send the Neighbor TLV when adjacency >> comes >> to UP if LDP session is not established. The non-connected routers >> will >> not know the adjacency, then, all the routes in non-connected >> routers >> will not change. The connected routers SHOULD start a SPF >> calculation. >> During the calculation, the adjacency SHOULD be used this adjacency >> SHOULD be used in it's calculation but ignore the two way check. >> The >> routes for establishing the LDP session can be calculated by this >> way. >> So, this method can compatible with the routers who do not >> support the >> Link-Overload property. The only constriction is that the connected >> router have to support this method both. >> 6. Security Considerations >> The Link-Overload property defined within this document describes >> an >> addition to the IS-IS Neighbor TLV and does not impact the security >> mechanism of the IS-IS protocol. >> 7. Acknowledgements >> The authors would like to thank Lixia Zhang, XiongYi, ZhangRenhai >> and >> LiDefeng for their useful comments. >> 8. References >> [1] ISO, "Intermediate system to Intermediate system routing >> information exchange protocol for use in conjunction with the >> Protocol for providing the Connectionless-mode Network Service >> (ISO 8473)," ISO/IEC 10589:1992. >> [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, >> December 1990. >> [3] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering" >> RFC 3906, October 2004. >> [4] Tony Przygienda, Naiming Shen and Nischal Sheth, "M-ISIS: Multi >> Topology (MT) Routing in IS-IS" Draft draft-ietf-isis-wg-multi- >> topology-10, May 2005. >> 9. Author's Address >> HeQian >> Beijing Institution of Huawei Technologies, China. >> Phone: 86-010-82882012 >> EMail: heqian@huawei.com >> >> ---------------------------------------------------------------------- >> -- >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Oct 21 10:50:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyEM-0002gn-9a; Fri, 21 Oct 2005 10:50:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyDe-0002Nf-Kj; Fri, 21 Oct 2005 10:50:06 -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 KAA25813; Fri, 21 Oct 2005 10:49:54 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESyPl-0003rW-7M; Fri, 21 Oct 2005 11:02:38 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESyDa-0008FP-7B; Fri, 21 Oct 2005 10:50:02 -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: Fri, 21 Oct 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-11.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 : M-ISIS: Multi Topology (MT) Routing in IS-IS Author(s) : T. Przygienda, et al. Filename : draft-ietf-isis-wg-multi-topology-11.txt Pages : 12 Date : 2005-10-21 This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-11.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-wg-multi-topology-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-wg-multi-topology-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: <2005-10-21101040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21101040.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 Oct 21 15:52:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2wN-0004vr-GY; Fri, 21 Oct 2005 15:52:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2u5-0003tV-6f; Fri, 21 Oct 2005 15:50:13 -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 PAA00079; Fri, 21 Oct 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET368-0004Ym-Km; Fri, 21 Oct 2005 16:02:45 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET2tv-0001H4-2P; Fri, 21 Oct 2005 15:50:03 -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: Fri, 21 Oct 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-24.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 : Management Information Base for IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-wg-mib-24.txt Pages : 101 Date : 2005-10-21 This document describes a management information base for the IS-IS Routing protocol when it is used to construct routing tables for IP networks. This memo defines a 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. 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-24.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-wg-mib-24.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-24.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-10-21150919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21150919.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 Mon Oct 24 14:24:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6zq-0003CS-QU; Mon, 24 Oct 2005 14:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6zo-0003CK-R7 for isis-wg@megatron.ietf.org; Mon, 24 Oct 2005 14:24:33 -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 OAA24701 for ; Mon, 24 Oct 2005 14:24:18 -0400 (EDT) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU7Cb-0004sN-LE for isis-wg@ietf.org; Mon, 24 Oct 2005 14:37:46 -0400 Received: from [???IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id E31B43DCC8B; Mon, 24 Oct 2005 11:24:15 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <248076C1-2203-4E2C-B90B-9E2EAB346BDD@rawdofmt.org> Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: 48 hour WG LC [Re: [Isis-wg] draft-ietf-isis-wg-mib-24.txt] Date: Mon, 24 Oct 2005 11:24:14 -0700 To: "Parker, Jeff" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Christian Hopps , ISIS WG 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 We plan on handing this slightly edited version to the ADs on Wednesday. Chris and Dave. On Oct 20, 2005, at 1:40 PM, Parker, Jeff wrote: > I have just forwarded a new mib draft to the IETF. > The changes were editorial, and include suggestions from Bert > > Moving text describing things into TC where possible > More description of makeup of LSP ID > Additional References > Configured values MUST, rather than will, survive reboot > Capitalized RessettingTimer > > Chris is eager to pull the trigger on this and move to last call. > > - jeff parker > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Oct 24 15:50:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Kv-00035U-92; Mon, 24 Oct 2005 15:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Ka-0002sc-6L; Mon, 24 Oct 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 PAA28561; Mon, 24 Oct 2005 15:49:49 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8XN-0007cJ-H3; Mon, 24 Oct 2005 16:03:18 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EU8KY-00028m-3z; Mon, 24 Oct 2005 15:50:02 -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, 24 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ipv6-06.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 : Routing IPv6 with IS-IS Author(s) : C. Hopps Filename : draft-ietf-isis-ipv6-06.txt Pages : 7 Date : 2005-10-24 This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes 2 new TLVs, a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.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-06.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-06.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-10-24123606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ipv6-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ipv6-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-24123606.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 Tue Oct 25 13:41:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSnN-0004xM-O7; Tue, 25 Oct 2005 13:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSnL-0004xF-PL for isis-wg@megatron.ietf.org; Tue, 25 Oct 2005 13:41:07 -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 NAA08001 for ; Tue, 25 Oct 2005 13:40:53 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUT0J-0003pJ-QR for isis-wg@ietf.org; Tue, 25 Oct 2005 13:54:34 -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 j9PHeuBT008755; Tue, 25 Oct 2005 10:40:56 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j9PHendh009131; Tue, 25 Oct 2005 10:40:49 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j9PHemPc009126; Tue, 25 Oct 2005 10:40:49 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 25 Oct 2005 10:40:48 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ISIS WG Subject: Re: [Isis-wg] draft-ietf-isis-wg-mib-24.txt In-Reply-To: <248076C1-2203-4E2C-B90B-9E2EAB346BDD@rawdofmt.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "Wijnen, Bert \(Bert\)" 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 Thu, 20 Oct 2005, Parker, Jeff wrote: Jeff> I have just forwarded a new mib draft to the IETF. Jeff> The changes were editorial, and include suggestions from Bert Jeff> Jeff> Moving text describing things into TC where possible Jeff> More description of makeup of LSP ID Jeff> Additional References Jeff> Configured values MUST, rather than will, survive reboot Jeff> Capitalized RessettingTimer Jeff> Jeff> Chris is eager to pull the trigger on this and move to last call. >>>>> On Mon, 24 Oct 2005, Christian Hopps replied: Chris> We plan on handing this slightly edited version to the ADs on Chris> Wednesday. All of Bert Wijnen's comments have been accounted for, and as far as I can tell no errors have been introduced during the most recent round of editing. In my opinion the document is definitely ready ready to move on to IETF Last Call. It will be good to see this document get published. //cmh _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Oct 27 20:16:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHur-0001Y5-0C; Thu, 27 Oct 2005 20:16:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHuk-0001S1-Uq; Thu, 27 Oct 2005 20:16:15 -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 UAA29426; Thu, 27 Oct 2005 20:15:53 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVI8D-0006qs-Om; Thu, 27 Oct 2005 20:30:06 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S0EmL18177; Thu, 27 Oct 2005 17:14:48 -0700 (PDT) Message-Id: <200510280014.j9S0EmL18177@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 27 Oct 2005 17:14:47 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: isis-wg@ietf.org, rfc-editor@rfc-editor.org Subject: [Isis-wg] RFC 4205 on Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) 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 Request for Comments is now available in online RFC libraries. RFC 4205 Title: Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Author(s): K. Kompella, Ed., Y. Rekhter, Ed. Status: Informational Date: October 2005 Mailbox: kireeti@juniper.net, yakov@juniper.net Pages: 11 Characters: 22323 Updates: 3784 I-D Tag: draft-ietf-isis-gmpls-extensions-19.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4205.txt This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). This document is a product of the IS-IS for IP Internets Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051027171327.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4205 --OtherAccess Content-Type: Message/External-body; name="rfc4205.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051027171327.RFC@RFC-EDITOR.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 Mon Oct 31 10:58:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc3J-0005Hu-Ul; Mon, 31 Oct 2005 10:58:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc3D-0005Fh-J5; Mon, 31 Oct 2005 10:58:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15732; Mon, 31 Oct 2005 10:58:03 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcHQ-0001hd-Tk; Mon, 31 Oct 2005 11:13:05 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EWc3D-0007Gw-37; Mon, 31 Oct 2005 10:58:23 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 31 Oct 2005 10:58:23 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isis-wg@ietf.org Subject: [Isis-wg] Last Call: 'Management Information Base for IS-IS' to Proposed Standard X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org 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 The IESG has received a request from the IS-IS for IP Internets WG to consider the following document: - 'Management Information Base for IS-IS ' as a Proposed Standard 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 2005-11-14. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-24.txt _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg