From isis-wg-admin@external.juniper.net Wed Apr 5 02:49:14 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06624 for ; Wed, 5 Apr 2000 02:49:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA88010; Tue, 4 Apr 2000 23:52:27 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA87960 for ; Tue, 4 Apr 2000 23:52:05 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 05 Apr 2000 12:22:42 +0530 Received: from saver.future ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA08885 for ; Wed, 5 Apr 2000 12:01:56 +0530 Received: by localhost with Microsoft MAPI; Wed, 5 Apr 2000 12:10:41 +0530 Message-Id: <01BF9EF7.F65A7FA0.selvarajr@future.futsoft.com> From: SelvarajR To: "'ISIS-WG'" Date: Wed, 5 Apr 2000 12:10:39 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BF9EF7.F66220C0" Subject: [Isis-wg] Doubt regarding PtPtCircId Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net ------ =_NextPart_000_01BF9EF7.F66220C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Please, could any of you tell the use of PtPtCircId in Integrated ISIS MIB. This object is mentioned in the circuit Table. The standard has mentioned some negotiation process for that. But I find it is no where used in the Protocol. SELVA ------ =_NextPart_000_01BF9EF7.F66220C0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IikGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAGwAAAERvdWJ0IHJlZ2FyZGluZyBQdFB0Q2lyY0lkAKcJAQWAAwAOAAAA 0AcEAAUADAAKACcAAwAgAQEggAMADgAAANAHBAAFAAwAAwAsAAMAHgEBCYABACEAAAAxOTY5OTI3 ODQxMEFENDExQTg1ODAwMjAzNTFGOTJBMADGBgEDkAYAYAQAACAAAAALAAIAAQAAAAsAIwAAAAAA AwAmAAAAAAALACkAAAAAAAMANgAAAAAAQAA5AMCCbNvJnr8BHgBwAAEAAAAbAAAARG91YnQgcmVn YXJkaW5nIFB0UHRDaXJjSWQAAAIBcQABAAAAFgAAAAG/nsnbY3iSaR8KQRHUqFgAIDUfkqAAAB4A HgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAdAAAAc2VsdmFyYWpyQGZ1dHVyZS5mdXRzb2Z0LmNv bQAAAAADAAYQNa9yjgMABxDCAAAAHgAIEAEAAABlAAAASElQTEVBU0UsQ09VTERBTllPRllPVVRF TExUSEVVU0VPRlBUUFRDSVJDSURJTklOVEVHUkFURURJU0lTTUlCVEhJU09CSkVDVElTTUVOVElP TkVESU5USEVDSVJDVUlUVEFCTAAAAAACAQkQAQAAAD8BAAA7AQAAgwEAAExaRnXoe3gMAwAKAHJj cGcxMjUWMgD4C2BuDhAwMzOdAfcgAqQD4wIAY2gKwGBzZXQwIAcTAoB9OQqBdWMAUAsDC7UgSA5p CuMKhAqAUGxlYQkRMCwgBaB1bGQggQBweSBvZiB5CGAQIHRlbAMgdGhlTCB1ETAVQlB0FsBDMGly Y0kU8AuAICBqSQIwZQnAYRXAFPBJBlMYYAXQSUIuIFTmaAQAFUBiagWQBUAZIXsHgAIwaQIgGDEX cRYSY2kXEXVpBUBUAaAUQC6XE3QZABYwcwGQbmQLEXYgEQAZ2nMDcBYwGlBnTm8aIBgQGjEgcANg Y38HkAQgAhAFwBYQGBAY4EJ6dQVASR9wC4AXURmjbnhvIHcWIAlwFkIad1A9A2B0HyAG8BvVE3pT RVhMVkETdBHxACUgAAMAEBAAAAAAAwAREAAAAAADAIAQ/////0AABzDgrjbkyJ6/AUAACDDgrjbk yJ6/AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYA AAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMAB4AIIAYAAAAAAMAA AAAAAABGAAAAAAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4w NAAAAAALAAmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABG AAAAABGFAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAyACCAGAAAAAADA AAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEA AAABAAAAAAAAAB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAA AAEAAAAAAAAAAwANNP03AAC+yw== ------ =_NextPart_000_01BF9EF7.F66220C0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Apr 5 04:32:48 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07244 for ; Wed, 5 Apr 2000 04:32:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA88170; Wed, 5 Apr 2000 01:29:42 -0700 (PDT) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA88141 for ; Wed, 5 Apr 2000 01:29:40 -0700 (PDT) Received: from mshand-8kcdt (lon-sto4-lan-vlan133-dhcp45.cisco.com [144.254.108.112]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA20387; Wed, 5 Apr 2000 09:10:25 +0100 (BST) Message-Id: <4.2.2.20000405090814.00aae610@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Apr 2000 09:11:21 +0100 To: SelvarajR , "'ISIS-WG'" From: Mike Shand Subject: Re: [Isis-wg] Doubt regarding PtPtCircId In-Reply-To: <01BF9EF7.F65A7FA0.selvarajr@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 12:10 05/04/2000 +0530, SelvarajR wrote: >Hi > >Please, could any of you tell the use of PtPtCircId in Integrated ISIS >MIB. This object is mentioned in the circuit Table. >The standard has mentioned some negotiation process for that. But I find >it is no where used in the Protocol. 8.2.4.2 sub-clause (d) (if the circuit ID changes drop the adjacency). You are right that this is not ever SENT in the protocol. The local circuit ID is used for that. But the existing value is checked against the newly computed value (based on the value of the other nodes's local circuit ID carried in the protocol. Mike >SELVA _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Apr 5 05:17:05 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07502 for ; Wed, 5 Apr 2000 05:17:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA88415; Wed, 5 Apr 2000 02:12:36 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA88388 for ; Wed, 5 Apr 2000 02:12:27 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 05 Apr 2000 14:43:00 +0530 Received: from saver.future ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id OAA11822 for ; Wed, 5 Apr 2000 14:22:21 +0530 Received: by localhost with Microsoft MAPI; Wed, 5 Apr 2000 14:31:06 +0530 Message-Id: <01BF9F0B.93E55480.selvarajr@future.futsoft.com> From: SelvarajR To: "'Mike Shand'" Cc: "'ISIS-WG'" Subject: RE: [Isis-wg] Doubt regarding PtPtCircId Date: Wed, 5 Apr 2000 14:31:02 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BF9F0B.93ECF5A0" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net ------ =_NextPart_000_01BF9F0B.93ECF5A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit But that section is totally left out in the 10589 1998 draft. This I'm mentioning just to consider while taking corrective action in the draft. Thanks SELVA -----Original Message----- From: Mike Shand [SMTP:mshand@cisco.com] Sent: Wednesday, April 05, 2000 1:41 PM To: SelvarajR; 'ISIS-WG' Subject: Re: [Isis-wg] Doubt regarding PtPtCircId At 12:10 05/04/2000 +0530, SelvarajR wrote: >Hi > >Please, could any of you tell the use of PtPtCircId in Integrated ISIS >MIB. This object is mentioned in the circuit Table. >The standard has mentioned some negotiation process for that. But I find >it is no where used in the Protocol. 8.2.4.2 sub-clause (d) (if the circuit ID changes drop the adjacency). You are right that this is not ever SENT in the protocol. The local circuit ID is used for that. But the existing value is checked against the newly computed value (based on the value of the other nodes's local circuit ID carried in the protocol. Mike >SELVA _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------ =_NextPart_000_01BF9F0B.93ECF5A0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgYJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAIAMAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAOQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAE1pa2UgU2hhbmQAU01U UABtc2hhbmRAY2lzY28uY29tAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgADMAEAAAARAAAAbXNo YW5kQGNpc2NvLmNvbQAAAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAANAAAAJ01pa2UgU2hhbmQn AAAAAAIBCzABAAAAFgAAAFNNVFA6TVNIQU5EQENJU0NPLkNPTQAAAAMAADkAAAAACwBAOgAAAAAD AHE6AAAAAB4A9l8BAAAACwAAAE1pa2UgU2hhbmQAAAIB918BAAAAOQAAAAAAAACBKx+kvqMQGZ1u AN0BD1QCAAABAE1pa2UgU2hhbmQAU01UUABtc2hhbmRAY2lzY28uY29tAAAAAAMA/V8BAAAAAwD/ XwAAAAACAfYPAQAAAAQAAAAAAAADEAAAAAMAADAEAAAACwAPDgAAAAACAf8PAQAAAG4AAAAAAAAA tTvCwCx3EBqhvAgAKypWwhUAAAAT3mZrXmHTEahYACA1H5KgZIgAAAAAAACBKx+kvqMQGZ1uAN0B D1QCAAAAAElTSVMtV0cAU01UUABpc2lzLXdnQGV4dGVybmFsLmp1bmlwZXIubmV0AAAAHgACMAEA AAAFAAAAU01UUAAAAAAeAAMwAQAAAB0AAABpc2lzLXdnQGV4dGVybmFsLmp1bmlwZXIubmV0AAAA AAMAFQwCAAAAAwD+DwYAAAAeAAEwAQAAAAoAAAAnSVNJUy1XRycAAAACAQswAQAAACIAAABTTVRQ OklTSVMtV0dARVhURVJOQUwuSlVOSVBFUi5ORVQAAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEAAAAI AAAASVNJUy1XRwACAfdfAQAAACwAAAC/AAAAtTvCwCx3EBqhvAgAKypWwhUAAAAT3mZrXmHTEahY ACA1H5KgZIgAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAEQZcBBIABACkAAABSRTog W0lzaXMtd2ddIERvdWJ0IHJlZ2FyZGluZyBQdFB0Q2lyY0lkABMOAQWAAwAOAAAA0AcEAAUADgAf AAIAAwASAQEggAMADgAAANAHBAAFAA4AGAAfAAMAKAEBCYABACEAAAAyNjY5OTI3ODQxMEFENDEx QTg1ODAwMjAzNTFGOTJBMADEBgEDkAYAtAcAACIAAAALAAIAAQAAAAsAIwAAAAAAAwAmAAAAAAAL ACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAgPwTeN2evwEeAHAAAQAAACkAAABSRTogW0lzaXMt d2ddIERvdWJ0IHJlZ2FyZGluZyBQdFB0Q2lyY0lkAAAAAAIBcQABAAAAFgAAAAG/nt132niSaSgK QRHUqFgAIDUfkqAAAB4AHgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAdAAAAc2VsdmFyYWpyQGZ1 dHVyZS5mdXRzb2Z0LmNvbQAAAAADAAYQrBTkowMABxBhAwAAHgAIEAEAAABlAAAAQlVUVEhBVFNF Q1RJT05JU1RPVEFMTFlMRUZUT1VUSU5USEUxMDU4OTE5OThEUkFGVFRISVNJTU1FTlRJT05JTkdK VVNUVE9DT05TSURFUldISUxFVEFLSU5HQ09SUkVDVElWRQAAAAACAQkQAQAAADsEAAA3BAAAgwYA AExaRnW9CosOAwAKAHJjcGcxMjV2MgD0AfcgAqQD4wIAY4JoCsBzZXQwIAcThwKDAFAPtnBycTIQ tmZ9CoAIyCA7CW8OMDWzAoAKgXVjAFALA2MAQUULYG4OEDAzMwumIHRCdQVAdBBABUAQcGO0dGkC ICAEABdQbwGQoGxseSBsAXEgCGAnBUALgBdRZSAWUDU4AjkZ0Dk5OCBkckJhAYAuIFRoGDFJeCdt IAeAAjAX8QuAZ5AganVzF0FvIAWgcwCBBIEgdxsQGOAXUGHeaxwCBaEJcBfRdhnAAND/F+QZhBqU CqIKhAqAGwAAcAZrBCEgKVNFTFZBwyAaCvRsaTM2AUAV0B8BQBIAGHAXwRFEMTYg6i0lEk8FEGcL gAdABdDhB5BzYWdlJRMgFiQkByPxCxMkJmktMTQ04wFAI3AxODABQAzQKLOoYiBGA2E6DINiEKAo TWlrGcBTIOFkIABbU01UUDptc1krMkBjBAAFoC4FoG2+XSAVKeAGYAIwKkdXCYDCbgeQZGF5LBCw EgA/AxEZ8C7gAdApQBnQOjSQMSBQTSz3VG8qRwkGYGx2CsBhalI7ECAnSVMyYC1XR2InLPh1YmoX wSpHUhRlOitwSQCQcy130GddIEQIYGIFQAlwJmcLERwCUHQ2UENp+HJjSQsxJt8n6CN0C7ZtICNB BUAOIDoWUC9RLygwNC8voysZ8DMwPy7gMacdQCQiKkAgIz5I1wCgPLQ8pVAY4GEQcC7gOQWgdWwr YABwGMBvZvwgeQhgF1AxsAMgGaIcUP8ZwD8xNlgZYhtAAjA1wBqgDyRAK2AyYiE1Pk1JQv0a5W8z kxgiG5VCERl1LFDpNrB1aQVAVAGgGOAgBb4+GwAZwBxgK0ELESAQQN1EKnMDcBnALoBnGHAHMOsX 4yQRYyYBIAIQBcAXYvsa4BciSUnQC4ArYDylRaF9GDFuHKAdUASQQBNEx1APJCFJgAbwIAs4LjIu zjROsBegM4AtYwtgQDI4KGQpT8AGkEULSUSfHLAg4SZABCAakG9wGZMYYWRqANAJ8GN5Kb0gC1k/ cQrAGcAlcWgXRe8XYBgxS9MFQGUeoAXAIgD8TlQZZiQSTZMa8RnACQD+YyXBRVYgFFERGDFMk0ns +RmiZXgEABfgHBEx0ApB/xgiEDAFkCrwPtE10AuAHGK7GbEugHcYsSAULLFwFzDzQhFbRChiPkEr YBgBGaJ/W0Q/MRmiGHBMQUvxAQBz/icEIFesURFdZgrACIFEx/9WxyJeCoBBcGV1KtJkXyBl9j4i DyAUX2lPal9rKliF/zTUG4ALcCNwHBEjcBxhJQB7QXE01EBasCRABKAHQC7rHEADAHAEkC4ugCRw ICQPFdI+sEdgAkBwOi8v226vb7EvbRIDgS9tkguA/QIQLwQANOMjwz6wOYUSwQIAdSAAAwAQEAAA AAADABEQAAAAAB4AQhABAAAALwAAADw0LjIuMi4yMDAwMDQwNTA5MDgxNC4wMGFhZTYxMEBqYXdz LmNpc2NvLmNvbT4AAAMAgBD/////QAAHMGCYBI/cnr8BQAAIMGCYBI/cnr8BCwAAgAggBgAAAAAA wAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAI IAYAAAAAAMAAAAAAAABGAAAAAFKFAADzFQAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAA AAAeAAiACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAAAAsACYAIIAYAAAAA AMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAAuA CCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAAB AAAAAQAAAAAAAAAeAA2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAOgAgg BgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAABQAAAFJFOiAAAAAAAwAN NP03AABe0g== ------ =_NextPart_000_01BF9F0B.93ECF5A0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Apr 5 05:26:53 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07580 for ; Wed, 5 Apr 2000 05:26:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA88498; Wed, 5 Apr 2000 02:24:28 -0700 (PDT) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA88475 for ; Wed, 5 Apr 2000 02:24:26 -0700 (PDT) Received: from mshand-8kcdt (lon-sto4-lan-vlan133-dhcp45.cisco.com [144.254.108.112]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA21938; Wed, 5 Apr 2000 10:14:54 +0100 (BST) Message-Id: <4.2.2.20000405101128.00aa7ec0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Apr 2000 10:15:51 +0100 To: SelvarajR From: Mike Shand Subject: RE: [Isis-wg] Doubt regarding PtPtCircId Cc: "'ISIS-WG'" In-Reply-To: <01BF9F0B.92E98F60.selvarajr@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 14:31 05/04/2000 +0530, SelvarajR wrote: >But that section is totally left out in the 10589 1998 draft. This I'm >mentioning just to consider while taking corrective action in the draft. Which just goes to show that you should not believe ANYTHING you read in the so called 1998 draft. I think the strategy being adopted is to ignore the 1998 draft, but start with the original 1992 standard, and apply all the defect reports etc. to that. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Apr 6 17:46:16 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15493 for ; Thu, 6 Apr 2000 17:46:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA90872; Thu, 6 Apr 2000 14:47:26 -0700 (PDT) Received: from mailgate.fore.com (mailgate.fore.com [169.144.68.6]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA90843 for ; Thu, 6 Apr 2000 14:47:24 -0700 (PDT) Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA05258; Thu, 6 Apr 2000 17:38:28 -0400 (EDT) Received: from bozo.dc.fore.com (bozo.dc.fore.com [169.144.136.163]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA23442; Thu, 6 Apr 2000 17:38:31 -0400 (EDT) Date: Thu, 6 Apr 2000 17:39:06 -0400 (EDT) From: Rajesh Varadarajan X-Sender: rvaradar@localhost.localdomain To: Mike Shand cc: SelvarajR , "'ISIS-WG'" Subject: RE: [Isis-wg] Doubt regarding PtPtCircId In-Reply-To: <4.2.2.20000405101128.00aa7ec0@jaws.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This misunderstanding of using one draft vs the other has happened *multiple* times in the mailing list. It would be useful to have a pointer to the ISO document that is to be used for reference at the IETF web site or at a place which is *freely* accessible. This will for hopefully avoid this type of misunderstanding so that people know what version of the standard to implement to. For ISO liasons or WG chairs - Would ISO would make it available for use for the IETF community for *free* :) along with the defect reports that are relevant for ISIS. thanks, rajesh On Wed, 5 Apr 2000, Mike Shand wrote: > At 14:31 05/04/2000 +0530, SelvarajR wrote: > >But that section is totally left out in the 10589 1998 draft. This I'm > >mentioning just to consider while taking corrective action in the draft. > > Which just goes to show that you should not believe ANYTHING you read in > the so called 1998 draft. > > I think the strategy being adopted is to ignore the 1998 draft, but start > with the original 1992 standard, and apply all the defect reports etc. to > that. > > > Mike > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Apr 7 08:40:36 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06943 for ; Fri, 7 Apr 2000 08:40:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA91871; Fri, 7 Apr 2000 05:41:56 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA91844 for ; Fri, 7 Apr 2000 05:41:33 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 07 Apr 2000 18:11:52 +0530 Received: from saver.future ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id RAA30905 for ; Fri, 7 Apr 2000 17:51:12 +0530 Received: by localhost with Microsoft MAPI; Fri, 7 Apr 2000 18:00:16 +0530 Message-Id: <01BFA0BB.20FDDDA0.selvarajr@future.futsoft.com> From: SelvarajR Reply-To: "selvarajr@future.futsoft.com" To: "'ISIS-WG'" Date: Fri, 7 Apr 2000 18:00:11 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFA0BB.21070560" Subject: [Isis-wg] Doubt reg system type usage in Integ. ISIS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net ------ =_NextPart_000_01BFA0BB.21070560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi The Integ,ISIS MIB draft has specified three values for system type( L1(1) or L2(2) or L1AndL2 (3) ) in the system table But the Hello PDU transmission is based on whether system Type is L1 (1) ,or L2 (3) and manualCircL2Only( TRUE/FALSE) Here, if the system type is L1AndL2 ( 3 ) then no Hello be sent. The system type object in the MIB shall be defined to take only two values, L1 (1) or L2 (2). No L1AndL2 ( 3 ). I hope the MIB Draft is still Valid.. How can we handle this anomaly? SELVA ------ =_NextPart_000_01BFA0BB.21070560 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhAMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAKwAAAERvdWJ0IHJlZyBzeXN0ZW0gdHlwZSB1c2FnZSBpbiBJbnRlZy4g SVNJUwDMDgEFgAMADgAAANAHBAAHABIAAAALAAUABAEBIIADAA4AAADQBwQABwARACwAJQAFAEkB AQmAAQAhAAAARUJGMzRBOUQ3QzBDRDQxMUE4NTgwMDIwMzUxRjkyQTAAHAcBA5AGACAFAAAgAAAA CwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQDAC30EjaC/AR4AcAAB AAAAKwAAAERvdWJ0IHJlZyBzeXN0ZW0gdHlwZSB1c2FnZSBpbiBJbnRlZy4gSVNJUwAAAgFxAAEA AAAWAAAAAb+gjQR1nUrz7Qx8EdSoWAAgNR+SoAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAA AB0AAABzZWx2YXJhanJAZnV0dXJlLmZ1dHNvZnQuY29tAAAAAAMABhC3lZrsAwAHEIgBAAAeAAgQ AQAAAGUAAABISVRIRUlOVEVHLElTSVNNSUJEUkFGVEhBU1NQRUNJRklFRFRIUkVFVkFMVUVTRk9S U1lTVEVNVFlQRShMMSgxKU9STDIoMilPUkwxQU5ETDIoMykpSU5USEVTWVNURU1UQUJMAAAAAAIB CRABAAAA7QEAAOkBAAC8AgAATFpGdWkT1GIDAAoAcmNwZzEyNRYyAPgLYG4OEDAzM50B9yACpAPj AgBjaArAYHNldDAgBxMCgH05CoF1YwBQCwMLtSBIDwCgCrEKhAqAVGhlIIJJAjBlZyxJUxTAgQXQ SUIgZHJhAYDmIBEABCBzcAWQBpAIkJBkIHRoCdEgdgdAjwpQBCACEAXAc3lzFIAKbRaAeRYAKCBM MRAoMSkgBbFMMihCMhi0MUFuZBkAIPwoMxiwGLALgBaBFEAXpskBoGxlE2RCdQVAGqIISGVsCQAg UERV1xaAFWAAgG0EAWkCIBpg3QQgYhXAFmEdwXcUMBqh/ReHVBghHeITZBhwGgAYoX4sBbAgJRn0 AHAWcAOBdSEHQENpcmMZAE9uBGx5GFBUUlVFL8BGQUxTRSkTahyAdQlwLBpgZhqbH7UZlyDOMxpB GqEDoCBuHMAchGZiGsEJ8HQuE24lmm+8YmoFkAVAGnUVEnMRAH8coChCAQELgBZiHMABkGv3KnEj ARaAdxzAFvQlACCF9xjTGgAZMC4HsBzAJosoy9pJFaBvH8ErNkQVYx3xFxfAAxADIFYHQGlkLqko y0hvB+BjA5F3FED/EQAZwBuAFoEd8QBwA3EjEI4/E2oTaiPQTFZBE2QFEfEAOLAAAAADABAQAAAA AAMAERAAAAAAAwCAEP////9AAAcwQDud14qgvwFAAAgwQDud14qgvwELAACACCAGAAAAAADAAAAA AAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAA AAAAwAAAAAAAAEYAAAAAUoUAAPMVAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAB4A CIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAAADguMDQAAAAACwAJgAggBgAAAAAAwAAA AAAAAEYAAAAADoUAAAAAAAADAAqACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAC4AIIAYA AAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAMgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAAB AAAAAAAAAB4ADYAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAA6ACCAGAAAA AADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAHgA9AAEAAAABAAAAAAAAAAMADTT9NwAASgs= ------ =_NextPart_000_01BFA0BB.21070560-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Apr 7 10:08:02 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08535 for ; Fri, 7 Apr 2000 10:08:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA92015; Fri, 7 Apr 2000 07:11:26 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA91988 for ; Fri, 7 Apr 2000 07:11:23 -0700 (PDT) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id KAA32307; Fri, 7 Apr 2000 10:01:45 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Apr 2000 10:01:45 -0400 Message-ID: From: Jeff Parker To: selvarajr@future.futsoft.com, "'ISIS-WG'" Date: Fri, 7 Apr 2000 10:01:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Doubt reg system type usage in Integ. ISIS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > Hi > > The Integ,ISIS MIB draft has specified three values for > system type( L1(1) or L2(2) or L1AndL2 (3) ) in the system table > But the Hello PDU transmission is based on whether system Type is > L1 (1) ,or > L2 (3) and manualCircL2Only( TRUE/FALSE) > > Here, if the system type is L1AndL2 ( 3 ) then no Hello be sent. > > The system type object in the MIB shall be defined to take > only two values, L1 (1) or L2 (2). No L1AndL2 ( 3 ). > > I hope the MIB Draft is still Valid.. > > How can we handle this anomaly? > > SELVA Selva - As you know, L2 in line 7 above means L1AndL2. The current MIB work reflects many changes that have been deployed since the original version of 10589 was written. This is one place where existing practice and the document conflict. When implementing a system, you may decide if you wish to implement the a system that supports system type of L2 only. If not, you need not vary your implementation of the Hello Transmission. If you would like to support L2 only systemType, you will need to change the algorithm in the Hello PDU transmission in the obvious fashion. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Apr 7 11:15:53 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10162 for ; Fri, 7 Apr 2000 11:15:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA92170; Fri, 7 Apr 2000 08:19:45 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA92142 for ; Fri, 7 Apr 2000 08:19:37 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 07 Apr 2000 20:49:56 +0530 Received: from saver.future ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id UAA00914 for ; Fri, 7 Apr 2000 20:29:14 +0530 Received: by localhost with Microsoft MAPI; Fri, 7 Apr 2000 20:38:18 +0530 Message-Id: <01BFA0D1.34EFC100.selvarajr@future.futsoft.com> From: SelvarajR Reply-To: "selvarajr@future.futsoft.com" To: "'Jeff Parker'" Cc: "'ISIS-WG'" Date: Fri, 7 Apr 2000 20:38:14 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFA0D1.34EFC100" Subject: [Isis-wg] RE: Doubt reg system type usage in Integ. ISIS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net ------ =_NextPart_000_01BFA0D1.34EFC100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jeff, Thank U Thers is one mistake in my last mail. The line number 7 should have been "L2 (2) and manualCircL2Only( TRUE/FALSE)" I'm sorry. That what I like to convey is, setting 3 to system type object in system table will case problem during Hello transmission. OK , anyhow I accept ur suggestion that the implementation should decide over the algorithm. SELVA -----Original Message----- From: Jeff Parker [SMTP:jparker@nexabit.com] Sent: Friday, April 07, 2000 7:32 PM To: selvarajr@kailash.future.futsoft.com; 'ISIS-WG' Subject: RE: Doubt reg system type usage in Integ. ISIS > Hi > > The Integ,ISIS MIB draft has specified three values for > system type( L1(1) or L2(2) or L1AndL2 (3) ) in the system table > But the Hello PDU transmission is based on whether system Type is > L1 (1) ,or > L2 (3) and manualCircL2Only( TRUE/FALSE) > > Here, if the system type is L1AndL2 ( 3 ) then no Hello be sent. > > The system type object in the MIB shall be defined to take > only two values, L1 (1) or L2 (2). No L1AndL2 ( 3 ). > > I hope the MIB Draft is still Valid.. > > How can we handle this anomaly? > > SELVA Selva - As you know, L2 in line 7 above means L1AndL2. The current MIB work reflects many changes that have been deployed since the original version of 10589 was written. This is one place where existing practice and the document conflict. When implementing a system, you may decide if you wish to implement the a system that supports system type of L2 only. If not, you need not vary your implementation of the Hello Transmission. If you would like to support L2 only systemType, you will need to change the algorithm in the Hello PDU transmission in the obvious fashion. - jeff parker ------ =_NextPart_000_01BFA0D1.34EFC100 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhIPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYALAMAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAEplZmYgUGFya2VyAFNN VFAAanBhcmtlckBuZXhhYml0LmNvbQAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAFAAA AGpwYXJrZXJAbmV4YWJpdC5jb20AAwAVDAEAAAADAP4PBgAAAB4AATABAAAADgAAACdKZWZmIFBh cmtlcicAAAACAQswAQAAABkAAABTTVRQOkpQQVJLRVJATkVYQUJJVC5DT00AAAAAAwAAOQAAAAAL AEA6AAAAAAMAcToAAAAAHgD2XwEAAAAMAAAASmVmZiBQYXJrZXIAAgH3XwEAAAA9AAAAAAAAAIEr H6S+oxAZnW4A3QEPVAIAAAEASmVmZiBQYXJrZXIAU01UUABqcGFya2VyQG5leGFiaXQuY29tAAAA AAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAADEAAAAAMAADAEAAAACwAPDgAAAAACAf8P AQAAAG4AAAAAAAAAtTvCwCx3EBqhvAgAKypWwhUAAAAT3mZrXmHTEahYACA1H5KgZIgAAAAAAACB Kx+kvqMQGZ1uAN0BD1QCAAAAAElTSVMtV0cAU01UUABpc2lzLXdnQGV4dGVybmFsLmp1bmlwZXIu bmV0AAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAAB0AAABpc2lzLXdnQGV4dGVybmFsLmp1 bmlwZXIubmV0AAAAAAMAFQwCAAAAAwD+DwYAAAAeAAEwAQAAAAoAAAAnSVNJUy1XRycAAAACAQsw AQAAACIAAABTTVRQOklTSVMtV0dARVhURVJOQUwuSlVOSVBFUi5ORVQAAAADAAA5AAAAAAsAQDoB AAAAHgD2XwEAAAAIAAAASVNJUy1XRwACAfdfAQAAACwAAAC/AAAAtTvCwCx3EBqhvAgAKypWwhUA AAAT3mZrXmHTEahYACA1H5KgZIgAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAE2Z0B BIABAC8AAABSRTogRG91YnQgcmVnIHN5c3RlbSB0eXBlIHVzYWdlIGluIEludGVnLiBJU0lTAL0P AQWAAwAOAAAA0AcEAAcAFAAmAA4ABQAvAQEggAMADgAAANAHBAAHABQACQAbAAUAHwEBCYABACEA AABGMEYzNEE5RDdDMENENDExQTg1ODAwMjAzNTFGOTJBMAALBwEDkAYAOAkAACIAAAALAAIAAQAA AAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAYKTTGKOgvwEeAHAA AQAAAC8AAABSRTogRG91YnQgcmVnIHN5c3RlbSB0eXBlIHVzYWdlIGluIEludGVnLiBJU0lTAAAC AXEAAQAAABYAAAABv6CjGKqdSvP0DHwR1KhYACA1H5KgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4A HwwBAAAAHQAAAHNlbHZhcmFqckBmdXR1cmUuZnV0c29mdC5jb20AAAAAAwAGEFIcAf0DAAcQRQUA AB4ACBABAAAAZQAAAEhJSkVGRixUSEFOS1VUSEVSU0lTT05FTUlTVEFLRUlOTVlMQVNUTUFJTFRI RUxJTkVOVU1CRVI3U0hPVUxESEFWRUJFRU4iTDIoMilBTkRNQU5VQUxDSVJDTDJPTkxZKFRSVUUA AAAAAgEJEAEAAACqBQAApgUAADUJAABMWkZ1gZfW2gMACgByY3BnMTI1djIA9AH3IAKkA+MCAGOC aArAc2V0MCAHE4cCgwBQD7ZwcnEyELZmfQqACMggOwlvDjA1swKACoF1YwBQCwNjAEFFC2BuDhAw MzMLpiDQSGkgSgERLAqiCoSFCoBUEEBuayBVF6wXBJAEIAQAIAIgZSBtOwQAAZBrGkALgBpQeSCP C2AagBpQC3BsLiAZkc4gGzALgBpAbnUG0ASQJCA3HCBzaAhgbGT6IBBAdhpAHMAJ8ArjCoAWIhXB EKBMEjAoMikuIABwHYADgXUHQENpBHJjHwBPbmx5KAEb4FJVRS9GQUwYU0UpHqAXs0knbVMdIAWw cnkb0mEFQHeNIrJJHDEasXRvIAWgbm4dwBsgBAAsHSAQgHSRC4BnIDMjonN5GoAiZSIQdHlwGkBv Yr5qBZAFQBrhJWYBoGwaQPUD8GwDIGMbUBpAEgAmIJsnYCIQZAhxJOFIZSeweSPAdHIAcRphAJAC IC6xF6pPSyAkcABweR1A5wfgI0AA0GNlBTEIcB0g+HVnZweQJMACICOgIrL7LUAawW0LUCWgCfAB kCzz+x01BYFpAQAaEB3ABcAtktUHQGcFsGktQG0qSzE/4gohUExWQTGfCpAV0ucXtwswHEAzNgFA HsEKoA8DYCWQJmARRDE2IC31NsJPBRBnC4AHQAXQB5D8c2EswDbDF6Y11DWhCxPBNdZpLTE0NAFA HEA4MTgwAUAM0DpjYiBqRgNhOgyDYhCgF1IgDlAKwBqwBcBbU01UWFA6agqxPQFAGjB4ywGgMIAu BaBtXRelO5CfBmACMDv3O7AvYGF5JHDmQRIAAxEwNyRwAdA68Ekc8DozEjBQTT7nVCZvO/cQcGx2 CsBhag0+AGsboRtQaC5mdXp0CHBlRHIiMAGAPpI7ECAnSVNF0C1XRxonPuh1JjM791JFOvQgRAhg YgVACXAk8CVq9nU30hrSSQIwSJAb0EXS3zhvOXo1JAu2F7M+FxFNZjdNZhvyShMsRdIF0ElC3yig KZABgB2RBCBzJfAvUO86MAmALTEJ0SBDkApBBCAfAhAK1E2iJWkgsEwxKD4xH1AFsR8AHzJUMjFB +x+AHwIzH1AfUBrhLZImyh1NZkJEkC2DKSRQRFX7KXsZ4mIn8R2ALREi8BCA+xmhJVZUJeIZ8U1m U9AfIP1UASwFsFunVVQffyCOTg7/KSAJcCRwBpBV+1s1VPclAf9dkC2RA6AcgCPAKSQcwCSB/wIw KkVObCVvJnMtkk/yHTD/B0ADIGRRAQEcUVFRKWEaou9NZgIgIJAjoHcjwFHUJHDvXCVUMx8iG9BO I8Bii2TP7yNAHUAl8Wd2RFBDGfEs4a0nsVYHQC9gLm0/SCuh7yfgWhEaQBhxZCdhLUAZ8fcAcANx IJA/ZN4yvwZgQ4FfNrAXpQGRELAEIHkIYCD6a2PAd2rxEjAa4RxDHQD3AaAvoRpQZQYiVPUb0B41 +3YJG/JjCHAJcAIwT+NqYPs88EhxZidgJmAEIAOBGyD/EDEWMAeRLUMdohekHfMBANkLUG95UUEA kG4sEC2DXzBhN0QvsVkjRTAgFlA17Dg5IuBQoXcwcWZAKjD/eZYYYBnxGfULUX9xWjEJcP4gPjAa cSTSEgAA0CTAf3HzXbItkmRvewAuIhekI+HvfDAN4D6AHCBXY3It1yTS/3XQZhQkcHbiAMAbIC81 YSH3F6R24gPxaCOiLdcv5GYH8yKyLJBwcAkRULFmIxek3yXUPLAfAWoCeYFJPLBjwP50iRQaMFFB j9FRwSJgdtLfBcAt3BekgPFXyFQpmo+D/4qzHVMjZo01F6SPBWYFWyL/iRQnk5BjI7J9Ay/sF6RV 1e9YD1kVVeQmIHYqEEmAUjDnREGUNBeqLSAmQDyhPbQLF6QSwQCgQAAAAwAQEAAAAAADABEQAAAA AB4AQhABAAAAPQAAADxCQUM5Q0NGMDRGRUVEMzExQkQxRDAwMDYyOTUwQUJCMTIxOEQwMEBiYW5k aXRvLm5leGFiaXQuY29tPgAAAAADAIAQ/////0AABzAgwBUTn6C/AUAACDAgwBUTn6C/AQsAAIAI IAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAA AAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAA AAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4wNAAAAAALAAmA CCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAA AAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAyACCAGAAAAAADAAAAAAAAARgAA AAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAA AB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTog AAAAAAMADTT9NwAABHA= ------ =_NextPart_000_01BFA0D1.34EFC100-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Apr 20 03:58:36 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03917 for ; Thu, 20 Apr 2000 03:58:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA12164; Thu, 20 Apr 2000 01:04:13 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA12132 for ; Thu, 20 Apr 2000 01:04:09 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 20 Apr 2000 13:33:56 +0530 Received: from narenr.future.futsoft.com ([172.16.1.15]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id NAA27836 for ; Thu, 20 Apr 2000 13:11:07 +0530 Received: by localhost with Microsoft MAPI; Thu, 20 Apr 2000 13:14:50 +0530 Message-Id: <01BFAACA.68C63880.navaneethk@future.futsoft.com> From: Navaneeth K Reply-To: "navaneethk@future.futsoft.com" To: "'isis-wg@external.juniper.net'" Date: Thu, 20 Apr 2000 13:14:49 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Clarification.. Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi.. In the case of processing of the LSPs in integrated ISIS , used for IP forwarding, How are the interface addresses (4 octet Values without mask) in the TLVs used in route tabel calculation. Can any of you help out on how these i/f addresses are used? Thanx Navaneeth. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Apr 20 09:11:58 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09688 for ; Thu, 20 Apr 2000 09:11:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA12681; Thu, 20 Apr 2000 06:19:20 -0700 (PDT) Received: from lobster.baynetworks.com (ns3.BayNetworks.COM [192.32.253.3]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA12654 for ; Thu, 20 Apr 2000 06:19:17 -0700 (PDT) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id JAA18264; Thu, 20 Apr 2000 09:12:24 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id JAA04216; Thu, 20 Apr 2000 09:12:51 -0400 (EDT) Received: from fyrfytr.engeast (fyrfytr [192.32.148.63]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id JAA12138; Thu, 20 Apr 2000 09:08:03 -0400 for Received: from nortelnetworks.com by fyrfytr.engeast (SMI-8.6/SMI-SVR4) id JAA04698; Thu, 20 Apr 2000 09:08:03 -0400 Message-ID: <38FF0133.43327691@nortelnetworks.com> Date: Thu, 20 Apr 2000 09:08:03 -0400 From: Prashant Kumar X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "navaneethk@future.futsoft.com" CC: "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] Clarification.. References: <01BFAACA.68C63880.navaneethk@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hello Navaneeth, For route calculation IP Internal reachability, IP external reachability and IS reachability TLVs are used. Please refer the SPF calculation section(Dijkstra) C.1 in RFC1195. Hope this helps you. Regards, Prashant. Navaneeth K wrote: > > Hi.. > > In the case of processing of the LSPs in integrated ISIS , used for IP forwarding, > How are the interface addresses (4 octet Values without mask) in the TLVs used in route tabel calculation. > Can any of you help out on how these i/f addresses are used? > > Thanx > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- Prashant Kumar Nortel Networks Telephone : 978-288-7947(o) Billerica, MA 01821 ESN : 288-7947 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Apr 20 11:45:06 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13665 for ; Thu, 20 Apr 2000 11:45:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA12884; Thu, 20 Apr 2000 08:52:46 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA12858 for ; Thu, 20 Apr 2000 08:52:42 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 20 Apr 2000 21:22:25 +0530 Received: from narenr.future.futsoft.com ([172.16.1.15]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id UAA06181 for ; Thu, 20 Apr 2000 20:59:36 +0530 Received: by localhost with Microsoft MAPI; Thu, 20 Apr 2000 20:56:47 +0530 Message-Id: <01BFAB0A.F10F5600.navaneethk@future.futsoft.com> From: Navaneeth K Reply-To: "navaneethk@future.futsoft.com" To: "'isis-wg@external.juniper.net'" Date: Thu, 20 Apr 2000 20:56:46 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Clarification on ISIS SPF algorithm Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi, This doubt is regarding the SPF algorithm mentioned in RFC 1195 The section 8 under STEP 0: Says: " Now add systems to which the local router does not have adjacencies, but which are mentioned in neighbouring pseudonode LSPs.The adjacency for such systems is set to that of the Designated router" What does it exactly mean? When is possible that a router does not have adjacency to a system mentioned in a neighbour's pseudonode LSP? Please clarify. Thanx and regards Navaneeth. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Apr 20 13:25:12 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16483 for ; Thu, 20 Apr 2000 13:25:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA13061; Thu, 20 Apr 2000 10:32:09 -0700 (PDT) Received: from redd210.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA13030 for ; Thu, 20 Apr 2000 10:32:07 -0700 (PDT) Received: (from henk@localhost) by redd210.procket.com (8.9.3/8.9.3) id KAA14464; Thu, 20 Apr 2000 10:21:25 -0700 From: Henk Smit Message-Id: <200004201721.KAA14464@redd210.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Clarification.. To: navaneethk@future.futsoft.com Date: Thu, 20 Apr 2000 10:21:25 -0700 (PDT) Cc: isis-wg@external.juniper.net ('isis-wg@external.juniper.net') In-Reply-To: <01BFAACA.68C63880.navaneethk@future.futsoft.com> from "Navaneeth K" at Apr 20, 2000 01:14:49 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > In the case of processing of the LSPs in integrated ISIS , used for > IP forwarding, How are the interface addresses (4 octet Values > without mask) in the TLVs used in route tabel calculation. Can any > of you help out on how these i/f addresses are used? They are not used for calculating the topology. The interface IP addresses are only used to determine the IP address of the first next-hop on the path to each destination. When you build a routing table, most implementations have entries there that look like: destination IP prefix, mask, outgoing interface, next-hop IP address For p2p interfaces you don't really need the next-hop IP address, the interface should be enough info. But for LANs it is much more convenient (though in theory the MAC address of the next-hop should be enough). Hope this helps, Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Apr 20 13:28:29 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16534 for ; Thu, 20 Apr 2000 13:28:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA13123; Thu, 20 Apr 2000 10:35:32 -0700 (PDT) Received: from redd210.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA13096 for ; Thu, 20 Apr 2000 10:35:30 -0700 (PDT) Received: (from henk@localhost) by redd210.procket.com (8.9.3/8.9.3) id KAA14475; Thu, 20 Apr 2000 10:24:50 -0700 From: Henk Smit Message-Id: <200004201724.KAA14475@redd210.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Clarification on ISIS SPF algorithm To: navaneethk@future.futsoft.com Date: Thu, 20 Apr 2000 10:24:50 -0700 (PDT) Cc: isis-wg@external.juniper.net ('isis-wg@external.juniper.net') In-Reply-To: <01BFAB0A.F10F5600.navaneethk@future.futsoft.com> from "Navaneeth K" at Apr 20, 2000 08:56:46 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Under buggy conditions on a LAN. Should never happen though. Another example might be when you configure your routers to model a Frame-relay, ATM or X25 cloud as a LAN. On those NBMA WAN technologies it is more likely that when some links fail, the resulting topology might be a partial mesh. Note that even if you do the trick that you quote, routing is still broken. IMHO on NBMA networks you need to configure all VCs as p2p links. Hope this helps, Henk. > Hi, > > This doubt is regarding the SPF algorithm mentioned in RFC 1195 > > The section 8 under STEP 0: > > Says: > > " Now add systems to which the local router does not have adjacencies, but > which are mentioned in neighbouring pseudonode LSPs.The adjacency for such > systems is set to that of the Designated router" > > What does it exactly mean? When is possible that a router does not have > adjacency to a system mentioned in a neighbour's pseudonode LSP? > > Please clarify. > > Thanx and regards > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Apr 20 13:41:55 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16892 for ; Thu, 20 Apr 2000 13:41:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA13329; Thu, 20 Apr 2000 10:48:33 -0700 (PDT) Received: from redd210.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA13267 for ; Thu, 20 Apr 2000 10:48:30 -0700 (PDT) Received: (from henk@localhost) by redd210.procket.com (8.9.3/8.9.3) id KAA14550; Thu, 20 Apr 2000 10:37:51 -0700 From: Henk Smit Message-Id: <200004201737.KAA14550@redd210.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Clarification.. To: navaneethk@future.futsoft.com Date: Thu, 20 Apr 2000 10:37:50 -0700 (PDT) Cc: isis-wg@external.juniper.net In-Reply-To: <01BFAB19.54F46C60.navaneethk@future.futsoft.com> from "Navaneeth K" at Apr 20, 2000 10:39:46 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > Thanks for the reponse. > I still have one doubt.. Can we use these addresses advetised in LSP TLV's > for next hop addresses.Since these addresses have no specific mapping to > the IP reachability information. > Please correct me if I'm wrong. Ai, sorry, I was to quick in my reply. The IP interface address TLV (TLV #132) I was talking about are the IP interface address TLVs used in *hellos*. Not in LSPs. In LSPs there is the same TLV (TLV #132). But those have no practical use. And you are not supposed to use them in your routing calculations. The easiest thing is to just ignore them during your SPF computation. Sorry about the confusion, Henk. > Thanx > Navaneeth > > -----Original Message----- > From: Henk Smit [SMTP:henk@procket.com] > Sent: Thursday, April 20, 2000 10:51 PM > To: navaneethk@kailash.future.futsoft.com > Cc: 'isis-wg@external.juniper.net' > Subject: Re: [Isis-wg] Clarification.. > > > > In the case of processing of the LSPs in integrated ISIS , used for > > IP forwarding, How are the interface addresses (4 octet Values > > without mask) in the TLVs used in route tabel calculation. Can any > > of you help out on how these i/f addresses are used? > > They are not used for calculating the topology. > The interface IP addresses are only used to determine the IP address > of the first next-hop on the path to each destination. When you > build a routing table, most implementations have entries there that > look like: > destination IP prefix, mask, outgoing interface, next-hop IP address > > For p2p interfaces you don't really need the next-hop IP address, the > interface should be enough info. But for LANs it is much more convenient > (though in theory the MAC address of the next-hop should be enough). > > Hope this helps, > > Henk. > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Apr 21 06:02:39 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11119 for ; Fri, 21 Apr 2000 06:02:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA14591; Fri, 21 Apr 2000 03:08:49 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA14565 for ; Fri, 21 Apr 2000 03:08:44 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 21 Apr 2000 15:38:13 +0530 Received: from narenr.future.futsoft.com ([172.16.1.15]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id PAA23138; Fri, 21 Apr 2000 15:15:19 +0530 Received: by localhost with Microsoft MAPI; Fri, 21 Apr 2000 14:50:55 +0530 Message-Id: <01BFABA0.FF0507A0.navaneethk@future.futsoft.com> From: Navaneeth K Reply-To: "navaneethk@future.futsoft.com" To: "'Henk Smit'" Cc: "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] Clarification on ISIS SPF algorithm Date: Fri, 21 Apr 2000 14:50:53 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi Henk, Thanks for your reply. I just want to confirm this. LAN nbrs will be loaded to TENT from Adjacency table as well as from the pseudonode LSP. In the second loading, since the Nbr is already present it wont be loaded (normal LAN scenario) Eventhough this is done as a pre-caution, it is unnecessary operation most of the time. Thanks Navaneeth Under buggy conditions on a LAN. Should never happen though. Another example might be when you configure your routers to model a Frame-relay, ATM or X25 cloud as a LAN. On those NBMA WAN technologies it is more likely that when some links fail, the resulting topology might be a partial mesh. Note that even if you do the trick that you quote, routing is still broken. IMHO on NBMA networks you need to configure all VCs as p2p links. Hope this helps, Henk. > Hi, > > This doubt is regarding the SPF algorithm mentioned in RFC 1195 > > The section 8 under STEP 0: > > Says: > > " Now add systems to which the local router does not have adjacencies, but > which are mentioned in neighbouring pseudonode LSPs.The adjacency for such > systems is set to that of the Designated router" > > What does it exactly mean? When is possible that a router does not have > adjacency to a system mentioned in a neighbour's pseudonode LSP? > > Please clarify. > > Thanx and regards > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Apr 21 13:52:46 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22336 for ; Fri, 21 Apr 2000 13:52:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA15114; Fri, 21 Apr 2000 10:56:22 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA15085 for ; Fri, 21 Apr 2000 10:56:20 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id KAA01833 for ; Fri, 21 Apr 2000 10:45:42 -0700 (PDT) Received: from redd210.procket.com (flowpoint.procket.com [205.253.146.41]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id LAA20426 for ; Fri, 21 Apr 2000 11:06:47 -0700 (PDT) (envelope-from henk@Procket.com) Received: (from henk@localhost) by redd210.procket.com (8.9.3/8.9.3) id KAA16241; Fri, 21 Apr 2000 10:45:32 -0700 From: Henk Smit Message-Id: <200004211745.KAA16241@redd210.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Clarification on ISIS SPF algorithm To: navaneethk@future.futsoft.com Date: Fri, 21 Apr 2000 10:45:32 -0700 (PDT) Cc: isis-wg@juniper.net In-Reply-To: <01BFABA0.FF0507A0.navaneethk@future.futsoft.com> from "Navaneeth K" at Apr 21, 2000 02:50:53 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit That is an implementation decision. The one implementation I am familiar with only looks at the content of the LSPs during SPF, and tries to find the relevant adjacencies in the adjacency database later. Henk. > I just want to confirm this. > LAN nbrs will be loaded to TENT from Adjacency table as well > as from the pseudonode LSP. In the second loading, since the Nbr is > already present it wont be loaded (normal LAN scenario) > Eventhough this is done as a pre-caution, it is unnecessary > operation most of the time. > > Thanks > Navaneeth _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue Apr 25 03:27:31 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06770 for ; Tue, 25 Apr 2000 03:27:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA21436; Tue, 25 Apr 2000 00:29:30 -0700 (PDT) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA21409 for ; Tue, 25 Apr 2000 00:29:24 -0700 (PDT) Received: from mshand-8kcdt (lon-sto4-lan-vlan133-dhcp47.cisco.com [144.254.108.114]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA26548; Tue, 25 Apr 2000 08:17:33 +0100 (BST) Message-Id: <4.2.2.20000425080927.00ab11b0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Apr 2000 08:18:32 +0100 To: Henk Smit , navaneethk@future.futsoft.com From: Mike Shand Subject: Re: [Isis-wg] Clarification on ISIS SPF algorithm Cc: isis-wg@external.juniper.net ('isis-wg@external.juniper.net') In-Reply-To: <200004201724.KAA14475@redd210.procket.com> References: <01BFAB0A.F10F5600.navaneethk@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 10:24 20/04/2000 -0700, Henk Smit wrote: > Under buggy conditions on a LAN. Should never happen though. Strictly its not just buggy conditions, but it can happen for some period of time when a new router comes up etc. It might well acquire the adjacency to the DR and hence discover that certain other nodes are reachable via its pseudonode, before it has acquired the adjacencies to the nodes themselves. All this is doing is saying that if the pseudonode claims reachability, but you don't have an adjacency(yet), then you can always get packets to the node in question by forwarding them to the DR (since that MUST have an adjacency to the node, otherwise it wouldn't appear in its pseudonode LSP. This was more of an issue with OSI, where the endsystem adjacencies could take a few minutes to be acquired in some cases (typically you run with quite long ESH timers to keep the traffic down from potentially thousands of Endsystems, and the soliciting mechanisms don't work for all implementations.) So, bottom line is that it doesn't happen very often, and even if it does it doesn't happen for very long, but it does avoid the problem of not having an adjacency, and gets things working a little bit quicker. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Apr 26 02:59:35 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20639 for ; Wed, 26 Apr 2000 02:59:34 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA22925; Wed, 26 Apr 2000 00:06:31 -0700 (PDT) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by external.juniper.net (8.9.3/8.9.3) with SMTP id AAA22898 for ; Wed, 26 Apr 2000 00:06:28 -0700 (PDT) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <2K2J32P9>; Wed, 26 Apr 2000 08:54:59 +0200 Message-ID: <98388C05D464D111B61800805F1504160148B3FD@p-ibis.issy.cnet.fr> From: DAUVERGNE Emmanuel FTRD/DAC/ISS To: "'isis-wg@external.juniper.net'" Date: Wed, 26 Apr 2000 08:54:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] ID status ? Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi, Just a refresh regarding 2 IDs : Is the ISIS WG still concerned with OMP works? (The last ID I read was draft-ietf-isis-omp-01, and it disapeared from the IETF server) Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved to the TEWG? Regardless of subTLV specifications, what is the status of the "wider metric" concept which was introduced in that ID? Thanks Manu (by the way, I sent this email last week, but I guess it got lost because my address changed. I fixed it, but sorry if you received it twice) _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Apr 26 03:50:42 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21227 for ; Wed, 26 Apr 2000 03:50:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA23144; Wed, 26 Apr 2000 00:57:55 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA23115 for ; Wed, 26 Apr 2000 00:57:54 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.8.7) with ESMTP id AAA11859; Wed, 26 Apr 2000 00:46:38 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id JAA08951; Wed, 26 Apr 2000 09:51:47 +0200 Message-Id: <200004260751.JAA08951@kraak.procket.com> Subject: Re: [Isis-wg] ID status ? To: emmanuel.dauvergne@rd.francetelecom.fr (DAUVERGNEEmmanuelFTRD/DAC/ISS) Date: Wed, 26 Apr 2000 09:51:47 +0200 (CEST) Cc: isis-wg@external.juniper.net ('isis-wg@external.juniper.net') In-Reply-To: <98388C05D464D111B61800805F1504160148B3FD@p-ibis.issy.cnet.fr> from "DAUVERGNEEmmanuelFTRD/DAC/ISS" at Apr 26, 2000 08:54:55 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > Just a refresh regarding 2 IDs : > > Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved > to the TEWG? I am one of the two authors. There have been no significant changes to the document, so basically we could just re-submit the draft with little work. But because I changed jobs I have little time to work on the draft. > Regardless of subTLV specifications, what is the status of the "wider > metric" concept which was introduced in that ID? What do you mean by "status of the wider metric concept" ? draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links and IP prefixes, and those new TLVs have more bits for metrics. I know of at least two inter-operable implementations that are use in ISP backbones today. Hope this helps, Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Apr 26 06:10:45 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22464 for ; Wed, 26 Apr 2000 06:10:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA23503; Wed, 26 Apr 2000 03:17:13 -0700 (PDT) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by external.juniper.net (8.9.3/8.9.3) with SMTP id DAA23475 for ; Wed, 26 Apr 2000 03:16:48 -0700 (PDT) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <2K2J3L5M>; Wed, 26 Apr 2000 12:05:17 +0200 Message-ID: <98388C05D464D111B61800805F1504160148B401@p-ibis.issy.cnet.fr> From: DAUVERGNE Emmanuel FTRD/DAC/ISS Cc: "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] ID status ? Date: Wed, 26 Apr 2000 12:05:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id DAA23476 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 8bit Thanks for your replies. My comments below... -----Message d'origine----- De: Henk Smit [mailto:henk@procket.com] Date: mercredi 26 avril 2000 09:52 À: emmanuel.dauvergne@rd.francetelecom.fr Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] ID status ? > Just a refresh regarding 2 IDs : > > Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved > to the TEWG? I am one of the two authors. There have been no significant changes to the document, so basically we could just re-submit the draft with little work. But because I changed jobs I have little time to work on the draft. I'm not trying to urge you, it was just a question ;-) > Regardless of subTLV specifications, what is the status of the "wider > metric" concept which was introduced in that ID? What do you mean by "status of the wider metric concept" ? My question was not clear, sorry for that, let me detail (and correct me if I'm wrong)... Actually, I was first concerned with the up/down bit encoding : - in draft-ietf-domain-wide-02, it is suggested to encode it in the classical TLVs (128 and 130) on the high-order bit reserved of the default metric. (And the 4-byte metrics field remain a structured field). rather than, - in draft-ietf-isis-traffic-01, it is suggested to encode it in the extended TLVs, where it is encoded in the control information field. (And the 4-byte metric is a flat field) I was confused about this difference : why not using the same high-order bit in the 4-byte metric? (which would leave 31-bit for the metric value) I was also confused about the extended IS reachibility TLV which default-metric is "only" 3-byte long (and not 4-byte long). Thanks for your time Manu draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links and IP prefixes, and those new TLVs have more bits for metrics. I know of at least two inter-operable implementations that are use in ISP backbones today. Hope this helps, Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Apr 26 07:22:51 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23442 for ; Wed, 26 Apr 2000 07:22:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA23662; Wed, 26 Apr 2000 04:30:11 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA23630 for ; Wed, 26 Apr 2000 04:30:09 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.8.7) with ESMTP id EAA14751; Wed, 26 Apr 2000 04:18:52 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id NAA09309; Wed, 26 Apr 2000 13:24:00 +0200 Message-Id: <200004261124.NAA09309@kraak.procket.com> Subject: Re: [Isis-wg] ID status ? To: emmanuel.dauvergne@rd.francetelecom.fr (DAUVERGNEEmmanuelFTRD/DAC/ISS) Date: Wed, 26 Apr 2000 13:24:00 +0200 (CEST) Cc: isis-wg@external.juniper.net ('isis-wg@external.juniper.net') In-Reply-To: <98388C05D464D111B61800805F1504160148B401@p-ibis.issy.cnet.fr> from "DAUVERGNEEmmanuelFTRD/DAC/ISS" at Apr 26, 2000 12:05:06 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > Actually, I was first concerned with the up/down bit encoding : - in > draft-ietf-domain-wide-02, it is suggested to encode it in the > classical TLVs (128 and 130) on the high-order bit reserved of the > default metric. (And the 4-byte metrics field remain a structured > field). The reason for this is that some customers wanted to have L2->L1 route-leaking in the older TLVs, and preferably in a way where you only need to upgrade the L1L2 routers. With this hack of using the reserved bit in existing TLVs 128 and 130, older implementations will just ignore the up/down bit. > rather than, - in draft-ietf-isis-traffic-01, it is suggested to > encode it in the extended TLVs, where it is encoded in the control > information field. (And the 4-byte metric is a flat field) This is a cleaner way. The up/down bit has nothing to do with the metrics. So why make it part of it. We have two unused bits in the prefix-lenght field, so we could save a byte for each IP prefix by using one of these two unused bits as the up/down bit. For the other bit we found another use: indicator whether there are sub-TLVs present. > I was confused about this difference : why not using the same > high-order bit in the 4-byte metric? (which would leave 31-bit for > the metric value) Because metric and up/down bit have nothing to do with each other. And why make the metric wider, and then start nibbling bits off of it again. Yes, we could have done it that way, but we didn't. Also note that draft-ietf-isis-traffic-01.txt is older than draft-ietf-domain-wide-02.txt. And draft-ietf-isis-traffic-01.txt is in use in the Internet today, while I don't know of any ISPs (or enterprise networks) that use draft-ietf-domain-wide-02.txt today. > I was also confused about the extended IS reachibility TLV which > default-metric is "only" 3-byte long (and not 4-byte long). That was my idea. One of the problems with the TLVs in 10589 and rfc1195 is that the metrics between areas (or rather between L1 and L2) are not very useful. Link metrics are 1-63, which creates some limitations for people designing networks. But the overall result is a little less bad, as the path inside an area or inside the L2 backbone can be up to 1023. However, if your L1 path has a cost over 63, that cost can not be advertised, it has to be rounded down to 63. The problem is the fact that the added cost of the links can be way bigger than what you can advertise in a TLV 128 or 130. We wanted to prevent that from happening. So the link cost can be 2^24 at most, while the advertised total path cost can be 2^32. That way you can have 256 links with the worst cost in your network, and still maintain the path cost when advertising between L1 and L2. And the risk of overflowing a ulong of 4 bytes in your implementation is reduced as well. Hope this helps, henk. > Thanks for your time > Manu > > > > draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links > and IP prefixes, and those new TLVs have more bits for metrics. I know > of at least two inter-operable implementations that are use in ISP > backbones today. > > Hope this helps, > > Henk. > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Apr 26 12:57:47 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00150 for ; Wed, 26 Apr 2000 12:57:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA24010; Wed, 26 Apr 2000 10:03:22 -0700 (PDT) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by external.juniper.net (8.9.3/8.9.3) with SMTP id KAA23982 for ; Wed, 26 Apr 2000 10:03:19 -0700 (PDT) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <2K2J3RY1>; Wed, 26 Apr 2000 18:51:46 +0200 Message-ID: <98388C05D464D111B61800805F1504160148B402@p-ibis.issy.cnet.fr> From: DAUVERGNE Emmanuel FTRD/DAC/ISS To: "'Henk Smit'" Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] ID status ? Date: Wed, 26 Apr 2000 18:51:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id KAA23983 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 8bit Ok, thanks a lot for this explanation. Fine for me! Manu -----Message d'origine----- De: Henk Smit [mailto:henk@procket.com] Date: mercredi 26 avril 2000 13:24 À: emmanuel.dauvergne@rd.francetelecom.fr Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] ID status ? > Actually, I was first concerned with the up/down bit encoding : - in > draft-ietf-domain-wide-02, it is suggested to encode it in the > classical TLVs (128 and 130) on the high-order bit reserved of the > default metric. (And the 4-byte metrics field remain a structured > field). The reason for this is that some customers wanted to have L2->L1 route-leaking in the older TLVs, and preferably in a way where you only need to upgrade the L1L2 routers. With this hack of using the reserved bit in existing TLVs 128 and 130, older implementations will just ignore the up/down bit. > rather than, - in draft-ietf-isis-traffic-01, it is suggested to > encode it in the extended TLVs, where it is encoded in the control > information field. (And the 4-byte metric is a flat field) This is a cleaner way. The up/down bit has nothing to do with the metrics. So why make it part of it. We have two unused bits in the prefix-lenght field, so we could save a byte for each IP prefix by using one of these two unused bits as the up/down bit. For the other bit we found another use: indicator whether there are sub-TLVs present. > I was confused about this difference : why not using the same > high-order bit in the 4-byte metric? (which would leave 31-bit for > the metric value) Because metric and up/down bit have nothing to do with each other. And why make the metric wider, and then start nibbling bits off of it again. Yes, we could have done it that way, but we didn't. Also note that draft-ietf-isis-traffic-01.txt is older than draft-ietf-domain-wide-02.txt. And draft-ietf-isis-traffic-01.txt is in use in the Internet today, while I don't know of any ISPs (or enterprise networks) that use draft-ietf-domain-wide-02.txt today. > I was also confused about the extended IS reachibility TLV which > default-metric is "only" 3-byte long (and not 4-byte long). That was my idea. One of the problems with the TLVs in 10589 and rfc1195 is that the metrics between areas (or rather between L1 and L2) are not very useful. Link metrics are 1-63, which creates some limitations for people designing networks. But the overall result is a little less bad, as the path inside an area or inside the L2 backbone can be up to 1023. However, if your L1 path has a cost over 63, that cost can not be advertised, it has to be rounded down to 63. The problem is the fact that the added cost of the links can be way bigger than what you can advertise in a TLV 128 or 130. We wanted to prevent that from happening. So the link cost can be 2^24 at most, while the advertised total path cost can be 2^32. That way you can have 256 links with the worst cost in your network, and still maintain the path cost when advertising between L1 and L2. And the risk of overflowing a ulong of 4 bytes in your implementation is reduced as well. Hope this helps, henk. > Thanks for your time > Manu > > > > draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links > and IP prefixes, and those new TLVs have more bits for metrics. I know > of at least two inter-operable implementations that are use in ISP > backbones today. > > Hope this helps, > > Henk. > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg