From isis-wg-bounces@ietf.org Tue Feb 1 03:25:43 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01751 for ; Tue, 1 Feb 2005 03:25:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvtJQ-0004s7-Iy; Tue, 01 Feb 2005 03:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvtH8-0004TN-IK for isis-wg@megatron.ietf.org; Tue, 01 Feb 2005 03:20:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01119 for ; Tue, 1 Feb 2005 03:20:40 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvtY6-0001ga-J1 for isis-wg@ietf.org; Tue, 01 Feb 2005 03:38:19 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB800ADN49JT4@szxga02-in.huawei.com> for isis-wg@ietf.org; Tue, 01 Feb 2005 16:15:19 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB8006EH49JI8@szxga02-in.huawei.com> for isis-wg@ietf.org; Tue, 01 Feb 2005 16:15:19 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB800HI44DWPZ@szxml01-in.huawei.com>; Tue, 01 Feb 2005 16:17:57 +0800 (CST) Date: Tue, 01 Feb 2005 13:43:30 +0530 From: hemanthbs Subject: RE: [Isis-wg] Wide Metric In-reply-to: <0BF32C4D-73CA-11D9-9301-0003934A79C2@sniff.de> To: "'Marc Binderberger'" Message-id: <002e01c50835$eaee6cb0$7204120a@in.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/mixed; boundary="Boundary_(ID_TNz6CaX89IE6YCRy51t56g)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MS-TNEF-Correlator: 00000000633B5356B31FDF468A98D29F6EEE9EA504922000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: isis-wg@ietf.org, "'Nurit Sprecher'" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@huawei.com 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_TNz6CaX89IE6YCRy51t56g) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi Marc, >> [...] This mandatory requirement does not >> allow advertising a non-TE link. If for example, an IS supports TE on >> some links but non-TE only on other links, this mandatory requirement >> causes that even the Non-TE links will be considered in the CSPF >> calculation. [...] > > The above concern may be answered as below, I guess. > In an implementation where in the TE links are considered based on the > following condition. "TE should be enabled for the ISIS process and > MPLS > TE should be enabled on the interface" > i.e for TE computation only those links be will be considered, for > which MPLS TE is enabled on the interface and TE is enabled for that > ISIS process running on that interface. Hemanth, but how does a distance router _know_ what interfaces are enabled if not IS-IS is signaling this? How does the IS-IS process running on A know that B's interface to C allows TE while the interface to D doesn't ? A--(te)--B--(te)--C | | | (te) | | D--------E Every ISIS process on a router will maintain a separate database for the TE information. The TE advertisements made will also be little different from the normal LSPs. With such a condition, Router B's TE advertisements would advertise a link to C but not to D. Hence when Router A processes this TE LSP, it would know that Router B has a TE link only to C and not to D. From this information Router A can build its own TE database, which it can use to build the TE link and network information. Finally this TE link and network information is given to CSPF. -Hemanth. (please switch on your fixed font ;-) Or is there the implicit condition that all routers must be "TE-aware" and you simply put a very high TE metric on the links you don't want? Or trial & error? (wasn't it named "cut back"? The RSVP will tell finally that a link is not TE/RSVP enabled). What am I missing? :-) Regards, Marc -- Marc Binderberger --Boundary_(ID_TNz6CaX89IE6YCRy51t56g) Content-type: application/ms-tnef; name=winmail.dat Content-disposition: attachment; filename=winmail.dat Content-Transfer-Encoding: base64 eJ8+Ih8IAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAqAMAAAAAAACrAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANUHAgABAA0AKwAAAAIAGQEB A5AGAHQTAAAtAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAWAAAAW0lzaXMtd2ddIFdpZGUgTWV0cmljAAAAAgFxAAEAAAAWAAAAAcUINeoV Wk9S+ql4R7a4Qs8BLW2PVgAAAgEdDAEAAAAaAAAAU01UUDpIRU1BTlRIQlNASFVBV0VJLkNPTQAA AAsAAQ4AAAAAQAAGDgCO/tc1CMUBAgEKDgEAAAAYAAAAAAAAAGM7U1azH99GipjSn27unqXCgAAA AwAUDgAAAAALAB8OAQAAAB4AKA4BAAAALQAAADAwMDAwMDA1AWhlbWFudGhic0BodWF3ZWkuY29t AXBvcC5odWF3ZWkuY29tAAAAAB4AKQ4BAAAALQAAADAwMDAwMDA1AWhlbWFudGhic0BodWF3ZWku Y29tAXBvcC5odWF3ZWkuY29tAAAAAAIBCRABAAAAcw4AAG8OAAC4KAAATFpGdXb4i/UDAAoAcmNw ZzkzNgkMYGMyAPVzdHNowQVwYmNoMTMO9AkAmw9wDuVoDeAQRmJpAUPBC2BuZzEwMw+gEbXkZmUB 0DUyAfcCpANjRwIAD3AKwHNldALRcJRycRMxKgqhbm8U4GwgMAHQAdA2EjATEDDONBaxAdAWoDR9 B20CgF8KgAHxDoAEVRSNMRWMN/0WkTkWMxcCFuAXYAhVB7LfAoMPkQLyFIcPkDQVLxYxPxIgFoAg EBagEiAgZX1cbCdjDDAhEGUhAQDgJ7RlNRWCZgdABUBTB3CQU3VufQKDMzgdn/cerx+/IMJAIQ4Y dRbAFB9/JI8cAxaAG9IWohagF0JCIG9vayBBAjBpcbR1YQKDOQ5AKJ0yI1JFKbIgB20gQ0UstDdP LS8W0C5fL2V5ciy0ObkojjE2AFAxnwNzRwnR/msYdRIgKH80kBjhNO8Dgt5UCHAdJCWwNy83MEE4 fyEDgihIZWIJcHcp/zn1GOE6ni5PPKYHEAGgDeB3PYYdgTO9OC0RP28DgkL/IlEN4DaHJHEzvh2B Qw8806JWCJB0bmEHgWU9hfc0kBj/LiYxL7AciC+2SQD/MEFJXjFlSs0zBUkAM4EZHf80lkrMNjsM AU9/ODVKzDnHvjI0sVLuO4VKzD0cMhjv/z8HV31Ayy4gWV9CtkrMRFz+MiRxUu9GdFd9SA5ZMCNt 0ymFIoUgVweQdASRIg/9ApI0PyJkD0bBJu9lpgKD/jUtDy4ZK/ovsygUMD8xSf9svDMFauAzjzSY bLs2NQHx/yABcW84N2y7OcYWgXSvQscvbLtEVgKRCOY7CW8wO/MKgXuOMjUn4HzJfdF9j/9+mXyA fMJ+wn0vgP+AvYA/635ve29lUpA4hoqHoYdf/4hpgLSIkob9fKSK7YqNig/7iD+KlDkOgI90kNGI 05DQUwKCDwB5bAeQaAngdPUAAHEDIWwRgQUQAUAD8LBkY3RsCrEAYHMKsEeUECkglFJudW1mUWGI dXRvAGBkanUPAPEFEGdodJNxCgGTQAoB4mkBkHAwIAqBC+EkcP8R5xKokzAQIQKyEMIAYAEydw9h mhEPkWMJwJPQmANuHnCYWZugEwIDMHNuZf54KXAHsAWwAMACcRiSFaBcY3MSIAMwldBklzBpznYW EA7wKVBtaRDAnrC5CfAgRAEQlYAiYVAKwMZhCcCXUGggRgIhncbvDxBJAKHRA2B3CzCWIAGAxHNX k9B0aEIPoJYguwqwnrBsEiAjYKN0cqPorxAAo1YBgKVXYqVXcqNSfyEgCrAkQKdCKaCnowTwZfxs bJPBoyCiwQFADxCfAP8AICJRodE9QKRwqfYJUKoUzwyxqiOUQKoUZGeq9qxw96v2mYCqFHaXgpMP lB+VL/+WP5dDC9QR5JflEuCztJlv/5p/m4Sz17cEnNVJAJ8snWT/RuABoJJwnclqAJ6ZoEAI0PsY 0JzRYq/gCYACIJ5ikkGzKUCvUDE0DjAlsDRKwHhIeXAEkJbhNnWeIzb/uy9SkLxPvVuhIKiwomAJ gP++KZIhTCGuj6+fsK+xv7LG/0KwmA+ZGA+RtTUOgbXfm4/fnJMKgcDGwVK4YzfBb6BwrwtiRuCd EZ3JOJ6KYsCv7b1bU8cwAiBnepMVoHuAYnYCUSB7Vb6QFeB3/xhh1OMOAAUw1XLWggxA1pHPlxXE R6ogDuFhMNTVvWFn1WLZY2AQNDk94r1SM/g3NDggECRwvVog8AqwPb5Bd1khFuDcVA+ANThr3PEA wHKsgDIbUN3Ecq/eNyRA2lDdxGLfc2fGoH9l4ZdzxNGiYMUAquEBgG68YmoAYAnwnrAQIFwV4KZ4 C2ACQG95CfBcnRD+cA8gACALkBXgoEGq4MWA7wDhAjACYACAYg9Q4oHFgdshYAIQcrvh5bFtDyDG 4PUhcGgFsHriUqxw3eILgZ2scGjlY0KwAUFnduf5f+axx1ALgDtwOlHogel1OX/doOez5rDcsOhz 60IKgWp/41EAcAsw4lGSUL5ADoB26QiQd2sLgGQkcO1SBPDfB0C0Ud0B3/CtgmXG4O61jQIQb8eA xYBseXTWAP8LgCFw4bHwR8dwAMDGoMWA/+KB5NDHcMbhCTLHEKigAlD/B0ALkPNRAlHtocRA8FDu Qf/FAAJgonHwQQJRACCtIeTQ/T1Aa+XRIXC9UgNg7/DbBe8DMSliKVDFAGSXgpbhnRD/AUDiIfJQ BJAhcPey+ELMEve9sfekoBRjCVD3sr1aDvCf4bPW8RWhAIAFkGx2o9D//NEOYJ2A/NIBkAAg/WLt of0J8HQBwfzRKSASANbyAjDnnSBtYMtTIC7WNfz1DoD//YLkEf3v/v8AD/zmD6DGIP8OoOcQAj8D SRiSBB/8uSRw38Yg9IAB/wMPCFspALyF8N8F/wtvCDXScQjTKDoBDJ///LlrAAo/D28QfxGPDWGd 5P/85m4wE6L9zxUPFh8R3/zI/yNgE68aHxsvHD8NbXFQGR//H38gjyGfF/IqIaxg72DQY//Dz8Tf xe/G/5b3KCJQIcHZ/8ivmMzLs8rfy++b/WqyaIH/l9KoAJcRJCAuDLU1NFExqIe0tDRQl4FIaSBN KmD8Yyx6sjowNQ6eMFARwbv9KAQgOJM0/zsGMQ83NzDgQCA+PiBbLj9wXW9G4LUwRzBxoWSnoOlw eXYge4BtQGl7gEcQIdAg99LwRyHlQHQ8/z4PPxP0cPvCsURQZKmSP+DQgAxQbWBB5UBuLVRFIL5y LtAgSWYg5bEgnRBIUBnwMGUsRFCf4ElTIPBzdXBw6XBCbz568eC/VSBF8KEwQf9I3z8Tc3GQ99JA vnI/8GIrwEWWoTDwQP9KUUpQoyBRYU1DR1CjID/v/0D1So9Lnz8T7kDy8U/QoyD/p6BG0J8An+BO 4bmRRcdP0P8p8KiwTZDSQHrgJCDB0PkBh/fw0IFUwkNTUEZRT99SX1Nl9ICgQKegaaEwRlD/P2NX v1jPPxFbT1xfPxE/sfvSQLogb58BVlHlkGpwT+H3QJBWIXGwc8LQVsIqkFYRM8KxR1BJIOBgkoBz Lrddn16vX7JJn+BHcWlHEv9BIlqDVcD48WOvPnrSQFcF/1VHKmBWO9KzTpJO4WM/Z89/X7Lv0MKi RUJWUZ7CWrIi/0Xh68GgQGrh0kB8ALoi9/D/RqJUwkegR6F5ELTAYvFHYY/382v/bQ84MFBMU3Jv /3N/X7Nvn2s3VvHgkSuQ5ZDOInUPdh9fsmku0kBGov9F4WCQRxArwGaETlOjIOVQ900n0kBV32RH UOWxec963/9fsmbgtUF0s0oiT8FwUYC//z56eG95cnITg1dwiaeggE/vhI9lU3Fq5dBuJLEMUGtj v1RBeSdjJoi/ic8/EEifYP9yIKMgR1BNoutBQWQnUJ7AnyQxYLFAoOPw4JEgX9XS/l9m0Yy6afSN /48PaNFwZe5pRoBBwUeRLUehT8HBwO8y0PRwRUJPoj+Nj5UPj6ifkRZxFJeyi2+f4EEg1dLpVBRC J0/QaZn/PnqGh/8r0FdgmX+fzz8BRGNKE4Khl7pAhi2hkURBY24nQVAPmQ+ifz6YqYFBLS0o1eCQ KanQQqnWQ6dfqG/7qXOtJ3ytd6r/rA+tH7DD/6nyrp+vr7C/ri+y/7QPqYL2RKnQuQRFOxg0TzlP NV/7Nm83dkVE4UCQcVtOoSdQ/5JFftNP8Hkh0HInULoPux//vC+9PzdJ/QAtwuCQJtDN4f/CH8Mv xD/FTzd2yn83HFAh/4fQ0sFwx0Xhwe/Ij8mfzJ//N0kosOYSfTPHX9CP0Z/Sr+03Ky7Yb8ucVM+f 1m/Xf//afzdLaVRExkETT9IHIH7Ef/RwTPBWEilw9SCk8W7wZtcwAFDgQUFm9pBtVLNBwJ/Uwd9v NyspQHTgUHPlz/nZfCBXLWCC4EfQCPEnUP9uxziC3I/dnzw/tkjojzej/lKSVJ7i4Z9+wG/T4cdF cf9psqGETaPu7zcrl2GmAgCg/+t/7I/tn+6v9X+QMJICZuH/R4DwxZ4gcaVT80/BfKHnwf9ikC1g 8oWeSPDGkPBiESdQ/0Xlz4/4D95v+p/1y05iAb//As/5LwTPNyuhk3IiQcAG/58IDwPfCk8LWvak IEbk9P9PwdSJ/QhaIEeAkMB+4Fbh/0oBkuBHgHygD8/LnM5W1T//Da8OvxVfNytikIKk/xEUEn9T 0aGCGv83KxRUaUkMRGX6dPKQcvPg1IlGUAy/GP/3Gg8eXzdLRsGQRGG/MCXfvws8Is8j3yTvKH83 SWgqT+8rXyxvLX/T2nMvTzBfCR//Ml/LnDRfNW8xbzev4JnPb/86XztvPH/mzSD+F88/j0Cfz0Gv 078TBk/BZ2lUg6Ghf1eB9v9FvadG+h9Ib+ERLf+QNUtvRb82b7mnUY9Tr1S/71XPVt+2T7dcKGYR zqJhoDfqEILRnfF5klBZwGZpxnhwo+SxOy0pWA9NH/9fv2DPV89e32KPUm9jn2Sv72W/R6hab4/y T1nA/mEgce+UMXjjfPCYcGMdUurWjIT/pCGSNeKRad+3eh3A5MB/IaIifKAtYXeUISJZb/9vj6Py hyFc0ZgRbLG/MH0Bd8BBvwOCsGeC4Hyh4lB0/nJycIX2fkR0YpFAppJxgD9doKbfcn9rC3ZhmGAg JveDoGYAgCA/W6BxgKaD/xFng8DiUIcwImOQ0c6QYxRrInwgVOFhUlNW/lDA1LIgwQF473n/uBBd IL8n9G3U86T+YZdSh1AvflO9h7UpjX1/T4BfuBBXbeN95RBJwSD+YGkQncB8IDqPXeCET4Vftz5S ZWeJcNRkc5CgTYlwY4mvir//uBCp0Iy/jc+4EIxyntDBkJfi0I+Pt3py46ByZ8CxbbghPFBgjJBA poDkUS4N4tA+Z1xRUDQ5MTAnknBoz7mWfQCYcAAeAEIQAQAAADAAAAA8MEJGMzJDNEQtNzNDQS0x MUQ5LTkzMDEtMDAwMzkzNEE3OUMyQHNuaWZmLmRlPgADAJIQAQAAAAMA3j+fTgAAAwACWQAAFgAD AAlZAwAAAAMAQGUAAAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAASACCAGAAAA AADAAAAAAAAARgAAAABShQAAG5cBAB4ABoAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAA ADEwLjAAAAAACwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALAEOACCAGAAAAAADAAAAA AAAARgAAAAAOhQAAAAAAAAMARYAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwBHgAggBgAA AAAAwAAAAAAAAEYAAAAAGIUAAAAAAAADAFuACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAEAA XIAIIAYAAAAAAMAAAAAAAABGAAAAAGCFAAAA0Hbl0f//HwsApoAIIAYAAAAAAMAAAAAAAABGAAAA AAaFAAAAAAAAAgH4DwEAAAAQAAAAYztTVrMf30aKmNKfbu6epQIB+g8BAAAAEAAAAGM7U1azH99G ipjSn27unqUCAfsPAQAAAJcAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABO SVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NcaGVtYW50aGJzXExvY2Fs IFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5wc3QA AAMA/g8FAAAAAwANNP03AgACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAA MDAwMDAwMDA2MzNCNTM1NkIzMUZERjQ2OEE5OEQyOUY2RUVFOUVBNTA0OTIyMDAwAAAAAAMABhBZ KR/lAwAHEOQFAAADABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAASElNQVJDLFRISVNNQU5EQVRP UllSRVFVSVJFTUVOVERPRVNOT1RBTExPV0FEVkVSVElTSU5HQU5PTi1URUxJTktJRkZPUkVYQU1Q TEUsQU5JU1NVUFBPUlRTVEVPTlNPTUVMSQAAAACVkg== --Boundary_(ID_TNz6CaX89IE6YCRy51t56g) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --Boundary_(ID_TNz6CaX89IE6YCRy51t56g)-- From oconnor@caths.co.uk Tue Feb 1 08:59:04 2005 Received: from caths69.com (acceso125.broadred.net [217.172.65.125]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03439 for ; Tue, 1 Feb 2005 08:59:04 -0500 (EST) Message-Id: <200502011359.IAA03439@ietf.org> From: LIOUDMILA OCONNOR To: isis-archive@ietf.org Reply-To: lioudmila.lioumila@gmx.net Subject: ATTENTION!!! CAN YOU BE HONEST? Date: Tue, 01 Feb 2005 02:59:15 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="128625aa-73f1-11d9-8947-006067903c18" This is a multi-part message in MIME format --128625aa-73f1-11d9-8947-006067903c18 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From:1002 Lausanne Switzerland Dear Friend. My name is Ms. LIOUDMILA OCONNOR a member of Independent Committee of Eminent Persons (ICEP), Switzerland. This Committee is charged with the responsibility of finding bank accounts in Switzerland belonging to non-Swiss indigenes, which have remained dormant since World War II. It may interest you to know that in July of 1997, the Swiss Banker's Association published a list of dormant accounts originally opened by non-Swiss citizens. These accounts had been dormant since the end of World War II (May 9, 1945). Most belonged to Holocaust victims. The continuing efforts of the Independent Committee of Eminent Persons have since resulted in the discovery of additional dormant accounts -54,000 in December, 1999. The published lists contain all types of dormant accounts, including interest-bearing savings accounts, securities accounts, safe deposit boxes, custody accounts, and non-interest-bearing transaction accounts. Numbered accounts are also included. Interest is paid on accounts that were interest bearing when established. The Claims Resolution Tribunal handles processing of all claims on accounts due non-Swiss citizens. A dormant account of (the deceased) with a credit balance of 21,000,000 US dollar plus accumulated interest was discovered by me. The beneficiary was murdered during the holocaust era, Leaving no WILL and no possible records for trace of heirs. The Claims Resolution Tribunal has been mandated to report all unclaimed funds for permanent closure of accounts and transfer of existing credit balance into the treasury of Switzerland government as provided by the law for management of assets of deceased beneficiaries who died interstate (living no wills). Being a top executive at ICEP, I have all secret details and necessary contacts for claim of the funds without any hitch. The funds will be banked in a safe haven and we can share the funds and use in investment of our choice. Due to the sensitive nature of my job, I need a foreigner to HELP claim the funds. All that is required is for you to provide me with your details for processing of the necessary legal and administrative claim documents for transfer of the funds to you, to this regard, you are expected to fill out a text form. I will pay all required fees to ensure that the fund is transferred to a secured, numbered account in your name, where you will be capable of accessing the funds and gradually transfering to your country and other banks of choice in the world. THERE IS NO RISK INVOLVED. You can find additional information about unclaimed funds through the internet at the following websites: www.swissbankclaims.com http://www.cnn.com/WORLD/europe/9902/09/germany.holocaust/ www.wiesenthal.com The Holocaust Claims Processing Office has put funds in Escrow awaiting submission of valid claims for necessary disbursement. I find myself priviledged to have this information and this may be a great opportunity for a life time of success without risks. Due to confidential reasons, reply via email only. You may reply to me securely through this email address (lioudmila.lioumila@gmx.net) I await your urgent response to this proposal via my email address. Thank you for your prompt response. My Regards kimaeva Lioudmila ****PRIVATE & CONFIDENTIAL***** this e-mail and any attached files are = confidential and may be legally privileged. If you are not the addressee, any disclosure, reproduction, copying, = distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender = immediately and then delete this e-mail. E-mail transmission cannot be guaranteed to be = secure or error free as information can be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We therefore cannot be held liable for any errors or omissions in the contents of this = message, which arise as a result of e-mail transmission. --128625aa-73f1-11d9-8947-006067903c18-- From isis-wg-bounces@ietf.org Tue Feb 1 09:31:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08720 for ; Tue, 1 Feb 2005 09:31:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvyuW-0001AS-Cy; Tue, 01 Feb 2005 09:21:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvyr7-0000cq-N1 for isis-wg@megatron.ietf.org; Tue, 01 Feb 2005 09:18:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06358 for ; Tue, 1 Feb 2005 09:18:09 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvz9E-0002xJ-Mq for isis-wg@ietf.org; Tue, 01 Feb 2005 09:36:58 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB800JKOL3ETU@szxga02-in.huawei.com> for isis-wg@ietf.org; Tue, 01 Feb 2005 22:18:50 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB800AY8L3E5V@szxga02-in.huawei.com> for isis-wg@ietf.org; Tue, 01 Feb 2005 22:18:50 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB800MYGL7RT9@szxml01-in.huawei.com>; Tue, 01 Feb 2005 22:21:28 +0800 (CST) Date: Tue, 01 Feb 2005 19:47:00 +0530 From: hemanthbs Subject: RE: [Isis-wg] Wide Metric In-reply-to: <6FAB860EC6AE3C4EB327204DEC33A52801091420@wombat.seabridge.co.il> To: "'Nurit Sprecher'" , "'Marc Binderberger'" Message-id: <004301c50868$b2f97100$7204120a@in.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7BIT Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@huawei.com 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 Content-Transfer-Encoding: 7BIT Hi Nurit/Marc, Though the draft doesn't clearly say on what basis can we decide if a link is a TE link, we use the following selection criteria to select a TE link., "We say that a link is TE link only if all TE sub-tlvs for eg: Maximum link bandwidth, Maximum Reservable Bandwidth ,,etc are present. Since the interface address sub-tlv can be present for non-TE links.(wide metric) If ,only this sub-tlv is present, then it can be considered for normal wide metric computation and not TE computation." i.e :- if(Maximum link bandwidth && Maximum Reservable Bandwidth && Color ....all TE sub-tlvs) { TE Link } else if(interface address sub-tlv) { Normal wide metric link } I think this will solve the problem were are addressing. -Hemanth S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. -----Original Message----- From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com] Sent: Tuesday, February 01, 2005 4:21 PM To: Marc Binderberger; hemanthbs@huawei.com Cc: isis-wg@ietf.org Subject: RE: [Isis-wg] Wide Metric Hi Marc, Thanks for your response. " Maybe Nurit is asking why the TE extensions have been "integrated" into extended IS reachability TLV type 22 instead of using a separate TLV. Nurit?" Right. I understand your answer. However, as I wrote earlier to Hemanth, I still think that combining the wide metric and the TE metric together is too confusing (if the TE metric does not appear use the value of the wide metric also for the TE metric.). I would prefer to see them independently. However, if not, this 'must' should be modified to something which is less obligating, like may. Thanks, Nurit. -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Monday, January 31, 2005 10:53 PM To: hemanthbs@huawei.com Cc: Nurit Sprecher; isis-wg@ietf.org Subject: Re: [Isis-wg] Wide Metric Hello, >> My doubt was why it is combined together with TE. > The main urge for development of wide metrics was TE. Though we had the > problems of smaller metric range. Maybe Nurit is asking why the TE extensions have been "integrated" into extended IS reachability TLV type 22 instead of using a separate TLV. Nurit? (in this case: at the beginning of RFC3784 the authors are counting octets, so I assume they tried to avoid the additional 7 octets for system Id and pseudonode number in a separate TLV. Beside that integrating it seems logical, all new per-link information are in one place/TLV) >> [...] This mandatory requirement does not >> allow advertising a non-TE link. If for example, an IS supports TE on >> some links but non-TE only on other links, this mandatory requirement >> causes that even the Non-TE links will be considered in the CSPF >> calculation. [...] > > The above concern may be answered as below, I guess. > In an implementation where in the TE links are considered based on the > following condition. "TE should be enabled for the ISIS process and > MPLS > TE should be enabled on the interface" > i.e for TE computation only those links be will be considered, for > which MPLS TE is enabled on the interface and TE is enabled for that > ISIS process running on that interface. Hemanth, but how does a distance router _know_ what interfaces are enabled if not IS-IS is signaling this? How does the IS-IS process running on A know that B's interface to C allows TE while the interface to D doesn't ? A--(te)--B--(te)--C | | | (te) | | D--------E (please switch on your fixed font ;-) Or is there the implicit condition that all routers must be "TE-aware" and you simply put a very high TE metric on the links you don't want? Or trial & error? (wasn't it named "cut back"? The RSVP will tell finally that a link is not TE/RSVP enabled). What am I missing? :-) Regards, Marc -- Marc Binderberger _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From oconnor@caths.co.uk Tue Feb 1 09:54:49 2005 Received: from caths100.com (acceso125.broadred.net [217.172.65.125]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11278 for ; Tue, 1 Feb 2005 09:54:47 -0500 (EST) Message-Id: <200502011454.JAA11278@ietf.org> From: LIOUDMILA OCONNOR To: isis-archive@ietf.org Reply-To: lioudmila.lioumila@gmx.net Subject: ATTENTION!!! CAN YOU BE HONEST? Date: Tue, 01 Feb 2005 03:54:57 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="128674d3-73f1-11d9-8947-006067903c18" This is a multi-part message in MIME format --128674d3-73f1-11d9-8947-006067903c18 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From:1002 Lausanne Switzerland Dear Friend. My name is Ms. LIOUDMILA OCONNOR a member of Independent Committee of Eminent Persons (ICEP), Switzerland. This Committee is charged with the responsibility of finding bank accounts in Switzerland belonging to non-Swiss indigenes, which have remained dormant since World War II. It may interest you to know that in July of 1997, the Swiss Banker's Association published a list of dormant accounts originally opened by non-Swiss citizens. These accounts had been dormant since the end of World War II (May 9, 1945). Most belonged to Holocaust victims. The continuing efforts of the Independent Committee of Eminent Persons have since resulted in the discovery of additional dormant accounts -54,000 in December, 1999. The published lists contain all types of dormant accounts, including interest-bearing savings accounts, securities accounts, safe deposit boxes, custody accounts, and non-interest-bearing transaction accounts. Numbered accounts are also included. Interest is paid on accounts that were interest bearing when established. The Claims Resolution Tribunal handles processing of all claims on accounts due non-Swiss citizens. A dormant account of (the deceased) with a credit balance of 21,000,000 US dollar plus accumulated interest was discovered by me. The beneficiary was murdered during the holocaust era, Leaving no WILL and no possible records for trace of heirs. The Claims Resolution Tribunal has been mandated to report all unclaimed funds for permanent closure of accounts and transfer of existing credit balance into the treasury of Switzerland government as provided by the law for management of assets of deceased beneficiaries who died interstate (living no wills). Being a top executive at ICEP, I have all secret details and necessary contacts for claim of the funds without any hitch. The funds will be banked in a safe haven and we can share the funds and use in investment of our choice. Due to the sensitive nature of my job, I need a foreigner to HELP claim the funds. All that is required is for you to provide me with your details for processing of the necessary legal and administrative claim documents for transfer of the funds to you, to this regard, you are expected to fill out a text form. I will pay all required fees to ensure that the fund is transferred to a secured, numbered account in your name, where you will be capable of accessing the funds and gradually transfering to your country and other banks of choice in the world. THERE IS NO RISK INVOLVED. You can find additional information about unclaimed funds through the internet at the following websites: www.swissbankclaims.com http://www.cnn.com/WORLD/europe/9902/09/germany.holocaust/ www.wiesenthal.com The Holocaust Claims Processing Office has put funds in Escrow awaiting submission of valid claims for necessary disbursement. I find myself priviledged to have this information and this may be a great opportunity for a life time of success without risks. Due to confidential reasons, reply via email only. You may reply to me securely through this email address (lioudmila.lioumila@gmx.net) I await your urgent response to this proposal via my email address. Thank you for your prompt response. My Regards kimaeva Lioudmila ****PRIVATE & CONFIDENTIAL***** this e-mail and any attached files are = confidential and may be legally privileged. If you are not the addressee, any disclosure, reproduction, copying, = distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender = immediately and then delete this e-mail. E-mail transmission cannot be guaranteed to be = secure or error free as information can be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We therefore cannot be held liable for any errors or omissions in the contents of this = message, which arise as a result of e-mail transmission. --128674d3-73f1-11d9-8947-006067903c18-- From isis-wg-bounces@ietf.org Tue Feb 1 10:05:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12529 for ; Tue, 1 Feb 2005 10:05:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzW9-0002AG-5l; Tue, 01 Feb 2005 10:00:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzNU-0008JE-Sh for isis-wg@megatron.ietf.org; Tue, 01 Feb 2005 09:51:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10848 for ; Tue, 1 Feb 2005 09:51:39 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvzdp-0003yh-Bt for isis-wg@ietf.org; Tue, 01 Feb 2005 10:10:27 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB800DNGM6GQ9@szxga02-in.huawei.com> for isis-wg@ietf.org; Tue, 01 Feb 2005 22:42:16 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB800M5ZM6GZ1@szxga02-in.huawei.com> for isis-wg@ietf.org; Tue, 01 Feb 2005 22:42:16 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB800MVYMAST9@szxml01-in.huawei.com>; Tue, 01 Feb 2005 22:44:54 +0800 (CST) Date: Tue, 01 Feb 2005 20:10:25 +0530 From: hemanthbs Subject: RE: [Isis-wg] Wide Metric In-reply-to: <6FAB860EC6AE3C4EB327204DEC33A52801091422@wombat.seabridge.co.il> To: "'Nurit Sprecher'" , "'Marc Binderberger'" Message-id: <005101c5086b$f85833a0$7204120a@in.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: 36ffee4f7c1a67a949d5f97400beba73 Cc: "'Philip Crocker'" , isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@huawei.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1826922966==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1826922966== Content-type: multipart/alternative; boundary="Boundary_(ID_sjQ/Jrmk0YLO1lbUP/wcEg)" This is a multi-part message in MIME format. --Boundary_(ID_sjQ/Jrmk0YLO1lbUP/wcEg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi Nurit, Yes I agree with you. The standard needs some clarifications. Regards, Hemanth. S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. -----Original Message----- From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com] Sent: Tuesday, February 01, 2005 7:59 PM To: hemanthbs@huawei.com; Marc Binderberger Cc: isis-wg@ietf.org; Philip Crocker Subject: RE: [Isis-wg] Wide Metric Hi Hemanth, I agree this is a reasonable interpretation/solution, and we can agree on this. However, the statement in the RFC should be fixed. The RFC explicitly states that " If a link is advertised without this sub-TLV (i.e. Sub-TLV 18: Traffic Engineering Default Metric), traffic engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV". There are no conditions regarding other sub-TLVs. This is misleading and I guess that it should be clarified. Thanks for your responses. Best regards, Nurit. -----Original Message----- From: hemanthbs [mailto:hemanthbs@huawei.com] Sent: Tuesday, February 01, 2005 4:17 PM To: Nurit Sprecher; 'Marc Binderberger' Cc: isis-wg@ietf.org Subject: RE: [Isis-wg] Wide Metric Hi Nurit/Marc, Though the draft doesn't clearly say on what basis can we decide if a link is a TE link, we use the following selection criteria to select a TE link., "We say that a link is TE link only if all TE sub-tlvs for eg: Maximum link bandwidth, Maximum Reservable Bandwidth ,,etc are present. Since the interface address sub-tlv can be present for non-TE links.(wide metric) If ,only this sub-tlv is present, then it can be considered for normal wide metric computation and not TE computation." i.e :- if(Maximum link bandwidth && Maximum Reservable Bandwidth && Color ....all TE sub-tlvs) { TE Link } else if(interface address sub-tlv) { Normal wide metric link } I think this will solve the problem were are addressing. -Hemanth S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. -----Original Message----- From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com] Sent: Tuesday, February 01, 2005 4:21 PM To: Marc Binderberger; hemanthbs@huawei.com Cc: isis-wg@ietf.org Subject: RE: [Isis-wg] Wide Metric Hi Marc, Thanks for your response. " Maybe Nurit is asking why the TE extensions have been "integrated" into extended IS reachability TLV type 22 instead of using a separate TLV. Nurit?" Right. I understand your answer. However, as I wrote earlier to Hemanth, I still think that combining the wide metric and the TE metric together is too confusing (if the TE metric does not appear use the value of the wide metric also for the TE metric.). I would prefer to see them independently. However, if not, this 'must' should be modified to something which is less obligating, like may. Thanks, Nurit. -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Monday, January 31, 2005 10:53 PM To: hemanthbs@huawei.com Cc: Nurit Sprecher; isis-wg@ietf.org Subject: Re: [Isis-wg] Wide Metric Hello, >> My doubt was why it is combined together with TE. > The main urge for development of wide metrics was TE. Though we had the > problems of smaller metric range. Maybe Nurit is asking why the TE extensions have been "integrated" into extended IS reachability TLV type 22 instead of using a separate TLV. Nurit? (in this case: at the beginning of RFC3784 the authors are counting octets, so I assume they tried to avoid the additional 7 octets for system Id and pseudonode number in a separate TLV. Beside that integrating it seems logical, all new per-link information are in one place/TLV) >> [...] This mandatory requirement does not >> allow advertising a non-TE link. If for example, an IS supports TE on >> some links but non-TE only on other links, this mandatory requirement >> causes that even the Non-TE links will be considered in the CSPF >> calculation. [...] > > The above concern may be answered as below, I guess. > In an implementation where in the TE links are considered based on the > following condition. "TE should be enabled for the ISIS process and > MPLS > TE should be enabled on the interface" > i.e for TE computation only those links be will be considered, for > which MPLS TE is enabled on the interface and TE is enabled for that > ISIS process running on that interface. Hemanth, but how does a distance router _know_ what interfaces are enabled if not IS-IS is signaling this? How does the IS-IS process running on A know that B's interface to C allows TE while the interface to D doesn't ? A--(te)--B--(te)--C | | | (te) | | D--------E (please switch on your fixed font ;-) Or is there the implicit condition that all routers must be "TE-aware" and you simply put a very high TE metric on the links you don't want? Or trial & error? (wasn't it named "cut back"? The RSVP will tell finally that a link is not TE/RSVP enabled). What am I missing? :-) Regards, Marc -- Marc Binderberger --Boundary_(ID_sjQ/Jrmk0YLO1lbUP/wcEg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi Nurit,

 

 Yes I agree with you. The standard needs some clarifications.

 

Regards,

Hemanth.

 

 

S.Hemanth Balaji.

Software Engineer.

Huawei Technologies India Pvt Ltd.

Bangalore, India.

 

-----Original Message-----
From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com]
Sent: Tuesday, February 01, 2005 7:59 PM
To: hemanthbs@huawei.com; Marc Binderberger
Cc: isis-wg@ietf.org; Philip Crocker
Subject: RE: [Isis-wg] Wide Metric

 

Hi Hemanth,

I agree this is a reasonable interpretation/solution, and we can agree on this.

However, the statement in the RFC should be fixed. The RFC explicitly states that " If a link is advertised without this sub-TLV (i.e. Sub-TLV 18: Traffic Engineering Default Metric), traffic engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV". There are no conditions regarding other sub-TLVs. This is misleading and I guess that it should be clarified.

Thanks for your responses.

Best regards,

Nurit.

 

-----Original Message-----
From: hemanthbs [mailto:hemanthbs@huawei.com]
Sent: Tuesday, February 01, 2005 4:17 PM
To: Nurit Sprecher; 'Marc Binderberger'
Cc: isis-wg@ietf.org
Subject: RE: [Isis-wg] Wide Metric

 

 

Hi Nurit/Marc,

 

Though the draft doesn't clearly say on what basis can we decide if a

link is a TE link, we use the following selection criteria to select a

TE link.,

 

"We say that a link is TE link only if all TE sub-tlvs for eg: Maximum

link bandwidth, Maximum Reservable Bandwidth ,,etc are present.

Since the interface address sub-tlv can be present for non-TE

links.(wide metric)

If ,only this sub-tlv is present, then it can be considered for normal

wide metric computation and not TE computation."

 

i.e :-          

 

 if(Maximum link bandwidth && Maximum Reservable Bandwidth && Color

....all TE sub-tlvs)

 {

    TE Link

 

}

else

if(interface address sub-tlv)

{

    Normal wide metric link

}

 

I think this will solve the problem were are addressing.

 

-Hemanth

 

S.Hemanth Balaji.

Software Engineer.

Huawei Technologies India Pvt Ltd.

Bangalore, India.

 

 

-----Original Message-----

From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com]

Sent: Tuesday, February 01, 2005 4:21 PM

To: Marc Binderberger; hemanthbs@huawei.com

Cc: isis-wg@ietf.org

Subject: RE: [Isis-wg] Wide Metric

 

Hi Marc,

Thanks for your response.

" Maybe Nurit is asking why the TE extensions have been "integrated"

into

extended IS reachability TLV type 22 instead of using a separate TLV.

Nurit?" Right. I understand your answer.

However, as I wrote earlier to Hemanth, I still think that combining the

wide metric and the TE metric together is too confusing (if the TE

metric does not appear use the value of the wide metric also for the TE

metric.).

I would prefer to see them independently. However, if not, this 'must'

should be modified to something which is less obligating, like may.

Thanks,

Nurit.

 

-----Original Message-----

From: Marc Binderberger [mailto:marc@sniff.de]

Sent: Monday, January 31, 2005 10:53 PM

To: hemanthbs@huawei.com

Cc: Nurit Sprecher; isis-wg@ietf.org

Subject: Re: [Isis-wg] Wide Metric

 

Hello,

 

>> My doubt was why it is combined together with TE.

> The main urge for development of wide metrics was TE. Though we had

the

> problems of smaller metric range.

 

Maybe Nurit is asking why the TE extensions have been "integrated" into

extended IS reachability TLV type 22 instead of using a separate TLV.

Nurit?

 

(in this case: at the beginning of RFC3784 the authors are counting

octets, so I assume they tried to avoid the additional 7 octets for

system Id and pseudonode number in a separate TLV. Beside that

integrating it seems logical, all new per-link information are in one

place/TLV)

 

>> [...] This mandatory requirement does not

>> allow advertising a non-TE link. If for example, an IS supports TE on

>> some links but non-TE only on other links, this mandatory requirement

>> causes that even the Non-TE links will be considered in the CSPF

>> calculation. [...]

>

> The above concern may be answered as below, I guess.

> In an implementation where in the TE links are considered based on the

> following condition. "TE should be enabled for the ISIS process and

> MPLS

> TE should be enabled on the interface"

> i.e for TE computation only those links be will be considered, for

> which MPLS TE is enabled on the interface and TE is enabled for that

> ISIS process running on that interface.

 

Hemanth, but how does a distance router _know_ what interfaces are

enabled if not IS-IS is signaling this?

 

How does the IS-IS process running on A know that B's interface to C

allows TE while the interface to D doesn't ?

 

   A--(te)--B--(te)--C

            |        |

            |       (te)

            |        |

            D--------E

 

(please switch on your fixed font ;-)

 

Or is there the implicit condition that all routers must be "TE-aware"

and you simply put a very high TE metric on the links you don't want?

 

Or trial & error? (wasn't it named "cut back"? The RSVP will tell

finally that a link is not TE/RSVP enabled).

 

 

What am I missing? :-)

 

 

Regards, Marc

--

Marc Binderberger    <marc@sniff.de>

 

 

 

 

--Boundary_(ID_sjQ/Jrmk0YLO1lbUP/wcEg)-- --===============1826922966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1826922966==-- From isis-wg-bounces@ietf.org Tue Feb 1 12:25:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27008 for ; Tue, 1 Feb 2005 12:25:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1VV-0004yW-3v; Tue, 01 Feb 2005 12:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvvYx-0003z2-FJ for isis-wg@megatron.ietf.org; Tue, 01 Feb 2005 05:47:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13205 for ; Tue, 1 Feb 2005 05:47:13 -0500 (EST) Received: from [212.25.127.226] (helo=wombat.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvvr5-0005d5-06 for isis-wg@ietf.org; Tue, 01 Feb 2005 06:05:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isis-wg] Wide Metric Date: Tue, 1 Feb 2005 12:46:23 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A528E543A7@wombat.seabridge.co.il> Thread-Topic: [Isis-wg] Wide Metric Thread-Index: AcUINeoVWk9S+ql4R7a4Qs8BLW2PVgAFP5oA From: "Nurit Sprecher" To: , "Marc Binderberger" X-Spam-Score: 0.3 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b X-Mailman-Approved-At: Tue, 01 Feb 2005 12:08:03 -0500 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: , Content-Type: multipart/mixed; boundary="===============1122017504==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1122017504== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5084B.45ECB5BC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5084B.45ECB5BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But if you want to use the link from B to D for non-TE advertisement using the wide metric, you have to use the extended TLV without the TE sub TLV. In such a case the value of the Wide metric is used also for the TE metric, and the link is considered as TE link. I think combining these two mechanisms (wide and TE) is too confusing. _____________________________________________ From: hemanthbs [mailto:hemanthbs@huawei.com]=20 Sent: Tuesday, February 01, 2005 10:14 AM To: 'Marc Binderberger' Cc: Nurit Sprecher; isis-wg@ietf.org Subject: RE: [Isis-wg] Wide Metric Hi Marc, >> [...] This mandatory requirement does not >> allow advertising a non-TE link. If for example, an IS supports TE on >> some links but non-TE only on other links, this mandatory requirement >> causes that even the Non-TE links will be considered in the CSPF >> calculation. [...] > > The above concern may be answered as below, I guess. > In an implementation where in the TE links are considered based on the > following condition. "TE should be enabled for the ISIS process and=20 > MPLS > TE should be enabled on the interface" > i.e for TE computation only those links be will be considered, for > which MPLS TE is enabled on the interface and TE is enabled for that > ISIS process running on that interface. Hemanth, but how does a distance router _know_ what interfaces are=20 enabled if not IS-IS is signaling this? How does the IS-IS process running on A know that B's interface to C=20 allows TE while the interface to D doesn't ? A--(te)--B--(te)--C | | | (te) | | D--------E Every ISIS process on a router will maintain a separate database for the TE information. The TE advertisements made will also be little different from the normal LSPs. With such a condition, Router B's TE advertisements would advertise a link to C but not to D. Hence when Router A processes this TE LSP, it would know that Router B has a TE link only to C and not to D. From this information Router A can build its own TE database, which it can use to build the TE link and network information. Finally this TE link and network information is given to CSPF. -Hemanth. (please switch on your fixed font ;-) Or is there the implicit condition that all routers must be "TE-aware"=20 and you simply put a very high TE metric on the links you don't want? Or trial & error? (wasn't it named "cut back"? The RSVP will tell=20 finally that a link is not TE/RSVP enabled). What am I missing? :-) Regards, Marc -- Marc Binderberger ------_=_NextPart_001_01C5084B.45ECB5BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Wide Metric

But if you want to use the = link from B to D for non-TE advertisement using the wide metric, you = have to use the extended TLV without the TE = sub TLV. In such = a case the value = of the Wide metric is used also for the TE metric, and the link is considered = as TE link.

I think combining these two mechanisms (wide = and TE) is too confusing.

_____________________________________________
From: hemanthbs [mailto:hemanthbs@huawei.com]
= Sent: Tuesday, = February 01, 2005 10:14 AM
To: 'Marc = Binderberger'
Cc: Nurit = Sprecher; isis-wg@ietf.org
Subject: RE: [Isis-wg] = Wide Metric

Hi Marc,

>> [...] This mandatory requirement does = not

>> allow advertising a non-TE link. If for = example, an IS supports TE on

>> some links but non-TE only on other links, this = mandatory requirement

>> causes that even the Non-TE links will be = considered in the CSPF

>> calculation. [...]

>

> = The above concern may be answered = as below, I guess.

> In = an implementation where in the TE links are considered based on = the

> = following condition. "TE should be enabled for the ISIS process and =

> = MPLS

> TE = should be enabled on the interface"

> = i.e for TE computation only those = links be will be considered, for

> = which MPLS TE is enabled on the interface and TE is enabled for = that

> = ISIS process running on that interface.

Hemanth, but how does a distance router _know_ what = interfaces are

enabled = if not IS-IS is signaling = this?

How = does the IS-IS process running on A know that B's interface to C =

allows = TE while the interface to D doesn't ?

   A--(te)--B--(te)--C

         &nb= sp;  |        = |

         &nb= sp;  |       (te)

         &nb= sp;  |        = |

         &nb= sp;  D--------E

Every ISIS process on a router will maintain a = separate database for the TE information. The TE advertisements made = will also be little different from the normal LSPs. With such a = condition,

Router B's = TE advertisements would advertise a link to C but not to D.

Hence when = Router A processes this TE LSP, it would know that Router B has a TE = link only to C and not to D. From this information Router A can build = its own TE database, which it can use to build the TE link and network = information. Finally this TE link and = network information is given to CSPF.

-Hemanth.


(please = switch on your fixed font ;-)








Or is = there the implicit condition that all routers must be = "TE-aware"

and you = simply put a very high TE metric on the links you don't = want?

Or = trial & error? (wasn't it = named "cut back"? The RSVP will tell

finally = that a link is not TE/RSVP enabled).


What am = I missing? :-)


Regards, Marc

--

Marc = Binderberger    <marc@sniff.de>

------_=_NextPart_001_01C5084B.45ECB5BC-- --===============1122017504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1122017504==-- From isis-wg-bounces@ietf.org Tue Feb 1 12:26:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27107 for ; Tue, 1 Feb 2005 12:26:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1VV-0004yb-Ia; Tue, 01 Feb 2005 12:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvvd0-0004gw-8C for isis-wg@megatron.ietf.org; Tue, 01 Feb 2005 05:51:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13559 for ; Tue, 1 Feb 2005 05:51:24 -0500 (EST) Received: from [212.25.127.226] (helo=wombat.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvvv8-0005jS-Vg for isis-wg@ietf.org; Tue, 01 Feb 2005 06:10:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Wide Metric Date: Tue, 1 Feb 2005 12:50:38 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A52801091420@wombat.seabridge.co.il> Thread-Topic: [Isis-wg] Wide Metric Thread-Index: AcUH1tufiv9GZmUfTd21CvRRR+CJYgAdG/Lw From: "Nurit Sprecher" To: "Marc Binderberger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 01 Feb 2005 12:08:03 -0500 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 Content-Transfer-Encoding: quoted-printable Hi Marc, Thanks for your response.=20 " Maybe Nurit is asking why the TE extensions have been "integrated" into=20 extended IS reachability TLV type 22 instead of using a separate TLV.=20 Nurit?" Right. I understand your answer. However, as I wrote earlier to Hemanth, I still think that combining the wide metric and the TE metric together is too confusing (if the TE metric does not appear use the value of the wide metric also for the TE metric.). I would prefer to see them independently. However, if not, this 'must' should be modified to something which is less obligating, like may. Thanks, Nurit. -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 Sent: Monday, January 31, 2005 10:53 PM To: hemanthbs@huawei.com Cc: Nurit Sprecher; isis-wg@ietf.org Subject: Re: [Isis-wg] Wide Metric Hello, >> My doubt was why it is combined together with TE. > The main urge for development of wide metrics was TE. Though we had the > problems of smaller metric range. Maybe Nurit is asking why the TE extensions have been "integrated" into=20 extended IS reachability TLV type 22 instead of using a separate TLV.=20 Nurit? (in this case: at the beginning of RFC3784 the authors are counting=20 octets, so I assume they tried to avoid the additional 7 octets for=20 system Id and pseudonode number in a separate TLV. Beside that=20 integrating it seems logical, all new per-link information are in one=20 place/TLV) >> [...] This mandatory requirement does not >> allow advertising a non-TE link. If for example, an IS supports TE on >> some links but non-TE only on other links, this mandatory requirement >> causes that even the Non-TE links will be considered in the CSPF >> calculation. [...] > > The above concern may be answered as below, I guess. > In an implementation where in the TE links are considered based on the > following condition. "TE should be enabled for the ISIS process and=20 > MPLS > TE should be enabled on the interface" > i.e for TE computation only those links be will be considered, for > which MPLS TE is enabled on the interface and TE is enabled for that > ISIS process running on that interface. Hemanth, but how does a distance router _know_ what interfaces are=20 enabled if not IS-IS is signaling this? How does the IS-IS process running on A know that B's interface to C=20 allows TE while the interface to D doesn't ? A--(te)--B--(te)--C | | | (te) | | D--------E (please switch on your fixed font ;-) Or is there the implicit condition that all routers must be "TE-aware"=20 and you simply put a very high TE metric on the links you don't want? Or trial & error? (wasn't it named "cut back"? The RSVP will tell=20 finally that a link is not TE/RSVP enabled). What am I missing? :-) Regards, Marc -- Marc Binderberger _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Feb 1 12:26:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27176 for ; Tue, 1 Feb 2005 12:26:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1VV-0004yg-SO; Tue, 01 Feb 2005 12:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvz23-0003Ez-M4 for isis-wg@megatron.ietf.org; Tue, 01 Feb 2005 09:29:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08554 for ; Tue, 1 Feb 2005 09:29:30 -0500 (EST) Received: from [212.25.127.226] (helo=wombat.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvzKB-0003Ko-Bb for isis-wg@ietf.org; Tue, 01 Feb 2005 09:48:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isis-wg] Wide Metric Date: Tue, 1 Feb 2005 16:28:32 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A52801091422@wombat.seabridge.co.il> Thread-Topic: [Isis-wg] Wide Metric Thread-Index: AcUIaMWVMkFxR0RtS56MK28okLl+KgAALWow From: "Nurit Sprecher" To: , "Marc Binderberger" X-Spam-Score: 0.1 (/) X-Scan-Signature: da38be4a423a556a4dcef9ca1fb76a0f X-Mailman-Approved-At: Tue, 01 Feb 2005 12:08:03 -0500 Cc: Philip Crocker , 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: , Content-Type: multipart/mixed; boundary="===============1623904540==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1623904540== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5086A.4EA78458" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5086A.4EA78458 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hemanth, I agree this is a reasonable interpretation/solution, and we can agree on this. However, the statement in the RFC should be fixed. The RFC explicitly states that " If a link is advertised without this sub-TLV (i.e. Sub-TLV 18: Traffic Engineering Default Metric), traffic engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV". There are no conditions regarding other sub-TLVs. This is misleading and I guess that it should be clarified. Thanks for your responses. Best regards, Nurit. =20 -----Original Message----- From: hemanthbs [mailto:hemanthbs@huawei.com]=20 Sent: Tuesday, February 01, 2005 4:17 PM To: Nurit Sprecher; 'Marc Binderberger' Cc: isis-wg@ietf.org Subject: RE: [Isis-wg] Wide Metric =20 =20 Hi Nurit/Marc, =20 Though the draft doesn't clearly say on what basis can we decide if a link is a TE link, we use the following selection criteria to select a TE link., =20 "We say that a link is TE link only if all TE sub-tlvs for eg: Maximum link bandwidth, Maximum Reservable Bandwidth ,,etc are present. Since the interface address sub-tlv can be present for non-TE links.(wide metric) If ,only this sub-tlv is present, then it can be considered for normal wide metric computation and not TE computation." =20 i.e :- =20 =20 if(Maximum link bandwidth && Maximum Reservable Bandwidth && Color ....all TE sub-tlvs) { TE Link =20 } else if(interface address sub-tlv) { Normal wide metric link } =20 I think this will solve the problem were are addressing. =20 -Hemanth =20 S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. =20 =20 -----Original Message----- From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com]=20 Sent: Tuesday, February 01, 2005 4:21 PM To: Marc Binderberger; hemanthbs@huawei.com Cc: isis-wg@ietf.org Subject: RE: [Isis-wg] Wide Metric =20 Hi Marc, Thanks for your response.=20 " Maybe Nurit is asking why the TE extensions have been "integrated" into=20 extended IS reachability TLV type 22 instead of using a separate TLV.=20 Nurit?" Right. I understand your answer. However, as I wrote earlier to Hemanth, I still think that combining the wide metric and the TE metric together is too confusing (if the TE metric does not appear use the value of the wide metric also for the TE metric.). I would prefer to see them independently. However, if not, this 'must' should be modified to something which is less obligating, like may. Thanks, Nurit. =20 -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 Sent: Monday, January 31, 2005 10:53 PM To: hemanthbs@huawei.com Cc: Nurit Sprecher; isis-wg@ietf.org Subject: Re: [Isis-wg] Wide Metric =20 Hello, =20 >> My doubt was why it is combined together with TE. > The main urge for development of wide metrics was TE. Though we had the > problems of smaller metric range. =20 Maybe Nurit is asking why the TE extensions have been "integrated" into=20 extended IS reachability TLV type 22 instead of using a separate TLV.=20 Nurit? =20 (in this case: at the beginning of RFC3784 the authors are counting=20 octets, so I assume they tried to avoid the additional 7 octets for=20 system Id and pseudonode number in a separate TLV. Beside that=20 integrating it seems logical, all new per-link information are in one=20 place/TLV) =20 >> [...] This mandatory requirement does not >> allow advertising a non-TE link. If for example, an IS supports TE on >> some links but non-TE only on other links, this mandatory requirement >> causes that even the Non-TE links will be considered in the CSPF >> calculation. [...] >=20 > The above concern may be answered as below, I guess. > In an implementation where in the TE links are considered based on the > following condition. "TE should be enabled for the ISIS process and=20 > MPLS > TE should be enabled on the interface" > i.e for TE computation only those links be will be considered, for > which MPLS TE is enabled on the interface and TE is enabled for that > ISIS process running on that interface. =20 Hemanth, but how does a distance router _know_ what interfaces are=20 enabled if not IS-IS is signaling this? =20 How does the IS-IS process running on A know that B's interface to C=20 allows TE while the interface to D doesn't ? =20 A--(te)--B--(te)--C | | | (te) | | D--------E =20 (please switch on your fixed font ;-) =20 Or is there the implicit condition that all routers must be "TE-aware"=20 and you simply put a very high TE metric on the links you don't want? =20 Or trial & error? (wasn't it named "cut back"? The RSVP will tell=20 finally that a link is not TE/RSVP enabled). =20 =20 What am I missing? :-) =20 =20 Regards, Marc -- Marc Binderberger =20 =20 =20 =20 ------_=_NextPart_001_01C5086A.4EA78458 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hemanth,

I agree this is a reasonable interpretation/solution, and we can = agree on this.

However, the statement in the RFC should be fixed. The RFC = explicitly states that " If a link is advertised without this sub-TLV (i.e. = Sub-TLV 18: Traffic Engineering Default Metric), traffic engineering SPF calculations = MUST use the normal default metric of this link, which is advertised in the fixed = part of the extended IS reachability TLV". There are no conditions = regarding other sub-TLVs. This is misleading and I guess that it should be = clarified.

Thanks for your responses.

Best regards,

Nurit.

 

-----Original Message-----
From: hemanthbs [mailto:hemanthbs@huawei.com]
Sent: Tuesday, February 01, 2005 4:17 PM
To: Nurit Sprecher; 'Marc Binderberger'
Cc: isis-wg@ietf.org
Subject: RE: [Isis-wg] Wide Metric

 

 

Hi Nurit/Marc,

 

Though the draft doesn't clearly say on what basis can we decide = if a

link is a TE link, we use the following selection criteria to = select a

TE link.,

 

"We say that a link is TE link only if all TE sub-tlvs for = eg: Maximum

link bandwidth, Maximum Reservable Bandwidth ,,etc are = present.

Since the interface address sub-tlv can be present for = non-TE

links.(wide metric)

If ,only this sub-tlv is present, then it can be considered for = normal

wide metric computation and not TE = computation."

 

i.e = :-           =

 

 if(Maximum link bandwidth && Maximum Reservable = Bandwidth && Color

....all TE sub-tlvs)

 {

    TE Link

 

}

else

if(interface address sub-tlv)

{

    Normal wide metric = link

}

 

I think this will solve the problem were are = addressing.

 

-Hemanth

 

S.Hemanth Balaji.

Software Engineer.

Huawei Technologies India Pvt Ltd.

Bangalore, India.

 

 

-----Original Message-----

From: Nurit Sprecher = [mailto:nurit.sprecher@SeabridgeNetworks.com] =

Sent: Tuesday, February 01, 2005 4:21 = PM

To: Marc Binderberger; = hemanthbs@huawei.com

Cc: isis-wg@ietf.org

Subject: RE: [Isis-wg] Wide Metric

 

Hi Marc,

Thanks for your response.

" Maybe Nurit is asking why the TE extensions have been "integrated"

into

extended IS reachability TLV type 22 instead of using a separate = TLV.

Nurit?" Right. I understand your = answer.

However, as I wrote earlier to Hemanth, I still think that = combining the

wide metric and the TE metric together is too confusing (if the = TE

metric does not appear use the value of the wide metric also for = the TE

metric.).

I would prefer to see them independently. However, if not, this = 'must'

should be modified to something which is less obligating, like = may.

Thanks,

Nurit.

 

-----Original Message-----

From: Marc Binderberger [mailto:marc@sniff.de] =

Sent: Monday, January 31, 2005 10:53 = PM

To: hemanthbs@huawei.com

Cc: Nurit Sprecher; = isis-wg@ietf.org

Subject: Re: [Isis-wg] Wide Metric

 

Hello,

 

>> My doubt was why it is combined together with = TE.

> The main urge for development of wide metrics was TE. = Though we had

the

> problems of smaller metric = range.

 

Maybe Nurit is asking why the TE extensions have been "integrated" into

extended IS reachability TLV type 22 instead of using a separate = TLV.

Nurit?

 

(in this case: at the beginning of RFC3784 the authors are = counting

octets, so I assume they tried to avoid the additional 7 octets = for

system Id and pseudonode number in a separate TLV. Beside that =

integrating it seems logical, all new per-link information are = in one

place/TLV)

 

>> [...] This mandatory requirement does = not

>> allow advertising a non-TE link. If for example, an IS supports TE on

>> some links but non-TE only on other links, this = mandatory requirement

>> causes that even the Non-TE links will be considered in = the CSPF

>> calculation. [...]

> 

> The above concern may be answered as below, I = guess.

> In an implementation where in the TE links are considered = based on the

> following condition. "TE should be enabled for the = ISIS process and

> MPLS

> TE should be enabled on the = interface"

> i.e for TE computation only those links be will be = considered, for

> which MPLS TE is enabled on the interface and TE is enabled = for that

> ISIS process running on = that interface.

 

Hemanth, but how does a distance router _know_ what interfaces = are

enabled if not IS-IS is signaling = this?

 

How does the IS-IS process running on A know that B's interface = to C

allows TE while the interface to D doesn't = ?

 

   A--(te)--B--(te)--C

           = ; |        = |

           = ; |       (te)

           = ; |        = |

           = ; D--------E

 

(please switch on your fixed font = ;-)

 

Or is there the implicit condition that all routers must be "TE-aware"

and you simply put a very high TE metric on the links you don't = want?

 

Or trial & error? (wasn't it named "cut back"? The = RSVP will tell

finally that a link is not TE/RSVP = enabled).

 

 

What am I missing? :-)

 

 

Regards, Marc

--

Marc Binderberger    = <marc@sniff.de>

 

 

 

 

------_=_NextPart_001_01C5086A.4EA78458-- --===============1623904540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1623904540==-- From isis-wg-bounces@ietf.org Wed Feb 2 19:07:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29628 for ; Wed, 2 Feb 2005 19:07:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwUVS-0005WI-3n; Wed, 02 Feb 2005 19:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwUPQ-0004KM-QK for isis-wg@megatron.ietf.org; Wed, 02 Feb 2005 18:59:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28842 for ; Wed, 2 Feb 2005 18:59:39 -0500 (EST) Received: from web20622.mail.yahoo.com ([216.136.227.80]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwUhs-0007Xd-19 for isis-wg@ietf.org; Wed, 02 Feb 2005 19:18:49 -0500 Received: (qmail 40065 invoked by uid 60001); 2 Feb 2005 23:59:41 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=6grIvyWmSu7Ko5nsxpU0P77lgx/9ANlNSNy5qPti7uHn+btq09Ksc7M6cmtRC6RtKkwCoVzZp1Q2yJrb72tpn5EUY/Use8jHo/olCM7ML1KteyuPAy4TjBXAppLveAWMiDaiPu0o5mgChxUclPrIYxjvt7OlDllQmaGuEMMMVWY= ; Message-ID: <20050202235941.40063.qmail@web20622.mail.yahoo.com> Received: from [66.17.149.13] by web20622.mail.yahoo.com via HTTP; Wed, 02 Feb 2005 15:59:41 PST Date: Wed, 2 Feb 2005 15:59:41 -0800 (PST) From: Satish Dattatri Subject: RE: [Isis-wg] Wide Metric To: Nurit Sprecher In-Reply-To: <6FAB860EC6AE3C4EB327204DEC33A528E543B1@wombat.seabridge.co.il> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: isis-wg@ietf.org, Nurit Sprecher 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 > > > However, the statement in the RFC should be fixed. The RFC explicitly > > states that " If a link is advertised without this sub-TLV (i.e. > Sub-TLV > > 18: Traffic Engineering Default Metric), traffic engineering SPF > > calculations MUST use the normal default metric of this link, which is > > advertised in the fixed part of the extended IS reachability TLV". > There > > are no conditions regarding other sub-TLVs. This is misleading and I > > guess that it should be clarified. > > > > This part of the RFC is talking about which metric to use in the CSPF. > To me all this means, if TE metric is present use that else use the > default metric (same one used in IGP/normal SPF) as the link cost > during your CSPF. > << metric sub-TLV does not exist, the link is not a TE link and we do not > want to consider it with the CSPF calculations.>>> Look at it this way, TE metric is specified to aid your CSPF engine to choose a different path than your SPF path. There very well could be links that are TE enabled, but do not have a specific TE metric configured. Since you can avoid using up some, need not send the TE metric. It is perfectly legal to send the same IGP link cost in the TE metric, but not necessary. > > In order to determine if a link is TE enabled or not base it on b/w > sub-tlvs. Remember that choosing a link in your CSPF is a *local* > decision. However, keep in mind that a TE enabled link need not have > the TE metric configured on it. > << as a TE link. If it is advertised as a non-TE link, it should be > considered for the SPF calculation only. Otherwise this is misleading > and confusing. All advertised links are considered for SPF. For CSPF consider only those links which have TE enabled (not by TE metric presence). > The integration between a TE and a wide metric is too strong. I can > still want to use the wide metric in a non-TE network without using the > TE-metric. Enabling wide metric usage and TE can be kept seperate in your implementation. The RFC does not ask you to bind it together. You do need to use the new-style of TLVs for this purpose. If and when TE is enabled start shipping those sub-tlvs as required. >If a wide metric does not appear, we do not take the TE > metric instead. Not sure what you mean here.. Without the wide metric => new-style of TLVs anyway we cannot have TE metric. > If someone wants to advertise a TE link, it should specifically assign a > value to the TE metric (if not configured, it can assign it with the > value of the wide metric>>> As mentioned above, this is upto your implementation, you certainly can send TE metric on links that have TE enabled (wasting LSP space) But, you cannot require other implementation to do the same. Hence you anyway need to handle missing TE metric but link being TE enabled in your CSPF. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Feb 6 15:26:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24352 for ; Sun, 6 Feb 2005 15:26:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxsxL-0002BD-K8; Sun, 06 Feb 2005 15:24:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxsvT-0001CC-A7 for isis-wg@megatron.ietf.org; Sun, 06 Feb 2005 15:22:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24006 for ; Sun, 6 Feb 2005 15:22:33 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.193]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxtEi-0005BS-9f for isis-wg@ietf.org; Sun, 06 Feb 2005 15:42:29 -0500 Received: by rproxy.gmail.com with SMTP id b11so576576rne for ; Sun, 06 Feb 2005 12:22:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=Qh/oQt+t/SCxtndC40Y4aL3oknkVJj3gM4S+hHKfK8QR1QSLsm6zLzRXMICEjFzPhwwSdqge+b/38VqLv7uqOGcem9NQCMUEtXQCyi4WNZN+vB90hjWQxhETkXWEtuPB6jkdH3cVqEsAD85Hdy8qXmdHvAzlP9f+rydO0bP9TXI= Received: by 10.38.98.65 with SMTP id v65mr168262rnb; Sun, 06 Feb 2005 12:22:03 -0800 (PST) Received: by 10.38.102.22 with HTTP; Sun, 6 Feb 2005 12:22:02 -0800 (PST) Message-ID: Date: Mon, 7 Feb 2005 01:52:02 +0530 From: Abhishek Verma To: "ISIS-WG (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Two Way Check in ISIS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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 Content-Transfer-Encoding: 7bit Hi, When running our SPF we do a 2 way neighbor check. So this is my understanding of this. If I dont see myself listed in Router A's LSPs then i assume that he cant reach me, or is not aware of me. In that case, I dont consider any IP reachability advertised by that Router and i just ignore it. OR we dont consider the neighbor in our TENT. Now what should i do if i dont see Router A including Router B in its LSPs. Is it possible for me to run any two way checks? Thanks, Abhishek -- -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Feb 7 13:41:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28270 for ; Mon, 7 Feb 2005 13:41:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDmR-0002PZ-0R; Mon, 07 Feb 2005 13:38:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDgm-00011n-Vz for isis-wg@megatron.ietf.org; Mon, 07 Feb 2005 13:32:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27405 for ; Mon, 7 Feb 2005 13:32:45 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyE0D-0007bu-M7 for isis-wg@ietf.org; Mon, 07 Feb 2005 13:52:54 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2005 13:32:17 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j17IWE1j025527; Mon, 7 Feb 2005 13:32:15 -0500 (EST) Received: from jlearman-w2k05.cisco.com (dhcp-64-102-83-173.cisco.com [64.102.83.173]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFD29072; Mon, 7 Feb 2005 10:32:13 -0800 (PST) Message-Id: <4.3.2.7.2.20050207111001.025e74e8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Feb 2005 11:50:47 -0500 To: Abhishek Verma , "ISIS-WG (E-mail)" From: Jeff Learman Subject: Re: [Isis-wg] Two Way Check in ISIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 At 03:22 PM 2/6/2005, Abhishek Verma wrote: >Hi, > >When running our SPF we do a 2 way neighbor check. So this is my >understanding of this. If I dont see myself listed in Router A's LSPs >then i assume that he cant reach me, or is not aware of me. In that >case, I dont consider any IP reachability advertised by that Router >and i just ignore it. If A is your neighbor, then you don't use the link between yourself and A when running SPF. But you don't ignore all of A's reachability info. > OR we dont consider the neighbor in our TENT. > >Now what should i do if i dont see Router A including Router B in its >LSPs. Is it possible for me to run any two way checks? If B lists A as a neighbor but A doesn't list B, don't use the link between A and B (in either direction) when running SPF. This is all quite clearly spelled out in ISO 10589. In particular, see the informative annex containing pseudocode for the SPF algorithm. This document is necessary to implement IS-IS or to understand many technical details. One situation where this check is necessary is when an area is partitioned due to failed links between the two partitions. For up to 20 minutes, your LSDB will still contain out-of-date LSPs from systems in the other partition, including links to their erstwhile neighbors in your partition. You mustn't use these links in SPF. Fortunately, they get deleted from the LSPs from their erstwhile neighbors (whose LSPs you're still receiving). The two-way check keeps you from having a black hole while old LSPs time out. Regards, Jeff >Thanks, >Abhishek > >-- > >-- >Class of 2004 >Institute of Technology, BHU >Varanasi, India > >_______________________________________________ >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 Feb 7 18:09:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12821 for ; Mon, 7 Feb 2005 18:09:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHpK-0000nt-Vp; Mon, 07 Feb 2005 17:57:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHfO-0006FT-J2 for isis-wg@megatron.ietf.org; Mon, 07 Feb 2005 17:47:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08416 for ; Mon, 7 Feb 2005 17:47:35 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHyr-0002L6-AH for isis-wg@ietf.org; Mon, 07 Feb 2005 18:07:46 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.31 ; Mon, 7 Feb 2005 17:47:01 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Feb 2005 17:47:01 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.122 140.233.20.122 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 07 Feb 2005 17:46:55 -0500 From: "Parker, Jeff" To: "'isis-wg@ietf.org'" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Feb 2005 22:47:01.0233 (UTC) FILETIME=[EFE22E10:01C50D66] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Version 18 of the MIB 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 Content-Transfer-Encoding: 7bit I have submitted version 18 of the MIB to the IETF, after much help behind the scenes from Sundar Ramachandran, Jon Harrison, Mike Bartlett, and Don Goodspeed. I would be happy to send a unicast copy to anyone who needs an early version. - jeff The change list is below -- Changes in version 18 -- Removed use of TimeTicks -- Removed 0 as possible length for LSPID -- Removed references to isisSysOrigLSPBuffSize -- Elaborated Units clauses -- New definition of isisCircLevelIDOctet -- Added isisPduBufferSize to isisOrigLSPBuffSizeMismatch -- Removed reference to isisManAreaAddr, isisSysManAddrDropFromAreas -- isisOriginatingBufferSize, -- Remove replaceOnlyWhileDisabled from isisSysLevelMetricStyle -- and isisSysLevelOrigLSPBuffSize -- Edited units to isisCircLastUpTime and isisPacketCountLSP -- Edited description of isisCircLastUpTime -- Restore isisManAreaAddrTable -- Modified text of isisAreaAddrTable to include areas we generate -- Changed name isisSysLevelOverloadState to isisSysLevelState, -- modified description -- Moved REVISION, added DESCRIPTION _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From Stonekgmcp@netizenislands.com Wed Feb 9 08:03:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28040; Wed, 9 Feb 2005 08:03:03 -0500 (EST) Received: from cpe.atm2-0-1071203.0x50a29e02.virnxx12.customer.tele.dk ([80.162.158.2]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CyroX-0006NS-Vp; Wed, 09 Feb 2005 08:23:31 -0500 Received: from hablas.com ([208.254.3.160]) by coriolanus.tabnet.com (InterMail vK.4.04.00.00 842-261-667 license 9dm865kr1218a4ic8f1ipu4251j3xjr1) with ESMTP id <99308988946734.BTNQ219.softwood@hablas.com> for ; Wed, 09 Feb 2005 11:06:15 -0200 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 09 Feb 2005 15:59:15 +0300 Received: from 217.75.248.21 by intrepid.sear.hotmail.msn.com with HTTP; Wed, 09 Feb 2005 06:01:15 -0700 GMT X-Originating-IP: [203.212.2.88] X-Originating-Email: [ingest@hablas.com] From: "Marisol Tillman" To: nogrvnew-work@ietf.org Subject: many passwords to real companionship Date: Wed, 09 Feb 2005 08:01:15 -0500 Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: Wed, 09 Feb 2005 12:05:15 -0100 (UTC) FILETIME=[2N8HWI00:02A46751] X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable




Goodbye<= /A>




dusenbury drovebaseman ingrown examinebengal mills genialbogeymen powerhouse indemnifypretense peaceable quadrantlitigious hairdo jewelblomberg billings mannerismchromosome clinging stardomrooky bristle sinfulcommentator From isis-wg-bounces@ietf.org Wed Feb 9 08:54:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02874 for ; Wed, 9 Feb 2005 08:54:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CysBR-0004uc-1u; Wed, 09 Feb 2005 08:47:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cys83-00042U-Io for isis-wg@megatron.ietf.org; Wed, 09 Feb 2005 08:43:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01685 for ; Wed, 9 Feb 2005 08:43:38 -0500 (EST) Received: from bzq-25-80-121.cust.bezeqint.net ([212.25.80.121] helo=tvril-mr01) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CysRq-0007Ov-Uo for Isis-wg@ietf.org; Wed, 09 Feb 2005 09:04:08 -0500 Received: From VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by tvril-mr01 (WebShield SMTP v4.5 MR1a P0803.345); id 1107956651500; Wed, 9 Feb 2005 15:44:11 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 9 Feb 2005 15:48:40 +0200 Message-ID: <52F6342A567975489F83368EB54C0D7D069E77@VRZIL-EX01.il.veraznetworks.com> Thread-Topic: question about the MIB Thread-Index: AcUOrVoZ4uzsrSw2SSemWZEkzz0KsQ== From: "Yossi Boaron" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [Isis-wg] question about the MIB 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="===============0576580766==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============0576580766== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50EAE.10001E4E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50EAE.10001E4E Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I have 3questions about controling LSP advertisement in IS-IS MIB. first question : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D By default the circuits that enabled to run IS-IS are advertised in the = LSP. I also want to advertise the following : 1. circuits that are not running IS-IS 2. static routes. 3. routes that added automatic by other routing protocol. Where can I configure in the MIB wheater to enable or disable = advertisement of each of the above? Second question : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Each router advertise in LSP his 'local' interfaces, each one of this = LSPs is flooded to all routers in the domain.the result is that each = router in the domain have the all LSPs database. How from this information the router 'builds' the domain graph ? =20 Third question =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I tried to connect to CISCO router with the standard IS-IS mib with no = success, does anyone connects to CISCO router with the IS-IS standard = MIB? Thanks Yossi ------_=_NextPart_001_01C50EAE.10001E4E Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable question about the MIB

I have 3questions about = controling LSP advertisement in IS-IS MIB.

first question :

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

By default the circuits that = enabled to run IS-IS are advertised in the LSP.

I also want to advertise the = following :

        1. circuits that are not running IS-IS

        2. static routes.

        3. routes that added automatic by other routing = protocol.

Where can I configure in the = MIB wheater to enable or disable advertisement of each of the = above?

Second question :

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Each router advertise in LSP = his 'local' interfaces, each one of this LSPs is flooded to all routers = in the domain.the result is that each router in the domain have the all = LSPs database.

How from this information the = router 'builds' the domain graph ?

 

Third question

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I tried to connect to CISCO = router with the standard IS-IS mib with no success, does anyone connects = to CISCO router with the IS-IS standard MIB?



Thanks

Yossi

------_=_NextPart_001_01C50EAE.10001E4E-- --===============0576580766== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0576580766==-- From isis-wg-bounces@ietf.org Wed Feb 9 09:45:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06523 for ; Wed, 9 Feb 2005 09:45:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CysyJ-0000jS-Jk; Wed, 09 Feb 2005 09:37:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cysse-00071f-ID for isis-wg@megatron.ietf.org; Wed, 09 Feb 2005 09:31:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05671 for ; Wed, 9 Feb 2005 09:31:46 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CytCT-000077-9h for Isis-wg@ietf.org; Wed, 09 Feb 2005 09:52:17 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.31 ; Wed, 9 Feb 2005 09:31:15 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Feb 2005 09:31:15 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.122 140.233.20.122 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 09 Feb 2005 09:31:15 -0500 Subject: Re: [Isis-wg] question about the MIB From: "Parker, Jeff" To: Yossi Boaron , Message-ID: In-Reply-To: <52F6342A567975489F83368EB54C0D7D069E77@VRZIL-EX01.il.veraznetworks.com> Mime-version: 1.0 X-OriginalArrivalTime: 09 Feb 2005 14:31:15.0248 (UTC) FILETIME=[02B89300:01C50EB4] X-Spam-Score: 0.8 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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="===============2129647557==" 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. --===============2129647557== Content-type: multipart/alternative; boundary="B_3190786275_174926" > 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_3190786275_174926 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Yossi - 3) The term =B3Standard IS-IS MIB=B2 is a misnomer: there is no standard IS-IS MIB. Should the stars align and the draft IS-IS MIB become a standard, there will be a lag between standardization and implementation. That lag may be measured in months or years, but in many cases will be measured in eons. I do not speak for Cisco, and cannot comment about their development schedule. =20 2) This is not a matter for the MIB. I think there was a recent pointer to the appendix of 10589 or it=B9s revision, which has a discussion of the SPF algorithm. 1) a) =20 isisCircPassiveCircuit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Should we include this interface in LSPs, even if it is not running the IS-IS Protocol?" DEFVAL { false } ::=3D { isisCircEntry 9 } b, c) The IS-IS MIB does not control what routes other protocols select. The proper redistribution of routes from other sources is specific to your implementation, and not covered by the IS-IS MIB. - jeff parker On 2/9/05 8:48 AM, "Yossi Boaron" wrote: >=20 >=20 > I have 3questions about controling LSP advertisement in IS-IS MIB. >=20 > first question : >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > By default the circuits that enabled to run IS-IS are advertised in the L= SP. >=20 > I also want to advertise the following : >=20 > 1. circuits that are not running IS-IS >=20 > 2. static routes. >=20 > 3. routes that added automatic by other routing protocol. >=20 > Where can I configure in the MIB wheater to enable or disable advertiseme= nt of > each of the above? >=20 > Second question : >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Each router advertise in LSP his 'local' interfaces, each one of this LSP= s is > flooded to all routers in the domain.the result is that each router in th= e > domain have the all LSPs database. >=20 > How from this information the router 'builds' the domain graph ? >=20 > =20 >=20 > Third question >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I tried to connect to CISCO router with the standard IS-IS mib with no > success, does anyone connects to CISCO router with the IS-IS standard MIB= ? >=20 >=20 >=20 > Thanks >=20 > Yossi >=20 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg --B_3190786275_174926 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] question about the MIB Yossi= -

3) The term “Standard IS-IS MIB” is a misnomer: there is no sta= ndard IS-IS MIB.  Should the stars align and the draft IS-IS MIB become= a standard, there will be a lag between standardization and implementation.=  That lag may be measured in months or years, but in many cases will b= e measured in eons.  I do not speak for Cisco, and cannot comment about= their development schedule.  

2) This is not a matter for the MIB.  I think there was a recent point= er to the appendix of 10589 or it’s revision, which has a discussion o= f the SPF algorithm.

1) a)    
     isisCircPassiveCircuit OBJECT-TYPE
        SYNTAX TruthValue
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            &qu= ot;Should we include this interface in LSPs, even if
            &nb= sp;it is not running the IS-IS Protocol?"
        DEFVAL { false }
    ::=3D { isisCircEntry 9 }
   b, c) The IS-IS MIB does not control what routes other pr= otocols select.  The proper redistribution of routes from other sources= is specific to your implementation, and not covered by the IS-IS MIB.

- jeff parker



On 2/9/05 8:48 AM, "Yossi Boaron" <Yossi.Boaron@veraznetworks.= com> wrote:



I have 3que= stions about controling LSP advertisement in IS-IS MIB.

first question :

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

By default the circuits that enabled to run IS-IS= are advertised in the LSP.

I also want to advertise the following :

        1= . circuits that are not running IS-IS

        2= . static routes.

        3= . routes that added automatic by other routing protocol.

Where can I configure in the MIB wheater to enabl= e or disable advertisement of each of the above?

Second question :

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Each router advertise in LSP his 'local' interfac= es, each one of this LSPs is flooded to all routers in the domain.the result= is that each router in the domain have the all LSPs database.

How from this information the router 'builds' the= domain graph ?

Third question

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I tried to connect to CISCO router with the stand= ard IS-IS mib with no success, does anyone connects to CISCO router with the= IS-IS standard MIB?



Thanks

Yossi

____________________= ___________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

 --B_3190786275_174926-- --===============2129647557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============2129647557==-- From isis-wg-bounces@ietf.org Wed Feb 9 17:53:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08661 for ; Wed, 9 Feb 2005 17:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz0Y2-0003ol-1l; Wed, 09 Feb 2005 17:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz0Wj-0003P4-F9 for isis-wg@megatron.ietf.org; Wed, 09 Feb 2005 17:41:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07251 for ; Wed, 9 Feb 2005 17:41:38 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz0qc-0001pB-TF for isis-wg@ietf.org; Wed, 09 Feb 2005 18:02:15 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.31 ; Wed, 9 Feb 2005 17:41:09 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Feb 2005 17:41:09 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.122 140.233.20.122 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 09 Feb 2005 17:41:09 -0500 From: "Parker, Jeff" To: "'isis-wg@ietf.org'" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Feb 2005 22:41:09.0597 (UTC) FILETIME=[731E48D0:01C50EF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Version 18 of the MIB 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 Content-Transfer-Encoding: 7bit The IETF has rejected version 18, as being too far ahead of it's time. Since they never put up version 17, it didn't exist. I have just revised version 18, titled it 17, and resubmitted. I will be asking for a Mib Dr. Review of the current document. I spent the afternoon prepared for the review by revising some of the boiler-plate that is outside the document, and by changing one textual convention (IsisISLevel) to make it more useful. - jeff The change list is below. Since this version must include all the changes that went into the first 17, the list is longer than yesterday's. -- Changes in version 17 -- -- Limited the types of address supported to IPv4 or IPv6 -- Added InterfaceIndex for CircIndex -- Changed names to match MIB guidelines -- Added display hints for Textual Conventions -- Cleaned up formatting -- Replaced isisSysProtSuppTable with BITS -- Limit states required to support RowStatus -- Removed arbitrary limits, replaces with non-zero unsigned -- Added SysLevel to IPRA table -- Changed access type on a number of fields -- Replace "out System ID" with "our System ID" -- Change access for Indicies -- Add new objects for notifications -- New MIB Boilerplate -- Removed use of TimeTicks -- Removed 0 as possible length for LSPID -- Removed references to isisSysOrigLSPBuffSize -- Elaborated Units clauses -- New definition of isisCircLevelIDOctet -- Added isisPduBufferSize to isisOrigLSPBuffSizeMismatch -- Removed reference to isisManAreaAddr, isisSysManAddrDropFromAreas -- isisOriginatingBufferSize, -- Remove replaceOnlyWhileDisabled from isisSysLevelMetricStyle -- and isisSysLevelOrigLSPBuffSize -- Edited units to isisCircLastUpTime and isisPacketCountLSP -- Edited description of isisCircLastUpTime -- Modified text of isisAreaAddrTable to include areas we generate -- Changed name isisSysLevelOverloadState to isisSysLevelState, -- modified description -- Moved REVISION, added DESCRIPTION _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Feb 10 05:45:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16853 for ; Thu, 10 Feb 2005 05:45:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzBjW-0004hq-QF; Thu, 10 Feb 2005 05:39:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzBgh-000450-O8 for isis-wg@megatron.ietf.org; Thu, 10 Feb 2005 05:36:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16240 for ; Thu, 10 Feb 2005 05:36:36 -0500 (EST) Received: from bzq-25-80-121.cust.bezeqint.net ([212.25.80.121] helo=tvril-mr01) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzC0b-0008Cw-PM for Isis-wg@ietf.org; Thu, 10 Feb 2005 05:57:18 -0500 Received: From VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by tvril-mr01 (WebShield SMTP v4.5 MR1a P0803.345); id 1108031826218; Thu, 10 Feb 2005 12:37:06 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: FW: [Isis-wg] question about the MIB Date: Thu, 10 Feb 2005 12:41:36 +0200 Message-ID: <52F6342A567975489F83368EB54C0D7D069E79@VRZIL-EX01.il.veraznetworks.com> Thread-Topic: [Isis-wg] question about the MIB Thread-Index: AcUOtLrrr4bYmXLxSyy8sqQzhShECgAlHbEgAAS//4A= From: "Yossi Boaron" To: , X-Spam-Score: 0.6 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e 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="===============0765606169==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============0765606169== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50F5D.187D9C2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50F5D.187D9C2C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Yossi Boaron=20 Sent: Thursday, February 10, 2005 12:39 PM To: 'Parker, Jeff'; ',Isis-wg@ietf.org' Subject: [Isis-wg] question about the MIB Hi Jeff=20 =20 First of all I want to thank you for your detailed answers. =20 Now I'm a little bit confused, what are the reasons for defining the = 'IP Reachable Address Table' in the MIB? =20 Thanks Yossi -----Original Message----- From: Parker, Jeff [mailto:jeffp@middlebury.edu] Sent: Wednesday, February 09, 2005 4:31 PM To: Yossi Boaron; Isis-wg@ietf.org Subject: Re: [Isis-wg] question about the MIB Yossi - 3) The term "Standard IS-IS MIB" is a misnomer: there is no standard = IS-IS MIB. Should the stars align and the draft IS-IS MIB become a = standard, there will be a lag between standardization and = implementation. That lag may be measured in months or years, but in = many cases will be measured in eons. I do not speak for Cisco, and = cannot comment about their development schedule. =20 2) This is not a matter for the MIB. I think there was a recent pointer = to the appendix of 10589 or it's revision, which has a discussion of the = SPF algorithm. 1) a) =20 isisCircPassiveCircuit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Should we include this interface in LSPs, even if it is not running the IS-IS Protocol?" DEFVAL { false } ::=3D { isisCircEntry 9 } b, c) The IS-IS MIB does not control what routes other protocols = select. The proper redistribution of routes from other sources is = specific to your implementation, and not covered by the IS-IS MIB. - jeff parker On 2/9/05 8:48 AM, "Yossi Boaron" = wrote: I have 3questions about controling LSP advertisement in IS-IS MIB. first question : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D By default the circuits that enabled to run IS-IS are advertised in the = LSP. I also want to advertise the following : 1. circuits that are not running IS-IS 2. static routes. 3. routes that added automatic by other routing protocol. Where can I configure in the MIB wheater to enable or disable = advertisement of each of the above? Second question : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Each router advertise in LSP his 'local' interfaces, each one of this = LSPs is flooded to all routers in the domain.the result is that each = router in the domain have the all LSPs database. How from this information the router 'builds' the domain graph ? Third question =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I tried to connect to CISCO router with the standard IS-IS mib with no = success, does anyone connects to CISCO router with the IS-IS standard = MIB? Thanks Yossi _____ =20 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg ------_=_NextPart_001_01C50F5D.187D9C2C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] question about the MIB
-----Original = Message-----
From: Yossi=20 Boaron
Sent: Thursday, February 10, 2005 12:39 = PM
To:=20 'Parker, Jeff'; ',Isis-wg@ietf.org'
Subject: [Isis-wg] = question about=20 the MIB

Hi=20 Jeff
 
First=20 of all I want to thank you for your detailed = answers.
 
Now=20 I'm a little bit confused, what are the reasons=20 for defining  the 'IP = Reachable=20 Address Table' in the MIB?
 
Thanks Yossi
-----Original Message-----
From: Parker, Jeff=20 [mailto:jeffp@middlebury.edu]
Sent: Wednesday, February 09, = 2005=20 4:31 PM
To: Yossi Boaron; = Isis-wg@ietf.org
Subject: Re:=20 [Isis-wg] question about the MIB

Yossi=20 -

3) The term "Standard IS-IS MIB" is a misnomer: there is no = standard=20 IS-IS MIB.  Should the stars align and the draft IS-IS MIB become = a=20 standard, there will be a lag between standardization and = implementation.=20  That lag may be measured in months or years, but in many cases = will be=20 measured in eons.  I do not speak for Cisco, and cannot comment = about=20 their development schedule.  

2) This is not a matter for = the MIB.=20  I think there was a recent pointer to the appendix of 10589 or = it's=20 revision, which has a discussion of the SPF algorithm.

1) a)=20 =    
     isisCircPassiveCircui= t=20 OBJECT-TYPE
        SYNTAX=20 = TruthValue
        MAX-ACCESS = read-create
        STATUS=20 = current
        DESCRIPTION            = "Should=20 we include this interface in LSPs, even=20 = if
           &= nbsp; it=20 is not running the IS-IS=20 Protocol?"
        DEFVAL { = false=20 }
    ::=3D { isisCircEntry 9 = }
   b,=20 c) The IS-IS MIB does not control what routes other protocols select.=20  The proper redistribution of routes from other sources is = specific to=20 your implementation, and not covered by the IS-IS MIB.

- jeff=20 parker



On 2/9/05 8:48 AM, "Yossi Boaron"=20 <Yossi.Boaron@veraznetworks.com> wrote:


I have 3questions about = controling=20 LSP advertisement in IS-IS MIB.

first question=20 :

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

By = default the=20 circuits that enabled to run IS-IS are advertised in the=20 LSP.

I also want to advertise the following = :

        1. circuits that are not running IS-IS

        2. static routes.

        3. routes that added automatic by other routing=20 protocol.

Where can I configure in the MIB wheater to enable or = disable=20 advertisement of each of the above?

Second question=20 :

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Each router=20 advertise in LSP his 'local' interfaces, each one of this LSPs is = flooded to=20 all routers in the domain.the result is that each router in the = domain have=20 the all LSPs database.

How = from this=20 information the router 'builds' the domain graph ?



Third=20 question

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I = tried to=20 connect to CISCO router with the standard IS-IS mib with no success, = does=20 anyone connects to CISCO router with the IS-IS standard = MIB?



Thanks

Yossi

_______________________________________________
Isis-wg=20 mailing=20 = list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-w= g

------_=_NextPart_001_01C50F5D.187D9C2C-- --===============0765606169== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0765606169==-- From anonymous@s1.eilan.net Thu Feb 10 08:37:17 2005 Received: from s1.eilan.net (s1.eilan.net [213.194.116.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29322 for ; Thu, 10 Feb 2005 08:37:15 -0500 (EST) Received: (qmail 8624 invoked by uid 48); 9 Feb 2005 21:22:00 -0000 Date: 9 Feb 2005 21:21:59 -0000 Message-ID: <20050209212159.8622.qmail@s1.eilan.net> Subject: READ MY PROPOSAL CAREFULLY. From: iantaylor X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer Content-Transfer-Encoding: 7bit FORTIS BANK CO-OPERATION , LONDON (F.B.C.L) . Email: iantaylor03@netscape.net Hello, I am IAN TAYLOR the Branch manager of bill and exchange at the foreign remittance department of FORTIS BANK CO-OPERATION LONDON (F.B.C.L) . In my department we discovered an abandoned sum of #20.500,000.00m pounds(Twenty thousand five hundred Million pounds) in an account that belongs to one of our foreign customer (MR. ANDREAS SCHRANNER from Munich, Germany) who died along with his entire family in Jully 2000 in a plane crash. http://news.bbc.co.uk/1/hi/world/europe/859479.stm Since we got information about his death, we have been expecting his next of kin to come over and claim his money because we cannot release it unless some body applies for it as next of kin or relation to the deceased as indicated in our banking guidlings and laws but unfortunately we learnt that all his supposed next of kin or relation died alongside with him at the plane crash leaving nobody behind for the claim. It is therefore upon this discovery that I now decided to make this business proposal to you and release the money to you as the next of kin or relation to the deceased for safety and subsequent disbursement since nobody is coming for it and we don't want this money to go into the bank treasury as unclaimed bill. The banking law and guidline here stipulates that if such money remained unclaimed after five years, the money will be transfered into the bank treasury as unclaimed fund. The request of foreigner as next of kin in this business is occassioned by the fact that the customer was a foreigner and we cannot stand as next of kin to a foreigner. I agree that 30% of this money will be for you as a respect to the provision of a foriegn account , 10% will be set aside for expenses incurred during the business and 60% would be for me Thereafter, I will visit your country for disbursement according to the percentage indicated Therefore, to enable the immediate transfer of this fund to you arranged,you must apply first to the bank as relation or next of kin of the deceased indicating your bank name, your bank account number, your private telephone and fax number for easy and effective communication and location where in the money will be remitted. Upon receipt of your reply, I will send to you by fax or email the text of the application . I will not fail to bring to your notice this transaction is hitch-free and that you should not entertain any atom of fear as all required arrangements have been made for the transfer. You should contact me immediately as soon as you receive this letter. Trusting to hear from you immediately. Yours Faithfully, Mr. Ian Taylor. FORTIS BANK CO-OPERATION (F.B.C.L) TREAT AS URGENT AND CONFIDENCIAL. NOTE: RESPONSE TO MY PRIVATE BOXES EMAIL: iantaylor03@netscape.net taylor_ian2003@yahoo.co.uk ___________________________________________________________________________ Mail sent from WebMail service at PHP-Nuke Powered Site - http://yoursite.com From isis-wg-bounces@ietf.org Thu Feb 10 17:18:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23760 for ; Thu, 10 Feb 2005 17:18:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzLcO-0005Vr-Pf; Thu, 10 Feb 2005 16:12:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzLHa-0004x4-3a; Thu, 10 Feb 2005 15:51:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06198; Thu, 10 Feb 2005 15:51:24 -0500 (EST) Message-Id: <200502102051.PAA06198@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 10 Feb 2005 15:51:24 -0500 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-17.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-17.txt Pages : 92 Date : 2005-2-10 This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner [1]. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES- IS protocol, and to add management support for current practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-17.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-17.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-17.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-2-10155909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-10155909.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Fri Feb 11 10:59:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10222 for ; Fri, 11 Feb 2005 10:59:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czd3h-00028j-Au; Fri, 11 Feb 2005 10:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzcqJ-0006Ek-1t; Fri, 11 Feb 2005 10:36:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08472; Fri, 11 Feb 2005 10:36:23 -0500 (EST) Received: from [199.45.47.28] (helo=resmail3.restoncampus.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzdAV-0001M2-SV; Fri, 11 Feb 2005 10:57:21 -0500 Received: from resmail01.restoncampus.com ([192.168.3.21]) by resmail3.restoncampus.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Feb 2005 10:35:53 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5104F.5EBE1124" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Fri, 11 Feb 2005 10:35:52 -0500 Message-ID: <923175FC567CCE4B84CA6D225B23CAAA167DDC@resmail01.restoncampus.com> X-MS-Has-Attach: yes Thread-Topic: Draft-ietf-isis-admin-tags-03.txt Thread-Index: AcUQTxejhTEjYOg2ThaWhVL4N+H3VA== From: "Martin, Christian" To: X-OriginalArrivalTime: 11 Feb 2005 15:35:53.0404 (UTC) FILETIME=[5F1BB7C0:01C5104F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: bneal@broadwing.com, chopps@procket.com, David Ward , stefano previdi , isis-wg@ietf.org Subject: [Isis-wg] Draft-ietf-isis-admin-tags-03.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 is a multi-part message in MIME format. ------_=_NextPart_001_01C5104F.5EBE1124 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ISIS WG, Please review and comment on this (hopefully final) version of the admin tags draft. We would like to go to last call with this ASAP. Regards, Chris ------_=_NextPart_001_01C5104F.5EBE1124 Content-Type: text/plain; name="draft-ietf-isis-admin-tags-03.txt" Content-Description: draft-ietf-isis-admin-tags-03.txt Content-Disposition: attachment; filename="draft-ietf-isis-admin-tags-03.txt" Content-Transfer-Encoding: base64 DQ0KDQoNCg0KICAgICAgSVMtSVMgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENocmlzdGlhbiBNYXJ0aW4gDQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWZXJpem9uIA0N CiAgICAgIElFVEYgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3RlZmFubyBQcmV2aWRpIA0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcyANDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEJyYWQgTmVhbCANDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBCcm9hZHdpbmcgQ29tbXVuaWNhdGlvbnMgDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0NCiAgICAgIEV4cGlyZXM6IEF1Z3Vz dCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAw NSANDQogICAgICAgDQ0KICAgICAgIA0NCiAgICAgICAgICAgICAgQSBQb2xpY3kgQ29udHJvbCBN ZWNoYW5pc20gaW4gSVMtSVMgVXNpbmcgQWRtaW5pc3RyYXRpdmUgVGFncyANDQogICAgICAgICAg DQ0KICAgICAgICAgIA0NCiAgICAgICAgICAgICAgICAgICAgICA8ZHJhZnQtaWV0Zi1pc2lzLWFk bWluLXRhZ3MtMDMudHh0PiANDQogICAgICAgDQ0KICAgICAgIA0NCiAgICAgIFN0YXR1cyBvZiB0 aGlzIE1lbW8gDQ0KICAgICAgICAgIA0NCiAgICAgICAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRl cm5ldC1EcmFmdCwgSSBjZXJ0aWZ5IHRoYXQgYW55IGFwcGxpY2FibGUgDQ0KICAgICAgICAgcGF0 ZW50IG9yIElQUiBjbGFpbXMgb2Ygd2hpY2ggSSBhbSBhd2FyZSBoYXZlIGJlZW4gZGlzY2xvc2Vk LCBhbmQgYW55IA0NCiAgICAgICAgIG9mIHdoaWNoIEkgYmVjb21lIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggUkZDIA0NCiAgICAgICAgIDM2NjguIA0NCiAgICAg ICANDQogICAgICAgICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBp biBmdWxsIGNvbmZvcm1hbmNlIHdpdGggDQ0KICAgICAgICAgYWxsIHByb3Zpc2lvbnMgb2YgU2Vj dGlvbiAxMCBvZiBSRkMyMDI2LiBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgDQ0KICAgICAg ICAgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRG KSwgaXRzIGFyZWFzLCANDQogICAgICAgICBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRo YXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgDQ0KICAgICAgICAgd29ya2luZyBk b2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgDQ0KICAgICAgICAgIA0NCiAgICAgICAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg c2l4IG1vbnRocyANDQogICAgICAgICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSANDQogICAgICAgICB0aW1lLiBJdCBp cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC0gRHJhZnRzIGFzIHJlZmVyZW5jZSANDQog ICAgICAgICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iIA0NCiAgICAgICAgICANDQogICAgICAgICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgDQ0KICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiANDQogICAgICAgICAgDQ0KICAgICAgICAg VGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nl c3NlZCBhdCANDQogICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLiANDQog ICAgICAgDQ0KICAgICAgIA0NCiAgICAgICANDQogICAgICAgDQ0KICAgICAgIA0NCiAgICAgICAN DQogICAgICAgDQ0KICAgICAgIA0NCiAgICAgICANDQogICAgICAgDQ0KICAgICAgTWFydGluLCBQ cmV2aWRpLCBOZWFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDFdIA0NCiAgICAgICAgDA0NCiAgICAgICANDQogICAgICBJbnRlcm5ldCBEcmFmdCAgICBk cmFmdC1pZXRmLWlzaXMtYWRtaW4tdGFncy0wMy50eHQgICAgICBGZWJydWFyeSAyMDA1IA0NCg0K ICAgICAgICAgIA0NCiAgICAgIEFic3RyYWN0IA0NCiAgICAgICAgICANDQogICAgICAgICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhbiBleHRlbnNpb24gdG8gdGhlIElTLUlTIHByb3RvY29sIHRv IGFkZCANDQogICAgICAgICBvcGVyYXRpb25hbCBjYXBhYmlsaXRpZXMgdGhhdCBhbGxvdyBmb3Ig ZWFzZSBvZiBtYW5hZ2VtZW50IGFuZCANDQogICAgICAgICBjb250cm9sIG92ZXIgSVAgcHJlZml4 IGRpc3RyaWJ1dGlvbiB3aXRoaW4gYW4gSVMtSVMgZG9tYWluLiBUaGlzIA0NCiAgICAgICAgIGRv Y3VtZW50IGVuaGFuY2VzIHRoZSBJUy1JUyBwcm90b2NvbCBieSBleHRlbmRpbmcgdGhlIGluZm9y bWF0aW9uIA0NCiAgICAgICAgIHRoYXQgYSBJbnRlcm1lZGlhdGUgU3lzdGVtIChJUykgW3JvdXRl cl0gY2FuIHBsYWNlIGluIExpbmsgU3RhdGUgDQ0KICAgICAgICAgUHJvdG9jb2wgRGF0YSBVbml0 cyAoTFNQcykgZm9yIHBvbGljeSB1c2UuIFRoaXMgZXh0ZW5zaW9uIHdpbGwgDQ0KICAgICAgICAg cHJvdmlkZSBvcGVyYXRvcnMgd2l0aCBhIG1lY2hhbmlzbSB0byBjb250cm9sIElQIHByZWZpeCBk aXN0cmlidXRpb24gDQ0KICAgICAgICAgdGhyb3VnaG91dCBtdWx0aS1sZXZlbCBJUy1JUyBkb21h aW5zLiBBZGRpdGlvbmFsbHksIHRoZSBpbmZvcm1hdGlvbiANDQogICAgICAgICBjYW4gYmUgcGxh Y2VkIGluIExTUHMgdGhhdCBoYXZlIFRMVnMgYXMgeWV0IHVuZGVmaW5lZCwgaWYgdGhpcyANDQog ICAgICAgICBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIGNvbnZleSB0aGUgc2FtZSBtZWFuaW5nIGlu IHRoZXNlIGZ1dHVyZSBUTFZzIA0NCiAgICAgICAgIGFzIGl0IGlzIHVzZWQgaW4gdGhlIGN1cnJl bnRseSBkZWZpbmVkIFRMVnMuIA0NCiAgICAgICANDQogICAgICAgDQ0KICAgICAgQ29udmVudGlv bnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IA0NCiAgICAgICANDQogICAgICAgICBUaGUga2V5IHdv cmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIs IA0NCiAgICAgICAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZ IiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyANDQogICAgICAgICBkb2N1bWVudCBhcmUgdG8gYmUg aW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQy0yMTE5LiANDQogICAgICAgDQ0KICAgICAg ICAgIA0NCiAgICAgICANDQogICAgICAxLiBJbnRyb2R1Y3Rpb24gDQ0KICAgICAgICAgIA0KDQ0K ICAgICAgICAgQXMgZGVmaW5lZCBpbiBbMl0gYW5kIGV4dGVuZGVkIGluIFszXSwgdGhlIElTLUlT IHByb3RvY29sIG1heSBiZSB1c2VkIA0NCiAgICAgICAgIHRvIGRpc3RyaWJ1dGUgSVB2NCBwcmVm aXggcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uIHRocm91Z2hvdXQgYW4gSVMtDQ0KICAgICAgICAg SVMgZG9tYWluLiBJbiBhZGRpdGlvbiwgdGhhbmtzIHRvIGV4dGVuc2lvbnMgbWFkZSBpbiBbNl0g YW5kIFs3XSwgSVMtDQ0KICAgICAgICAgSVMgbWF5IGJlIHVzZWQgdG8gZGlzdHJpYnV0ZSBJUHY2 IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbi4gIA0NCiAgICAgICAgICANDQogICAgICAgICAgDQ0K ICAgICAgICAgVGhlIElQdjQgcHJlZml4IGluZm9ybWF0aW9uIGlzIGVuY29kZWQgYXMgVExWIHR5 cGUgMTI4IGFuZCAxMzAgaW4gDQ0KICAgICAgICAgWzJdLCB3aXRoIGFkZGl0aW9uYWwgaW5mb3Jt YXRpb24gY2FycmllZCBpbiBUTFYgMTM1IGFzIHNwZWNpZmllZCBpbiANDQogICAgICAgICBbM10g YW5kIFRMViAyMzUgYXMgZGVmaW5lZCBpbiBbNl0uICBJbiBwYXJ0aWN1bGFyLCB0aGUgZXh0ZW5k ZWQgSVAgDQ0KICAgICAgICAgUmVhY2hhYmlsaXR5IFRMViAoVExWIDEzNSkgY29udGFpbnMgc3Vw cG9ydCBmb3IgYSBsYXJnZXIgbWV0cmljIA0NCiAgICAgICAgIHNwYWNlLCBhbiB1cC9kb3duIGJp dCB0byBpbmRpY2F0ZSByZWRpc3RyaWJ1dGlvbiBiZXR3ZWVuIGRpZmZlcmVudCANDQogICAgICAg ICBsZXZlbHMgaW4gdGhlIGhpZXJhcmNoeSwgYW4gSVAgcHJlZml4LCBhbmQgb25lIG9yIG1vcmUg c3ViLVRMVnMgdGhhdCANDQogICAgICAgICBjYW4gYmUgdXNlZCB0byBjYXJyeSBzcGVjaWZpYyBp bmZvcm1hdGlvbiBhYm91dCB0aGUgcHJlZml4LiBUTFYgMjM1IA0NCiAgICAgICAgIGlzIGEgZGVy aXZhdGl2ZSBvZiBUTFYgMTM1LCB3aXRoIHRoZSBhZGRpdGlvbiBvZiBNdWx0aS1Ub3BvbG9neSAN DQogICAgICAgICBtZW1iZXJzaGlwIGluZm9ybWF0aW9uIFs2XS4gVGhlIElQdjYgcHJlZml4IGlu Zm9ybWF0aW9uIGlzIGVuY29kZWQgYXMgDQ0KICAgICAgICAgVExWIDIzNiBpbiBbN10gYW5kIFRM ViAyMzcgaW4gWzZdLiANDQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCiAgICAgICAgIEFzIG9m IHRoaXMgd3JpdGluZyBubyBzdWItVExWcyBoYXZlIGJlZW4gZGVmaW5lZDsgaG93ZXZlciwgdGhp cyBkcmFmdCANDQogICAgICAgICBwcm9wb3NlcyAyIG5ldyBzdWItVExWcyBmb3IgVExWIDEzNSwg VExWIDIzNSwgVExWIDIzNiBhbmQgVExWIDIzNyANDQogICAgICAgICB0aGF0IG1heSBiZSB1c2Vk IHRvIGNhcnJ5IGFkbWluaXN0cmF0aXZlIGluZm9ybWF0aW9uIGFib3V0IGFuIElQICANDQogICAg ICAgICBwcmVmaXguIA0NCiAgICAgICAgICANDQogICAgICAgICAgDQ0KICAgICAgICAgICANDQog ICAgICAgICAgDQ0KICAgICAgIA0NCiAgICAgIE1hcnRpbiwgUHJldmlkaSwgTmVhbC4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQ0KICAgICAgICAMDQ0K ICAgICAgIA0NCiAgICAgIEludGVybmV0IERyYWZ0ICAgIGRyYWZ0LWlldGYtaXNpcy1hZG1pbi10 YWdzLTAzLnR4dCAgICAgIEZlYnJ1YXJ5IDIwMDUgDQ0KDQogICAgICAgICAgDQ0KICAgICAgMi4g U3ViLVRMViBBZGRpdGlvbnMgDQ0KICAgICAgICAgIA0KDQ0KICAgICAgICAgVGhpcyBkcmFmdCBw cm9wb3NlcyAyIG5ldyAiQWRtaW5pc3RyYXRpdmUgVGFnIiBzdWItVExWcyB0byBiZSBhZGRlZCAN DQogICAgICAgICB0byBUTFYgMTM1LCBUTFYgMjM1LCBUTFYgMjM2IGFuZCBUTFYgMjM3LiAgVGhl c2UgVExWcyBzcGVjaWZ5IG9uZSBvciANDQogICAgICAgICBtb3JlIG9yZGVyZWQsIDMyIG9yIDY0 IGJpdCB1bnNpZ25lZCBpbnRlZ2VycyB0aGF0IG1heSBiZSBhc3NvY2lhdGVkIA0NCiAgICAgICAg IHdpdGggYW4gSVAgcHJlZml4LiBFeGFtcGxlIHVzZXMgb2YgdGhlc2UgdGFncyBpbmNsdWRlIGNv bnRyb2xsaW5nIA0NCiAgICAgICAgIHJlZGlzdHJpYnV0aW9uIGJldHdlZW4gbGV2ZWxzIGFuZCBh cmVhcywgZGlmZmVyZW50IHJvdXRpbmcgcHJvdG9jb2xzLCANDQogICAgICAgICBvciBtdWx0aXBs ZSBpbnN0YW5jZXMgb2YgSVMtSVMgcnVubmluZyBvbiB0aGUgc2FtZSByb3V0ZXIsIG9yIA0NCiAg ICAgICAgIGNhcnJ5aW5nIEJHUCBzdGFuZGFyZCBvciBleHRlbmRlZCBjb21tdW5pdGllcy4gDQ0K ICAgICAgICAgIA0NCiAgICAgICAgICANDQogICAgICAgICBUaGUgbWV0aG9kcyBmb3Igd2hpY2gg dGhlaXIgdXNlIGlzIGVtcGxveWVkIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgDQ0KICAgICAgICAg dGhpcyBkb2N1bWVudCBhbmQgbGVmdCB0byB0aGUgaW1wbGVtZW50ZXIgYW5kL29yIG9wZXJhdG9y LiANDQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCiAgICAgICAgIFRoZSBlbmNvZGluZyBvZiB0 aGUgc3ViLVRMVihzKSBpcyBkaXNjdXNzZWQgaW4gdGhlIGZvbGxvd2luZyANDQogICAgICAgICBz dWJzZWN0aW9ucy4gDQ0KICAgICAgICAgIA0NCiAgICAgICAgICANDQogICAgICAgICAyLjEuIDMy LWJpdCBBZG1pbmlzdHJhdGl2ZSBUYWcgU3ViLVRMViAxIA0NCiAgICAgICAgICANCg0NCiAgICAg ICAgIFRoZSBBZG1pbmlzdHJhdGl2ZSBUYWcgU0hBTEwgYmUgZW5jb2RlZCBhcyBvbmUgb3IgbW9y ZSA0IG9jdGV0IA0NCiAgICAgICAgIHVuc2lnbmVkIGludGVnZXJzIHVzaW5nIFN1Yi1UTFYgMSBp biBUTFYtMTM1IFszXSwgVExWIDIzNSBbNl0sIFRMViANDQogICAgICAgICAyMzYgWzddIGFuZCBU TFYgMjM3IFs2XS4gVGhlIEFkbWluaXN0cmF0aXZlIFRhZyBTdWItVExWIGhhcyBmb2xsb3dpbmcg DQ0KICAgICAgICAgc3RydWN0dXJlOiANDQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCiAgICAg ICAgICAgICAgICAgMSBvY3RldCBvZiB0eXBlICh2YWx1ZTogMSkgDQ0KICAgICAgICAgICAgICAg ICAxIG9jdGV0IG9mIGxlbmd0aCAodmFsdWU6IG11bHRpcGxlIG9mIDQpIA0NCiAgICAgICAgICAg ICAgICAgb25lIG9yIG1vcmUgaW5zdGFuY2VzIG9mIDQgb2N0ZXRzIG9mIGFkbWluaXN0cmF0aXZl IHRhZyANDQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCiAgICAgICAgIEFuIGltcGxlbWVudGF0 aW9uIE1BWSBjb25zaWRlciBvbmx5IG9uZSBvZiB0aGUgZW5jb2RlZCB0YWdzLCBpbiB3aGljaCAN DQogICAgICAgICBjYXNlIHRoZSBmaXJzdCBlbmNvZGVkIHRhZyBNVVNUIGJlIGNvbnNpZGVyZWQu ICBBIHRhZyB2YWx1ZSBvZiB6ZXJvIA0NCiAgICAgICAgIGlzIHJlc2VydmVkIGFuZCBTSE9VTEQg YmUgdHJlYXRlZCBhcyAibm8gdGFnIi4gDQ0KICAgICAgIA0NCiAgICAgICANDQogICAgICAgICAy LjIuIDY0LWJpdCBBZG1pbmlzdHJhdGl2ZSBUYWcgU3ViLVRMViAyIA0NCiAgICAgICAgICANCg0N CiAgICAgICAgIFRoZSBBZG1pbmlzdHJhdGl2ZSBUYWcgU0hBTEwgYmUgZW5jb2RlZCBhcyBvbmUg b3IgbW9yZSA4IG9jdGV0IA0NCiAgICAgICAgIHVuc2lnbmVkIGludGVnZXJzIHVzaW5nIFN1Yi1U TFYgMiBpbiBUTFYtMTM1IFszXSwgVExWIDIzNSBbNl0sIFRMViANDQogICAgICAgICAyMzYgWzdd IGFuZCBUTFYgMjM3IFs2XS4gVGhlIDY0LWJpdCBBZG1pbmlzdHJhdGl2ZSBUYWcgU3ViLVRMViBo YXMgDQ0KICAgICAgICAgZm9sbG93aW5nIHN0cnVjdHVyZTogDQ0KICAgICAgICAgIA0NCiAgICAg ICAgICANDQogICAgICAgICAgICAgICAgIDEgb2N0ZXQgb2YgdHlwZSAodmFsdWU6IDIpIA0NCiAg ICAgICAgICAgICAgICAgMSBvY3RldCBvZiBsZW5ndGggKHZhbHVlOiBtdWx0aXBsZSBvZiA4KSAN DQogICAgICAgICAgICAgICAgIG9uZSBvciBtb3JlIGluc3RhbmNlcyBvZiA4IG9jdGV0cyBvZiBh ZG1pbmlzdHJhdGl2ZSB0YWcgDQ0KICAgICAgICAgIA0NCiAgICAgICAgICANDQoNCiAgICAgICAN DQogICAgICBNYXJ0aW4sIFByZXZpZGksIE5lYWwuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDNdIA0NCiAgICAgICAgDA0NCiAgICAgICANDQogICAgICBJbnRl cm5ldCBEcmFmdCAgICBkcmFmdC1pZXRmLWlzaXMtYWRtaW4tdGFncy0wMy50eHQgICAgICBGZWJy dWFyeSAyMDA1IA0NCg0KICAgICAgICAgQW4gaW1wbGVtZW50YXRpb24gTUFZIGNvbnNpZGVyIG9u bHkgb25lIG9mIHRoZSBlbmNvZGVkIHRhZ3MsIGluIHdoaWNoIA0NCiAgICAgICAgIGNhc2UgdGhl IGZpcnN0IGVuY29kZWQgdGFnIE1VU1QgYmUgY29uc2lkZXJlZC4gIEEgdGFnIHZhbHVlIG9mIHpl cm8gDQ0KICAgICAgICAgaXMgcmVzZXJ2ZWQgYW5kIFNIT1VMRCBiZSB0cmVhdGVkIGFzICJubyB0 YWciLiANDQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCiAgICAgICANDQogICAgICAzLiBPcmRl cmluZyBvZiBUYWdzIA0NCiAgICAgICAgICANCg0NCiAgICAgICAgIFRoZSBzZW1hbnRpY3Mgb2Yg dGhlIHRhZyBvcmRlciBhcmUgaW1wbGVtZW50YXRpb24tZGVwZW5kZW50LiAgVGhhdCANDQogICAg ICAgICBpcywgdGhlcmUgaXMgbm8gaW1wbGllZCBtZWFuaW5nIHRvIHRoZSBvcmRlcmluZyBvZiB0 aGUgdGFncyB0aGF0IA0NCiAgICAgICAgIGluZGljYXRlcyBhIGNlcnRhaW4gb3BlcmF0aW9uIG9y IHNldCBvZiBvcGVyYXRpb25zIG5lZWQgYmUgcGVyZm9ybWVkIA0NCiAgICAgICAgIGJhc2VkIG9u IHRoZSBvcmRlciBvZiB0aGUgdGFncy4gIEVhY2ggdGFnIFNIT1VMRCBiZSB0cmVhdGVkIGFzIGFu IA0NCiAgICAgICAgIGF1dG9ub21vdXMgaWRlbnRpZmllciB0aGF0IE1BWSBiZSB1c2VkIGluIHBv bGljeSB0byBwZXJmb3JtIGEgcG9saWN5IA0NCiAgICAgICAgIGFjdGlvbi4gIFdoZXRoZXIgb3Ig bm90IHRhZyBBIHByZWNlZGVzIG9yIHN1Y2NlZWRzIHRhZyBCIFNIT1VMRCBub3QgDQ0KICAgICAg ICAgY2hhbmdlIHRoZSBtZWFuaW5nIG9mIHRoZSB0YWcgc2V0LiAgSG93ZXZlciwgYW4gaW1wbGVt ZW50YXRpb24gTUFZIA0NCiAgICAgICAgIHdpc2ggdG8gcHJlc2VydmUgdGFnIG9yZGVyaW5nIHN1 Y2ggdGhhdCBhbiBvcmRlcmVkIHNldCBvZiB0YWdzIGhhcyANDQogICAgICAgICBtZWFuaW5nIHRv IHRoZSBsb2NhbCBwb2xpY3kuIA0NCiAgICAgICAgICANDQogICAgICAgICAgDQ0KICAgICAgICAg RWFjaCBJUyB0aGF0IHJlY2VpdmVzIGFuIExTUCB3aXRoIFRMVihzKSAxMzUgYW5kL29yIDIzNSBh bmQvb3IgMjM2IA0NCiAgICAgICAgIGFuZC9vciAyMzcsIHRoYXQgaGF2ZSBhc3NvY2lhdGVkIFN1 YlRMVihzKSAxIGFuZC9vciAyLCBNQVkgb3BlcmF0ZSBvbiANDQogICAgICAgICB0aGUgdGFnIHZh bHVlcyBhcyB3YXJyYW50ZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uLiAgSWYgYW4gDQ0KICAgICAg ICAgaW1wbGVtZW50YXRpb24gbmVlZHMgdG8gY2hhbmdlIHRhZyB2YWx1ZXMsIGZvciBleGFtcGxl LCBhdCBhbiBhcmVhIA0NCiAgICAgICAgIGJvdW5kYXJ5LCB0aGVuIHRoZSBUTFYocykgU0hPVUxE IGJlIGNvcGllZCB0byB0aGUgbmV3bHkgZ2VuZXJhdGVkIA0NCiAgICAgICAgIExldmVsLTEgb3Ig TGV2ZWwtMiBMU1AgYXQgd2hpY2ggcG9pbnQsIHRoZSBjb250ZW50cyBvZiB0aGUgU3ViVExWKHMp IA0NCiAgICAgICAgIE1BWSBjaGFuZ2UgYXMgZGljdGF0ZWQgYnkgdGhlIHBvbGljeSBhY3Rpb24u ICBJbiB0aGUgZXZlbnQgdGhhdCBubyANDQogICAgICAgICBjaGFuZ2UgaXMgcmVxdWlyZWQsIHRo ZSBTdWJUTFYocykgU0hPVUxEIGJlIGNvcGllZCBpbiBvcmRlciBpbnRvIHRoZSANDQogICAgICAg ICBuZXcgTFNQLCBzdWNoIHRoYXQgb3JkZXJpbmcgaXMgcHJlc2VydmVkLiANDQogICAgICAgICAg DQ0KICAgICAgICAgICANDQogICAgICAgDQ0KICAgICAgNC4gQ29tcGxpYW5jZSANDQogICAgICAg DQoNDQogICAgICAgICBBIGNvbXBsaWFudCBJUy1JUyBpbXBsZW1lbnRhdGlvbiBNVVNUIGJlIGFi bGUgdG8gYXNzaWduIG9uZSB0YWcgdG8gDQ0KICAgICAgICAgYW55IElQIHByZWZpeCBpbiBhbnkg b2YgdGhlIGZvbGxvd2luZyBUTFZzOiBUTFYgMTM1LCBUTFYgMjM1LCBUTFYgDQ0KICAgICAgICAg MjM2LCBUTFYgMjM3LiANDQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCiAgICAgICAgIEEgY29t cGxpYW50IElTLUlTIGltcGxlbWVudGF0aW9uIE1BWSBiZSBhYmxlIHRvIGFzc2lnbiBtb3JlIHRo YW4gb25lIA0NCiAgICAgICAgIHRhZyB0byBhbnkgSVAgcHJlZml4IGluIGFueSBvZiB0aGUgZm9s bG93aW5nIFRMVnM6IFRMViAxMzUsIFRMViAyMzUsIA0NCiAgICAgICAgIFRMViAyMzYsIFRMViAy MzcuIA0NCiAgICAgICAgICANDQogICAgICAgICAgDQ0KICAgICAgICAgQSBjb21wbGlhbnQgSVMt SVMgaW1wbGVtZW50YXRpb24gTUFZIGJlIGFibGUgdG8gcmV3cml0ZSBvciByZW1vdmUgb25lIA0N CiAgICAgICAgIG9yIG1vcmUgdGFncyBhc3NvY2lhdGVkIHdpdGggYSBwcmVmaXggaW4gYW55IG9m IHRoZSBmb2xsb3dpbmcgVExWczogDQ0KICAgICAgICAgVExWIDEzNSwgVExWIDIzNSwgVExWIDIz NiwgVExWIDIzNy4gDQ0KICAgICAgICAgIA0NCiAgICAgICANDQogICAgICA1LiBPcGVyYXRpb25z IA0NCiAgICAgICAgICANCg0NCiAgICAgICAgIEFuIGFkbWluaXN0cmF0b3IgYXNzb2NpYXRlcyBh biBBZG1pbmlzdHJhdGl2ZSBUYWcgdmFsdWUgd2l0aCBzb21lIA0NCiAgICAgICAgIGludGVyZXN0 aW5nIHByb3BlcnR5LiAgV2hlbiBJUy1JUyBhZHZlcnRpc2VzIHJlYWNoYWJpbGl0eSBmb3Igc29t ZSBJUCANDQogICAgICAgDQ0KICAgICAgTWFydGluLCBQcmV2aWRpLCBOZWFsLiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA0XSANDQogICAgICAgIAwNDQogICAg ICAgDQ0KICAgICAgSW50ZXJuZXQgRHJhZnQgICAgZHJhZnQtaWV0Zi1pc2lzLWFkbWluLXRhZ3Mt MDMudHh0ICAgICAgRmVicnVhcnkgMjAwNSANDQoNCiAgICAgICAgIHByZWZpeCB0aGF0IGhhcyB0 aGF0IHByb3BlcnR5LCBpdCBhZGRzIHRoZSBBZG1pbmlzdHJhdGl2ZSBUYWcgdG8gdGhlIA0NCiAg ICAgICAgIElQIHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiBUTFYgZm9yIHRoYXQgcHJlZml4LCBh bmQgdGhlIHRhZyAic3RpY2tzIiANDQogICAgICAgICB0byB0aGUgcHJlZml4IGFzIGl0IGlzIGZs b29kZWQgdGhyb3VnaG91dCB0aGUgcm91dGluZyBkb21haW4uIA0NCiAgICAgICAgICANDQogICAg ICAgICAgDQ0KICAgICAgICAgQ29uc2lkZXIgdGhlIG5ldHdvcmsgaW4gZmlndXJlIDEuIFdlIHdp c2ggdG8gImxlYWsiIEwxIHByZWZpeGVzIFs1XSANDQogICAgICAgICB3aXRoIHNvbWUgcHJvcGVy dHksIEEsIGZyb20gTDIgdG8gdGhlIEwxIHJvdXRlciBSMS4gIFdpdGhvdXQgcG9saWN5LQ0NCiAg ICAgICAgIGdyb3VwcywgdGhlcmUgaXMgbm8gd2F5IGZvciBSMiB0byBrbm93IHByb3BlcnR5IEEg cHJlZml4ZXMgZnJvbSANDQogICAgICAgICBwcm9wZXJ0eSBCIHByZWZpeGVzLiANDQogICAgICAg ICAgDQ0KICAgICAgICAgIA0NCiAgICAgICAgICANDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFIyLS0tLS0tLS1SMy0tLS0tLS0tUjQgDQ0KICAgICAgICAgICAgICAgICAgICAgIEwyICAg ICAvICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgIA0NCiAgICAgICAgICAgICAgICAgICAg ICAtIC0gLSAvLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIA0NCiAgICAgICAgICAgICAgICAg ICAgICBMMSAgIC8gICAgICAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgDQ0KICAg ICAgICAgICAgICAgICAgICAgICAgIFIxLS0tLTEuMS4xLjAvMjQgKEEpICAgICAgIFI1IA0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxLjEuMi4wLzI0 IChCKSANDQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCiAgICAgICAgICANDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMSANDQogICAgICAgICAgDQ0KICAgICAg ICAgIA0NCiAgICAgICAgICANDQogICAgICAgICBXZSBhc3NvY2lhdGUgQWRtaW5pc3RyYXRpdmUg VGFnIDEwMCB3aXRoIHByb3BlcnR5IEEsIGFuZCBoYXZlIFI1IA0NCiAgICAgICAgIGF0dGFjaCB0 aGF0IHZhbHVlIHRvIHRoZSBJUCBleHRlbmRlZCByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24gVExW IGZvciANDQogICAgICAgICBwcmVmaXggMS4xLjIuMC8yNC4gUjIgaGFzIGEgcG9saWN5IGluIHBs YWNlIHRvICJtYXRjaCBwcmVmaXhlcyB3aXRoIA0NCiAgICAgICAgIEFkbWluaXN0cmF0aXZlIFRh ZyAxMDAsIGFuZCBsZWFrIHRvIEwxLiIgDQ0KICAgICAgICAgIA0NCiAgICAgICAgICANDQogICAg ICAgICBUaGUgcHJldmlvdXMgZXhhbXBsZSBpcyByYXRoZXIgc2ltcGxpc3RpYzsgaXQgc2VlbXMg dGhhdCBpdCB3b3VsZCBiZSANDQogICAgICAgICBqdXN0IGFzIGVhc3kgZm9yIFIyIHNpbXBseSB0 byBtYXRjaCB0aGUgcHJlZml4IDEuMS4yLjAvMjQuIEhvd2V2ZXIsIA0NCiAgICAgICAgIGlmIHRo ZXJlIGFyZSBhIGxhcmdlIG51bWJlciBvZiByb3V0ZXJzIHRoYXQgbmVlZCB0byBhcHBseSBzb21l IHBvbGljeSANDQogICAgICAgICBhY2NvcmRpbmcgdG8gcHJvcGVydHkgQSBhbmQgbGFyZ2UgbnVt YmVyIG9mICJBIiBwcmVmaXhlcywgdGhpcyANDQogICAgICAgICBtZWNoYW5pc20gY2FuIGJlIHF1 aXRlIGhlbHBmdWwuIA0NCiAgICAgICAgICANDQogICAgICAgICAgDQ0KICAgICAgNi4gU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgDQ0KICAgICAgICAgDQogDQ0KICAgICAgICAgVGhpcyBkb2N1bWVu dCByYWlzZXMgbm8gbmV3IHNlY3VyaXR5IGlzc3VlcyBmb3IgSVMtSVMsIGFzIGFueSANDQogICAg ICAgICBhbm5vdGF0aW9ucyB0byBJUCBwcmVmaXhlcyBzaG91bGQgbm90IHBhc3Mgb3V0c2lkZSB0 aGUgYWRtaW5pc3RyYXRpdmUgDQ0KICAgICAgICAgY29udHJvbCBvZiB0aGUgbmV0d29yayBvcGVy YXRvciBvZiB0aGUgSVMtSVMgZG9tYWluLiAgU3VjaCBhbiANDQogICAgICAgICBhbGxvd2FuY2Ug d291bGQgdmlvbGF0ZSB0aGUgc3Bpcml0IG9mIEludGVyaW9yIEdhdGV3YXkgUHJvdG9jb2xzIGlu IA0NCiAgICAgICAgIGdlbmVyYWwgYW5kIElTLUlTIGluIHBhcnRpY3VsYXIgDQ0KICAgICAgICAg IA0NCiAgICAgICAgICANDQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCg0KICAgICAgIA0NCiAg ICAgIE1hcnRpbiwgUHJldmlkaSwgTmVhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgNV0gDQ0KICAgICAgICAMDQ0KICAgICAgIA0NCiAgICAgIEludGVybmV0 IERyYWZ0ICAgIGRyYWZ0LWlldGYtaXNpcy1hZG1pbi10YWdzLTAzLnR4dCAgICAgIEZlYnJ1YXJ5 IDIwMDUgDQ0KDQogICAgICA3LiBJQU5BIENvbnNpZGVyYXRpb25zIA0NCiAgICAgICAgIA0KIA0N CiAgICAgICAgIFRoZSBhdXRob3JzIGhhdmUgY2hvc2VuICIxIiBhcyB0aGUgdHlwZSBjb2RlIG9m IHRoZSAzMi1iaXRzIA0NCiAgICAgICAgIEFkbWluaXN0cmF0aXZlIFRhZyBTdWItVExWIGFuZCAi MiIgYXMgdGhlIHR5cGUgY29kZSBvZiB0aGUgNjQtYml0cyANDQogICAgICAgICBBZG1pbmlzdHJh dGl2ZSBUYWcgU3ViLVRMVi4gVGhlc2UgdmFsdWVzIG11c3QgYmUgYWxsb2NhdGVkIGJ5IElBTkEu IA0NCiAgICAgICAgICANDQogICAgICAgDQ0KICAgICAgICAgIA0NCiAgICAgIDguIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQgDQ0KICAgICAgICAgDQogDQ0KICAgICAgICAgVGhlIElF VEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBh bnkgDQ0KICAgICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdo dHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvIA0NCiAgICAgICAgIHBlcnRhaW4gdG8gdGhlIGlt cGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gDQ0KICAg ICAgICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVu ZGVyIHN1Y2ggcmlnaHRzIA0NCiAgICAgICAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFi bGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcyANDQogICAgICAgICBtYWRlIGFu eSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiBJbmZvcm1h dGlvbiANDQogICAgICAgICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRz IGluIFJGQyBkb2N1bWVudHMgY2FuIGJlIA0NCiAgICAgICAgIGZvdW5kIGluIEJDUCA3OCBhbmQg QkNQIDc5LiANDQogICAgICAgICAgDQ0KICAgICAgICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJl cyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkgDQ0KICAgICAgICAgYXNzdXJh bmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBh biANDQogICAgICAgICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9y IHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YgDQ0KICAgICAgICAgc3VjaCBwcm9wcmlldGFyeSBy aWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgDQ0KICAgICAgICAgc3BlY2lm aWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0 b3J5IGF0IA0NCiAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiANDQogICAgICAgICAg DQ0KICAgICAgICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmlu ZyB0byBpdHMgYXR0ZW50aW9uIGFueSANDQogICAgICAgICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9y IHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5IA0NCiAgICAgICAgIHJp Z2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGlt cGxlbWVudCANDQogICAgICAgICB0aGlzIHN0YW5kYXJkLiBQbGVhc2UgYWRkcmVzcyB0aGUgaW5m b3JtYXRpb24gdG8gdGhlIElFVEYgYXQgaWV0Zi0gDQ0KICAgICAgICAgaXByQGlldGYub3JnLi4g IA0NCiAgICAgICAgICANDQogICAgICAgICA4LjEuIElQUiBEaXNjbG9zdXJlIEFja25vd2xlZGdl bWVudCANDQogICAgICAgICAgICAgDQoNDQogICAgICAgICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50 ZXJuZXQtRHJhZnQsIEkgY2VydGlmeSB0aGF0IGFueSBhcHBsaWNhYmxlIA0NCiAgICAgICAgIHBh dGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIEkgYW0gYXdhcmUgaGF2ZSBiZWVuIGRp c2Nsb3NlZCwgDQ0KICAgICAgICAgYW5kIGFueSBvZiB3aGljaCBJIGJlY29tZSBhd2FyZSB3aWxs IGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIA0NCiAgICAgICAgIFJGQyAzNjY4LiAN DQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCiAgICAgICAgICANDQogICAgICA5LiBBY2tub3ds ZWRnbWVudHMgDQ0KICAgICAgIA0KDQ0KICAgICAgICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0 byB0aGFuayBIZW5rIFNtaXQgZm9yIGNsYXJpZnlpbmcgdGhlIGJlc3QgDQ0KICAgICAgICAgcGxh Y2UgdG8gZGVzY3JpYmUgdGhpcyBuZXcgaW5mb3JtYXRpb24sIFRvbnkgTGkgYW5kIFRvbnkgUHJ6 eWdpZW5kYSANDQogICAgICAgICBmb3IgdXNlZnVsIGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQsIERh bm55IE1jUGhlcnNvbiBmb3Igc29tZSBtdWNoIA0NCiAgICAgICAgIG5lZWRlZCBmb3JtYXR0aW5n IGFzc2lzdGFuY2UsIGFuZCBNaWtlIFNoYW5kIGZvciB1c2VmdWwgZGlzY3Vzc2lvbnMgDQ0KICAg ICAgICAgb24gZW5jb2Rpbmcgc3RydWN0dXJlIG9mIHRoZSBzdWItVExWLiANDQogICAgICAgICAg DQ0KICAgICAgICAgIA0NCiAgICAgICAgICANDQogICAgICAgICAgDQ0KICAgICAgIA0NCiAgICAg IE1hcnRpbiwgUHJldmlkaSwgTmVhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgNl0gDQ0KICAgICAgICAMDQ0KICAgICAgIA0NCiAgICAgIEludGVybmV0IERy YWZ0ICAgIGRyYWZ0LWlldGYtaXNpcy1hZG1pbi10YWdzLTAzLnR4dCAgICAgIEZlYnJ1YXJ5IDIw MDUgDQ0KDQogICAgICAgICAgDQ0KICAgICAgMTAuIFJlZmVyZW5jZXMgDQ0KICAgICAgIA0KDQ0K ICAgICAgICAgMTAuMS4gTm9ybWF0aXZlIHJlZmVyZW5jZXMgDQ0KICAgICAgIA0KDQ0KICAgICAg ICAgW1JGQ10gQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIGluZGlj YXRlIA0NCiAgICAgICAgIHJlcXVpcmVtZW50cyBsZXZlbHMiLCBSRkMgMjExOSwgTWFyY2ggMTk5 Ny4gDQ0KICAgICAgICAgIA0NCiAgICAgICAgIFtSRkMzNjY3XSBCcmFkbmVyLCBTLiwgIklFVEYg UmlnaHRzIGluIENvbnRyaWJ1dGlvbnMiLCBCQ1AgNzgsIA0NCiAgICAgICAgIFJGQyAzNjY3LCBG ZWJydWFyeSAyMDA0LiANDQogICAgICAgICAgDQ0KICAgICAgICAgW1JGQzM2NjhdIEJyYWRuZXIs IFMuLCBFZC4sICJJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIGluIElFVEYgDQ0KICAgICAg ICAgVGVjaG5vbG9neSIsIEJDUCA3OSwgUkZDIDM2NjgsIEZlYnJ1YXJ5IDIwMDQuIA0NCiAgICAg ICANDQogICAgICAgICBbMV0gIkludGVybWVkaWF0ZSBTeXN0ZW0gdG8gSW50ZXJtZWRpYXRlIFN5 c3RlbSBJbnRyYS1Eb21haW4gUm91dGluZyANDQogICAgICAgICBFeGNoYW5nZSBQcm90b2NvbCAi IElTTyAxMDU4OS4gDQ0KICAgICAgICAgIA0NCiAgICAgICAgIFsyXSBDYWxsb24sIFIuLCAiVXNl IG9mIE9TSSBJUy1JUyBmb3Igcm91dGluZyBpbiBUQ1AvSVAgYW5kIGR1YWwgDQ0KICAgICAgICAg ZW52aXJvbm1lbnRzIiwgUkZDIDExOTUsIERlY2VtYmVyIDE5OTAuICANDQogICAgICAgDQ0KICAg ICAgICAgWzNdIExpLCBULiwgU21pdCwgSC4sICJJUy1JUyBleHRlbnNpb25zIGZvciBUcmFmZmlj IEVuZ2luZWVyaW5nIiwgUkZDIA0NCiAgICAgICAgIDM3ODQsIEp1bmUgMjAwNC4gDQ0KICAgICAg ICAgIA0NCiAgICAgICAgIFs0XSBBZHd1Y2hlLCBELiwgTWFsY29sbSwgSi4sIEFnb2didWEsIE0u LCBPJ0RlbGwsIE0uIGFuZCBNY01hbnVzLCANDQogICAgICAgICBKLiwgIlJlcXVpcmVtZW50cyBm b3IgVHJhZmZpYyBFbmdpbmVlcmluZyBPdmVyIE1QTFMsIiBSRkMgMjcwMiwgDQ0KICAgICAgICAg U2VwdGVtYmVyIDE5OTkuIA0NCiAgICAgICAgICANDQogICAgICAgICBbNV0gTGksVC4sIFByenln aWVuZGEsIFQuLCBTbWl0LCBILiwgIkRvbWFpbi13aWRlIFByZWZpeCBEaXN0cmlidXRpb24gDQ0K ICAgICAgICAgd2l0aCBUd28tTGV2ZWwgSVMtSVMiIFJGQyAyOTY2LCBPY3RvYmVyIDIwMDAgDQ0K ICAgICAgICAgIA0NCiAgICAgICAgIDEwLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgDQ0KICAg ICAgICAgIA0KDQ0KICAgICAgICAgWzZdIFByenlnaWVuZGEsIFQuLCBTaGVuLCBOLiwgU2hldGgs IE4uLCAiTS1JU0lTOiBNdWx0aSBUb3BvbG9neSANDQogICAgICAgICBSb3V0aW5nIGluIElTLUlT IiwgZHJhZnQtaWV0Zi1pc2lzLXdnLW11bHRpLXRvcG9sb2d5LTAzLnR4dCwgQXByaWwgDQ0KICAg ICAgICAgMjAwMi4gDQ0KICAgICAgIA0NCiAgICAgICAgIFs3XSBIb3BwcywgQy4sICJSb3V0aW5n IElQdjYgd2l0aCBJUy1JUyIsIGRyYWZ0LWlldGYtaXNpcy1pcHY2LQ0NCiAgICAgICAgIDA1LnR4 dCwgSmFudWFyeSAyMDAzIA0NCiAgICAgICANDQogICAgICAgDQ0KICAgICAgIA0NCiAgICAgICAN DQogICAgICAgDQ0KICAgICAgIA0NCiAgICAgIDExLiBFZGl0b3JzJyBBZGRyZXNzICANDQogICAg ICAgICAgIA0KDQ0KICAgICAgICAgIENocmlzdGlhbiBNYXJ0aW4gDQ0KICAgICAgICAgIFZlcml6 b24gDQ0KICAgICAgICAgIDE4ODAgQ2FtcHVzIENvbW1vbnMgRHIgDQ0KICAgICAgICAgIFJlc3Rv biwgVkEgMjAxOTEgDQ0KICAgICAgICAgIEVtYWlsOiBjbWFydGluQHZlcml6b24uY29tIA0NCiAg ICAgICAgICANDQogICAgICAgDQ0KICAgICAgTWFydGluLCBQcmV2aWRpLCBOZWFsLiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3XSANDQogICAgICAgIAwNDQog ICAgICAgDQ0KICAgICAgSW50ZXJuZXQgRHJhZnQgICAgZHJhZnQtaWV0Zi1pc2lzLWFkbWluLXRh Z3MtMDMudHh0ICAgICAgRmVicnVhcnkgMjAwNSANDQoNCiAgICAgICAgICANDQogICAgICAgICAg U3RlZmFubyBQcmV2aWRpIA0NCiAgICAgICAgICBDaXNjbyBTeXN0ZW1zLCBJbmMuIA0NCiAgICAg ICAgICBWaWEgRGVsIFNlcmFmaWNvLCAyMDAgDQ0KICAgICAgICAgIDAwMTQyIFJvbWEgLSBJdGFs eSANDQogICAgICAgICAgZW1haWw6IHNwcmV2aWRpQGNpc2NvLmNvbSANDQogICAgICAgICAgDQ0K ICAgICAgICAgIA0NCiAgICAgICAgICBCcmFkIE5lYWwgDQ0KICAgICAgICAgIEJyb2Fkd2luZyBD b21tdW5pY2F0aW9ucyANDQogICAgICAgICAgMTgzNSBLcmFtZXIgTGFuZSAtIFN1aXRlIDEwMCAN DQogICAgICAgICAgQXVzdGluLCBUWCA3ODc1OCANDQogICAgICAgICAgVVNBIA0NCiAgICAgICAg ICBFbWFpbDogYm5lYWxAYnJvYWR3aW5nLmNvbSANDQogICAgICAgICAgIA0NCiAgICAgIEZ1bGwg Q29weXJpZ2h0IFN0YXRlbWVudCANDQogICAgICAgDQ0KICAgICAgQ29weXJpZ2h0IChDKSBUaGUg SW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gDQ0K ICAgICAgdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4g QkNQIDc4LCBhbmQgZXhjZXB0IGFzIA0NCiAgICAgIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0 aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4gDQ0KICAgICAgICAgIA0NCiAgICAgIFRoaXMg ZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRl ZCBvbiBhbiAgIA0NCiAgICAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhF IE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUyBPUiANDQogICAgICBJUyBTUE9OU09SRUQg QlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgDQ0KICAg ICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVT UyBPUiBJTVBMSUVELCANDQogICAgICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBX QVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFIA0NCiAgICAgIElORk9STUFUSU9OIEhFUkVJTiBX SUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIA0NCiAgICAgIFdBUlJB TlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ T1NFLiANDQogICAgICAgICAgDQ0KICAgICAgICAgIA0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICAgIA0NCiAgICAgIE1hcnRpbiwgUHJldmlkaSwgTmVh bC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0gDQ0KICAg ICAgICAM ------_=_NextPart_001_01C5104F.5EBE1124 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg ------_=_NextPart_001_01C5104F.5EBE1124-- From isis-wg-bounces@ietf.org Fri Feb 11 16:40:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23634 for ; Fri, 11 Feb 2005 16:39:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czi12-0005XV-RR; Fri, 11 Feb 2005 16:07:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzhR6-00029o-RR; Fri, 11 Feb 2005 15:30:44 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06008; Fri, 11 Feb 2005 15:30:43 -0500 (EST) Message-Id: <200502112030.PAA06008@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 11 Feb 2005 15:30:43 -0500 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-admin-tags-03.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 : A Policy Control Mechanism is IS-IS Using Administrative Tags Author(s) : C. Martin, et al. Filename : draft-ietf-isis-admin-tags-03.txt Pages : 8 Date : 2005-2-11 This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs) for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. Additionally, the information can be placed in LSPs that have TLVs as yet undefined, if this information is used to convey the same meaning in these future TLVs as it is used in the currently defined TLVs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.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-admin-tags-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-admin-tags-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-11154057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-admin-tags-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-admin-tags-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-11154057.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From Hessbsgq@norcov.com Fri Feb 11 18:10:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09815; Fri, 11 Feb 2005 18:10:19 -0500 (EST) Received: from [219.251.172.83] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzkFn-0002Ti-2C; Fri, 11 Feb 2005 18:31:21 -0500 Received: from homily.bangkok.com ([66.33.212.137]) by decline.owt.com (InterMail vK.4.04.00.00 583-428-466 license 8od910gq0871f7ki0m8zka4321s9bgz9) with ESMTP id <41653068121518.ZKYQ957.blab@homily.bangkok.com> for ; Sat, 12 Feb 2005 03:07:50 +0400 Received: from noisy ([81.169.173.239]) by homily.bangkok.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 12 2000)) with ESMTPA id for avt@ietf.org; Fri, 11 Feb 2005 18:06:50 -0500 (IDT) Date: Fri, 11 Feb 2005 22:06:50 -0100 From: "Diane Foreman" To: "Avt" Subject: GQ magazine : Do you need a friend Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_589_0951_12D0UMSU.Z03Z6958" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Spam-Score: 21.3 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_589_0951_12D0UMSU.Z03Z6958 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit




Goodbye




hildebrand distributivecomic neuron argivefoxhole arson balustradeabrasion cartographer humptydiscovery gerundial cataractborg sail ildominion swabby caterpillareldest incredulous elaboratetess bundestag thyroxinesclerotic ------=_NextPart_589_0951_12D0UMSU.Z03Z6958 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable




Goodbye=




principal emigratecinder psychosis bywordhertz sciatica dunecatalytic nodule chemicgalvanic blackbird linkagemillennia demon caucasianfaa reserve caterairlock callaghan abigailbarbarian dastard arremoval ------=_NextPart_589_0951_12D0UMSU.Z03Z6958-- From isis-wg-bounces@ietf.org Mon Feb 14 06:00:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16108 for ; Mon, 14 Feb 2005 06:00:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0dvb-0005SV-5K; Mon, 14 Feb 2005 05:58:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0dp5-0004th-TA for isis-wg@megatron.ietf.org; Mon, 14 Feb 2005 05:51:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13950 for ; Mon, 14 Feb 2005 05:51:21 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0e9t-0006WQ-Rp for isis-wg@ietf.org; Mon, 14 Feb 2005 06:12:55 -0500 Received: by rproxy.gmail.com with SMTP id a41so623754rng for ; Mon, 14 Feb 2005 02:51:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=roMoxVh+/neKwm7YbHH4+f+5+bdX1/k3dGS6BAtXDgHqXhU1ZACXO6SrLzBE7teQFjwr2cRm2oZNjNTgzbIYrQ6AvjGIU2D7DcunMQn/3A+/JLqpc9mJ2AIHZSGjvilfLm0fEOMbkBd5G64sFwuD5lbOO4N11ST+oQUqjE8jJ8c= Received: by 10.38.73.5 with SMTP id v5mr110772rna; Mon, 14 Feb 2005 02:51:21 -0800 (PST) Received: by 10.38.102.22 with HTTP; Mon, 14 Feb 2005 02:51:21 -0800 (PST) Message-ID: Date: Mon, 14 Feb 2005 16:21:21 +0530 From: Abhishek Verma To: "ISIS-WG (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Zero Cost links in ISIS X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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 Content-Transfer-Encoding: 7bit Hi, When we advertise an interface using the extended IP Reach TLV the cost is by default 10. So why is it that we advertise our loopbacks with a cost of 0? As i understand, because of the nature of ISO addressing all the ISIS routers end up as nodes in the SPF tree, and all IP reachability information is attached as leaves to that tree. Now, if an IP interface goes down i will not see a neighbor anymore. So, i will remove it from my LSP and announce this to my neighbors. I will also remove this information from my IP reachability TLV info. Now the recieving routers will need to run the *full* SPF when they recieve this LSP as the topology has changed. SO why do we say that in ISIS if IP reachability changes then other ISIS routers dont need to run their full SPFs (as compared to OSPFv2). I am confused because whenever IP reachability changes (route goes up/down) the topology would always get affected. I know i am missing something. Would someone be good enough to point that out? Thanks a lot, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Feb 14 14:28:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04813 for ; Mon, 14 Feb 2005 14:28:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0lpM-0001HX-CT; Mon, 14 Feb 2005 14:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0lm1-0000g5-CT for isis-wg@megatron.ietf.org; Mon, 14 Feb 2005 14:20:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04049 for ; Mon, 14 Feb 2005 14:20:43 -0500 (EST) Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0m6t-0001ip-Hb for isis-wg@ietf.org; Mon, 14 Feb 2005 14:42:20 -0500 Received: from dgoodspeedpc ([172.22.184.130] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Feb 2005 11:20:08 -0800 From: "Don Goodspeed" To: "'Abhishek Verma'" , "'ISIS-WG \(E-mail\)'" Subject: RE: [Isis-wg] Zero Cost links in ISIS Date: Mon, 14 Feb 2005 11:20:05 -0800 Message-ID: <002301c512ca$31438710$f703a8c0@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-OriginalArrivalTime: 14 Feb 2005 19:20:08.0907 (UTC) FILETIME=[3273C9B0:01C512CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Don.Goodspeed@alcatel.com 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 Content-Transfer-Encoding: 7bit Abhishek, You are asking questions regarding one ISIS implementation that do not necessarily apply to all vendor's implementations. As such you will need to ask that specific vendor for the answers as to why they do these particular actions. Thanks, Don -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Abhishek Verma Sent: Monday, February 14, 2005 2:51 AM To: ISIS-WG (E-mail) Subject: [Isis-wg] Zero Cost links in ISIS Hi, When we advertise an interface using the extended IP Reach TLV the cost is by default 10. So why is it that we advertise our loopbacks with a cost of 0? As i understand, because of the nature of ISO addressing all the ISIS routers end up as nodes in the SPF tree, and all IP reachability information is attached as leaves to that tree. Now, if an IP interface goes down i will not see a neighbor anymore. So, i will remove it from my LSP and announce this to my neighbors. I will also remove this information from my IP reachability TLV info. Now the recieving routers will need to run the *full* SPF when they recieve this LSP as the topology has changed. SO why do we say that in ISIS if IP reachability changes then other ISIS routers dont need to run their full SPFs (as compared to OSPFv2). I am confused because whenever IP reachability changes (route goes up/down) the topology would always get affected. I know i am missing something. Would someone be good enough to point that out? Thanks a lot, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ 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 Santiagokezuw@louisa.net Tue Feb 15 02:59:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03158; Tue, 15 Feb 2005 02:59:16 -0500 (EST) Received: from [211.232.51.207] (helo=211-232-51-207.intertns.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D0xx4-0005dw-8g; Tue, 15 Feb 2005 03:21:00 -0500 Received: from flagfootballplayer.com ([81.171.8.137]) by invocate.chinese.net.my (InterMail vK.4.04.00.00 832-547-337 license 3ud880yr8608b5tt8k8rzs4477i5tnv0) with ESMTP id <27929488964400.WAGR162.superfluous@flagfootballplayer.com> for ; Tue, 15 Feb 2005 10:53:36 +0300 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 15 Feb 2005 09:57:36 +0200 Received: from 205.158.62.105 by cohesion.barkeep.hotmail.msn.com with HTTP; Tue, 15 Feb 2005 02:56:36 -0500 GMT X-Originating-IP: [203.86.166.44] X-Originating-Email: [kong@flagfootballplayer.com] From: "Kate Hinkle" To: hc@ietf.org Subject: GQ magazine : Don't you need a companion Date: Tue, 15 Feb 2005 02:01:36 -0600 Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: Tue, 15 Feb 2005 00:57:36 -0700 (UTC) FILETIME=[9S6E[3 X-Spam-Score: 8.2 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Content-Transfer-Encoding: quoted-printable From isis-wg-bounces@ietf.org Tue Feb 15 15:10:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04778 for ; Tue, 15 Feb 2005 15:10:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18dQ-0005NR-M9; Tue, 15 Feb 2005 14:45:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D17kH-00065x-S3 for isis-wg@megatron.ietf.org; Tue, 15 Feb 2005 13:48:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15696 for ; Tue, 15 Feb 2005 13:48:24 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D185L-0002IZ-SV for isis-wg@ietf.org; Tue, 15 Feb 2005 14:10:14 -0500 Received: by rproxy.gmail.com with SMTP id a41so897482rng for ; Tue, 15 Feb 2005 10:48:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=J19dGZz0091YxjRxLQ+SKJCNuMzqwJQ5YEojPQdGV+KXmBqCPtU2u3Hns+Q6gozbgeyDrK8Uuk376muap+n75Z8YzlxbArmlelKMNSZJQlToYMiGsGpKtuzWZ56eUp6Nws5Hzu7c0J/JEtgjzdzmnLGbH4ZgF4mvBdj9dh+ME+4= Received: by 10.38.68.14 with SMTP id q14mr68310rna; Tue, 15 Feb 2005 10:48:19 -0800 (PST) Received: by 10.38.102.22 with HTTP; Tue, 15 Feb 2005 10:48:18 -0800 (PST) Message-ID: Date: Wed, 16 Feb 2005 00:18:18 +0530 From: Abhishek Verma To: "ISIS-WG (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Normal and Ext Reach TLVs X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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 Content-Transfer-Encoding: 7bit Hi, What should a router that is configured for TE extensions (i.e. the one that can understand extended metrics) do when it recieves an LSP with both the normal and extended IP reachability TLVs. I am talking of the case when all IP reachability information is repeated twice. Once in the normal reachability TLV and the second time in the extended TLV. Should we process just the extended TLVs. I guess so. Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Feb 15 16:01:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11722 for ; Tue, 15 Feb 2005 16:01:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D19ma-0001lM-Gr; Tue, 15 Feb 2005 15:58:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D19jJ-0000bw-ET for isis-wg@megatron.ietf.org; Tue, 15 Feb 2005 15:55:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11177 for ; Tue, 15 Feb 2005 15:55:31 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1A4N-0001NJ-7M for isis-wg@ietf.org; Tue, 15 Feb 2005 16:17:22 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.32 ; Tue, 15 Feb 2005 15:54:57 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Feb 2005 15:54:57 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.180 140.233.20.180 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 15 Feb 2005 15:54:56 -0500 Subject: Re: [Isis-wg] Normal and Ext Reach TLVs From: "Parker, Jeff" To: Abhishek Verma , "ISIS-WG (E-mail)" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Feb 2005 20:54:57.0001 (UTC) FILETIME=[9B3BCD90:01C513A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Content-Transfer-Encoding: 7bit Abhishek - I believe we tried to cover this in the interoperability documents, RFC 3787 in section 5. Most people who liked this document also purchased a copy of RFC 3719. - jeff parker On 2/15/05 1:48 PM, "Abhishek Verma" wrote: > Hi, > > What should a router that is configured for TE extensions (i.e. the > one that can understand extended metrics) do when it recieves an LSP > with both the normal and extended IP reachability TLVs. > > I am talking of the case when all IP reachability information is > repeated twice. Once in the normal reachability TLV and the second > time in the extended TLV. > > Should we process just the extended TLVs. I guess so. > > Thanks, > Abhishek > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India > > _______________________________________________ > 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 Feb 15 18:01:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24187 for ; Tue, 15 Feb 2005 18:01:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1BfZ-00035b-Nr; Tue, 15 Feb 2005 17:59:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1BaN-0001Od-U0 for isis-wg@megatron.ietf.org; Tue, 15 Feb 2005 17:54:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23607 for ; Tue, 15 Feb 2005 17:54:25 -0500 (EST) Received: from web25403.mail.ukl.yahoo.com ([217.12.10.137]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1BvS-0004Tf-Th for isis-wg@ietf.org; Tue, 15 Feb 2005 18:16:18 -0500 Received: (qmail 13074 invoked by uid 60001); 15 Feb 2005 22:53:52 -0000 Message-ID: <20050215225352.13072.qmail@web25403.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25403.mail.ukl.yahoo.com via HTTP; Tue, 15 Feb 2005 22:53:52 GMT Date: Tue, 15 Feb 2005 22:53:52 +0000 (GMT) From: "Sugar, Sylvia" To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit Subject: [Isis-wg] CSPF 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 Content-Transfer-Encoding: 8bit Hi, I am new to ISIS TE and i have a doubt here. We use SPF to calculate our topology and to install routes in FIB. When ISIS TE is used we run CSPF in addition to our ordinary SPF. The result of the SPF is used in updating the FIB (as usual) while results of the CSPF are fed into the MPLS modules for them to select the best paths. Is my understand correct? CSPF in no way can affect the routes that i install in my kernel. Thanks, Sylvia ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Feb 15 23:36:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15800 for ; Tue, 15 Feb 2005 23:36:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Gpy-0007so-V9; Tue, 15 Feb 2005 23:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Git-0005YI-O5 for isis-wg@megatron.ietf.org; Tue, 15 Feb 2005 23:23:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14217 for ; Tue, 15 Feb 2005 23:23:32 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1H42-0005ks-NC for isis-wg@ietf.org; Tue, 15 Feb 2005 23:45:28 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IBZ00EM1LIMIV@szxga03-in.huawei.com> for isis-wg@ietf.org; Wed, 16 Feb 2005 12:23:10 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IBZ00DUDLIMAB@szxga03-in.huawei.com> for isis-wg@ietf.org; Wed, 16 Feb 2005 12:23:10 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IBZ00AOCLL5VY@szxml02-in.huawei.com>; Wed, 16 Feb 2005 12:24:42 +0800 (CST) Date: Wed, 16 Feb 2005 09:52:33 +0530 From: hemanthbs Subject: RE: [Isis-wg] CSPF In-reply-to: <20050215225352.13072.qmail@web25403.mail.ukl.yahoo.com> To: "'Sugar, Sylvia'" , isis-wg@ietf.org Message-id: <001f01c513df$238bb3c0$7204120a@in.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7BIT X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@huawei.com 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 Content-Transfer-Encoding: 7BIT Hi Sylvia, CSPF can be thought of as a separate module. In TE , an IGP's ( ISIS/OSPF) role is just to transport all the TE parameters. Its normal route calculation still remains the same. CSPF will use the ISIS flooded TE information to build its own TEDB( Traffic engineering database) and compute the constraint based routes. This computed route will then be used by some MPLS TE signaling protocol like RSVP-TE or CR-LDP to setup the TE lsp (TE tunnel). Bye Hemanth S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of Sugar, Sylvia Sent: Wednesday, February 16, 2005 4:24 AM To: isis-wg@ietf.org Subject: [Isis-wg] CSPF Hi, I am new to ISIS TE and i have a doubt here. We use SPF to calculate our topology and to install routes in FIB. When ISIS TE is used we run CSPF in addition to our ordinary SPF. The result of the SPF is used in updating the FIB (as usual) while results of the CSPF are fed into the MPLS modules for them to select the best paths. Is my understand correct? CSPF in no way can affect the routes that i install in my kernel. Thanks, Sylvia ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.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 Wed Feb 16 14:53:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11246 for ; Wed, 16 Feb 2005 14:53:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1TgL-00019I-37; Wed, 16 Feb 2005 13:13:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1SPi-0002ws-3k for isis-wg@megatron.ietf.org; Wed, 16 Feb 2005 11:52:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19848 for ; Wed, 16 Feb 2005 11:52:30 -0500 (EST) 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.33) id 1D1Sky-0007ci-9I for isis-wg@ietf.org; Wed, 16 Feb 2005 12:14:33 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 83A723DCCAD; Wed, 16 Feb 2005 08:51:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <64df796eb52f3fb1aa8fbe4fd7a7ecef@rawdofmt.org> Content-Transfer-Encoding: 7bit From: Christian Hopps Date: Wed, 16 Feb 2005 08:52:00 -0800 To: ISIS-WG (E-mail) X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: David D Ward Subject: [Isis-wg] Agenda Items for next IETF 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 Content-Transfer-Encoding: 7bit Please submit requests for agenda time slots for the upcoming IETF isiswg meeting. Seeing as we didn't have an isiswg meeting last IETF, we plan to at least hold one this time with a status update. Chris & Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Feb 17 04:42:52 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29482 for ; Thu, 17 Feb 2005 04:42:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hzq-0002wK-13; Thu, 17 Feb 2005 04:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hvh-0001Jm-Db for isis-wg@megatron.ietf.org; Thu, 17 Feb 2005 04:26:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28025 for ; Thu, 17 Feb 2005 04:26:35 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1iH6-00057l-V7 for Isis-wg@ietf.org; Thu, 17 Feb 2005 04:48:46 -0500 Received: from bzq-25-80-121.cust.bezeqint.net ([212.25.80.121] helo=tvril-mr01) by mx2.foretec.com with smtp (Exim 4.24) id 1D1huM-0008HC-2K for Isis-wg@ietf.org; Thu, 17 Feb 2005 04:26:34 -0500 Received: From VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by tvril-mr01 (WebShield SMTP v4.5 MR1a P0803.345); id 1108631966968; Thu, 17 Feb 2005 11:19:26 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 17 Feb 2005 11:22:32 +0200 Message-ID: <52F6342A567975489F83368EB54C0D7D069E82@VRZIL-EX01.il.veraznetworks.com> Thread-Topic: Interfaces that configured to run IS-IS L1. Thread-Index: AcUU0XcZWq59OSpHQhW/RK3LQaIrjQ== From: "Yossi Boaron" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Isis-wg] Interfaces that configured to run IS-IS L1. 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="===============0819230683==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============0819230683== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C514D2.35D7220A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C514D2.35D7220A Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi everybody I have a router with 4 interfaces. The router configuration is described below :=20 1. interface#1 runs ISIS level 1 2. interface#2 runs ISIS level 1 3. interface#3 isn't running ISIS , but 'passivecircuit' is true . 4. interface#4 isn't running ISIS , and 'passivecircuit' is false(means = don't include this interface in the LSP advertisement). Which kind(Hello,LSP,Sequence number) of packets will be sent and = received on each of the interfaces? I think that : Interface#1 will send and receive L1 Hellos, L1 LSPs, and L1 sequence = number. Interface#2 will send and receive L1 Hellos, L1 LSPs, and L1 sequence = number. Interface#3 will not send neither receive any ISIS packet (including = flooding). Interface#3 will not send neither receive any ISIS packet (including = flooding). Am I correct? Yossi ------_=_NextPart_001_01C514D2.35D7220A Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Interfaces that configured to run IS-IS L1.

Hi everybody

I have a router with 4 = interfaces.

The router configuration is = described below :

1. interface#1 runs ISIS = level 1

2. interface#2 runs ISIS = level 1

3. interface#3 isn't running = ISIS , but 'passivecircuit'  is true .

4. interface#4 isn't running = ISIS , and 'passivecircuit'  is false(means don't include this = interface in        the LSP = advertisement).


Which kind(Hello,LSP,Sequence = number) of packets will be sent and received on each of the = interfaces?

I think that :

Interface#1 will send and = receive L1 Hellos, L1 LSPs, and L1 sequence number.

Interface#2 will send and = receive L1 Hellos, L1 LSPs, and L1 sequence number.

Interface#3 will not send = neither receive any ISIS packet (including flooding).

Interface#3 will not send = neither receive any ISIS packet (including flooding).

Am  I = correct?

Yossi

------_=_NextPart_001_01C514D2.35D7220A-- --===============0819230683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0819230683==-- From isis-wg-bounces@ietf.org Thu Feb 17 05:13:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02059 for ; Thu, 17 Feb 2005 05:13:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ics-0000VU-KI; Thu, 17 Feb 2005 05:11:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1iZk-0007VV-5B for isis-wg@megatron.ietf.org; Thu, 17 Feb 2005 05:08:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01765 for ; Thu, 17 Feb 2005 05:07:58 -0500 (EST) Received: from bzq-25-80-121.cust.bezeqint.net ([212.25.80.121] helo=tvril-mr01) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1iui-00065b-JE for Isis-wg@ietf.org; Thu, 17 Feb 2005 05:30:09 -0500 Received: From VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by tvril-mr01 (WebShield SMTP v4.5 MR1a P0803.345); id 1108634848796; Thu, 17 Feb 2005 12:07:28 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 17 Feb 2005 12:02:05 +0200 Message-ID: <52F6342A567975489F83368EB54C0D7D069E86@VRZIL-EX01.il.veraznetworks.com> Thread-Topic: Interfaces that configured to run IS-IS L1. Thread-Index: AcUU1v2CtWwO626KRVGromJvofjZCA== From: "Yossi Boaron" To: "Yossi Boaron" , X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Isis-wg] Interfaces that configured to run IS-IS L1. 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="===============1967480606==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1967480606== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C514D7.BC38A922" This is a multi-part message in MIME format. ------_=_NextPart_001_01C514D7.BC38A922 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi everybody I have a router with 4 interfaces. The router configuration is described below :=20 1. interface#1 runs ISIS level 1 2. interface#2 runs ISIS level 1 3. interface#3 isn't running ISIS , but 'passivecircuit' is true . 4. interface#4 isn't running ISIS , and 'passivecircuit' is false(means = don't include this interface in the LSP advertisement). Which kind(Hello,LSP,Sequence number) of packets will be sent and = received on each of the interfaces? I think that : Interface#1 will send and receive L1 Hellos, L1 LSPs, and L1 sequence = number. Interface#2 will send and receive L1 Hellos, L1 LSPs, and L1 sequence = number. Interface#3 will not send neither receive any ISIS packet (including = flooding). Interface#3 will not send neither receive any ISIS packet (including = flooding). Am I correct? Yossi ------_=_NextPart_001_01C514D7.BC38A922 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Interfaces that configured to run IS-IS L1.

Hi everybody

I have a router with 4 = interfaces.

The router configuration is = described below :

1. interface#1 runs ISIS = level 1

2. interface#2 runs ISIS = level 1

3. interface#3 isn't running = ISIS , but 'passivecircuit'  is true .

4. interface#4 isn't running = ISIS , and 'passivecircuit'  is false(means don't include this = interface in        the LSP = advertisement).


Which kind(Hello,LSP,Sequence = number) of packets will be sent and received on each of the = interfaces?

I think that :

Interface#1 will send and = receive L1 Hellos, L1 LSPs, and L1 sequence number.

Interface#2 will send and = receive L1 Hellos, L1 LSPs, and L1 sequence number.

Interface#3 will not send = neither receive any ISIS packet (including flooding).

Interface#3 will not send = neither receive any ISIS packet (including flooding).

Am  I = correct?

Yossi

------_=_NextPart_001_01C514D7.BC38A922-- --===============1967480606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1967480606==-- From isis-wg-bounces@ietf.org Thu Feb 17 05:15:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02312 for ; Thu, 17 Feb 2005 05:15:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ict-0000W5-Hx; Thu, 17 Feb 2005 05:11:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1iZg-0007VE-R7 for isis-wg@megatron.ietf.org; Thu, 17 Feb 2005 05:07:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01761 for ; Thu, 17 Feb 2005 05:07:55 -0500 (EST) Received: from bzq-25-80-121.cust.bezeqint.net ([212.25.80.121] helo=tvril-mr01) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1iui-00065a-DZ for isis-wg@ietf.org; Thu, 17 Feb 2005 05:30:06 -0500 Received: From VRZIL-EX01.il.veraznetworks.com ([172.29.1.6]) by tvril-mr01 (WebShield SMTP v4.5 MR1a P0803.345); id 1108634848750; Thu, 17 Feb 2005 12:07:28 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 17 Feb 2005 11:45:02 +0200 Message-ID: <52F6342A567975489F83368EB54C0D7D069E85@VRZIL-EX01.il.veraznetworks.com> Thread-Topic: Interfaces that configured to run IS-IS Thread-Index: AcUU1JtbEX6sA8PDT5Ccsfbk2uERnQ== From: "Yossi Boaron" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Isis-wg] Interfaces that configured to run 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: , Content-Type: multipart/mixed; boundary="===============1054859959==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1054859959== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C514D5.5A10BA84" This is a multi-part message in MIME format. ------_=_NextPart_001_01C514D5.5A10BA84 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi everybody I have a router with 4 interfaces. The router configuration is described below :=20 1. interface#1 runs ISIS level 1 2. interface#2 runs ISIS level 1 3. interface#3 isn't running ISIS , but 'passivecircuit' is true . 4. interface#4 isn't running ISIS , and 'passivecircuit' is false(means = don't include this interface in the LSP advertisement). Which kind(Hello,LSP,Sequence number) of packets will be sent and = received on each of the interfaces? I think that : Interface#1 will send and receive L1 Hellos, L1 LSPs, and L1 sequence = number. Interface#2 will send and receive L1 Hellos, L1 LSPs, and L1 sequence = number. Interface#3 will not send neither receive any ISIS packet (including = flooding). Interface#3 will not send neither receive any ISIS packet (including = flooding). Am I correct? Yossi ------_=_NextPart_001_01C514D5.5A10BA84 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Interfaces that configured to run IS-IS

Hi everybody

I have a router with 4 = interfaces.

The router configuration is = described below :

1. interface#1 runs ISIS = level 1

2. interface#2 runs ISIS = level 1

3. interface#3 isn't running = ISIS , but 'passivecircuit'  is true .

4. interface#4 isn't running = ISIS , and 'passivecircuit'  is false(means don't include this = interface in        the LSP = advertisement).


Which kind(Hello,LSP,Sequence = number) of packets will be sent and received on each of the = interfaces?

I think that :

Interface#1 will send and = receive L1 Hellos, L1 LSPs, and L1 sequence number.

Interface#2 will send and = receive L1 Hellos, L1 LSPs, and L1 sequence number.

Interface#3 will not send = neither receive any ISIS packet (including flooding).

Interface#3 will not send = neither receive any ISIS packet (including flooding).

Am  I = correct?

Yossi

------_=_NextPart_001_01C514D5.5A10BA84-- --===============1054859959== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1054859959==-- From isis-wg-bounces@ietf.org Thu Feb 17 15:28:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01551 for ; Thu, 17 Feb 2005 15:28:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qZO-0006kr-DS; Thu, 17 Feb 2005 13:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nlc-0004Vh-7F for isis-wg@megatron.ietf.org; Thu, 17 Feb 2005 10:40:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07560 for ; Thu, 17 Feb 2005 10:40:34 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1o74-0006y8-Bl for Isis-wg@ietf.org; Thu, 17 Feb 2005 11:02:47 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.32 ; Thu, 17 Feb 2005 10:39:57 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Feb 2005 10:39:56 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.180 140.233.20.180 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 17 Feb 2005 10:39:56 -0500 Subject: Re: [Isis-wg] Interfaces that configured to run IS-IS L1. From: "Parker, Jeff" To: Yossi Boaron , Message-ID: In-Reply-To: <52F6342A567975489F83368EB54C0D7D069E82@VRZIL-EX01.il.veraznetworks.com> Mime-version: 1.0 X-OriginalArrivalTime: 17 Feb 2005 15:39:56.0407 (UTC) FILETIME=[EE6D8870:01C51506] X-Spam-Score: 0.8 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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="===============1418653289==" 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. --===============1418653289== Content-type: multipart/alternative; boundary="B_3191481596_143730" > 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_3191481596_143730 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Correct (with the assumption that the third instance of Interface #3 should be Interface #4) The difference between 3 and 4 that you don=B9t mention is that the networks on interface 3 will be advertised in the LSPs send on 1 and 2. - jeff parker On 2/17/05 4:22 AM, "Yossi Boaron" wrote: > Hi everybody >=20 > I have a router with 4 interfaces. >=20 > The router configuration is described below : >=20 > 1. interface#1 runs ISIS level 1 >=20 > 2. interface#2 runs ISIS level 1 >=20 > 3. interface#3 isn't running ISIS , but 'passivecircuit' is true . >=20 > 4. interface#4 isn't running ISIS , and 'passivecircuit' is false(means = don't > include this interface in the LSP advertisement). >=20 >=20 > Which kind(Hello,LSP,Sequence number) of packets will be sent and receive= d on > each of the interfaces? >=20 > I think that : >=20 > Interface#1 will send and receive L1 Hellos, L1 LSPs, and L1 sequence num= ber. >=20 > Interface#2 will send and receive L1 Hellos, L1 LSPs, and L1 sequence num= ber. >=20 > Interface#3 will not send neither receive any ISIS packet (including > flooding). >=20 > Interface#3 will not send neither receive any ISIS packet (including > flooding). >=20 > Am I correct? >=20 > Yossi >=20 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg --B_3191481596_143730 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] Interfaces that configured to run IS-IS L1. Corre= ct (with the assumption that the third instance of Interface #3 should be In= terface #4)
The difference between 3 and 4 that you don’t mention is that the net= works on interface 3 will be advertised in the LSPs send on 1 and 2.  <= BR>
- jeff parker


On 2/17/05 4:22 AM, "Yossi Boaron" <Yossi.Boaron@veraznetworks= .com> wrote:

Hi everybody

I have a router with 4 interfaces.

The router configuration is described below :
1. interface#1 runs ISIS level 1

2. interface#2 runs ISIS level 1

3. interface#3 isn't running ISIS , but 'passivec= ircuit'  is true .

4. interface#4 isn't running ISIS , and 'passivec= ircuit'  is false(means don't include this interface in   &nb= sp;    the LSP advertisement).


Which kind(Hello,LSP,Sequence number) of packets = will be sent and received on each of the interfaces?

I think that :

Interface#1 will send and receive L1 Hellos, L1 L= SPs, and L1 sequence number.

Interface#2 will send and receive L1 Hellos, L1 L= SPs, and L1 sequence number.

Interface#3 will not send neither receive any ISI= S packet (including flooding).

Interface#3 will not send neither receive any ISI= S packet (including flooding).

Am  I correct?

Yossi

____________________= ___________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

 --B_3191481596_143730-- --===============1418653289== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1418653289==-- From isis-wg-bounces@ietf.org Thu Feb 17 17:39:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19103 for ; Thu, 17 Feb 2005 17:39:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tls-0000PD-Bo; Thu, 17 Feb 2005 17:05:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tVE-0005JZ-Gx for isis-wg@megatron.ietf.org; Thu, 17 Feb 2005 16:48:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09422 for ; Thu, 17 Feb 2005 16:48:02 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1tql-0000Ym-7V for Isis-wg@ietf.org; Thu, 17 Feb 2005 17:10:19 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.32 ; Thu, 17 Feb 2005 16:47:32 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Feb 2005 16:47:32 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.180 140.233.20.180 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 17 Feb 2005 16:47:31 -0500 From: "Parker, Jeff" To: "ISIS-WG (E-mail)" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Feb 2005 21:47:32.0004 (UTC) FILETIME=[48968E40:01C5153A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: "j.schoenwaelder@iu-bremen.de" Subject: [Isis-wg] Version 18 of ISIS MIB 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 Content-Transfer-Encoding: 7bit I have had some initial feedback from Juergen Schoenwaelder to prepare the MIB for review. I have made a number of changes, and submitted the new version as draft 18. Here is short list of changes. -- Replaced FORMFEED with ^L -- Removed reference to MIB-II -- Added acknowledgements to Mike Bartlett, Chris Hops and Sundar Raachandran -- Removed Long Lines -- Added IANA Consideration Section -- Added text on security section I will be happy to unicast a copy. Juergen is still concerned about the security section. The guidelines suggest we should include information about any object that represents a security risk. I offered to include a recursive reference to the entire MIB, but we haven't reached closure on that point. He has suggested that we provide a conformance statement that allows implementations that only permit read access, if that is what we anticipate. - 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 Feb 18 12:57:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13601 for ; Fri, 18 Feb 2005 12:57:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2C4j-0001Sk-KZ; Fri, 18 Feb 2005 12:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Bom-0002D5-BK for isis-wg@megatron.ietf.org; Fri, 18 Feb 2005 12:21:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09810 for ; Fri, 18 Feb 2005 12:21:24 -0500 (EST) From: jcucchiara@mindspring.com Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2CAR-0002UM-Rd for Isis-wg@ietf.org; Fri, 18 Feb 2005 12:43:53 -0500 Received: from h-66-167-175-180.cmbrmaor.dynamic.covad.net ([66.167.175.180] helo=jluciani-laptop) by mclean.mail.mindspring.net with smtp (Exim 3.33 #1) id 1D2Boh-0003Cr-00; Fri, 18 Feb 2005 12:21:23 -0500 Message-Id: <3.0.1.32.20050218102907.0133c65c@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 18 Feb 2005 10:29:07 -0500 To: "Parker, Jeff" , "ISIS-WG (E-mail)" Subject: Re: [Isis-wg] Version 18 of ISIS MIB In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.4 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "j.schoenwaelder@iu-bremen.de" 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 At 04:47 PM 2/17/05 -0500, Parker, Jeff wrote: >I have had some initial feedback from Juergen Schoenwaelder to prepare the >MIB for review. I have made a number of changes, and submitted the new >version as draft 18. > >Here is short list of changes. > > -- Replaced FORMFEED with ^L > -- Removed reference to MIB-II > -- Added acknowledgements to Mike Bartlett, Chris Hops and Sundar >Raachandran > -- Removed Long Lines > -- Added IANA Consideration Section > -- Added text on security section > >I will be happy to unicast a copy. > >Juergen is still concerned about the security section. The guidelines >suggest we should include information about any object that represents a >security risk. I offered to include a recursive reference to the entire >MIB, but we haven't reached closure on that point. >He has suggested that we >provide a conformance statement that allows implementations that only permit >read access, if that is what we anticipate. I am in favor of an additional conformance statement of read-only. Customers sometimes prefer to configure via CLI (or someother mechanism) and not SNMP, so that is why I am in favor of adding a read-only conformance statement. -Joan > >- 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 Fri Feb 18 16:45:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27582 for ; Fri, 18 Feb 2005 16:45:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2EtH-00081U-Jr; Fri, 18 Feb 2005 15:38:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2EhO-00030Z-L9; Fri, 18 Feb 2005 15:26:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08832; Fri, 18 Feb 2005 15:26:01 -0500 (EST) Message-Id: <200502182026.PAA08832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 18 Feb 2005 15:26:01 -0500 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-18.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-18.txt Pages : 91 Date : 2005-2-18 This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner [1]. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES- IS protocol, and to add management support for current practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-18.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-18.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-18.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-2-18144457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-18144457.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Sun Feb 20 13:54:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28734 for ; Sun, 20 Feb 2005 13:54:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2uVq-0001Rs-V0; Sun, 20 Feb 2005 12:04:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2tSd-00050k-5k for isis-wg@megatron.ietf.org; Sun, 20 Feb 2005 10:57:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14018 for ; Sun, 20 Feb 2005 10:57:15 -0500 (EST) Received: from c-230.static.at.kpnqwest.net ([193.154.188.230] helo=ghostrider.gredler.at) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2toU-0001AJ-QA for isis-wg@ietf.org; Sun, 20 Feb 2005 11:20:08 -0500 Received: from ghostrider.gredler.at (localhost [127.0.0.1]) by ghostrider.gredler.at (8.13.1/8.12.11) with ESMTP id j1KFvAjX012739; Sun, 20 Feb 2005 16:57:10 +0100 Received: (from hannes@localhost) by ghostrider.gredler.at (8.13.1/8.13.1/Submit) id j1KFv8aq012738; Sun, 20 Feb 2005 16:57:08 +0100 Date: Sun, 20 Feb 2005 16:57:08 +0100 From: Hannes Gredler To: Abhishek Verma Subject: Re: [Isis-wg] Zero Cost links in ISIS Message-ID: <20050220155708.GB12679@juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "ISIS-WG \(E-mail\)" 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 Mon, Feb 14, 2005 at 04:21:21PM +0530, Abhishek Verma wrote: | I am confused because whenever IP reachability changes (route goes | up/down) the topology would always get affected. I know i am missing | something. Would someone be good enough to point that out? we tend to use the word "SPF run" or "full SPF run" in a very loose fashion - what most routers do in fact is 1. calculate a topology graph based on (extd) IS reach information based on dijkstra's algorithm; 2. attach the leaf information [IP routes] to each of the nodes in the topology. 3. sort the leaf information [IP routes] based on the path cost resulting from step [1] 4. populate the kernel/FIB if there has been a change in IP forwarding state from the previous run. --- so to answer your question: no - just a change in IP reachability information does not require to repeat from step 1 - what routers need to do is to calculate from step 2 onwards. in some vendors implementaton is is termed as a "partial" SPF run, while in fact its not a real SPF run but rather a sort operation; HTH, /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Feb 21 10:07:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05555 for ; Mon, 21 Feb 2005 10:07:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3E7j-0008Lq-5o; Mon, 21 Feb 2005 09:01:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3DUg-0000hE-4w for isis-wg@megatron.ietf.org; Mon, 21 Feb 2005 08:20:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24316 for ; Mon, 21 Feb 2005 08:20:52 -0500 (EST) Received: from web25402.mail.ukl.yahoo.com ([217.12.10.136]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3Dqr-0000ma-IR for isis-wg@ietf.org; Mon, 21 Feb 2005 08:43:55 -0500 Received: (qmail 591 invoked by uid 60001); 21 Feb 2005 13:20:20 -0000 Message-ID: <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25402.mail.ukl.yahoo.com via HTTP; Mon, 21 Feb 2005 13:20:19 GMT Date: Mon, 21 Feb 2005 13:20:19 +0000 (GMT) From: "Sugar, Sylvia" To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 8bit Subject: [Isis-wg] Running SPF 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 Content-Transfer-Encoding: 8bit Hi, When i run my SPF is it fair to add all my connected adjacencies directly to the TENTs, without checking if they are already in the PATHs? Is it ever possible for a directly connected neighbor to be in the PATHs already and us getting this information again? Also when processing pseudonode LSPs, is there anything special that we need to take care of? In our implementation we process the LSPs from our adjacent neighbor and then look for the pseudonode LSP if it exists. If yes, then I am thinking of adding the neighbors listed in the pseudonode LSPs directly to the PATHs. Is this correct interpretation of the ISO 10589 and RFC 1195 standard? Sylvia ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Feb 21 17:16:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21589 for ; Mon, 21 Feb 2005 17:16:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3JxC-0007OY-8h; Mon, 21 Feb 2005 15:14:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Ig7-0005OV-Qj for isis-wg@megatron.ietf.org; Mon, 21 Feb 2005 13:53:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00855 for ; Mon, 21 Feb 2005 13:53:01 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3J2M-0001Xc-G1 for isis-wg@ietf.org; Mon, 21 Feb 2005 14:16:07 -0500 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1LIquKw020388 for ; Mon, 21 Feb 2005 11:52:56 -0700 (MST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IC900M01YZ696@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for isis-wg@ietf.org; Mon, 21 Feb 2005 13:52:55 -0500 (EST) Received: from sun.com (vpn-129-150-24-105.SFBay.Sun.COM [129.150.24.105]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IC900IUSZ47R2@bur-mail2.east.sun.com>; Mon, 21 Feb 2005 13:52:55 -0500 (EST) Date: Mon, 21 Feb 2005 10:52:55 -0800 From: Radia Perlman Subject: Re: [Isis-wg] Running SPF In-reply-to: <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> To: "Sugar, Sylvia" Message-id: <421A2E07.5020308@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 References: <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Content-Transfer-Encoding: 7BIT Sugar, Sylvia wrote: >Hi, > >When i run my SPF is it fair to add all my connected adjacencies directly to the TENTs, without >checking if they are already in the PATHs? Is it ever possible for a directly connected neighbor >to be in the PATHs already and us getting this information again? > > Yes, you may very well find more paths, and if you don't check if something is already in PATH, you would not be doing correct behavior. Being in PATHs says that this is the best path from you (S) to target T. You might find lots more paths to T, which will all be worse than the path in PATHs, but if your implementation keeps looking for "the shortest path still in TENT" and looking at paths through that, you'll never terminate. Radia _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Feb 23 00:48:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13870 for ; Wed, 23 Feb 2005 00:48:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kfV-0004PA-KH; Tue, 22 Feb 2005 19:46:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3cy3-0008It-CJ for isis-wg@megatron.ietf.org; Tue, 22 Feb 2005 11:32:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18776 for ; Tue, 22 Feb 2005 11:32:51 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3dKU-00024I-IP for isis-wg@ietf.org; Tue, 22 Feb 2005 11:56:10 -0500 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1MGWqL0014863 for ; Tue, 22 Feb 2005 09:32:53 -0700 (MST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ICB00901N50LD@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for isis-wg@ietf.org; Tue, 22 Feb 2005 11:32:52 -0500 (EST) Received: from Sun.COM (sr1-usca-06.SFBay.Sun.COM [129.145.155.98]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0ICB000LYNAPSE@bur-mail2.east.sun.com>; Tue, 22 Feb 2005 11:32:52 -0500 (EST) Date: Tue, 22 Feb 2005 08:32:48 -0800 From: Radia Perlman Subject: Re: [Isis-wg] Running SPF In-reply-to: <4.3.2.7.2.20050222085529.02320658@jaws.cisco.com> To: mike shand Message-id: <421B5EB0.3020600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> <4.3.2.7.2.20050222085529.02320658@jaws.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7BIT Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Radia.Perlman@Sun.COM 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 Content-Transfer-Encoding: 7BIT Mike...maybe you and I interpreted the original quesiton differently. There's no problem with doing what you said, but what I thought he was asking was ignoring the check, during the run of SPF, to see if a node was already in PATHs. With my interpretation of his question, I think the algorithm would keep finding longer paths. I suppose if when you put something from TENT into PATH, if you then looked to see if that node was already in PATH it would terminate, but it would be quite inefficient to explore a longer path to D once you have already found the shortest path to D. Anyway, you and I are not disagreeing...we're just answering different questions. Hope one of us has interpreted his question correctly. Radia mike shand wrote: > At 10:52 21/02/2005 -0800, Radia Perlman wrote: > > > >>Sugar, Sylvia wrote: >> >> >>>Hi, >>> >>>When i run my SPF is it fair to add all my connected adjacencies directly >>>to the TENTs, without >>>checking if they are already in the PATHs? Is it ever possible for a >>>directly connected neighbor >>>to be in the PATHs already and us getting this information again? >>> >> >>Yes, you may very well find more paths, and if you don't check if something is >>already in PATH, you would not be doing correct behavior. >>Being in PATHs says that this is the best path from you (S) >>to target T. You might find lots more paths to T, which will all be worse >>than the path >>in PATHs, but if your implementation keeps looking for "the shortest path >>still in TENT" >>and looking at paths through that, you'll never terminate. > > > I'm confused. Surely adding all your directly connected adjacencies to TENT > is exactly equivalent to processing you own LSP first and then adding the > contents to TENT. Or are you suggesting your own LSP may have a different > content than your adjacency set? > > I must be misunderstanding something. > > > >>Radia >> >> >> >> >>_______________________________________________ >>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 Feb 23 01:04:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15884 for ; Wed, 23 Feb 2005 01:04:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kfp-0004Xc-Ez; Tue, 22 Feb 2005 19:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3dqQ-0005qm-JF for isis-wg@megatron.ietf.org; Tue, 22 Feb 2005 12:29:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25873 for ; Tue, 22 Feb 2005 12:29:02 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3eCr-0003nD-9w for isis-wg@ietf.org; Tue, 22 Feb 2005 12:52:22 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Feb 2005 18:44:58 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j1MHSTlu011587; Tue, 22 Feb 2005 18:28:30 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp273.cisco.com [10.61.65.17]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA12135; Tue, 22 Feb 2005 17:28:28 GMT Message-Id: <4.3.2.7.2.20050222172602.021e2e38@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Feb 2005 17:28:16 +0000 To: Radia.Perlman@Sun.COM From: mike shand Subject: Re: [Isis-wg] Running SPF In-Reply-To: <421B5EB0.3020600@Sun.COM> References: <4.3.2.7.2.20050222085529.02320658@jaws.cisco.com> <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> <4.3.2.7.2.20050222085529.02320658@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 At 08:32 22/02/2005 -0800, Radia Perlman wrote: >Mike...maybe you and I interpreted the original quesiton differently. >There's no problem with doing what you said, but what I thought he >was asking was ignoring the check, during the run of SPF, to see if >a node was already in PATHs. With my interpretation of his question, >I think the algorithm would keep finding longer paths. I suppose if >when you put something from TENT into PATH, if you then looked to >see if that node was already in PATH it would terminate, but it would >be quite inefficient to explore a longer path to D once you have already >found the shortest path to D. I agree. >Anyway, you and I are not disagreeing...we're just answering different >questions. Hope one of us has interpreted his question correctly. Yes. Whichever it was, we have between us provided a correct answer to it :-) Mike >Radia > > > >mike shand wrote: > > At 10:52 21/02/2005 -0800, Radia Perlman wrote: > > > > > > > >>Sugar, Sylvia wrote: > >> > >> > >>>Hi, > >>> > >>>When i run my SPF is it fair to add all my connected adjacencies directly > >>>to the TENTs, without > >>>checking if they are already in the PATHs? Is it ever possible for a > >>>directly connected neighbor > >>>to be in the PATHs already and us getting this information again? > >>> > >> > >>Yes, you may very well find more paths, and if you don't check if > something is > >>already in PATH, you would not be doing correct behavior. > >>Being in PATHs says that this is the best path from you (S) > >>to target T. You might find lots more paths to T, which will all be worse > >>than the path > >>in PATHs, but if your implementation keeps looking for "the shortest path > >>still in TENT" > >>and looking at paths through that, you'll never terminate. > > > > > > I'm confused. Surely adding all your directly connected adjacencies to > TENT > > is exactly equivalent to processing you own LSP first and then adding the > > contents to TENT. Or are you suggesting your own LSP may have a different > > content than your adjacency set? > > > > I must be misunderstanding something. > > > > > > > >>Radia > >> > >> > >> > >> > >>_______________________________________________ > >>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 Feb 23 20:39:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17426 for ; Wed, 23 Feb 2005 20:39:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3knF-0006dw-3F; Tue, 22 Feb 2005 19:54:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3W3t-0004no-W1 for isis-wg@megatron.ietf.org; Tue, 22 Feb 2005 04:10:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03126 for ; Tue, 22 Feb 2005 04:10:27 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3WQH-0005Ea-Dp for isis-wg@ietf.org; Tue, 22 Feb 2005 04:33:41 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Feb 2005 10:26:17 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j1M99slu000830; Tue, 22 Feb 2005 10:09:55 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp273.cisco.com [10.61.65.17]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA00818; Tue, 22 Feb 2005 09:09:53 GMT Message-Id: <4.3.2.7.2.20050222090025.02ee0ae8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Feb 2005 09:09:51 +0000 To: "Sugar, Sylvia" From: mike shand Subject: Re: [Isis-wg] Running SPF In-Reply-To: <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 At 13:20 21/02/2005 +0000, Sugar, Sylvia wrote: >Also when processing pseudonode LSPs, is there anything special that we >need to take care of? In >our implementation we process the LSPs from our adjacent neighbor and then >look for the pseudonode >LSP if it exists. If yes, then I am thinking of adding the neighbors >listed in the pseudonode LSPs >directly to the PATHs. The normal way to do this is to treat the pseudonode as a normal node, with the exception that if there are multiple nodes with the same (lowest) cost at the top of TENT you should choose a pseudonode in preference to a non-pseudonode. If you don't do this you will not find the equal cost paths correctly. I don't really follow what you are proposing, but the "adding the nodes listing in the psuodonode LSPs directly to PATHs" doesn't sound right. Mike _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Feb 23 21:19:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01310 for ; Wed, 23 Feb 2005 21:19:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3knR-0006ik-3R; Tue, 22 Feb 2005 19:54:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Wtb-0003Yd-Dl for isis-wg@megatron.ietf.org; Tue, 22 Feb 2005 05:03:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09153 for ; Tue, 22 Feb 2005 05:03:50 -0500 (EST) Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3XFu-0007Bb-GH for isis-wg@ietf.org; Tue, 22 Feb 2005 05:27:05 -0500 Received: from [192.168.0.130] ([10.58.48.27]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id j1MA3G106406; Tue, 22 Feb 2005 11:03:16 +0100 (CET) In-Reply-To: <421A2E07.5020308@sun.com> References: <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> <421A2E07.5020308@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ad8b05fd837c30f5f38eb1e936197c4@cisco.com> Content-Transfer-Encoding: 7bit From: stefano previdi Subject: Re: [Isis-wg] Running SPF Date: Tue, 22 Feb 2005 11:04:10 +0100 To: Radia Perlman X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Content-Transfer-Encoding: 7bit On Feb 21, 2005, at 7:52 PM, Radia Perlman wrote: > > Sugar, Sylvia wrote: > >> Hi, >> >> When i run my SPF is it fair to add all my connected adjacencies >> directly to the TENTs, without >> checking if they are already in the PATHs? Is it ever possible for a >> directly connected neighbor >> to be in the PATHs already and us getting this information again? >> > Yes, you may very well find more paths, and if you don't check if > something is > already in PATH, you would not be doing correct behavior. I'm not sure but I believe here we are referring to the adjacent neighbors of the router computing SPF. In such case I would say that: - The only place in SPF algorithm where the computing router moves its adjacent neighbors in TENT is when the algorithm starts: - step-0: tent and paths are empty - step-1: move myself to tent - step-2: move best node from tent to paths (i.e.: move myself to paths) - step-3: move my neighbors to tent - .... - Therefore, at the time the computing node moves its neighbors in TENT, TENT is always empty so the check is not strictly necessary. Having said that, from an implementation perspective, the check is probably always done since the SPF processing loop starts at step-2 and step-2 applies to all nodes, not only ourselves. s. > Being in PATHs says that this is the best path from you (S) > to target T. You might find lots more paths to T, which will all be > worse than the path > in PATHs, but if your implementation keeps looking for "the shortest > path still in TENT" > and looking at paths through that, you'll never terminate. > > Radia > > > > > _______________________________________________ > 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 Feb 23 22:56:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08726 for ; Wed, 23 Feb 2005 22:56:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kn3-0006X2-3q; Tue, 22 Feb 2005 19:54:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Vth-0002uf-Oc for isis-wg@megatron.ietf.org; Tue, 22 Feb 2005 04:00:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00207 for ; Tue, 22 Feb 2005 03:59:54 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3WG4-0004gw-1E for isis-wg@ietf.org; Tue, 22 Feb 2005 04:23:09 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Feb 2005 10:15:44 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j1M8xKlu027265; Tue, 22 Feb 2005 09:59:21 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp273.cisco.com [10.61.65.17]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA00177; Tue, 22 Feb 2005 08:59:20 GMT Message-Id: <4.3.2.7.2.20050222085529.02320658@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Feb 2005 08:59:17 +0000 To: Radia Perlman From: mike shand Subject: Re: [Isis-wg] Running SPF In-Reply-To: <421A2E07.5020308@sun.com> References: <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> <20050221132020.588.qmail@web25402.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 At 10:52 21/02/2005 -0800, Radia Perlman wrote: >Sugar, Sylvia wrote: > >>Hi, >> >>When i run my SPF is it fair to add all my connected adjacencies directly >>to the TENTs, without >>checking if they are already in the PATHs? Is it ever possible for a >>directly connected neighbor >>to be in the PATHs already and us getting this information again? >> >Yes, you may very well find more paths, and if you don't check if something is >already in PATH, you would not be doing correct behavior. >Being in PATHs says that this is the best path from you (S) >to target T. You might find lots more paths to T, which will all be worse >than the path >in PATHs, but if your implementation keeps looking for "the shortest path >still in TENT" >and looking at paths through that, you'll never terminate. I'm confused. Surely adding all your directly connected adjacencies to TENT is exactly equivalent to processing you own LSP first and then adding the contents to TENT. Or are you suggesting your own LSP may have a different content than your adjacency set? I must be misunderstanding something. >Radia > > > > >_______________________________________________ >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 Feb 24 01:53:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11895 for ; Thu, 24 Feb 2005 01:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CN4-0000Px-3a; Thu, 24 Feb 2005 01:21:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CN2-0000P0-6x for isis-wg@megatron.ietf.org; Thu, 24 Feb 2005 01:21:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29584 for ; Thu, 24 Feb 2005 01:21:07 -0500 (EST) Received: from web25404.mail.ukl.yahoo.com ([217.12.10.138]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4Cjq-0007Tv-Vd for isis-wg@ietf.org; Thu, 24 Feb 2005 01:44:44 -0500 Received: (qmail 83304 invoked by uid 60001); 24 Feb 2005 06:20:56 -0000 Message-ID: <20050224062056.83302.qmail@web25404.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25404.mail.ukl.yahoo.com via HTTP; Thu, 24 Feb 2005 06:20:56 GMT Date: Thu, 24 Feb 2005 06:20:56 +0000 (GMT) From: "Sugar, Sylvia" Subject: Re: [Isis-wg] Running SPF To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 8bit 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 Content-Transfer-Encoding: 8bit Hi Mike, >>>When i run my SPF is it fair to add all my connected adjacencies directly >>>to the TENTs, without >>>checking if they are already in the PATHs? Is it ever possible for a >>>directly connected neighbor >>>to be in the PATHs already and us getting this information again? >>> [..] > > I'm confused. Surely adding all your directly connected adjacencies to TENT > is exactly equivalent to processing you own LSP first and then adding the > contents to TENT. Or are you suggesting your own LSP may have a different > content than your adjacency set? I am asking if this can *ever* happen. The reason why i ask this is because i was look at an ISIS implementation and there they check before placing their own adjacency if its in PATHs. I could not understand the reason for this and hence i put in the original mail. IMO its not required. Is there a scenario where this would make any sense? Thanks to Radia/Stefano and Mike for taking some time off and replying to me! Regards, Sylvia ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Feb 24 13:53:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29492 for ; Thu, 24 Feb 2005 13:53:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4O3S-0001qk-70; Thu, 24 Feb 2005 13:49:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4O3Q-0001jv-5U for isis-wg@megatron.ietf.org; Thu, 24 Feb 2005 13:49:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29057 for ; Thu, 24 Feb 2005 13:49:36 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OQL-0006w0-5z for isis-wg@ietf.org; Thu, 24 Feb 2005 14:13:23 -0500 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1OInaKw013127 for ; Thu, 24 Feb 2005 11:49:36 -0700 (MST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ICF00301IUMOO@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for isis-wg@ietf.org; Thu, 24 Feb 2005 13:49:36 -0500 (EST) Received: from sun.com (vpn-129-150-25-169.SFBay.Sun.COM [129.150.25.169]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0ICF007J7IYN82@bur-mail2.east.sun.com>; Thu, 24 Feb 2005 13:49:36 -0500 (EST) Date: Thu, 24 Feb 2005 10:49:39 -0800 From: Radia Perlman Subject: Re: [Isis-wg] Running SPF In-reply-to: <20050224062056.83302.qmail@web25404.mail.ukl.yahoo.com> To: "Sugar, Sylvia" Message-id: <421E21C3.4030608@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 References: <20050224062056.83302.qmail@web25404.mail.ukl.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Content-Transfer-Encoding: 7BIT Aha. It was Mike Shand that interpreted your question correctly. Where I got confused was not interpreting "my" as being "the node running SPF", and instead I interpreted it as "the", as in, whenever running SPF, adding things to TENT without checking PATHs, in the phrase "is it fair to add all my connected adjacencies directly to the TENT, without checking if they are already in PATH". With that interpretation of the question, the answer would have been "no, it's not safe", but that wasn't your question. So Sylvia, I think you are correct in your hypothesis. What you are asking is whether on the first iteration, when the node R running SPF looks at the first LSP (R's own adjacencies), R can safely not bother checking PATH, and as Mike said, this is safe because nothing would be in PATH at that point. Radia Sugar, Sylvia wrote: >Hi Mike, > > > >>>>When i run my SPF is it fair to add all my connected adjacencies directly >>>>to the TENTs, without >>>>checking if they are already in the PATHs? Is it ever possible for a >>>>directly connected neighbor >>>>to be in the PATHs already and us getting this information again? >>>> >>>> >>>> > >[..] > > > >>I'm confused. Surely adding all your directly connected adjacencies to TENT >>is exactly equivalent to processing you own LSP first and then adding the >>contents to TENT. Or are you suggesting your own LSP may have a different >>content than your adjacency set? >> >> > >I am asking if this can *ever* happen. The reason why i ask this is because i was look at an ISIS >implementation and there they check before placing their own adjacency if its in PATHs. I could >not understand the reason for this and hence i put in the original mail. > >IMO its not required. Is there a scenario where this would make any sense? > >Thanks to Radia/Stefano and Mike for taking some time off and replying to me! > >Regards, >Sylvia > > > > > > >___________________________________________________________ >ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.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 Feb 24 13:53:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29520 for ; Thu, 24 Feb 2005 13:53:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4O3l-0002VI-6z; Thu, 24 Feb 2005 13:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4O3j-0002VA-Bi for isis-wg@megatron.ietf.org; Thu, 24 Feb 2005 13:49:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29074 for ; Thu, 24 Feb 2005 13:49:56 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OQd-0006wN-Bu for isis-wg@ietf.org; Thu, 24 Feb 2005 14:13:42 -0500 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j1OInshl015447 for ; Thu, 24 Feb 2005 11:49:54 -0700 (MST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ICF00301IUMOO@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for isis-wg@ietf.org; Thu, 24 Feb 2005 13:49:54 -0500 (EST) Received: from sun.com (vpn-129-150-25-169.SFBay.Sun.COM [129.150.25.169]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0ICF007LEIZ682@bur-mail2.east.sun.com>; Thu, 24 Feb 2005 13:49:54 -0500 (EST) Date: Thu, 24 Feb 2005 10:49:58 -0800 From: Radia Perlman Subject: Re: [Isis-wg] Running SPF In-reply-to: <20050224062056.83302.qmail@web25404.mail.ukl.yahoo.com> To: "Sugar, Sylvia" Message-id: <421E21D6.8050504@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 References: <20050224062056.83302.qmail@web25404.mail.ukl.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Content-Transfer-Encoding: 7BIT Aha. It was Mike Shand that interpreted your question correctly. Where I got confused was not interpreting "my" as being "the node running SPF", and instead I interpreted it as "the", as in, whenever running SPF, adding things to TENT without checking PATHs, in the phrase "is it fair to add all my connected adjacencies directly to the TENT, without checking if they are already in PATH". With that interpretation of the question, the answer would have been "no, it's not safe", but that wasn't your question. So Sylvia, I think you are correct in your hypothesis. What you are asking is whether on the first iteration, when the node R running SPF looks at the first LSP (R's own adjacencies), R can safely not bother checking PATH, and as Mike said, this is safe because nothing would be in PATH at that point. Radia Sugar, Sylvia wrote: >Hi Mike, > > > >>>>When i run my SPF is it fair to add all my connected adjacencies directly >>>>to the TENTs, without >>>>checking if they are already in the PATHs? Is it ever possible for a >>>>directly connected neighbor >>>>to be in the PATHs already and us getting this information again? >>>> >>>> >>>> > >[..] > > > >>I'm confused. Surely adding all your directly connected adjacencies to TENT >>is exactly equivalent to processing you own LSP first and then adding the >>contents to TENT. Or are you suggesting your own LSP may have a different >>content than your adjacency set? >> >> > >I am asking if this can *ever* happen. The reason why i ask this is because i was look at an ISIS >implementation and there they check before placing their own adjacency if its in PATHs. I could >not understand the reason for this and hence i put in the original mail. > >IMO its not required. Is there a scenario where this would make any sense? > >Thanks to Radia/Stefano and Mike for taking some time off and replying to me! > >Regards, >Sylvia > > > > > > >___________________________________________________________ >ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.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